I ran into an issue where there is a visualization discrepancy between an input widget color change and notification (color change and error/message only takes effect when “Enter” is pressed) and the Next button enabled state (updates immediately when an acceptable value is entered, before “Enter” is pressed).
Is there any clever way to resolve this and get these behaviors to sync?
Perhaps having the user interact with a visible input widget whose trigger updates the value of a parallel variable corresponding to an input widget off screen, and have the Next button enabled state tied to the offscreen input widget?
This is an interesting one - the TL;DR (too long; didn’t read): This is not a bug, and this is actually all intended behavior.
There are kinda 3 different things going on in your example:
the toast – because this is part of the trigger, it’ll happen on enter. it looks like you are using some custom validation in an “enter key pressed” trigger on the widget to power that toast. Unless there’s a really strong reason to use this, we’d recommend using the built-in error messages that are part of the widget, since they’re more informative than their error message anyway
the invalid state on the widget - this activates for the first time after the first blur (enter is one way to do this), then it updates live after the first blur as the user types. It works this way to prevent immediately blasting the user with red as soon as they start typing, since it’s likely invalid to begin with
the enabled state of the button - this activates live. It has to work like this because if it didn’t check until the input was dirty, it could accidentally allow it to be enabled when it’s meant to be disabled.
The only way to get these behaviors 100% aligned right now is to stop using input validation, and do everything “the old way” via triggers. Have an on enter trigger on the input widget that
updates some variables used for styling the widget
shows the toast. and
updates a variable used for the enabled state of the button.
This means that everything stays in sync, but you lose 2 very important things:
no more live validation on the input widget (after the first blur), which is likely a more annoying user experience
the button is no longer guaranteed to be disabled based on the input validity the same way as before. It’s easy for it to accidentally start enabled, or be set to enabled somewhere else if the input widget itself isn’t touched
To solve 2, instead of using enabled/disabled, you’d just conditionally take the action, i.e. an additional validation check after the button is clicked. This is all possible, but is a whole lot of super clunky work, and basically the exact use case input validation and enabled/disabled were created to solve
If you start using the default input validation error formatting, instead of the trigger toast, that will at least fully unify the behavior of the error message and the error styling.
The idea of allowing app builders to configure their input widgets to always validate in real time rather than waiting until after the first blur has come up a few times, and then in that case everything would be live-updating all the time… but requires functionality we don’t have yet in the platform
