Allow opting out of startTransition

[KurtGokhan]

Original issue here #12552, and paraphrasing my comment directly:

I brought myself up to date with the concurrency in React. I already had some information about them but I wasn't aware of the whole implications until I used them in a real application.

startTransition is not a silver bullet and it shouldn't be used blindly. There are cases where it is perfectly valid to disable it. Things that happened instantly before don't happen instantly anymore. It is a huge tradeoff in terms of complexity when the old way used to work perfectly for some use cases (most, considering we didn't have this feature before).

It is possible to make your entire app transition-aware. But this is too impractical, and often unnecessary. From my experience, transition-aware hooks/components are not easily composable. Also there are some bugs and unexpected behaviors that make it harder (examples facebook/react#31819, facebook/react#25814, and all caveats here).

Transitions are a feature of React, but so is useDeferredValue and useSyncExternalStore. I think it's not good to fixate on one solution and ignore others. You don't have to sacrifice old features to add new features.

I could keep using v6. Or I could stop overthinking and ignore sub-second state tearing issues and tiny lags like most of the slop out there. But I am asking you to reconsider, for the greater good. I am sure more people will (or worse, won't) notice these issues as they keep migrating to v7.

I am aware I made too much noise, but TLDR:

There should be a way to opt-out of startTransition.

After a few unsuccessful attempts to migrate to v7, my thoughts are still the same.

This issue can be solved in one of the two ways:

1. Allow passing an option to router context, navigation components and hooks to opt-out of startTransition.
2. Don't use startTransition, but internally use useDeferredValue to get the router state. Expose another hook like useLocationSync that can get the non-deferred router state so that users can opt-out and build their custom hooks upon that. This is more effort and I don't know if it would work well.

I think startTransition is incompatible with most client-side applications, and it will be too late when people start noticing this. Please don't let this be another nail in the coffin for client-side React.

[einarq]

I'm using "createBrowserRouter" in a Redux app. The app is quite up to date, with latest versions of React Redux, RTK Query, etc etc.
The combination has been great, so I hope the reply here isn't just "don't use redux". We use RTK Query heavily, and we use loaders to initiate the queries as early as possible (nice noticeable perf improvement).

However, I'm definitely seeing some weird behavior when trying to upgrade to v7. I'm on the second attempt now, and I'm thinking I might just have to drop it until this opt-out is supported.
My hunch on the first attempt was that it was related to startTransition, and this discussion has re-enforced that hunch.
Its a bit difficult to find something reproducible, but it seems like the state some times has an old value, which would seem related to concurrent features.

I'm not sure Redux is considered concurrent safe these days?

Please allow for opting out of startTransition.

Any chance of this being supported @brophdawg11 ?

[einarq]

After looking into the code of RouterProvider a bit I noticed that you can provide a flushSync implementation, so that when providing "flushSync: true" on router.navigate calls you can actually opt-out of startTransition for some of the navigation at least.

[einarq]

Using flushSync as a general optout introduced other issues it seems, so a proper optout would be nice

[KurtGokhan]

It's baffling, but flushSync doesn't sync transitions in React. I don't know the proper terms, but transitions seem to live in a different queue than render queue, and flushSync doesn't affect it.

[brophdawg11]

Can you provide an example of this? The original reproduction from #12552 seems to be fixed when adding flushSync: https://stackblitz.com/edit/vitejs-vite-tex9m6kt

[eliasrmz01]

Leaving here a mention of how we "solved it" in case it helps:
#12546 (comment)

I agree with this proposal.
It would be great to make it optional with default behaviour enabling the startTransition, as this feature proposal states 🙏.

Again, hope it helps!

[schuma7]

We're also experiencing significant issues with the mandatory startTransition behavior in React Router v7. Our application uses a component with URL state synchronization, and we've encountered race conditions where searchParams updates are asynchronous, causing stale values to be applied in certain effects. This didn't occur in v6.

The timing differences introduced by startTransition have forced us to implement workarounds using refs to track our own state changes and distinguish them from external URL updates. While we've managed to patch these issues, it's added considerable complexity to what was previously straightforward state-to-URL synchronization.

We strongly support adding an opt-out mechanism for startTransition. Not every application benefits from this feature, and having it forced upon all navigation makes migration from v6 unnecessarily difficult. An option to disable it would greatly help applications that rely on immediate, synchronous updates.

[brophdawg11]

Does flushSync help your case ? That fixes the original reproduction in the issue that prompted this proposal. If not, can you provide a minimal reproduction where flushSync doesn't help so we can take a look?