What is a preferable way to handle async side affects?

[serhiipalash]

Hi! Can you tell me what variant is the right one or preferable one?

{
  "id": "user-form",
  "initial": "idle",
  "context": {
    "name": ""
  },
  "on": {
    "NAME__CHANGE": {
      "target": ".loading",
      "actions": ["setNameInContext"]
    }
  },
  "states": {
    "idle": {},
    "loading": {
      "invoke": {
        "id": "user-name-update",
        "src": "updateUserNameInDb",
        "onDone": {
          "actions": ["setNameInContext"]
        },
      }
    },
  }
}

or

{
  "id": "user-form",
  "initial": "editing",
  "context": {
    "name": ""
  },
  "states": {
    "editing": {
      "on": {
        "NAME__CHANGE": {
          "actions": ["setNameInContext", "updateUserNameInDb"]
        }
      },
      "invoke": {
        "id": "user-name-watch",
        "src": "watchUserNameInDb",
        "on": {
          "NAME__FETCH": {
            "actions": ["setNameInContext"]
          }
        }
      }
    }
  }
}

The first variant listen to NAME__CHANGE event which can be triggered from the UI, then updates context with new name value and transit to loading state which invokes a service to update name value in db. When service is done, name value in context is updated too.

The second variant also listens to NAME__CHANGE event from UI, but instead of transitioning in another state with attached service, it triggers request to db as an action without waiting for request result. To get request to db result there is an ongoing watcher service, which updates the name value in context every time value in db is changed.

So, my main question is "Is it okey to trigger promises as actions or is it always better to put them in a separate state with corresponding service? Or maybe it's preferable to always put promises into state services to make them canceled on machine exit?"

P.S. This question is inspired by this comment https://dev.to/codingdive/comment/o1dk in The most elegant debounce code you'll ever write featuring XState article

[Andarist]

I usually go for making a service for such things (so the first variant). Cleanup of stopped machines is nice - like you have mentioned.

[serhiipalash]

I totally agree with you when updateUserNameInDb is an http-request, but what if you have a WebSocket connection?

Our app is built on Firebase Realtime Database and is basically WebSocket-based app. It seems like there is no practice to cancel write operations, but there is a lot of docs about canceling various listeners in Firebase.

[Andarist]

U can wrap ur WS connection in a callback service and provide the appropriate cleanup function there.