Feature - Add web element for sharing state about elements HOT 5 CLOSED

@angelfraga thnak you for the elaborate description of your use case, now I finnaly understand what are you trying to achieve!

The main goal of this library is to allow simple and seamless usage of lazy laoded elements as any other component inside of an Angular shell, that means we want to be able to use standard Angular template bindings like <my-org-document-manager [contextId]="contextId" (documentChange)="handleChange($event)">. This template binding is Angular specific.

As far as I understand react does NOT allow us to bind to custom HTML events like documentChange using standard react approaches as it uses syntetic event system which simulates the DOM but is not the DOM...

For that reason I would recommend proceeding with global registry but using it imperativaly inside of react micro-apps... eg check registry and if it was not there then load and bind elements properties and events imperativaly...

Unfortunatelly mi knowledge of Vue is lacking so I dont know how it would work there...

In general it might be nice to have similar or even fully generic library to do this for every framework but as stated above this library optimizes for ANgular with its nice template bindings...

Hope this answer clarified it also for you and wish you good luck with your apps!

And hope you will keep using library in the future! 😉

from elements.

Hi @angelfraga !

Can you please provide more details about: "web element (root-axLazyElement) that can be used instead of the directive or the current axLazyElement component."

ad I am not sure if I can follow there ?

from elements.

@tomastrajan let say we have the main app (aka shell) and two web elements(A, B) which are supposed to be loaded thanks to the @angular-extensions/elements.

Then shell & A need include web element B, each bundle (shell and A) has its own @angular-extensions/elements instance and we can not prevent loading B twice since we will have two registries.

Recently @angular-extensions/elements releases a feature that allows the use of custom registry service. That is great because it allows us to decided how to share and maintain that registry.

But @angular-extensions/elements doesn't give a generic way to avoiding that shell & A load B web element twice.

I think whether the Shell @angular-extensions/elements instance registers a custom element root-axLazyElement as a wrapper for the current axLazyElement , A could use this root-axLazyElement instead of its own axLazyElement making possible in somehow reuse the registry from the shell.

Please correct me if am missing something or am wrong with this theory.

from elements.

@angelfraga but as you said yourself, you can implement global registry right ? So with global registry, once something was added it will not be downloaded again, so what would this new feature bring which can not yet be achieved with a global registry ?

from elements.

@tomastrajan thanks for the answer, you are right, maybe this feature is very close to my specific case and it doesn't fit the most cases where the custom registry is enough 😃 .

I am playing around with https://github.com/manfredsteyer/angular-microapp + @angular-extensions/elements ). I built a custom registry based on a global variable and was fine for shell & micro-app written in angular. But when I want to load a micro-app written with another framework then I would have to install another tool for that framework, and then connect it with the root custom registry.

In my case, I loaded a micro-app written in react which also needs to load web elements. The motivation was making possible load elements in the react micro-app using the existing @angular-extensions/elements since the shell is written in angular.

Then, i was asking me if I would need to write another x-extension/elements or maybe move to vanilla javascript the base implementation and then create react-extension/elements, vuejs-extension/elements & angularjs-extension/elements wrappers.

Or just offer this web element from the shell thanks to @angular-extensions/elements new feature described here.

Anyway thanks for having a look to this issue, please close it if you feel it doesn't fit with the main goal of the library.

from elements.