Some recommended alternatives to useEffect are less declarative and concise

[jedwards1211]

Summary

You Might Not Need an Effect has this example:

  // 🔴 Avoid: Adjusting state on prop change in an Effect
  useEffect(() => {
    setSelection(null);
  }, [items]);

I understand the technical reasons for discouraging useEffect, but it seems like the authors haven't considered this from a readability perspective.

The docs suggest this instead, which is way less concise, declarative, and IMO much less readable:

  // Better: Adjust the state while rendering
  const [prevItems, setPrevItems] = useState(items);
  if (items !== prevItems) {
    setPrevItems(items);
    setSelection(null);
  }

Page

https://react.dev/learn/you-might-not-need-an-effect#adjusting-some-state-when-a-prop-changes

Details

To have the better readability, I would use this custom hook in userland. Since it's so easy for people to abuse useEffect, I would argue React should provide something like the following as a builtin. But if not, the docs should at least recommend it:

useImmediateEffect(() => {
  setSelection(null);
}, [items]);

function useImmediateEffect(effect, deps) {
  const [finishLastEffect, setFinishLastEffect] = useState(() => {});
  const [prevDeps, setPrevDeps] = useState(deps);
  if (!shallowEqual(deps, prevDeps)) {
    setPrevDeps(deps);
    finishLastEffect();
    setFinishLastEffect(effect());
  }
}

[Luccasoli]

I agree! And it helps to influence technically within the technical teams we work with!

I recently saw this article creating a custom hook similar to yours: https://www.jacobparis.com/content/use-reset-callback#extracting-the-logic-into-a-custom-hook

function useResetCallback(initialValue, resetFn: () => any) {
  const [prevValue, setPrevValue] = useState(initialValue)
  if (prevValue !== initialValue) {
    resetFn()
    setPrevValue(initialValue)
  }
}

[karlhorky]

Also relevant here are two new React Compiler ESLint rules:

• react-hooks/set-state-in-effect
• react-hooks/set-state-in-render

Enabling and following the problems reported by these two lint rules makes it much more challenging to achieve deriving state, as synchronous setState() usage in useEffect() or render will now be reported as a problem.

[jedwards1211]

@karlhorky okay I tried out set-state-in-render and it seems to ignore setState calls inside a conditional like

  if (items !== prevItems) {
    setPrevItems(items);
  }

so thank goodness for that. That does mean it wouldn't catch infinite loops like the following though, so we'll see if it stays that way

  if (items !== prevItems) {
    setPrevItems([...items]);
  }

[gaearon]

The linter plugin works correctly but its docs were misleading. I edited in https://github.com/reactjs/react.dev/pull/8033/files.

Re: the original point, yes, this pattern is annoying. Ideally there would be a first-class API for this that is less awkward to use. The team is aware of the pain point.

I would not recommend the custom hook you're suggesting. It hides the pattern away and makes excessive render cycles invisible. It's also not an effect and it is misleading in the sense that people will start putting arbitrary side effects there. Whereas the only thing you're allowed to do during the render cycle is to call setState. So the awkward raw pattern is better. If there's ever a first-class API for it, it would be easy to search for and codemod.

[jedwards1211]

makes excessive render cycles invisible

The tension between simple, declarative code and good rendering performance is pretty fundamental to all of React. Is there really a coherent philosophy about what should and shouldn't be hidden? I think declarative patterns are still worthwhile in many cases

[gaearon]

I agree that this does need a declarative API. Just not what's suggested in this thread (because it's not an "effect", doesn't behave like one, and it would be bad if people started putting things into their bodies that they usually put into "effects").

A declarative API for this could look like modifying useState to have an extra argument that lets you reset it or something like that. I do agree it's worthwhile, just not this one.

[jedwards1211]

Would it be limited to resetting to the initial value though? I would hope for something more flexible

[jedwards1211]

For example I have the following in one of my components, and I wish there were a more concise best practice way of declaring what should happen here:

