@xstate/react feature request: trigger predifined events before stopping the interpreted service

[dmitrybirin]

Hello 👋

Thanks for the cool libraries! State Machines for the win! 🎉

Got a feature request for the @xstate/react and useMachine hook.

What?
Sending predefined event/events before interpreted service stops.

Why?
In some cases you need to clear up external stuff like connection, that your machine manages, to different services, but you need to do it before the service stopped.

Why again?

On component unmount, I want to close connection, that my machine manages, but useMachine hook just calling service.stop() on unmount and I couldn't find any other way to squeeze some event before
I can wrap my component and use service interpreter just manipulate it, but I don't need @xstate/react then.

Here's some code sandbox example

in a nutshell

...
import { myCoolMachine } from './myCoolFile'

const CoolConnectionState = () => {

    const [state, send, service] = useMachine(myCoolConnectionMachine)

    useEffect(() => {
        send('CONNECT')

        return () => send('DISCONNECT') // doesn't work, cause machine is stopped already by useMachine
    }, [send]) //send shouldn't change

    return <div>{state.value}</div>

}

Request
would be cool have additional option for useMachine like 'eventsBeforeStop' or 'beforeStop' and send all of them right before stop.
Looks a bit clangy right now, but maybe there is another option for that or the whole thing could be done much easier.

[davidkpiano]

That should be an implementation detail, no?

For instance, if you are invoking an actor, you should specify the disposal there:

// example
// ...
{
  invoke: {
    src: (context, event) => (sendBack) => {
      // ...
      
      // disposal
      return () => {
        // do proper disposal here
      }
    }
  }
}

And when the service is stopped (service.stop() as you've mentioned) it will properly stop the invoked service.

[dmitrybirin]

Thanks for the answer @davidkpiano ! Yeah, it definitely could be the implementation detail. It's the first complex project, where I'm using xstate after all :) But I still can't wrap my head around it.
Question: Will it be valid then to have state, that invoke some actor with the clean up and also child states?
Like that:

Machine({
    initial:'idle',
    context: {
    // ... client and additional context
    },
    states: {
     // ... other states
    connected: {
      on: {
        SIMPLE_ERROR: '.loading',
        RECONNECTED: '.idle',
        CRITICAL_ERROR: 'failed',
      },
      invoke: {
        src: (context) => (sendBack) => {
          context.client.connection.bind('simple-error', (error) => sendBack('SIMPLE_ERROR', error))

          context.client.connection.bind('critical-error', (error) => sendBack('CRITICAL_ERROR', error))

          context.client.connection.bind('reconnected', (error) => sendBack('RECONNECTED', error))

                                          // this is executing after I'm leaving the 'connected' state, right?
          return () => context.client.disconnect() // disconnecting and unbinding
        }
      },
      states: {
        idle: {},
        loading: {}
      }
    }
  }
}, {
// ... actions and services
})

If so, then I misunderstood the concept a bit, and my feature request indeed not needed.

[davidkpiano]

                                          // this is executing after I'm leaving the 'connected' state, right?
          return () => context.client.disconnect() // disconnecting and unbinding

☝️ Yep, this is correct!

[Andarist]

Keep in mind that React actively discourages thinking in terms of mount/unmount - their model is synchronization to the state.

If you absolutely need this (but usually you really shouldn't) then you can just reorder things:

  let state, send
  
  useEffect(() => {
    send("CONNECT");

    return () => send("DISCONNECT");
  }, []);

  ;([state, send] = useMachine(connectionMachine));

But as @davidkpiano said - you probably should make this an invoked service and have it managed for you.

[dmitrybirin]

Yeah, you right, it will work. Didn't think about that. But will need multiline comment with why, though)
Yeah, I also hope that I'll solve it from the machine point of view, not react.
The reason why I did it in the first place: we're using React Native view in the application, and want to close everything, when the user will close the view, using unmount - the direct approach.