`useTransition().type` does not expose `done` value after successfull form submit, like `fetcher.type` does

[cliffordfajardo]

What version of Remix are you using?

1.9.0

Background Context

While creating my own custom hook to detect when useSubmit is done responding from the server, I found that useTransition().type doesnt expose a done value, unlike fetcher.type

// Easier to implement since `done` is exposed on `fetcher.type`
const {submit} = useRemixFetcher({
  onSuccess(){..}, 
  onError(){..}
})


// harder to implement  since `done` is not exposed on `useTransition.type`
const {submit} = useRemixSubmit({
  onSuccess(){..}, 
  onError(){..}
})

Expected Behavior

After calling useSubmit and successfully receiving a response back from the server, useTransition's useTransition().state value should be idle and the useTransition().type value should be done, eventually

Actual Behavior

After calling useSubmit() and successfully receiving a response back from the server, useTransition.type value does not get updated to done to indicate inform our remix app that the form submission has successfully completed, instead useTransition.type === 'idle'.

Steps to Reproduce

Stackblitz URL: https://stackblitz.com/edit/node-s1xxwy?file=package.json,app%2Froutes%2Findex.tsx

Testing useSubmit

1. Click getData button inside the Child1Component container
2. View console.log's, you'll see that transtion.type will never have a done value

Testing useFetcher

1. Click getData button inside the Child2Component container
2. View console.log's, you'll see that transtion.type will never have a done value

Video Reproduction

useSubmit--vs--useFetcher---type-value.mp4

Why is useTransition().type === 'done' important?

1.Currently fetcher.type exposes done after a full form submission has completed:
https://github.com/remix-run/remix/blob/main/packages/remix-react/transition.ts#L121-L247

2.Having a done state is useful in user land, as it allows use to tap into when a submission completed from the backend.

For example, you can use fetcher.type === 'done' to trigger an onSuccess or onError callback in your code and show a Toast to the user after the server has responded successfully or with an error.
I created a custom lightweight hook around useFetcher called useRemixFetcher which allows a user specify onSuccess and onError callbacks like this & I use fetcher.type === 'done' to know when my submission has completed in order to fire my callbacks.

// DEMO: https://stackblitz.com/edit/node-s1xxwy?file=package.json,app%2Froutes%2Findex.tsx

const { submit, state } = useRemixFetcher({
    onSuccess: () => {
       toast.success('🎉 Success')
    },
    onError: (error) => {
       toast.error('❌ Error')
    },
  });

Currently it's more complicated to detect when a useSubmit has completed due to done not being exposed to transition.type Stackblitz URL: https://stackblitz.com/edit/node-s1xxwy?file=package.json,app%2Froutes%2Findex.tsx

Follow up questions

I'm aware that useTransition is a global singleton whereas useFetcher's are completely independent of other useFetcher's

1.I was curious if this omission of done on useTransition is intentional?
2.I think we should expose it to TransitionStates just like how its exposed in useFetcher's FetcherStates type

[cliffordfajardo]

@ryanflorence showed on the Roadmap planning LiveStream, potentially exploring something like this for a future API, which would eliminate the custom lightweight hooks I have around useSubmit and useFetcher

// Timestamped discussion for API code below: https://youtu.be/eGWG22olL0o?t=1936
useFetcher({
  onStart() {},
  onError() {},
  onSuccess() {},
  onComplete() {},
});

That future API for useFetcher would be really awesome, hopefully for useSubmit as well

References

• Add `submitOptions` argument for `useSubmit` and `useFetcher` #9737 (comment)
• Discord conversation thread

[cliffordfajardo]

Discord Thread

ryanflorence:
Transitions are never done. You can land on any url with both GET and POST. You are either loading, submitting, or idle. There is no “done” state like fetchers

abelsj60:
You're totally right, but you could look at the completion of a navigation as "done," which is where I settled. It can be meaningful at times.

ryanflorence:
location.key will be “default” for the first page visit. Every location after can then be thought of as either “done” or “idle”, we went with idle; I’m saying the semantics of your idea of “done” is the same as “idle”. It’s always done.

I need to dig into this more; regarding this thought from Ryan on useTransition:

I’m saying the semantics of your idea of “done” is the same as “idle”. It’s always done.

More Thoughts 💭

I'm curious why fetcher doesn't follow the same general idea to represent "done" as transiton.type as well? since in theory going back to idle is like done or no?

Stackblitz link

useSubmit scenario observing `transition` (see stackblitz)
- idle --> actionSubmission --> actionReload --> idle

useFetcher's scenario observing `fetcher.submit` (see stackblitz)
- init --> actionSubmission --> actionReload --> done

Another idea?
Have transition.type emit a done value temporarily and after very short amount of time return it back to idle?
This is similar to the codeblock above with some minor differences

useSubmit scenario observing `transition.type` (see stackblitz)
- idle --> actionSubmission --> actionReload --> done🟢 --> idle

useFetcher's scenario observing `fetcher.type` (see stackblitz)
- init --> actionSubmission --> actionReload --> done --> idle🟢

I just wish there was an easier way to detect when a useSubmit call is done similar to fetcher without needing to keep a "transition log" to check "ok it started at idle , changed transition states in between & now its idle again"

@kentcdodds @sergiodxa @brophdawg11 curious on your thoughts 🙏

[brophdawg11]

This feels like a proposal to change the current APIs to more closely align useTransition.state and useFetcher.state, rather than a bug since these are both working as designed. Should this be converted to a Discussion in the Proposals category?

since in theory going back to idle is like done or no?

This is where I land personally. I think done is sort of confusing on fetchers, since (1) you can usually infer it from the presence of fetcher.data and (2) it's not really "done" since it can be relaunched at will. My gut reaction is that once the events API comes around we remove the fetcher done state to align with navigations. This would have to be a Remix v2 change though since it's breaking

[brophdawg11]

There's a handy "convert to discussion" action - but that may only be available to maintainers? If you don't see that let me know and I'll do it so you don't have to copy/paste everything over!

[cliffordfajardo]

Hi @brophdawg11 - converting to a discussion sounds good 👍

I think its only available to maintainers - convert to discussion github docs

Initially was curious if transition.state not having done state was like fetcher was intentional or not before digging into the codebase 😄 thanks for saving me time and adding more context

My gut reaction is that once the events API comes around we remove the fetcher done state to align with navigations.
Any docs/code to get a glimpse on this events API - that seems super useful!

[cliffordfajardo]

For anyone else who stumbles upon my example & code in the future, I just saw in the v1.10.0 Remix release notes type was removed from the transition object

• https://github.com/remix-run/remix/releases/tag/remix%401.10.0#:~:text=true%3B%0A%7D-,New%20hooks,-%F0%9F%AA%9D

[brophdawg11]

oh - transition.type is still there - that wording is confusing. I updated it to clarify we removed type in the new useNavigation hook that is replacing useTransition. But for Remix v1 useTransition remains unaffected. In Remix v2 we'll drop useTransition so it's recommended to start moving over to useNavigation now ahead of an eventual Remix v2 release.

[brophdawg11]

I'm also going to transfer this issue over to the react-router repository since all the useFetcher and useNavigation code lives over there now.