charmbracelet
feat(textinput): make validation customizable
This PR builds upon the excellent work in #167 and #114 and adds a bit more customizability to the feature.
Currently, the validation API will completely block text input if the Validate function returns an error. This commit makes this behavior configurable by introducing a ValidateAction which decides how to proceed in case a validation error happens. To preserve backwards compatibility, the default behavior remains unchanged.
If ValidateAction is set to AllowInput, the text input error will still be set if needed, but actual input will not be blocked.
This is helpful for cases where the user is requested to type an existing system path, and the Validate function keeps asserting the existence of the path. With the current implementation such a validation is not possible.
For example:
> /
Err: nil
> /t
Err: /t: No such file or directory
> /tm
Err: /tm: No such file or directory
> /tmp
Err: nil
❤️ This is fantastic! @meowgorithm and I were just talking about how this would be a great addition. Thank you for reading our minds @GabrielNagy 😄
Hey @GabrielNagy sorry for forgetting about this one!
I almost wonder if the ValidateFunc should return an error and a boolean on whether to block the input such that validation could block some input but not block all input (i.e. warnings vs errors).
The difference would be you could then validate input and give warning errors such as "file not found" but also prevent input that will never be valid such as inserting a special character in a file name.
This obviously would be a breaking API change so we might need to think about it a little more, but I'm curious to hear your thoughts on the validation function returning a bool for whether to allow the input or block it from changing. And, you can always return false or always return true for the behaviour in the current PR.
That sounds good to me! It's definitely the better solution apart from the backwards compatibility issue.
I really like the option to block or warn on invalid input!
Would it be reasonable to set a behavior flag, like m.textInput.Warning()', and let the validator logic flip it back after writing the rune? It shouldn't break any users' code, and they'd set the behavior flag before returning their Err`.
As for the separate validation functions, would a more general Submit() function work for this? Maybe it could just run the former Validate function with block set before executing a user-supplied Submit function.
(I'd also love a SubmitKey tea.Msg to proc Submit() when set, but scope is scope.)
I just hit this issue as well, and I need to stop using the Validate function as a result. Is there anything we can do to accelerate getting this functionality added?
Hitting this issue too. Can't validate FQDN because I can't type in the first dot. What it needs for this to be merged?
I rebased and implemented the backwards-incompatible suggestion from @maaslalani. I'd be happy to work on some tests as well once we decide on a way forward.