CODEWITHSUNDEEP
htmlstate-machine
user728650
user728650

Reputation: 1986

Using state machine to validate a form field

This is my first take on a state machine and got a bit confused about the possible states that i can define while implementing the subject matter. P.s. (this question is about how to infer states from a problem and not about how to actually implementing it in code. I know and have used xstate lib).

Scenario is simple, a password field with few validation rules.

The states i came up with are

Error message is displayed based on the current state.

For example, in default state, user didn't enter any data yet, so logical it is invalid state.

But we do not want to show errors to the user right away after opening the form (that will be horrible ux, right ?)

So I added a state specifically for that purpose.

Is this right? Can it be further simplied or is there a state i am missing?

Secondly, there seems to be arbitrary states Like

Should these also be in the mix of states? They look like states to me though.

Lastly, can we say

Million dollar questions are,

Upvotes: 0

Views: 933

Answers (1)

Thomas Kuhlmann
Thomas Kuhlmann

Reputation: 1003

You've probably already solved this, but just in case somebody else comes across this question and could use some pointers - I found the trick was to keep in mind that even simple elements have often multiple states in parallel, e.g. a button can be disabled and show a loading spinner at the same time, a menu can be open and fetching data, an avatar can be showing a placeholder and fetching an image at the same time etc.

for your example I'd look at it like this:

Field level

If you think in terms of a password field, it actually has multiple parallel states at the same time:

  1. Interaction
  2. Validity
  3. Visibility

All three states exist at the same time and have multiple child states

Interaction

this should probably mirror the default input events and have matching state events (e.g. onChange -> set to changed):

  • blurred
  • focussed
  • changed
  • ...

Validity

probably just two states, potentially three if you need asynchronous validation (e.g. if you need to check if an email already exists). For a password field you'd just use:

  • valid
  • invalid
  • validating (optional)

Visibility

straight forward:

  • visible
  • hidden

Form level

You probably end up with two main states with multiple child states:

  1. form
  2. error

Form

  1. Idle
  2. Editing
  3. Validating
  4. Submitting

Error

That could translate into an alert which you show when e.g. an account already exists or the login details can't be verified:

  1. Inactive
  2. Active

Your form state machine would basically handle the input, validation, submission, and form errors, and just communicate the state to individual field machines (field error messages etc). Alternatively, you could pass the validation rules to the field machines and they can execute the field-level validation on i.e. change events. Things like visibility have nothing to do with the form, so you'd manage the state in the field state machine.

I think you were on the right track, you were just thinking a bit too sequential and not considering parallel states. It's just a matter of taking a step back, looking at the form and thinking about everything that can change in it from a UI point of view.

Upvotes: 1

Related Questions