Colton Idle
08/06/2021, 11:31 PMColumn{
BasicInput()
EmailInput()
PhoneInput()
}
A few team members have argued that the validation shouldn't be baked into a composable, so we originally were doing all checks in a ViewModel and not in the composable, but the issue is, someone builds a new screen, the add EmailInput() but forgets to add the validation in the VM for the new screen and now we're back at square 1.
What would you do?hfhbd
08/06/2021, 11:42 PMEmailInput(initial, placeholder, modifier etc) { validEmailAtChangeOrSubmitOrFocusLost ->
}
Tash
08/06/2021, 11:59 PMinterface EmailInputState { /** handles validations, internal text highlighting, etc **/ }
and then your component could do something like this:
@Composable fun EmailInput(state: EmailInputState, ....)
add default param value of state = remember { EmailInputState() }
if the component defines some default policies. this way you’d be hoisting the validation info as well.
check out this for more infoeygraber
08/08/2021, 2:02 AMColton Idle
08/09/2021, 12:58 AMIf each Composable is defined by a set of requirements that call out its existence in the first place, then it should come with its own corresponding State class that implements all the smarts.
Tash
08/09/2021, 8:27 AMThis line isn’t in the docs anywhere right?@Colton Idle that was my overall takeaway from the concepts of state hoisting and the various sections that API guidelines doc, but yeah 😅
validation logic as being stateright, the logic isn’t the state, the result of the logic could be, though. at the end of the day you have one model essentially that is responsible for obfuscating the “logic” and surfacing the result of that logic as state. thus the state, when hoisted could allow the caller of the composable to access information like validity, reason for invalidity if any, etc. whatever you want the EmailInput() to figure out for you