Implement @nnotations, dependency injection, fragments & extensions

[as-shura]

Greetings I find this project amazing and would like to propose some development directions.

there are already other projects that have some features already implemented and I will list them as follow:

• https://github.com/lorry2018/minimajs
• https://github.com/cescoffier/hubu/

For the documentation concerning @nnotations:

https://docs.osgi.org/javadoc/osgi.cmpn/7.0.0/org/osgi/service/component/annotations/Component.html

If you would like to have an already usable framework that has @nnotations & dependency injection I recommend you check Inversify. It is already used by the Eclipse Theia project and have extensions already implemented for UI development like in Eclipse IDE.

https://inversify.io/

Maybe this can be a good roadmap.

Best Regards

[as-shura]

This could be related with this thread : #12

Any feedback on this?

[noherczeg]

@as-shura sorry for the late response. We are aware of inversify, but Pandino is pretty different. One of the key differences is the life cycle handling. While traditional DI tools provide a "one-off" wiring with imports and references to classes / constants, Pandino is completely decoupled, and supports the coming and going of bundles and services.

[noherczeg]

Another challenge for us is, that sadly there is not even an RFC in the ECMA standard which covers functions, and support for decorating them. We are currently focusing on supporting functional programming.

[as-shura]

Another challenge for us is, that sadly there is not even an RFC in the ECMA standard which covers functions, and support for decorating them. We are currently focusing on supporting functional programming.

There is such thing already like in Actionscript MetaDatas you have some similar mechanisms in TypeScript with Decorators/Annotations alike Java.

https://www.beyondjava.net/typescript-and-es2016-decorators-vs-java-annotations

[noherczeg]

Sorry there could be a misunderstanding. We know, that ES has decorators, our "problem" is that we would like to be able to implement #12 in a way, where the decorators are as light as possible. Also: we are currently working with mostly React codebases, and since it means everything is a function, we cannot decorate React hooks / FC-s.

The reason for this is, that in a "Traditional" DI app, the decorators are classes/functions and are code split into some chunk in the application code. In Pandino, bundles do not contain any runtime code related to the OSGi runtime. Everything is decoupled.

Since interfaces are not native ES citizens, we currently rely on string -> interface pairing. Although this is not error-prone if the same interface has a different version (since strings are inlined into bundled code), at least we do not rely on bundled classes / functions. At least for now.

Long story short, we will have a go again with #12 in the near future, but it's not a trivial topic, unless we "give up" on current architectural values.

[as-shura]

Well when you depend on React it is somehow how a bottleneck isn't it? All the other frameworks I listed are UI framework independant.

[noherczeg]

Pandino has 0 dependencies on any third party library. All I meant by the React reference is that when it comes to plugin/module/extension development, we've been focusing on React hooks, and gathering feedback on such "extensions".

Given that we seem to have potential client for #12 I'll look into it right now. You peaked my interest ;)