Input caret will jump to end of string when using store

[AlexThurston]

Using the basic-flow example and adding a name to the state:

const initialState: State = {
  count: 0,
  name: 'john doe',
};

And an action to set the name:

const actions = {
  increment:
    (): Action<State> =>
    ({ setState, getState }) => {
      setState({
        count: getState().count + 1,
      });
    },
  setName:
    (name: string): Action<State> =>
    ({ setState }) => {
      setState({
        name: name,
      });
    },
};

And a simple input component to the CounterHook component:

const CounterHook = () => {
  const [{ count, name }, { increment, setName }] = useCounter();

  return (
    <div>
      <h3>With Hooks</h3>
      <p>{count}</p>
      <p>{name}</p>
      <button onClick={increment}>+1</button>
      <input value={name} onChange={e => setName(e.target.value)} />
    </div>
  );
};

If text is added to the beginning, or middle of the name field, the first character will be correct, but the caret will jump to the end of the text after a single entry.

This is not the behaviour if I make a local state using React.useState

Here is a video of the behaviour:

Screen.Recording.2022-09-22.at.12.38.05.PM.mov

[AlexThurston]

You can also see this behaviour with the advanced-scoped-flow in it's stock form while using the input component.

[albertogasparin]

Ha, good catch, I've never known of this gotcha. It's related to facebook/react#955
React tracks the cursor position only for sync re-renders 😞 so, since we moved RSS updates to be scheduled by default (even if with a duration of just one tick), it loses the cursor position.
Quite tricky. Not sure how to handle this 🤔

[albertogasparin]

What do you think about a flushSync API (similar to the react-dom v18 util) to force updates to be dispatched synchronously?

const actions = {
  setName:
    (name: string): Action<State> =>
    ({ setState }) => {
      flushSync(() => {
        setState({ name: name });
      });
    },
};

Or an alternative could be adding a second, optional argument to setState:

const actions = {
  setName:
    (name: string): Action<State> =>
    ({ setState }) => {
      setState({ name: name }, { sync: true });
    },
};

[bholloway]

So for reference we are talking about flushSync in react.

Given the setState interface is already analogous to react then it's important to keep using react paradigms as much as possible. To avoid confusion and to take advantage of existing familiarity with react.

Having a function scope where the synchronous event occurs is useful in that arbitrary other operations can be located there be known to be synchronous.

In comparison the additional arguments on the setState() is less elegant IMO. Fails interface segregation principle adding a bunch more "options" to achieve what can be done by composition.