export function DebugPlots({ config, ranges: inputRanges }) {
  const [ranges, setRanges] = useState(inputRanges || {})

  const autoTimeRange = useMemo(() => {
    if (inputRanges?.time) return undefined
    ... // (computes a luxon time Interval from config.plots if they have data available)
  }, [config.plots]);

  // apply the autoTimeRange to state whenever it changes, as long as it's fully defined

  const [lastAutoTimeRange, setLastAutoTimeRange] = useState(autoTimeRange);
  if (
    autoTimeRange &&
    (lastAutoTimeRange == null || !autoTimeRange.equals(lastAutoTimeRange))
  ) {
    setLastAutoTimeRange(autoTimeRange);
    const { start, end } = autoTimeRange;
    if (start && end) {
      setRanges((ranges) => ({
        ...ranges, time: { left: +start, right: +end } },
      }));
    }
  }

  ...

  // (event handlers may call setRanges for other axes besides time)
}

[gaearon]

When you have multiple pieces of state resetting each other, you usually want to move that into a reducer. Does that help?

[jedwards1211]

Not really...the resetting only happens in one direction, not both. The second useState call is just helping determine if the auto time range has changed from one render to another. The docs recommend using useState to check if a value is different from the previous render, not useReducer.

This is a plot component where the user can drag the time and value range around with the mouse. For convenience, the developer can either pass in the initial time range they want, or omit that prop and let the component choose an auto time range from the data series. But after that, the user can manipulate the time range. If a new data series is passed into the plot though, and no time range is passed in, it should reset to the auto time range for the new data.
Using a reducer for this would be more cumbersome to me

[karlhorky]

I ran into a react-hooks/set-state-in-effect error with useActionState() (the line after eslint-disable-next-line):

function UpdateUserForm(props: Props) {
  const [state, formAction, isPending] = useActionState(updateUserAction, {
    type: 'initial',
  });
  const [isEditing, setIsEditing] = useState(false);

  // Reset editing after user updated successfully
  useEffect(() => {
    // eslint-disable-next-line react-hooks/set-state-in-effect -- TODO: Consider how to do this without setState in useEffect, maybe with setting state during render https://react.dev/learn/you-might-not-need-an-effect#updating-state-based-on-props-or-state:~:text=adjust%20the%20state%20directly%20during%20rendering
    if (state.type === 'success') setIsEditing(false);
  }, [state]);

  return (
    <form action={formAction}>
      <EditableField
        isEditing={isEditing}
        name="firstName"
        defaultValue={props.user.firstName}
      />
      <EditableField
        isEditing={isEditing}
        name="lastName"
        defaultValue={props.user.lastName}
      />

      {!isEditing ? (
        <button
          onClick={(event) => {
            event.preventDefault();
            setIsEditing(true);
          }}
        >
          Edit
        </button>
      ) : (
        <button disabled={isPending}>Save</button>
      )}

      <ServerActionErrors state={state} />
    </form>
  );
}

Based on Storing information from previous renders and Adjusting some state when a prop changes, the previous state could be saved and state set during render instead:

+  const [prevState, setPrevState] = useState(state);

   // Reset editing after user updated successfully
-  useEffect(() => {
-    // eslint-disable-next-line react-hooks/set-state-in-effect -- TODO: Consider how to do this without setState in useEffect, maybe with setting state during render https://react.dev/learn/you-might-not-need-an-effect#updating-state-based-on-props-or-state:~:text=adjust%20the%20state%20directly%20during%20rendering
-    if (state.type === 'success') setIsEditing(false);
-  }, [state]);
+  if (previousState !== state) {
+    setPreviousState(state);
+    if (state.type === 'success') setIsEditing(false);
+  }

This works, so I'm assuming this is the recommended pattern here: trading the useEffect() for an additional state variable.

Alternatives considered

1. Use the key prop to re-render everything in the component (downsides: re-renders everything, possibly losing form field focus)
2. Use an async function instead of passing updateUserAction directly to useActionState() (downside: gives up progressive enhancement)
3. Moving the isEditing state variable into the action state (downside: it doesn't belong in action state)
4. Using startTransition(), requestAnimationFrame() or setTimeout() around the setIsEditing() in the useEffect() (downside: seems like tricking the lint rule)