SplitAtom re-renders from current and previous atom

[philipaarseth]

Playing around with the code sandbox linked in the documentation I noticed some curiosities.
https://docs.pmnd.rs/jotai/api/utils#split-atom

Which I added another task and some console.logs
https://codesandbox.io/s/react-typescript-forked-81z0j

On this screenshot I've simply clicked on the task one, two and three, but as you see, one and two is re-rendered twice.
Once when I actually click it, and once when I click the next one.

Is this expected behaviour, a bug or am I simply missing something here?

[dai-shi]

It's expected behavior. It's best effort to be compatible with concurrent rendering.
If you check the log in useEffect, it should be more intuitive. So, it's double-render-one-commit behavior.

  useEffect(() => {
    console.log(todo.task, "committed");
  })

[dai-shi]

If you are doing computationally heavy, React.memo or useMemo would help to optimize. But, it has little to do with dual render behavior.
If it's not about heavy computation, what is your problem? Debugging experience?

To answer your question, there's no option to disable this behavior. We has some discussion in react-tracked, and it's now opt-in in react-tracked. For jotai and valtio, unless we have serious problems, we would keep it for simplicity. This is because eventually react provides useMutableSource, and the behavior will be changed (probably as you expect.) So, think it like a limitation meanwhile.

[philipaarseth]

It's not necessarily the computation that is the problem as much as the re-render itself that can cause for instance form items to loose focus. Essentially any item that you'd rather not keep track of it's state because of performance or UX concerns. Most of the text editors I've tried absolutely prefer not re-rendering the editor itself.

Are you then saying when react provides useMutableSource that this double render behaviour will go away? So it's a temporary problem?

[dai-shi]

It's double-render-one-commit. From DOM perspective, it's single commit. It shouldn't matter how many renders happen before the commit. If any UX issue is reproducible, we should fix it.

We can't predict what the final useMutableSource will be like. It's my hope. double-render-one-commit will happen in concurrent rendering anyway, so it shouldn't cause any UI issue.

I'm not very familiar with text editors, so it's good to learn if there's a failing example.

[TwistedMinda]

Very intersting really. I was banging my head on the wall on this!

When searching for simplicity, I wanted to understand when the render happen to make sure I understood clearly. But I could not figure out what caused the extra re-render, really confusing!

So it seems that putting console.log inside useEffect() does the trick to allow to know if we're optimal on commits! Oof!
This is very much not in the habits of react developers I suppose.
Would really worth being mentioned somewhere in the docs, if it's not already!

Thanks for those detailed information guys

[dai-shi]

There are some updates since then. #1158 (comment)

• React 18's useReducer renders more before commit.
• fix(core): do not re-render if value is the same #1159 will fix primitive atom case for React 18, but for derived atoms, you will still see more console logs in render. I guess this is expected behavioral change in concurrent rendering.
• using useEffect should be a good solution for debugging. Note that, in strict effect in React 18, we should see two logs on mount.