This PR makes the async import of libphonenumber-js-utils (from initRequests) a blocking import, resolving the problem from #347 (and any RTL-related issue that has the async import not be ready in time for the test). The asynchronous import really seems to be causing trouble with test runners. Clients are probably safe because so many things are happening in the browser that the user can't see the delay between the async import start and resolution.
Since the component is inert until the validation logic is ready, which happens when the import is done, it might make sense to have this toggle a loading state of some kind.
This is still an experiment
Todo
[ ] Evaluate impact on usability
[ ] Implement loading state based on whether the import is ready or not.
Types of changes
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
[ ] I have used ESLint & Prettier to follow the code style of this project.
Description
:construction: WIP
This PR makes the async import of
libphonenumber-js-utils(frominitRequests) a blocking import, resolving the problem from #347 (and any RTL-related issue that has the async import not be ready in time for the test). The asynchronous import really seems to be causing trouble with test runners. Clients are probably safe because so many things are happening in the browser that the user can't see the delay between the async import start and resolution.Since the component is inert until the validation logic is ready, which happens when the import is done, it might make sense to have this toggle a loading state of some kind.
This is still an experiment
Todo
Types of changes
Checklist: