11

I am trying to create a small project to implement micro-frontend architecture following Micro Frontends article. I am creating multiple repositories for each MFE(Micro frontend) and also using Redux for the application. I have the following architecture:

  1. Frame - A centralised(main) repo that is responsible for rendering the main application part and MFEs based on routing(I am using connected-react-router). It initialises the Redux store and also adds an injectReducer function to dynamically add reducers as explained in code splitting in redux docs. The frame fetches the manifest for particular MFE and renders it. The frame also has some redux data for authentication purpose.
  2. MFEs - These are the individual feature-wise application and are rendered by frame.

Now I have a problem that I want to use injectReducer function into my MFEs to dynamically add reducers to store. For this, I need access to the same store instance that is created by frame. As mentioned in this answer, the ideal way is to export the created store instance and use it but how we can share the same instance of the store across multiple repos?

aditya81070
  • 678
  • 1
  • 5
  • 22

3 Answers3

9

There is a comment in the article addressing this directly:

If you are using redux, the usual approach is to have a single, global, shared store for the entire application. However, if each micro frontend is supposed to be its own self-contained application, then it makes sense for each one to have its own redux store. The redux docs even mention "isolating a Redux app as a component in a bigger application" as a valid reason to have multiple stores.

Long story short: Don't share your redux store

Sharing anything between your micro frontends no longer makes them separate entities and defeats the entire purpose of it. Now it's just an overengineered monolith. Just turn those respective repos into well-defined modules inside a monolith repo. It is still possible to split responsibilities into their own silos in a unified repo. It just takes more discipline.

Andrew
  • 7,201
  • 5
  • 25
  • 34
  • I understood your point that if each MF is self-contained then it is good to have multiple stores. But it will arise one more problem. Suppose a situation in which my frame have some data (user or client info) that will be used in APIs used in MFEs. Then how I will get the data from frame's store? ( I think you can only access data from nearest Redux provider) – aditya81070 Jul 13 '20 at 05:00
  • One more case is there that we need to know about all the reducers for each MFEs beforehand into the frame. – aditya81070 Jul 13 '20 at 05:03
  • The article even talks about the use case - multiple parallel teams. They should not be sharing _anything_. If they need the same data, then they should independently make service calls and manage their own stores. You 're trying to have the benefits of MFEs but do not want to adhere to design paradigms that are necessary to make them work to begin with – Andrew Jul 16 '20 at 20:12
  • The MFEs are not sharing data between each other. Even if you have 100MFEs, there will be one application responsible for controlling all of those for example when to render a specific MFEs. Some data obviously need to be shared between this application and MFEs. Do you mean that instead of sharing the store, I should send the data to individual MFEs via props or context? By this we can remove redux store(shared) and each MFE can have its own individual store and can also store this shared data if it wants? – aditya81070 Jul 21 '20 at 11:28
  • I'm interested in this as well. I agree with what @aditya81070 is saying.... What if in the frame/container that hosts all the MFs need a login to get auth state? And then that auth state is given to all the MFs that need it in order to make further requests? It wouldn't make sense for each MF to have to log in each time in order to be authenticated right? – Kabu Oct 20 '20 at 19:43
  • @Wayne Auth credentials shouldn't be living in react at all. What auth strategy are you using? Shouldn't your credentials exist in cookies or `localStorage`? You can access that resource from any MFE. What other use cases do you have that would require shared resources that must exist in react's data ecosystem? I imagine MFE places more burden on information being stored server-side to mitigate the consequences of complete decoupling when using MFEs – Andrew Oct 21 '20 at 17:06
  • @Andrew The one simple use-case is that when your application allows users to login into a different account in different tabs. In that case, keeping the authentication state like the current account in the redux is more flexible than keeping it in the local storage. – aditya81070 May 24 '21 at 17:55
  • 1
    @aditya81070 Of all the websites you frequent, what percentage of them implement tab-specific sessions? That's not a real-world use case for production applications. Keep session information in the backend. These types of use cases have different solutions that make more sense – Andrew May 24 '21 at 18:40
4

Use synthetic events for cross micro frontends communication using eventListeners and CustomEvent like below:

MF-1:

function Cart() {
  const [cartItems, addCartItems] = useState([]);

  const handleAddToCart = (event) => {
    addCartItems((currentItems) => [...currentItems,
    event.detail.item]);
  };

  useEffect(() => {
    window.addEventListener('addToCart', handleAddToCart);

    return () => {
      window.removeEventListener('addToCart', handleAddToCart)
    }
  }, [handleAddToCart]);
  ...
}

MF-2:

function itemLookUp() {
  const handleSubmit = (item) => {
    const customEvent = new CustomEvent('message', { detail: item });
    window.dispatchEvent(customEvent)
  }
  ...
}
rmlockerd
  • 3,776
  • 2
  • 15
  • 25
  • 1
    Welcome to SO. When posting an answer to an older question that already has answers, please try and explain why yours is different or an improvement on the others. – rmlockerd Aug 06 '21 at 20:43
  • This is clearly better because it maintains decoupling using a pub-sub architecture. And there is no answer here that I can see. +1 – Jordan Dec 14 '22 at 14:47
3

You can take a look at this NPM package. This package would allow each Micro Frontend to have its own redux store but allow other Micro Frontends to see and subscribe to state changes of other Micro Frontends.

Github
https://github.com/microsoft/redux-micro-frontend

NPM
https://www.npmjs.com/package/redux-micro-frontend

Article
https://www.codezap.dev/post/state-management-ii-world-of-micro-frontends

Might solve your problem.

Pratik Bhattacharya
  • 3,596
  • 2
  • 32
  • 60
  • Is it possible to use microsoft redux frontend in share point for state management across webparts in the same site? @Pratik – Sharun Sep 03 '21 at 14:12
  • Hi @Sharun, we haven't used this library in Sharepoint, but there shouldn't be any issue in using this. Since you can use Redux in Sharepoint, this lib can also be used. – Pratik Bhattacharya Sep 03 '21 at 15:16
  • I'm using this and i think is the best way to share store between apps. – jics Jun 20 '22 at 17:22