0

Would love to read your thoughts on how you would model a input (textfield) with xState.

According to an input ux article a textfield could have following states:

Input text fields can have one of the following states: default, focused, error, and disabled. All states should be clearly differentiated from one another.

This makes sense as other libs like Material UI uses more or less the same states.

Im wondering how to model this.

Let me just write down some thoughts:

  • I think its obvious that the value should be part of the xState context as it could have any value
  • the mentioned states makes sense as well

Now the part where im not so sure: lets say we have an inline validation (onChange) which says the textfields value is ok and for that we set want to set with css a class "valid" which gives the textfield a green border.

  • We would need either a state transition from default to default_valid (not just valid because we are still in the default state) ... the same applies for default_invalid ... and aswell for some more combinations which would possible end in a state explosion.

  • model it in xState as a child state and access it via default.valid or default.invalid ...

In both scenarios we would need in the textfield component another mapping which reads something like

(just pseudocode)

switch(state) {
'default.invalid': setColor(red), setDisabled(false)
'default.valid': setColor(green), setDisabled(false)
'default.valid.submitting': {
setColor(green)
setDisabled(true)
}

Im really not happy with this approach to manage the state in the component and time in xState machine. This just seems wrong to me.

I would prefer to just use the input machines states ... which works well for some default like, default, focused ... but as soon as the field is "in 2 or more states" it gets a mess.

One way would be to just keep some high level states and write the additional ones in the context and just pass it to the textfield? (sounds not that good either tbh)

So would love to hear your thoughts how you would model something like this.

user1966723
  • 85
  • 2
  • 8

1 Answers1

0

You can use state.matches(...) to clean things up, and/or you can place those actions directly in the states they're relevant for, e.g., in entry or exit.

David Khourshid
  • 4,918
  • 1
  • 11
  • 10
  • yes, state matches was one of my thoughts but its more or less like the switch statement above. i have either split it in parts and forward it the the native html textinput or something like that. but i could not only check with state alone which props i should provide to the textinput. or do you see this otherwhise? to your second part on entry or exit: how would you do that as i have to provide this to the html field how would a action helps in that case other then setting e.g. disabled in context? – user1966723 May 09 '20 at 15:44