Slices and Dependency Inversion (D from SOLID)

[simprl]

Hi Redux Toolkit team,

I’m working with Redux slices and encountered some architectural questions regarding SOLID principles and Dependency Inversion Principle.

For example, I have two slices: Application (which manages core app logic) and Notifications (which handles displaying notifications). Sometimes, Application needs to trigger a notification in Notifications. In previous Redux patterns, we had actions as abstractions and reducers as implementations, which helped avoid circular dependencies by using actions as a common interface. But with slices, actions and reducers are now combined in the same file, so there’s less separation between abstraction and implementation.

On the Redux Toolkit documentation site, it’s recommended to extract common actions into a separate slice to prevent circular dependencies between slices. However, if I create a “shared actions” slice, this new slice itself wouldn’t fully follow the Dependency Inversion Principle, which states that high-level modules should not depend on low-level modules. In this case, the “shared actions” slice essentially becomes a low-level module, and having high-level slices like Application depend on it seems to break this principle.

My questions are:

Should we be applying SOLID principles, like Dependency Inversion, when working with slices in Redux Toolkit? Or is it acceptable to have high-level slices directly depend on “shared actions” even if they’re considered low-level?