An RxJs observable is like a promise that can be interrupted by a new emission in the stream.
The application is using Redux with React, a reducer will trigger re-rendering for components related to the data modified by the reducer.
Now, here is the strange part. The reducer is called from an observable. So if I emit a new data in the observable, it should interrupt the previous ongoing call to the reducer.
questions:
What will happen? Can it cause a bug or are there benefits?
Since the reducer that is interrupted will not finish re-rendering the react view, maybe the page will look ugly or react will crash.
Maybe we will avoid unnecessary updates in react if we call the same reducer 100 times. That seems very interesting. It means we can optimize by using observables with redux. Is it actually possible?
Maybe the redux internal will have registered the reducer in a callback and it cannot be interrupted.
There is an obvious fix for this if there is bug by calling a promise from the observable.
No, the reducer won’t (and actually can’t) get interrupted, it will just return a new state – the whole point of redux is that it’s a predictable state container. And react can handle state updates, no matter how often or in which frequency they occur (although for the benefit of performance, you might implement shouldComponentUpdate() methods to avoid unnecessary re-rendering).
If an RxJS stream gets interrupted however that would mean that the corresponding redux action wouldn’t get dispatched in the first place… assuming of course the action gets dispatched in the .subscribe() callback, not as a side effect somewhere in between.