How to provide application wide entities in decoupled modules

Client
1

Hi there,

I think about reusing a module (for the module registry of the client) of one project in another project. As far as the general integration goes, it doesn’t seem to be a big deal to provide a package with the module which I can import afterwards. But how do I ensure that the module itself is fully decoupled from the parent application if it uses application wide entities like a specific selector or a react component which is used by other modules too?

Here an example for a better understanding:

  1. I have two projects Foo and Bar
  2. Foo has a module Baz which is almost fully decoupled from the rest of the application. But it uses a selector - which is not part of the module - to access the application wide theme state which I then use in styled components to tweak the styling if needed
  3. If I would add Baz to Bar, the selector for the theme would be missing
  4. At the same time Bar has also a theme state but a different selector to access it which can’t be used by Baz either

(A similar example would be providing a test mode flag or a wrapper component for an engine which contains some specific styles.)

So how can I create a reusable module and, at the same time, provide application wide entities without the need of keeping copies of them on module level?

Up until now several potential solutions came to my mind:

  • Provide “core” module which has actions, reducer and selector for the theme → overkill to create an own repo for just this amount of functionality
  • Somehow provide a selector as a prop into the module to make components use this one to get the theme that’s somewhere in the state → doesn’t feel right at all to me
  • Module references that information from a context instead of the store and requires the parent application to add a provider to the app page → Inconsistent that one module receives the theme information from a context and the other ones from the store but at least it’s easy to achieve and somehow feels like an A12 way by using a provider

If someone has another clever idea, I would be quite happy to hear about it :slight_smile: Maybe there’s even a best practice in A12 I don’t know about.

2

Hi @steve-windy-mist,

I don’t think that you second point is such a bad idea:

Somehow provide a selector as a prop into the module to make components use this one to get the theme that’s somewhere in the state → doesn’t feel right at all to me

If your decoupled module does make use of a module provider or factory pattern, it is a good way to go to handover specific selector function, as configuration parameter of your module.

your module itself then only contains a selector that provides the expected args and return types and just do a call on the selector handed over by configuration.