Initial version

[Jade-GG]

Allows a very simple VAT check on any input with:

v-on:change="window.app.$emit('vat-change', $event)"

We can add this by default into the core/checkout-theme/account inputs as well, making this package full plug and play.

[royduin]

Would be nice to have in the core by default

[Jade-GG]

For sure, I'm waiting for this to be approved first and then I'll make a PR to the core, checkout theme, and account. Should still have this in the readme though, so that people can easily add it to their own fields :)

[Jade-GG]

rapidez/core#607
rapidez/core#606
rapidez/checkout-theme#120
rapidez/account#53

[indykoning]

Should we also return a 4xx response on an incorrect vat?
https://github.com/rapidez/vat-validation/pull/1/files/33022e7a5301702f72834832d9aa22d6304ce132#r1796635804

[Jade-GG]

Personally, I think returning a 4xx when the VAT is invalid seems improper, given that something being invalid is still a valid output of a check.

I would expect a true or false output, not a true or ERROR 4xx output.

[indykoning]

You could still return false on an error 4xx.
As outlined in #1 (comment)
this is inconsistent with Laravel's validator method.

We could've created a custom validation rule for a valid VAT, resulting in Laravel returning a 4xx response.
Same as how it will return a 4xx now if no vat id is provided, but a 2xx if anything is provided in the vat id field

[Jade-GG]

Sounds fun until you end up getting a FetchError just because the status code is a 4xx 🙂 we would have to work around these pre-existing error handling routines just to get the same effect as just returning true or false, and I don't think I prefer that.

Again, I also don't think that returning a client or server error is the right call in this case. You also don't get an error out of the isEmailAvailable magento rest api query when an email is not available, for example.

[indykoning]

While it would happen more often we would be getting that without returning a 4xx ourselves as well.
Laravel returns a 4xx on validation failure too so we must account for that anyways.

I don't think we need to work around pre-existing error handling, we simply need to handle the error.
Luckily that's an easy fix already implemented here for Graphql https://github.com/rapidez/core/blob/a93fbc0de64a55559149ad0665a8d05339682c17/resources/js/components/GraphqlMutation.vue#L125

So during our catch we just need to check some additional things and change the return value:

return await window
    .rapidezAPI('post', 'vat-validate', data, options)
        .catch(async (error) => {
            if (FetchError.prototype.isPrototypeOf(error)) {
                // Now we know for sure error.response is available
                if (error.response.status === 422) {
                    // Validation did not pass since laravel returned a 422 https://laravel.com/docs/11.x/validation#quick-xhr-requests-and-validation
                    return false
                }
             }

            window.Notify(window.config.translations.errors.wrong, 'error')
       	    return 'error'
        })

Of course we can shorten it to a single if statement if we like

[Jade-GG]

I've made an internal issue for this specific thing for now (key: RAP-948) 🙂