[bjnewman85]

UI=F((irreducibleComplexity + poorDesignChoices + poorArchitectureChoices + techDebt + bad coding + states)^n). The author mixes web and native UI development here to encompass a partial range of possible UIs, there's obviously a lot more complexity in UI development if we expand that list to include AR/VR, CLIs, voice-based interfaces, etc.

But also most software UIs we are building today are overly complicated. Because devs forget f() is supposed to narrow the complexity space to match the users needs, by making illegal states unrepresentable.

[jimberlage]

TBH - I find the opposite is true. Far more complaints have been of the form “this isn’t an illegal state, the dev mistakenly thought so because they’re not a domain expert - why won’t they let me do this?”

And some illegal states are useful. Letting a form exist with a field the user can’t fill out, along with disabled logic and a helper message, is often the best way to onboard users to your tool. Lots of proponents of making illegal states unrepresentable take those fields away so they don’t have to muck with validation logic, which takes away your best way to explain how to use your tool to a user.

[tikhonj]

The lesson here should not be "make illegal states representable", but rather "the state of the form widget in the UI" and "the state of the value the form represents" are conceptually distinct. We should explicitly consider the state of the form, the state of what the form represents/controls and the mapping between them. We should think about these separately and represent them in our code separately.

[dvdkon]

I think you often have an opportunity to model the UI closely after the internal state, in data entry UIs mostly, and you should take that opportunity. It means less code complexity, and the users will expect the UI to closely match whatever database entity you're storing anyway.

[hombre_fatal]

That's not criticism of syncing possible states with expected ones.

e.g. Not having a disabled={condition} on some input field isn't going to change the fact that the client wasn't built to handle that state. Either the client was written to expect it or it was not.

All you're saying is just expect the states that make sense which is (A) a trivial claim and (B) something you have to do even if you don't make unexpected states impossible.

[bjnewman85]

i would argue that any state that is useful should not be illegal, but i agree with you that people have often used that phrase to mean what you said

[iamwil]

This is the stance that https://acko.net/blog/i-is-for-intent/ takes--that there needs to be some way of representing a temporarily illegal state.

[ape_key]

The number of times I’ve started typing my email address into a form and the form yelling in DANGER ALLCAPS RED: “INVALID”.

Yeah I know “a” isn’t a valid email address, but let me finish typing lol.

This is for everyone. Please, please leave HTML form behavior alone as much as possible. Whatever it is you’re changing, you’re probably wrong.

[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