Action Logic Flow

[MentalGear]

I'm starting out with xState, and it seems strange that actions: would need to be followed immediately by a assign in order to change context data. In some cases you might have a super lengthy function and only want to actually do an assign/change if all checks work out. If the checks do not work out, one would need to assign /return the already existing state in order for the context to not get corrupted.

Example:

                editItem: {
                    actions: function ({ context, event }) {
                        const newItemData = event?.itemData
                        const itemId = event?.id
                        if (!itemId) return false
                        const itemFoundIndex = context.lists.findIndex(
                            (item) => item?.id === itemId
                        )
                        if (!itemFoundIndex) return false

                        const itemFound = structuredClone(
                            context.lists?.[itemFoundIndex]
                        )

                        const newItem = { ...itemFound, ...newItemData }
                        const newList = structuredClone(context.lists)

                        newList.splice(newItem, itemFoundIndex, 1)

                        return assign({ lists: newList }) // <- would make sense to do it here
                    },
                },

This would be more idiomatic yet it doesn't work if not the whole function is wrapped in the assign.

[MentalGear]

PS: I would understand if the main logic body (e.g. finding the item, cloning, etc) could be done beforehand, but this would require read access to the context data of the actor, which seems not available on the actor object.

[davidkpiano]

Keep in mind that the action you created does not do anything; assign(…) is not imperative. It returns an assign action object.

So the code should be:

  editItem: {
    actions: assign(({ context, event }) => {
      const newItemData = event?.itemData;
      const itemId = event?.id;

      if (!itemId) return {}; // No changes

      const itemFoundIndex = context.lists.findIndex(
        (item) => item?.id === itemId
      );

      if (!itemFoundIndex) return {}; // No changes

      const itemFound = structuredClone(context.lists?.[itemFoundIndex]);

      const newItem = { ...itemFound, ...newItemData };
      const newList = structuredClone(context.lists);

      newList.splice(newItem, itemFoundIndex, 1);

      return { lists: newList }; // <- would make sense to do it here
    })
  }

Regarding your initial point of not assigning until you need to, you can use enqueueActions(...) to accomplish that:

  editItem: {
    actions: enqueueActions(({ context, event, enqueue }) => {
      const newItemData = event?.itemData;
      const itemId = event?.id;

      if (!itemId) return; // No changes

      const itemFoundIndex = context.lists.findIndex(
        (item) => item?.id === itemId
      );

      if (!itemFoundIndex) return; // No changes

      const itemFound = structuredClone(context.lists?.[itemFoundIndex]);

      const newItem = { ...itemFound, ...newItemData };
      const newList = structuredClone(context.lists);

      newList.splice(newItem, itemFoundIndex, 1);

      enqueue.assign({ lists: newList }); // <- Doing it here!
    })
  }

[MentalGear]

Hey David, your reply is much appreciated and thank you in general for the terrific work you all have done!

enqueueActions is really handy, I which it was also mentioned on the context page about data manipulation.

That being said, I'm currently at a conceptual crossroad on what the most architecturally clean solution is: should all app/business logic stay within xState (as above), or only keep xState to a minium/as pure as possible by doing all the logic beforehand (reading data using getSnapshot) and then only call xState to mutate state when necessary.

E.g.::

// beforehand-business-logic.js
      if (action === 'edit') {
          const listsActorSnapshot = listsActor.getSnapshot()
          const listsData = listsActorSnapshot?.context?.lists
    
          const itemId = event?.id;
    
          if (!itemId) return; // No changes
    
          const itemFoundIndex = context.lists.findIndex(
            (item) => item?.id === itemId
          );
    
          if (!itemFoundIndex) return; // No changes
    
          const itemFound = structuredClone(context.lists?.[itemFoundIndex]);
    
          const newItem = { ...itemFound, ...newItemData };
          const newList = structuredClone(context.lists);
    
          newList.splice(newItem, itemFoundIndex, 1);

          return listsActor.send({
              type: 'editItem',
              //     // additional data
              id: itemId,
              newList,
          })
      }

// listsMachine.js
        editItem: {
            actions: assign({
                lists: function ({ context, event }) {
                    lists: event?.newList
                },
            }),
        },

I'd appreciate to hear what you consider the best approach?

---

EDITED:
Quick side-note: during initial development I accidentally modified the context object directly which is of course something you shouldn't do but still worked. If this is done, maybe xState should trigger a console error or even keep one from modifying it at all by, for ex:, freezing the object or using a proxy trap to decline any modifications outside the official API / assign use.

[davidkpiano]

A couple things to keep in mind that can inform the decision are:

• Events should accurately describe what happened
• Impossible states should be impossible

For example, if you're making a deposit at the bank, you wouldn't tell your bank what your new balance should be. That is for them to calculate, so it makes sense for that calculation to be part of the bank's business logic. Try to do minimal logic outside of the state machine; it is meant to encapsulate business logic (not necessarily view logic).

---

Re: mutation, it will "accidentally" work, but there are reasons to avoid mutation in general in a codebase. For XState specifically, this can lead to unexpected consequences such as:

• The initial context mutated in one actor can accidentally mutate it in all actors
• snapshot.can(someEvent) may prematurely mutate context (it "executes" assign actions to determine if a transition will be taken)
• There are helpers like getNextSnapshot(...) that also execute transitions and expect assignments to be pure (same problem as above)