How to deal with on/off listeners on service with TypeScript

[danielkcz]

I hope this is something that's planned to change in V5. The service.onTransition and friends returning service instance is not that convenient as it seems. It should be returning unsubscribe function. Let me show you a little example.

React.useEffect(() => {
  // extracted the type, but it's horrible to deal with that
  const onTransition: Parameters<typeof service['onTransition']>[0] = (state) => {

  }
  service.onTransition(onTransition)
  return () => {
    service.off(onTransition)
  }
})

So ideally it should look like this. Small change, but a huge difference in user code.

React.useEffect(() => {
  return service.onTransition(state => {
  })
})

[Andarist]

Keep in mind that React is only an integration point with XState and its APIs should not influence the API decisions for XState itself.

That being said I probably would prefer the proposed change as well. However, this makes patterns like this more awkward to write:

interpret(machine)
  .onTransition(() => {})
  .start()

OTOH I feel like onTransition should be used really sparingly, so ultimately maybe it doesn't matter much which style is preferred by the core?

[davidkpiano]

The service.onTransition and friends returning service instance is not that convenient as it seems. It should be returning unsubscribe function.

That is what service.subscribe(...) is for. It returns an object with the unsubscribe function: { unsubscribe: ... }. The reason it returns a subscription object is because that's part of the proposed TC39 Observable spec.

[danielkcz]

@davidkpiano I see, I have no problem with object returned, the annoyance is generally in the need to keep identify of callback around.

So you would generally recommend service.subscribe for persistence purposes? It's not clear if onTransition does something more or less.

And service.stop() won't remove these subscriptions?

[davidkpiano]

the annoyance is generally in the need to keep identify of callback around.

This "annoyance" is not unique to XState (e.g., window.addEventListener(...)) 😉

So you would generally recommend service.subscribe for persistence purposes? It's not clear if onTransition does something more or less.

They essentially do the same thing.

And service.stop() won't remove these subscriptions?

It will.

[Andarist]

Right, did not know that service.stop() is that powerful 😅 And I see it's also used in useMachine so technically I don't need to care about cleanup then?

Yes and no. Yes - your listeners will be cleaned up, but no - because React might decide to setup the "same" listener multiple times, so if you do not implement cleanup per hook basis then you might end up with multiple same-ish listeners being fired.

The latter problem is not quite solved by @xstate/react itself right now so I wouldn't worry about it yet. And, right now, to the best of my knowledge, this can only happen when you are using Fast Refresh.

[danielkcz]

@Andarist Thanks for pointing that out, makes total sense. At least there is the service.subscribe which makes it much easier.

[davidkpiano]

Answer: #1531 (reply in thread)