[jimberlage]

The right way to handle this is - store both the user input and the validated value (potentially null) and an error state (potentially null.) Then, when the user takes action to submit the form, validate and set the error state if needed. That way you’re not constantly setting the error state on typing, but when some concrete action is taken you can signal what went wrong.

Admittedly, anecdotal, but most of the guys in my career who have been really into UI = f(state) only consider the validated state, and wish the stuff that’s purely user input and never sent to your backend would just go away.

And when you consider that state is both what you want to send to the server, and a bunch of intermediate state that only ever means something to the client, the UI = f(state) idea (while true!) doesn’t seem all that helpful. Technically every app is a function of state, but if your definition of state is that broad what help is the idea?

[ape_key]

Yeah it’s more useful to think of unvalidated state and validated state. Use different types if you can.

What I don’t care about is if the state is from a prop, a value inside a DOM object, a global…

If I have to know where the state comes from, the code is smelly