Derived Context

[lmcgartland]

I've been really enjoying Svelte's derived stores that update their values automatically when the value of a parent store changes. I was wondering if there was a similar pattern that could be used in xstate context? Ideally, there would be a way to subscribe to a part of the context and calculate a derived value for whenever that part of the context changes. Has anyone modeled something like this before?

Edit: found a couple mentions of derived context in the spectrum chat

• https://spectrum.chat/statecharts/general/derived-context-alternatives~cf6ad7be-4e75-44db-a61a-4c0ed33e855b
• https://spectrum.chat/statecharts/general/xstate-wish-list~6f025b10-fcbc-4ab5-ae59-5201112f06f2?m=MTU3MzkyOTcyNjY5MQ==

[VanTanev]

@xstate/react provides useSelector(), which might be what you're looking for. #2077 has a newer implementation that should land in the near future if you want to look at how that works. Right now, there is no equivalent for @xstate/vue, but maybe you could write one? I'm not familiar enough with Vue to attempt it.

Caveat: useSelector() uses identity to check if the current and previous value of useSelector() are different and a new render is necessary. If you return a value where identity check does not work (eg, arrays), then you should also provide the third argument to useSelector() that's a compare function.
Also, all functions passed to useSelector() must be stable (ie, either defined outside component scope, or wrapped in React.useCallback()).

[ChrisShank]

As much as this would be a killer feature, it means that xstate would have to, more or less, implement its own reactivity system to accomplish this. It's unclear to me if that is in the scope of xstate?

Maybe a more robust solution is for xstate to provide primitives so third-party reactivity systems could more easily integrate with xstate's context so that you could derive context in the reactivity system that you are already using? There have been some conversations about how to implement this on twitter, but I imagine some more research needs to be done in this area!

[Andarist]

Yep, I imagine smth like this should be implemented in the future - a way to assign stuff onto reactive cells provided by the framework. It has some implications on portability, APIs etc so this needs a deeper analysis.

[with-heart]

@Andarist I've been thinking about this feature lately. Do you have any examples of prior art? Could you explain what the implications on portability would be?

[imeghri-sami]

Any updates about this feature ? 🤔