Yet another global- or App-level saga discussion :-/

[marcandrews]

To not take away anything from @RobertSheaO's amazing work in PR #1545, I created this issue to continue a discussion about where the code for global- or app-level sagas should reside.

In response to @gihrig's comment ...

In this case, we're using sagas, but no matter which method you choose to manage side-effects, there is still the issue of where the code for "global" side-effects reside.

The three places where this code could reside (summarized by the issue numbers @gihrig listed in his comment), seem to be:

1. Define your actions/reducer/sagas/selectors anywhere in your project, and then inject these sagas along with each route.
2. Define your actions/reducer/sagas/selectors in /app/containers/App and inject these sagas in a root-level component route (like this PR).
3. Define your actions/reducer/sagas/selectors in their own container. For example, for authentication purposes, these would be defined in /app/containers/SessionProvider similar to how /app/containers/LanguageProvider is defined. Then, this SessionProvider is imported into /app/app.js and included in the ReactDOM.render method (just like the LanguageProvidor).

(1) seems cumbersome.

(2) seems like a better approach, but something like session information and components related to session like sign in interface and account management may clutter the App container (which may be better suited to presentation only). This is where I am in my own project: an App container with it's defined role unclear. So if I move the sign in/account management into their own container, then those sagas should go with them. This leads me to:

(3), a completely modular solution to the problem. My authentication actions/reducer/sagas/selectors are defined in /app/containers/SessionProvider, along with all the UI components and additional state necessary session management. This leaves the App container for presentation only, and in the future, I can easily remove/replace/refactor this provider without having to tease it away from the App container.

Looking forward to any input on this.

[sbruton]

given that the SessionProvider container isn't mapped to a route, where are you injecting the sagas?

[marcandrews]

@sbruton I imported my session provider saga in app/app.js right after the store is initialized:

import SessionProviderSagas from 'containers/SessionProvider/sagas';
...
export const store = configureStore(initialState, browserHistory);

SessionProviderSagas.map(store.runSaga);

[kai23]

Do you have any full example of this ?

[gretzky]

Closing due to inactivity

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.