feat: Formz validator now allows async validation

[gabrielchaves7]

Description

I've added code to support async form validations.
Initially I just want to bring to discussion on how to do it. Not exactly want the initial PR to be merged.

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore

[jmsandiegoo]

Any updates regarding this?

[gabrielchaves7]

Any updates regarding this?

I don't know if this is the right approach to do it, I opened the PR to start the discussion with the guys from VGV, but they didn't leave any comment yet

[renancaraujo]

Adding reference to the issue here: #15

[gabrielchaves7]

I would love to implement this one, I'm just waiting the review guys

[tomarra]

@gabrielchaves7 it looks like there is a merge conflict. Can you please resolve?

[gabrielchaves7]

@tomarra @alestiago Just fixed the conflicts, sorry for the delay >_<

[gabrielchaves7]

All checks passing, can someone take a look?

[alestiago]

Thanks for the contribution @gabrielchaves7 💙. I would like to give it a look. However, you'll have to bear with me a bit. Sorry for the delay.

cc: @wolfenrain , @renancaraujo

[gabrielchaves7]

don't worry, feel free to point anything

[gabrielchaves7]

@alestiago Can you review again?

[gabrielchaves7]

Thanks for the review @alestiago really appreciate it :)

[gabrielchaves7]

What are the next steps here?

[wolfenrain]

What are the next steps here?

Hi! Me and @alestiago just had a look at the PR and I think we need re-evaluate the solution of the PR's goal. formz in its current state can be used in a broad set of scenarios and this PR as it is will limit them.

I do think that async validation is a necessity but we need to think about how we will introduce this with as little as possible breaking changes both in the API and the scenarios.

[gabrielchaves7]

• What do you think it should be re evaluate?
• Which breaking change (s) do you think we should try to avoid?

[wolfenrain]

• What do you think it should be re evaluate?
• Which breaking change (s) do you think we should try to avoid?

If anything we would prefer to prevent any breaking changes, which might mean we just need to provide a new API on top of the existing that is async ready, assuming we can make that work use-cases such as using the FormzInputs directly in the build tree.

Formz is simple enough that people can use it in versatile ways and we would love to ensure that we dont break that simplicity which requires us to evaluate our options, so all I can say right now is that we do want to provide async validation.

If you (or anyone else) want/need it right now you can always make an API on top of Formz that is asynchronous. That is also the beauty of Formz.

[tomarra]

Hi @gabrielchaves7 looking to get your feedback here as we are attempting to cleanup open PR's across our packages. Given the last comment from @wolfenrain is this something you plan on still pursuing?

[gabrielchaves7]

Right now I don't intend to move on with this PR. If I come up with any implementation that can address @wolfenrain then I will open a new PR. I really appreciated the review you did but I think we did a bad job on scoping. I waste my time and your time just bc we did not discuss the implementation enough before implementing it and I apologize for that