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.

[tshowan]

Thanks for that answer. Btw, where is assign() documented? I somehow can never find what I need in the xstate documentation, and when I can it's for v4 with a "checkout v5!" banner that just goes to the main page.

[tshowan]

Update: I have just wasted a great deal of time on this and found that as given, your answer gives crazy behaviour. Any assign() that tries to change context.currentSelectedItem also ends up fucking around with that same item in context.items.

So given this:

// called on "add new" btn:
createNewItem: assign(({ context, event }) => {
  const new_item = {/* ... */}
  const items = [...context.items, new_item]
  return {
    items: items,
    currentSelectedItem: new_item
  }
}),

// called onclick an existing item:
selectItem: assign({
    currentSelectedItem: ({ context, event }) => { return event.item }
}),

If you start with:

context: {
   items: [ {id:1, name:"abc"},  {id:2, name:"def"},  {id:3, name:"ghi"} ],
   currentSelectedItem: null
}

You get the behaviour:

• assigning currentSelectedItem to items[0] appears to work as expected
• then assigning currentSelectedItem to items[1] overwrites both currentSelectedItem and items[0].

If instead you do:

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

the problem appears to go away.

Is this intended behaviour? If so, why?

Also, I notice you were able to return { items, currentSelectedItem: ... } instead of {items: items, currentSeletecItem: ...}. What is happening there?

[tshowan]

Another update: the produce() code is playing funny tricks as well.

I have

       setEntryPreviewCoords: assign(({ context, event }) => {
        console.log('action: setEntryPreviewCoords');
        /*return produce( context,draft =>{
            draft.newEntryPreview = {x:event.x, y:event.y}
            console.log("setEntryPreviewCoords finished")
        })*/
        return {
            newEntryPreview: {x:event.x, y:event.y}
        }
      }),

With the produce() return statement commented out as shown, I can trigger that action as many times as I like.

With the produce() return uncommented:

• I can trigger the action once, it appears to run fine, and the rest of the machine keeps functioning.
• 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.

Nothing else is screwing with the context.setEntryPreviewCoords object, and when I do the exact same operation without using produce(), it all works perfectly.

I have no intuition for what to do next, this appears to be some interaction happening within the library below the level of my understanding.

[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?