[cluckindan]

>components should be simple and not store data in themselves.

That is a ”controlled component” model which is bad for interactivity, especially text inputs.

If every keypress triggers a state change and rerender, the UI will be slow and things like focus management become complex issues.

Without a rerender, it must now use a reactive binding to update the field value.

If you don’t want to update state on every keypress, your component must be uncontrolled, store its state internally (in the DOM) and update it to a parent store e.g. when the user stops typing (debounced) or moves focus out of the field. These are not trivial things either, and as a result, components get more boilerplate to handle the UX complexity. And of course, there are now UX pitfalls.

Indeed, these are reasons why reactive patterns exist. Now, if they just managed to abstract away the tedium.

[Izkata]

I don't know what people generally recommend now, but for a long time the best practices with organizing React components had them connected to the store midway down the tree or higher, which definitely would have contributed to the UI slowness since it would rerender everything below that on each update. Push the store access down as far into the leaves as possible and you won't get anything noticeable, even though it is still doing more work than just accessing the DOM state as needed.

Also, focus management isn't really a thing in React, the vdom diffing means DOM nodes are updated instead of replaced so focus isn't lost or changed unexpectedly. There used to be a demo on the React homepage showing this, since the idea was very new to most people at the time - everything popular before it was just rendering template fragments to replace nodes and did have this problem.

[cluckindan]

Focus management is absolutely a thing in React if you plan to be ADA or WCAG compliant, even if it’s not needed for text inputs.