So I'm experimenting with ngrx & ngrx/effects by building the following sandbox:
https://stackblitz.com/edit/ngrx-vanilla
Quick intro:
- it has a root store in app/store
- it has lazy loading of two modules in app/features
- it has singleton services in app/commons
Three pages:
- action items: routing to this pages triggers a random generation of three goofy corporate action items
- users: a basic master > detail redux implementation with router support
- meeting: the place that raises my question, click the "start meeting" to witness a relevant exchange of ideas.
Question & context:
- I understand all data updates in redux are to happen via actions
- the "effects" library is to handle async events in order to dispatch new actions based on 3rd party events and async calls.
- the app/common/meeting/service imitates the behavior of for instance a websocket or a firebase realtime DB pushing updates.
Upon receiving an update (illustrated in app/store/effects/meeting.effects.ts), a new action is dispatched.
Finally, the question: Is it a clean practice to have a a common service know about the store? Where is the best place to register a listener to a websocket / firebase realtime db in order to dispatch actions upon data being pushed?
Here, I made it so that an effect (meeting.effects) reacts upon the meetingActions.START_MEETING action type and whenever data is pushed, dispatch an update order to the store, but this feels wrong for a series of reasons I come up with:
- Hard to unit test in isolation (needs more context than itself)
- In case of a "stop meeting" action, this approach needs to store a Subscription (or?) in order to stop the subscription. In my approach, there's no control over the observable being created in the wilderness.
How are such cases usually handled?