feat(textinput): do not block input on validation

[GabrielNagy]

This PR builds upon the excellent work in #167 and #114 and makes a breaking change to the validation API.

Currently, validation will completely block text input if the Validate function returns an error. This is now changed so the function no longer blocks input if this is the case, thus handing this responsibility to the clients.

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

[maaslalani]

❤️ This is fantastic! @meowgorithm and I were just talking about how this would be a great addition. Thank you for reading our minds @GabrielNagy 😄

[GabrielNagy]

@maaslalani let me know how I can help getting this merged 🙏🏼

[maaslalani]

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.

[GabrielNagy]

That sounds good to me! It's definitely the better solution apart from the backwards compatibility issue.

[hopefulTex]

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.)

[rynowak]

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?

[CoMfUcIoS]

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?

[GabrielNagy]

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.

[CoMfUcIoS]

Any updates on this? Willing to help if needed as well.

[maaslalani]

@GabrielNagy, what do you think of simply removing the blocking of the validation?

That way we can keep the signature of the function the same. We would then simply put the responsibility on the user to ensure that there is no m.Err before they submit their form.

I like the idea of keeping the func Validate(s string) err since that the signature we use for huh, but for huh we just validate on Blur.

[maaslalani]

So essentially we just remove this line and never block.

[GabrielNagy]

Thanks for coming back to this. Yeah, not blocking the input would solve all our issues since we already handled blocking submit ourselves, e.g. https://github.com/ubuntu/adsys/blob/ca3458501ff5b2f72f16be266bad7a189a890acf/internal/watchdtui/watchdtui.go#L224-L227

I'll push an update to the PR!

[maaslalani]

Thanks for all your patience on this one @GabrielNagy!

[jippi]

👋 Thanks for looking at this - I just spent a couple of hours debugging this issue on my own project 😆

[maaslalani]

Any reason for deleting this?

[maaslalani]

Ah I see it's a duplicate now.

[GabrielNagy]

Yes, apologies should have pulled that to a separate commit. It confused me as well when re-reading the code. 😅

[maaslalani]

Awesome work @GabrielNagy, just tested and it works great!

[maaslalani]

Ah I see it's a duplicate now.