feat: enable HMR of persistentReducedStreams (opt in)

[sseppola]

Adds:

• a global config object in order to configure the internals of rxbeach
• enables opt-in HMR of persistentReducedStreams

What it does NOT handle:

• HMR of reduceState() and action$.pipe()s

I'm hoping we can use this to start a discussion about how we can enable full HMR support over time, the challenge is mainly accessing the internal state of observables in order to set the initial state based on the previous state like this PR does with persistentReducedStreams.

Without being well versed in RXJS, I think the pattern of directly subscribing to the $action stream is problematic because it exposes implementation details to the end user, and prevents us from wrapping the registration to add things like HMR. To get where we want we need to be able to:

1. Access a $action stream observable's internal state
   • eg. in development, tap into the stream and store its local state where the re-registration can access it
2. Unregister an the observable from the $action stream
   • .pipe seems to remove this flexibility from us/requires that the developer register HMR manually
   • Perhaps we abstract the action$.pipe subscription in order to combine the action$ stream with a development-mode takeUntil(onDestroy$)
3. Re-register the observable with the new implementation and previous state
   • The biggest question here is where do we get the previous state from, but there are many ways of doing this

I think it should be possible, my biggest problem at the moment is that I do not know RXJS well enough.

Not sure who else should review, but please add anyone who could have insight into this as I'm actively looking for feedback.

[chriskr]

Why are you using try-catch instead of module.hot?

That error detection seems the wrong trigger for hot reloading?

[sseppola]

Good question!

This file is not the file that is being hot reloaded, it is the file that uses this function that will be reloaded. So that file will run multiple times and register a persistentReducedStream each time, which typically is a duplicate reducer error that needs to be handled in order to allow HMR to happen.

[chriskr]

I see. Using that error type is an indirect pattern, that is basically not ideal. I think it would be better to add some info in dev mode to the subscriber that this is a subscription triggered by a hot reloading to make the reason for the re-subscription explicit.

[rafaa2]

For this part of it. All looks good to me, except for the comment from chriskr.

But also have you tested that this is working?

[sseppola]

It's working, but a better solution is required. I haven't had time to revisit it yet, but I'll circle back to it. I'm getting exposed to a lot more work with streams and rxbeach so I'll be better suited for the next iteration 👌