Controlled form input with signal value that needs to respond to defaultValue changes

[rejhgadellaa]

I have a use-case where I have a form that can be edited by multiple users (the state is synced between clients via websockets).

For form elements, I usually go for a controlled form input that receives a defaultValue prop and use that to init its local state:

function Input( props ) {
  const { defaultValue } = props;
  const signal = useSignal( defaultValue );
  return (
    <input
      onInput={ event => signal.value = event.target.value }
      value={ signal.value }
    />
  );
}

But now, because other users can edit these inputs as well, the component needs to react to changes to the defaultValue prop. At first, I figured I could just useEffect() my way out of this, and simply update the local state value whenever defaultValue changes:

function Input( props ) {

  // Init the local state with defaultValue.
  const { defaultValue } = props;
  const signal = useSignal( defaultValue );

  // Update the value whenever defaultValue changes.
  useEffect(() => signal.value = defaultValue, [ defaultValue ]);

  return (
    <input
      onInput={ event => signal.value = event.target.value }
      value={ signal.value }
    />
  );
}

This works, but the downside is that it causes an extra render pass:

1. The defaultValue prop changes: the component re-renders.
2. Then the DOM updates and useEffect() runs, where the signal.value is changed: the component re-renders again.

According to React docs, you should not useEffect() to adjust some state when a prop changes, but rather change the state directly during a render:

React will re-render the List immediately after it exits with a return statement. React has not rendered the [...] children or updated the DOM yet.

React - You Might Not Need an Effect

So I came up with this reusable hook that returns a signal that will immediately (= during render) change its .value whenever the initial value changes:

function useSignalWithDefaultValue( value ) {

  const prevRef = useRef( value );
  const signal = useSignal( value );

  if ( prevRef.current !== value ) {
    prevRef.current = value;
    signal.value = value;
  }

  return signal;

}

So then my component looks like this:

function Input( props ) {
  const { defaultValue } = props;
  const signal = useSignalWithDefaultValue( defaultValue );
  return (
    <input
      onInput={ event => signal.value = event.target.value }
      value={ signal.value }
    />
  );
}

So my questions are:

1. Does preact behave the same as react when it comes to changing state during render? (as in: immediately retry the render?)
2. Any improvements I could make to useSignalWithDefaultValue? (better names for the function are welcome, too 😅)
3. Am I holding this wrong? Is there a better way to handle defaultValue (maybe even without the need to react to changes)?

Thanks!

Note(s):

I know my example component here consists of a single <input /> which can not, by definition, have any children, so the impact of re-renders is fairly limited. But I can imagine a more complex component like a dropdown or combobox, which does have a lot of children that will render twice just to respond to the defaultValue changing.

[rschristian]

Simplest solution, if you can get away with it: make defaultValue a signal? At which point you can use useSignalEffect() if you need to sync up with a prop past initialization.

Otherwise I don't think your setup here is unreasonable.

[rejhgadellaa]

Yeah I wish useSignal would have some sort of optional dependency array that would allow updating the value like useMemo():

// Init with value and update whenever it changes
const signal = useSignal( value, [ value ] )

[rejhgadellaa]

I just realized that one thing that I think I could do to improve on this is to not use signal.value, but just pass the signal to the value property of <input />:

function Input( props ) {
  const { defaultValue } = props;
  const signal = useSignalWithDefaultValue( defaultValue );
  return (
    <input
      onInput={ event => signal.value = event.target.value }
      value={ signal } // <= pass `signal`, not `signal.value`
    />
  );
}

I keep forgetting that preact signals will skip the render and just update the DOM if you pass a signal directly. Looks like this works for properties and attributes as well!

With value={ signal.value }, changing signal.value triggers a re-render. But with value={ signal }, it doesn't! So this way, only defaultValue changes will trigger an actual re-render, but only one. Even better, onInput() doesn't trigger a re-render either!

[rschristian]

Sorry, I would've mentioned it but I assumed the non-use was intentional!

Indeed, that will reduce renders greatly.

[rejhgadellaa]

There's always a chance that, for some reason, I do need to read signal.value (add a class whenever the value contains 'foo' or something 😅), but this helps a lot. Thanks!

[developit]

This is a decent approach. I have a variant of this that doesn't allow the argument and signal value to diverge (any render overwrites if different) that I have been calling useLiveSignal:
https://gist.github.com/developit/a72311c247756f24da5b22d19c9dad48#file-signal-utils-js-L46:L55

It's slightly different than yours in that it doesn't need the ref, but I think for your case what you came up with is actually pretty clever.

Re your first question:

Does preact behave the same as react when it comes to changing state during render? (as in: immediately retry the render?)

Yes. If you mutate useState values synchronously during rendering, Preact will immediately retry rendering your function component, up to 25 times.

[rejhgadellaa]

Yeah I tried doing it without the ref, but then the signal.value will reset to the value of the prop on each render. Before I switched from value={ signal.value } to value={ signal }, the component would re-render on input, which meant the value never changed 😅. But I can still see the need for changing props/state for some other reason in the future, and I only want the signal to be set when the defaultValue prop changes. So to prevent this from breaking as soon as I (or a colleague) introduces a state change in here, I think the useRef version should be good.

Thanks!