The code given in this plunker works fine even when changed with subscribe in the beta version 50. But this does not work when the classes are put in separate files and exported.
How to have the classes in separate files and use broadcaster to reflect change in data.
http://plnkr.co/edit/URXycFe3njtMKGmHrz9W?p=preview
broadcaster.subscribe(
data=>{ generatedNumber => this.receivedNumber = generatedNumber}
);
To communicate between components, you need to use a shared service containing an observable / subject. You can send an event that will be received by all components that subscribe to it.
You need to be careful to share the same instance. For this, specify the service provider into the main component of your application.
See this doc for more details:
https://angular.io/docs/ts/latest/cookbook/component-communication.html#!#bidirectional-service
Related
TLDR; How to use a single context between react micro frontends?
The application is divided into multiple Microfrontends or react apps. Each of these is running on a different port. A container is hosting other Micrfrontends. Each one is a separate react app and it is a runtime integration. (I have used martinfowler example to implement micro frontend)
Currently passing some data via URL and browser storage (localStorage/cookies) to other Microfrontends.
I need to pass the data across these react apps (MFEs) using React Context.
I have defined ReactContext Provider in Container (ReactApp1) and stored value (say color=black). To access this color inside the lower level Microfrontend (ReactApp2) we need the context to be available from any micro frontend. How to make it available?
(NOTE: I don't want to use localStorage or cookies for global data sharing)
<Container>
<LowerLevelMFE1/>
<LowerLevelMFE2/>
...
</Container>
Webpack 5's Module Federation & ModuleFederationPlugin is the best way I've found to achieve this architectural pattern.
In essence you create a "host" application that wraps the React.context around a "remote" component. This "remote" is actually another component in a standalone application that is being exposed as a remote through its webpack config file. In this 2nd application you would consume the context as normal using React.useContext.
You can find a full example of this setup here on github.
A few things to note:
Both applications will need to consume this Context's source code so moving it into its own package is preferred.
Your Context consuming application will still need, what I call in MFEs, "developer scaffolding". In this case that would be a simple component that wraps your <ContextConsumer /> in a <ContextProvider /> that you are importing from your shared Context package I mentioned in 1.
Remember this app with scaffolding is only exposing the <ContextConsumer /> which you need to make sure to specify in the webpack config.
I think sharing context between Micro-frontends is an anti-pattern and should be avoided if you can. If you use context to share data, you will automatically couple the MFes that depend on the context, eliminating the benefits of independent deployments by introducing coordination and a dependency.
My advice is that each micro-frontend loads the data they need and if there is communication need it, you need an api or a contract to handle this communication.
I think if you need that type of comunication between the mfe's then they are splited wrong.
As Ruben says, is an anti pattern.
My website is built with Angular2. Imagine it as a big dashboard with a lot of modules. Sometimes information from multiple modules are required at the same time - therefore I want to allow my users to open a module in a new window. A real-world example for this is the video container of Hangout.
From my research there would be 2 ways to do this:
I open the route of the selected Ng-Component in a new window. As a result angular would reinit all services. To keep my data consistent I would need find a way to sync the instances. Maybe some kind of service that writes all attributes to localStorage?
This is somehow the way GoldenLayout implemented the Popouts.
I could init my component in window A and hide it - Now open a new window (B) and pass a copy (Css, HTML, Data) of my component to it. This would mean that I only need to sync the mirrored component, but I am not sure if this is good architecture.
Which way would you go to solve the described problem and are there more elegant solutions?
Can I create a pub/sub message message queue with RxJS inside angulajs application. I have for example two modules:
ModuleA
ModuleB
They exists as separate npm package but connected in ModuleC - it's the main shell.
I don't want to create a dependency as ModuleD and create a tight coupling between the modules. So my thought is to create a message bus using RxJS.
Is it possible?
I presume an API will look like that:
RxQueue.subscribe("name:of:the:queuemessage", handler => { handler.result } );
RxQueue.create("name:of:the:queuemessage", (observer) => {
// implementation of usual Rx subscribtion
})
I think this might be closest to what you are asking for:
rxmqjs/rxmq.js: JavaScript pub/sub library based on RxJS
https://github.com/rxmqjs/rxmq.js
https://www.npmjs.com/package/rxmq
Not angular specific, but I consider that a good thing.
It might not be exactly what you are looking for but for sharing state and data between different components and modules, you could use redux/ngrx-store.
Redux is an architecture in which you can send state to a store. The store will update itself and notify everyone listening to it if something has changed.
So your modules could both subscribe to the store and listen to events. If they want to communicate, they could send a message to the store. The store would then notify everyone listening if something has changed.
One difference is that this store object will actually store this object as a temp database would. This isn't really queue behaviour.
Checkout http://redux.js.org/ for more information.
I am trying to create a service for showing alerts (in case sending a form goes wrong). This will be used on various forms of my project so I thought I could use an independant service for this. The problem is: for this alert I need HTML code at a certain place of my form, so what I need to know is : what's best practice for that?
Can I define a template for my service? And how do I use this template in my form wihch uses the service?
I had a difficult time using angular2 packages for notifications then I decided to create my own notification for a system I'm working on. I scrapped online till I found Mathew Ross' Post Check it out and see if it guides you, somehow.
If showing alerts means showing a popup then it should be a component. Components have a view that is added to the DOM.
You can share a global service that allows other components, directives and services to communicate with your AlertsComponent and pass strings or component types to be shown in the alert. For more details see https://angular.io/docs/ts/latest/cookbook/component-communication.html
I would use ViewContainerRef.createComponent() like demonstrated in Angular 2 dynamic tabs with user-click chosen components to display arbitrary components as content of the alert if you need custom HTML support with Angular bindings in the alert content.
I am trying to understand singleton pattern.
I write a lot of code in angular and recently I wanted to refactor some of my code and move it to a common place which can be shared by different controllers.So I moved all common utils to my services.
Now the documentation over here says that angular services are singletons but I want to understand the reason behind having singleton pattern here ? Why not have multiple instances of the service object instead of passing references to controllers ?
It all falls in the name "Service". Service, acts like a medium to communicate between controllers or even directives for that matter. Not only for communication, you can add a set of utility functions in your service, which can be used throughout the module/app. This does not need to have multiple instances to serve the purpose. Hence, singleton.
Angular services are the recommended way to exchange data and communicate between controllers. In order therefore to allow this data exchange, services are singleton objects which means that you are guaranteed to have the same service reference between all your controllers.
As an example, imagine that you have an Angular application that displays a list of messages received from another user in the center of the page, as well as the number of received messages or new message notifications in the header. The header and the page content will most probably be under different scopes and be handled by different controllers. In order for these two controllers to have the same view of messages received and be able to display them consistently they will need to use a singleton object holding this information. This object is an Angular service.