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?

[markerikson]

My honest response is to not worry about that whatsoever :)

As a general rule of thumb, trying to apply backend/OOP-inspired architectural patterns on the client-side is questionable in the first place. The concepts are not completely useless, but they're also not relevant enough and there's an impedance mismatch.

As of.... 1.6-ish? RTK does some clever work internally to allow slices to import and reference each other while mostly avoiding circular import errors.

Beyond that:

I don't see actions as an "abstraction". Conceptually, Redux's use of combineReducers is more of an event emitter pattern, where any slice reducer can listen and respond to the actions it cares about.

That said, historically 95% (hand-wave-y fake stat, but accurate) of actions are only ever handled by one slice reducer. So, createSlice was designed to optimize for the common case of "here's a reducer, and also we'll auto-generate the action you need to dispatch to trigger running that reducer".

Overall, it's valid to define standalone action types that are handled by multiple slices, and it's also valid to have slice B importing an action from slice A and handling that

[EskiMojo14]

here's a quick demo to prove slices can import each other: https://codesandbox.io/p/devbox/rtk-linked-normalized-states-mmrfyt?file=%2Fsrc%2Fslices%2Fcomments.ts
check comments.ts and posts.ts :)