Imperatively setting context values

[tshowan]

I understand there are ideological reasons behind making context immutable and only updatable from within actions.

I have managed to get the impression that the accepted way to update the context is with the assign() action. But I don't seem able to call assign() from within any other action - the action itself has to be "assign".

I immediately ran into multiple situations where you want to assign() from within a custom action. For example, you need to update context with information that you don't have until you calculate it, or you need to update a nested value but you don't know what it is yet.

Here's a simple example of something I want to do, which I think is a pretty commonplace requirement:

/* entries in the actions:{} object: */

// we have a list of items we're displaying in our app, which we access through snapshot.context.items

// called on the "'add new' btn pressed" event:
createNewItem: ( context, event ) => {
    const new_item = { /* some object calculated at length */ }
    context.items = [...context.items, new_item]
    context.currentSelectedItem = new_item;
},

// called on the "field updated" event, which is sent in multiple places with different arguments to target it:
updateItem: ( context, event ) => {
    context.items[ event.item_idx ][ event.item_property_to_update ] = event.new_value;
}

I obviously can't use the code above. So what is the right way to do this?

I am using xstate v5.

[davidkpiano]

For your examples, you can still use assign(…):

createNewItem: assign(({ context, event }) => {
  const new_item = {/* ... */}
  const items = [...context.items, new_item]
  return {
    items,
    currentSelectedItem: new_item
  } // partially update context
})

And, for the second example, I'm going to take the opportunity to demonstrate how you can use Immer to help:

import { produce } from 'immer';

// ...

updateItem: assign(({ context, event }) => {
  return produce(context, draft => {
    draft.items[ event.item_idx ][ event.item_property_to_update ] = event.new_value;
  })
})

See Usage with Immer for more information.

[davidkpiano]

Overall, there is nothing special happening; intuitively, these are just immutable state updates, similar to if you were to use useState(…) in React.

If you notice anything weird happening, it's likely because you're (maybe unknowingly) mutating something.

[tshowan]

Well I've gone through everything multiple times and confirmed that at no point am I setting context from anything other than an assign() function. I don't know how else to guarantee I'm not unknowingly mutating something - from my point of view all the internals of the xstate library are unknown!

I am using this with @xstate/solid. One thing I am wondering is whether Immer's produce() and/or xstate's assign() might be fighting with Solid.js' Store objects. I've had an issue in the past when working with custom Proxy objects, if I tried do a createStore() or createMutable() from them I got all sorts of errors, even though I thought that Proxies should be able to stack up transparently.

Can you tell me what you think is going on with the selectedItem: new_item versus selectedItem: {...new_item} issue I mentioned above? Is this the kind of thing you expect people to do?

[fev4]

@tshowan did you ever find what happened here? I believe I'm facing the same issues when dealing with Svelte 5 and it's signal-based state, specially the part where you mentioned:

When I come to trigger the action again, it once again appears to run (I see the "setEntryPreviewCoords finished" message appear in the console). However, no values have been changed and the Actor has stopped.

I have checked many times and I'm not mutating the context or any key controlled by xstate in any way, but I still get:

fs.js:4 Event "resize" was sent to stopped actor "x:8 (x:8)". This actor has already reached its final state, and will not transition.
Event: {"type":"resize","maxOptions":4}

and everything goes kaboom there, it simply breaks

[davidkpiano]

@fev4 Can you share a code reproduction?

[tshowan]

@tshowan did you ever find what happened here?

@fev4 I'm afraid not. I gave up on this module and wrote my own xstate clone designed to work with Solid.js from the get go. This set me back some time, but results in something that works the way I want, and when it doesn't I can actually reason about why, because I know what's going on under the bonnet. I'm not sure whether to recommend doing this for Svelte or not - it really depends on how much time you have to spend on this.