title: Advice on this Angular + ngRx (effects) - what about websocket events?
body: <p>So I'm experimenting with ngrx &amp; ngrx/effects by building the following sandbox:</p>
  
  <p><a href="https://stackblitz.com/edit/ngrx-vanilla" rel="noreferrer">https://stackblitz.com/edit/ngrx-vanilla</a></p>
  
  <p>Quick intro:</p>
  
  <ul>
  <li>it has a root store in app/store</li>
  <li>it has lazy loading of two modules in app/features</li>
  <li>it has singleton services in app/commons</li>
  </ul>
  
  <p>Three pages:</p>
  
  <ul>
  <li>action items: routing to this pages triggers a random generation of three goofy corporate action items</li>
  <li>users: a basic master > detail redux implementation with router support</li>
  <li>meeting: the place that raises my question, click the "start meeting" to witness a relevant exchange of ideas.</li>
  </ul>
  
  <p>Question &amp; context:</p>
  
  <ul>
  <li>I understand all data updates in redux are to happen via actions</li>
  <li>the "effects" library is to handle async events in order to dispatch new actions based on 3rd party events and async calls.</li>
  <li>the app/common/meeting/service imitates the behavior of for instance a websocket or a firebase realtime DB pushing updates.</li>
  </ul>
  
  <p>Upon receiving an update (illustrated in app/store/effects/meeting.effects.ts), a new action is dispatched.</p>
  
  <p>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?</p>
  
  <p>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:</p>
  
  <ul>
  <li>Hard to unit test in isolation (needs more context than itself)</li>
  <li>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.</li>
  </ul>
  
  <p>How are such cases usually handled?</p>