How React Suspense and Concurrent Mode Fit Into The Picture

[andria-dev]

Without changing XState to suit React's needs, what ways do we think would be possible to allow support for Suspense to be used with things such as invoked promises? I do believe this will benefit more than just React users in the future as UI as a first-class feature potentially becomes a more popular idea.

Idea

I'd imagine that extremely basic support would involve exposing the promise that was invoked so that it could be thrown, for example:

async function getTheThing(ctx) {
  // Do some asynchronous stuff, maybe a fetch or two
}

const promiseMachine = Machine({
  /* ... */,
  states: {
    loading: {
      invoke: {
        src: getTheThing,
        onDone: /* save the data */,
        onError: /* save the error */,
      },
    },
    /* More states... */
})

function MyComponent() {
  const [current] = useMachine(promiseMachine)

  // MAGIC HERE. There currently isn't a `.invoked.src` or even a `.invoked`
  if (current.matches('loading'))
    throw current.invoked.src

  // maybe throw an error if one occurred
  // then if everything is good and done, render stuff
  return <p>{current.context.theThing}</p>
}

// Somewhere else:
<Suspense fallback={<Spinner label="Getting the thing, hold on..." />}>
  <MyComponent />
</Suspense>

To re-iterate, I don't think XState needs to really change hardly anything, just being able to see the promise should be enough. As of right now, I can't find any way to view the promise from the result of useMachine() at all — I'm assuming useMachine isn't the problem here.

What do we have currently?

I've found that you can see some info about your invoked thing by looking at .activities, sadly it doesn't provide what we need. Here is an example of what can be found in .activites:

// current.activities ===
{
  "image-loading-machine.fetching:invocation[0]": {
    type: "xstate.start",
    activity: {
      id: "image-loading-machine.fetching:invocation[0]",
      src: "image-loading-machine.fetching:invocation[0]",
      type: "xstate.invoke",
    },
  },
}

If you'll notice above, there is a .src on the activity itself but it is just the id again for some reason.

Discussion

If anyone has any other ideas on how this could work feel free to bring your ideas, this discussion is open.

[Andarist]

I'm not sure if useMachine is the best companion to Suspense. Or at least not in a way that you have demoed it.

useMachine keeps state local to a component but, from what I understand, when you suspend you throw away your local state. So to make your pseudo-code work with Suspense you would have to externalize your machine state anyway - or persist it and rehydrate with useMachine.

Quite frankly the Suspense, even if partially working already, is not mainstream yet and patterns etc are not yet fully emerged. I'm not sure if we are best suited here for figuring them out - I would much more prefer to just learn from others' findings and incorporate best ideas to XState. That being said - I'm thinking about this from time to time, there is just so many things that we still can do for the XState itself that are not as uncertain as integrating with Suspense that this is pretty low on my priority list.

[Andarist]

And I don't think you need to externalize the machine's state still unless what you mean by that is to move it up one level. I've yet to find a use case where the following pattern doesn't work

I've done some additional tests and THIS IS WILD :O I totally did not realize that the suspended tree actually gets committed (with style="display: none !important;")- just without component(s) that has thrown a promise. So indeed splitting the component into Outer/Inner pair works just OK. My demo that might be useful for other readers: https://codesandbox.io/s/zealous-mcnulty-9ccme?file=/src/App.js

[andria-dev]

That is interesting, I never noticed the display: none !important style either. I guess it makes sense since React handles each step of rendering each component so it would be able to stop midway when one component suspends and hide anything else under the <Suspense> component with display: none. Which, in turn, would allow preserving of the state of components between the suspending component and the nearest <Suspense>.

[Andarist]

Right - it seems that this works exactly like that but I somehow always have assumed that React only keeps the rendered output in memory and nothing actually gets committed until the whole subtree is ready.

One slight problem with the proposed solution that I have is that it requires access to service but usually, we try to avoid that. I can't figure out any viable alternatives though 🤔

[andria-dev]

@Andarist I think there is a way to do it without access to service by using useRef. I'll fork your CodeSandbox and see if I can make it work and then report back here.

[andria-dev]

I did it! I almost thought it couldn't be done but it's actually kinda nice. So, what I did was create a promise but extract it's resolve callback to the component's function scope so I could put it into useRef() so I could resolve the promise from anywhere in the component at any time. I also store the promise in the ref so that we can throw that if necessary. Alongside these values, I placed some basic resource-style values in there — i.e. status and result.

Getting the first value after "resolving"

Once I had those in my ref I was able to write an if-statement for the condition and if it passed I would update the status to "resolved" and use the getter to retrieve the value that the developer wants. That got us the one-time value. Now we want to subscribe to more updates.

Updating like a subscription

In order to subscribe to future data updates, I wrote a simple useEffect that would check for the "resolved" status and would simply run the getter to provide the developer with the newest state. This would re-fire whenever the dependencies of useEffect would change making it act as a "subscription".

Suspending and returning

After all of that, all that was left was to create a Resource Reader. For this, I'm just making an object with a read method:

{ read() {} }

This handles the throwing of the promise to suspend when in the "loading" status and returning the value when in the "resolved" status.

View the full example on CodeSandbox

function useSuspensefulGetter(state, condition, getter) {
  let resolveValue;
  const promise = new Promise((resolve) => {
    resolveValue = resolve;
  });

  const ref = useRef({
    promise,
    resolve: resolveValue,
    status: "loading",
    result: null
  });

  useEffect(() => {
    if (ref.current.status === "resolved") {
      ref.current.result = getter(state);
    }
  }, [ref, state, getter]);

  if (condition(state)) {
    ref.current.status = "resolved";
    ref.current.result = getter(state);
    ref.current.resolve();
  }

  return {
    read() {
      switch (ref.current.status) {
        case "resolved":
          return ref.current.result;
        case "loading":
        default:
          throw ref.current.promise;
      }
    }
  };
}