It seems I misinterpreted the point you were trying to make, but with your last feedback I feel confident that that is clear now. I see how you attempted to fix something that was missing in the solution I sketched: it does not offer some generic mechanism to asynchronously/eventually ‘fix’ the store. But here’s the thing: a reducer is fundamentally incapable of asynchronously settling state. The observable that Victor allows his navigation reducer to return, is *fundamentally flawed* (and I must admit it feels totally awkward to state this so boldly about someone as smart as him). Therefore I am not in favour of your proposal to rely on that observable.

That does not mean it is impossible to supply such a generic mechanism. One solution could be:

• in the navigation reducer, besides updating the filters, also delete the store data that is outdated by the new filters.
• in a router event, dispatch an APPLY_FILTER action. Not sure which event is the best to (filter and) subscribe on.
• implement an APPLY_FILTER effect.

I think this approach has a lot to like:

• target components can render synchronously
• they need not have any logic of where to get data from (IF there data needs don’t exceed what the route provides, which is as it should be according to Victor). This keeps the components simple, and data logic is in one place.
• they just specify the exact data out of the store that they need.
• and can still be very specific in rendering visual clues while loading data.