• Home
  • Blog
  • Micro frontends. How to manage the state of apps – Eventrix


17.06.2021 - Read in 3 min.

Micro frontends. How to manage the state of apps – Eventrix

17.06.2021 - Read in 3 min.

What do micro frontends look like? It is just dividing apps into independent services that feed particular data to our modules, allowing for communication with a given domain in our application. See how Eventrix can help in managing the global state.

Micro frontends. How to manage the state of apps – Eventrix
5/5 - (2 votes)

In other words, micro frontends provide us with many services, each of them with their individual responsibilities. Our modules, or separate parts of an app, use one or many services in order to present data in a way that is transparent and understandable to the user. It all seems simple and easy but what about information that needs to be kept in a global state and is used in many modules or components? This makes us store our data in a global state in which they can be shared by services and modules of our application. This necessity prompted me to create Eventrix.

Eventrix – a library for managing a global state

If you need to manage a state that is shared between services and components in an app, Eventrix is the best solution available. Similar to a message broker for fronted with an addition allowing to manage the global states, it also enables these elements to communicate through events.  

To cut long story short, Eventrix is shared within all services and modules, thus allowing them to communicate with each other. Services are responsible for receiving events and modifying their state, while components not only reload when the state changes but they also emit events.

The entire architecture is based on 4 elements:

  • state – a global state of an application managed by stateManager in the instance of Eventri,. StateManager emits events about the change of a state,
  • receiver – a receiver of events that can modify the state thanks to access to stateManager after registering it in the instance of Eventrix,
  • listener – scans for events in the instance of Eventrix in order to perform other actions,
  • emitter – emits events through the instance of Eventrix.

These elements allow for communication between services and components in an app. According to the main assumption, services are supposed to register their receivers that would be responsible for receiving data from the server and transferring them to the global state. It is obvious that a receiver activates when it records an event that it is scanning for. Components should be tasked with emitting events and scanning for changes of the state as well as other emitted events.


Select a library that has more advantages than disadvantages

What does Eventrix have to offer that other solutions allowing to manage the global state fail to provide?

The first significant difference is the fact that Eventrix informs about the change of the state and defines the state that has changed. Thanks to this components are able to scan for particular states and be rendered only when the state they are scanning for is modified.

Another advantage is that components can communicate with each other through events. Wherever components are located in the structure of an application, Eventrix allows them to send events and scan for them.

Last but not least, in this architecture modules and services are not directly dependant on one another as they both scan for events and emit them.  If something is not loaded, they will not emit events or scan for them, making us lose some functionalities, but the remaining elements of the app will function properly.


Eventrix has certain disadvantages, though. One of them is the necessity to keep the names of events in one place and make sure that the names are in line with one naming convention. It might be somewhat problematic as there are loads of events in a large application. Therefore, it might be a good idea to divide events by domains so that it is easier to define their origin or target group. With many applications the number of events might be somewhat overwhelming, but still manageable.



  • encapsulated functionalities
  • possibility of creating independent generic solutions
  • little code to write
  • developing tool that supports optimisation
  • scanning only for what is important for a particular component
  • communication between components or services



  • names of events must be unique.


If you want to see how to use the Eventrix library step by step, go to.

To learn more about microservices read an article by Andrzej Lewandowski:

Microservices – architecture based on microservices. 


Article notes

5/5 - (2 votes)


RST Software Mariusz Przodała

Mariusz Przodała

Frontend Technical Architect

An experienced Technical Team Leader passionate about his work. A dedicated programmer who loves creating innovative solutions and cracking complex problems. He uses every opportunity to share his knowledge and help other people. Privately he is a military and shooting enthusiast. 

Our website uses cookies to work correctly. Using this website with current settings means that cookies will be stored in the browser’s memory. Cookies settings can be changed in the browser’s options. For more information please visit Cookies policy.