Bug or feature request
Feature request
Description
I think that XState can be treated as a store (as Vuex) in VueJS but on steroids. The context of a machine is effectively acting like a store, but with the lack of reactivity that will make Vue components re-render on state changes.
Hopefully, Vue on version 2.6 as introduced the Vue.observable API that can make any provided object "reactive", causing the so expected re-render of the component. I tried it by transforming the context of a machine into an observable, and it seems to work. By a complete hazard, I started to create an API similar to useMachine of xstate-react, with some extras to be similar to vuex by introducing getters, etc, and by looking at on going issues, I found that someone is expecting the same API for Vue #807. In fact it is almost the same feature, but what I try to achieve is to decouple completely a component from the domain logic as Vuex can allow it, using potentially several machines as stores.
So it works great, but fails in some situations. If I want to define actions on a machine with assign to benefit from futures improvements on xstate (using it as mutations in vuex for time travel feature someday maybe :smile:), the reactivity is no more working. Looking at core/src/utils.ts in updateContext, I see return Object.assign({}, acc, partialUpdate), so the observable context provided is completely recreated on assign, breaking the reactivity. For react it is not a problem but on Vue it is.
A simple solution would be to replace this merge by a loop on partialUpdate and updating the properties of acc I think but I do not have an idea of the impact of it on the project, and I'm not familiar with Typescript so I can't really help.
What do you think about it?
Edit: I don't know how to put an enhancement label, can somebody change it?
Related: #807
@xstate/vue is now available (pre-1.0) with the composition API - please give it a try!
Most helpful comment
@xstate/vueis now available (pre-1.0) with the composition API - please give it a try!