Minor improvements.
NxtChg opened this issue · comments
-
ops.available.forEach(function(locale)instead ofops.available.forEach((locale) => {to support older browsers. There is no need to be fancy here - you saved exactly 4 (four) characters. -
Don't use fancy strings here:
console.error(`v-localize:\n\tCould not find localization for "${binding.value.item}" in "${localize.locale}" language.`);and everywhere else. Again, why? You don't even save anything here... -
This component should not use localStorage internally - the decision of where to store current locale should be left to the user.
Thank you for the feedback! I'll go ahead and make these changes, to be honest I hacked this together for a small personal project. As far as storing the state of the localization, it was either Vuex or localStorage/cookies -- or at least that's the route I assumed most users would take.
Because localStorage has become an open standard, I assumed it would be the best route to keep the plugin as simple as possible without any need for external libraries. In this regard, would it make more sense to make the localStorage store optional rather then entirely depending on the developer to sort the locale state?
Because localStorage has become an open standard, I assumed it would be the best route to keep the plugin as simple as possible without any need for external libraries.
localStorage is fine, it just shouldn't be inside the component. It's not the job of the component to store the locale.
If not in the component, how would the developer dictate the state of the locale? The plugin currently works like so,
- Plugin is initialized and if a locale is not found, it defaults to the default specified in the configuration and pushes that to local storage.
- When the locale is changed, the locale is updated in local storage and the window is reloaded so on next visit the plugin will automatically load from that localization branch.
I guess I can pass a reference to the store for the plugin to read from and on mutation commit to local storage, but that seems like a roundabout way to go about it.
I guess the plugin is too tightly coupled with local storage in that regard.
It also reloads the window?! That's terrible...
OK, I thought it was a universal component, now I see it's just some sort of hack you did for your own projects...
I don't think such components should be published on vue-awesome, but, alas, they don't check submissions.
Disregarding the state of the locale, how else would we persist current localization? As far as not reloading the window, it would require two way data binding, which isn't a huge deal -- but may cascade into a performance issue with medium to large problems and is pretty difficult to impose on existing projects strictly passing data with props. This could also be resolved using Vuex, but again, it's a simplistic solution to localization.
You shouldn't be changing your localization every so often regardless, the standard end user would only change it once -- causing the window to reload once within the scope of the usage. So you would change your locale to lets say Spanish, and from then on it would persist until the end user opens another browser or clears their cache.
I've removed ES6 references, the plugin should now be compatible with browsers not supporting concise functions, template literals, and the arrow notation. If you have anymore feedback feel free to reopen, I'm open to optimizations.
As far as not reloading the window, it would require two way data binding, which isn't a huge deal
I am not sure what would be the best solution from performance point of view. You could, for example, store an array of all elements your directive is bound to and then update them if locale changes, but that might be overkill. Not doing real-time locale update is perfectly reasonable.
In that case, reloading the window is fine, it's just doing so (and storing locale) inside the component is bad architecture.
What you should do is leave this to the user. Your component should be much simpler: the user gives it the current locale as input and that's it.
Then it will be universal.
Just saw the notification, I apologize for closing this prematurely.
Regarding the list of elements, that's a very fascinating idea! I'm definitely going to experiment around with this -- I'll try and rough up a proposal later.
Regarding the locale being stored in the tagged component, I see what you mean -- I was misunderstanding what you were explaining earlier. I'll play around after work and try and make this less opinionated. Thank you!
Great, I will keep an eye on it!
@NxtChg I finally got around to releasing 1.1.0. Let me know what you think! Users can now choose between reactivity and reloading the window when initializing their Vue instance.
In 'example/vendor' the name of v-localize.js should be v-localize.min.js, otherwise it's not found.
After I fixed it, the page went into infinite reloading loop with this error in console:
"Localizations for locale [object Object] not found."
I see that you added the ability to update localization on the fly, but the major problem is still not fixed: the component stores the locale inside and also still refreshes the page if hot update is not enabled. This is not its job. If you want it to be universal you should fix it.
Fixed the example; nice catch! It will be available in version 1.1.2. Regarding the current behavior of the $locale function, I'll have stale mode phased out soon -- I'm working on a few more performance improvements.
Is my approach for updating binded directives too hacky though? Or do you think it will suffice.
I'll have stale mode phased out soon
Not sure it's a good idea to phase it out completely. It's nice to have an option - to track or not all elements for hot update. If the user doesn't need hot updates, no reason to waste memory/cpu.
Is my approach for updating binded directives too hacky though?
You mean this: Vue.directive('localize').bind(e.el, e.binding, e.vm); });?
I don't even understand how it works because using Vue.directive() like this is not documented :)
So it's probably not a good idea to do it like this.
I also don't see you tracking changes, i.e. removing elements from 'linked' list on 'unbind', monitoring 'update', etc. Did you test it with dynamic elements, which can change their text, for example, or be removed?
I see, that makes sense. So write to local storage but don't force a window reload on stale? Regarding unbinding elements, didn't cross my mind -- I'll also add that into 1.1.2. Thanks for all the feedback man!
So write to local storage but don't force a window reload on stale?
Yes. Except don't store locale inside too :)
The reason I am telling you that it's not the job of this component is that there is no way you can anticipate where the user will decide to store his locale: in localStorage, in IndexDB, in cookies, or as a simple "/en/" url path! What if I want "en.mysite.com"? What if localStorage is turned off in user's browser? My site works perfectly, but your component now does not.
You see my point here? Right now it's not universal and it can't be. The only way is to give the choice back to the user.