Patterns for startTransition

[tesseralis]

One major use case for startTransition is to update an input instantaneously while things that depend on that input's value are possibly delayed:

function TransInput({ value, onChange }) {
  const [internal, setInternal] = useState(value)
  return <input value={internal} onChange={(e) => {
    setInternal(e.target.value)
    startTransition(() => onChange(e.target.value))
  } />
}

In this case, the initial value passed in is only used to initialize the input, which is then controlled internally by the component. I believe this is already a common use case, with debounce instead of startTransition.

However, if the value can change through other means, such as a reset button on a form, this pattern is broken:

function Form() {
  const [state, setState] = useState({ value: "hello" })
  return <form>
    <TransInput value={state.value} onChange={(newValue) => setState({ ...state, value: newValue })} />
   <button onClick={() => setState({ value: "hello" })>Reset</button>
  {/* lots of other inputs */}
  </form>

In the example, the reset button does not work: even though state.value has been updated, <TransInput /> does not update the value because the value prop is discarded after the initial render.

While this example is simplistic, and there's still questions on where startTransition should be used, I imagine this is a common pattern that can arise for its use case: whenever there is state that needs to be immediately updated in one part of the UI but may be deferred in others, the same state must be kept in two places and be "synced" in some way. Has the React team dealt with this situation? If so how have they resolved it? If not, is there an alternate pattern or way of encoding the same desired behavior?

[gaearon]

It's a bit confusing that we explained startTransition through this example because the canonical way to "unblock" parts of the tree is probably useDeferredValue.

function Form() {
  const [state, setState] = useState({ value: "hello" })
  const deferredState = useDeferredValue(state)
  // ...

Here there's no startTransition at all anywhere. You pass deferredState to the parts that are ok to lag, and pass state to parts like input themselves that need to be controlled. The parts that are allowed to lag need to be memoized (to not block urgent updates).

Is this helpful? We're still working out how to explain the primitives. There's definitely some overlap there.

[gaearon]

Yeah.

[drcmda]

is it correct that with useDeferredValue we don't get a pending state? i am switching between the two in a test app that fetches stuff but i want the current result to remain until the new comes in without dropping into fallbacks. with startTransition i can do that and i can inform the UI. with useDeferredValue everything seems to work the same way, but i can not inform the UI?

[Andarist]

Wouldn't value !== deferredValue check be enough to determine that?

[drcmda]

Wouldn't value !== deferredValue check be enough to determine that?

interesting! i will try ...

[gaearon]

Yeah that's what we usually do.