Closed DamienLaw closed 2 months ago
That is a fair point, thanks for the clear write-up.
Before I decide what to do about this, I would be interested to hear more about your use case - is there a reason that you need to load the utils script with a script tag at the start of the page, rather than lazy loading it when you initialise the plugin? The downside of the former approach is that it will block the whole page while the utils script (over 200KB) is loading.
By the way, the simplest workaround would be to leave your script tag where it is, and simply use the utilsScript
initialisation option as well, passing the exact same URL, and then it should just re-use the cached utils script.
Alternatively, I've updated the readme to say:
If size is not a concern and you want to preload the utils script, you will just need to hook it up yourself e.g.
intlTelInput.utils = window.intlTelInputUtils;
That should also fix your issue. I'll close this for now, but do let me know if you have any other problems.
That is a fair point, thanks for the clear write-up.
Before I decide what to do about this, I would be interested to hear more about your use case - is there a reason that you need to load the utils script with a script tag at the start of the page, rather than lazy loading it when you initialise the plugin? The downside of the former approach is that it will block the whole page while the utils script (over 200KB) is loading.
In our projects, we bundle and minified several javascript libraries together into a big js file. util.js
is part of the bundle and loaded together with other libraries using a <script>
tag. The bundle would be cached by the browser and the next request would just retrieve it from the cache saving some download time.
By the way, the simplest workaround would be to leave your script tag where it is, and simply use the
utilsScript
initialisation option as well, passing the exact same URL, and then it should just re-use the cached utils script.
If we were to lazy load util.js
, and the file would be cached, will the cache survive page refresh and survive navigating to different pages that are also using intl-tel-input? By default the browser would cache until it's removed unless some cache busting technique is implemented while lazy-loading the file (like appending a timestamp as a querystring while retrieving util.js
).
Alternatively, I've updated the readme to say:
If size is not a concern and you want to preload the utils script, you will just need to hook it up yourself e.g.
intlTelInput.utils = window.intlTelInputUtils;
That should also fix your issue. I'll close this for now, but do let me know if you have any other problems.
It does, thanks a lot for the prompt solution.
According to the README, it doesn't matter if
util.js
is pre-loaded or lazy loaded. So I opted to pre-load theutil.js
using a<script>
tag at the top of the page.In v20.3.0,
intlTelInputGlobals.getInstance("#phone").isValidNumber()
works as expected and returnstrue
orfalse
. This can be observed in this pen here. https://codepen.io/damienlaw-the-scripter/pen/JjVQJORHowever, in the latest version v22.0.2,
intlTelInput.getInstance("#phone").isValidNumber()
returns anull
as shown in the pen here. https://codepen.io/damienlaw-the-scripter/pen/ZEZdyoEAs it turns out,
isValidNumber()
checks if the propertyintlTelInput.utils
is defined. If it isn't, it'll return anull
as seen above.intlTelInput.utils
will only be defined if I lazy load theutil.js
file using the "utilsScript" initialization option.This is the screenshot of the README that says it's okay to pre-load the![image](https://github.com/jackocnr/intl-tel-input/assets/14930009/d4666a0e-587f-467e-b57a-ba333a90073b)
util.js
file.