I develop my own vue components library, and this components have a lot of texts that needs to be localized. vue-i18n doesn't support this, because it should be attached to Vue (e.g. Vue.use(VueI18n)), but in case of component library, it will result in conflict.
I need to have independent translation files in my library, totally separated from my application (to prevent conflicts)
I'm struggling to find any answer to this question in other sources, and I hope someone can give me example for this case. Thanks in advance.
Well it really seems that vue-i18n is not tailored for use in component libraries for reasons you are mentioning (attaching itself into Vue.prototype + conflict with user's code).
I don't know what features of vue-i18n are you using but if it's just simple translation, it seems rolling your own custom solution with an option to plug in the i18n library of user's choice would be the best. It's not that hard. Most of the component libraries are going that way...
You can take a look at how "big guys" do it - in this case Vuetify.
Docs
Code
Related
I'm very new to nuxt3 and want to know if i't possible to use it with quasar. specially that quasar has his own ssr system .
does anyone successfully created a project with these two frameworks ?
i tried to look if there is any open source projects with these two frameworks but i couldn't find anything useful
Got that question answered here: https://stackoverflow.com/a/67604708/8816585
The TLDR is why would you mix both if they are doing the same thing. What does Quasar have over Nuxt (or the opposite)? Take one, it will allow you to do anything from the other afterward if needed.
Quasar is already 147kB, not sure that it's wise to add that to a Nuxt3 app anyway.
I really love using Svelte but at this moment, one of its cons is the lack of ready-to-use components for Svelte. I want to use vue-atlaskit in a project, but I really prefer using Svelte. Is it possible to use vue components inside a Svelte app?
I guess it all should be just "web-components", but I really don't know how to do it.
I checked with people in the Svelte Discourse. There is no simple way to do that. The suggestion is to convert the UI components I need from Vue to Svelte.
While not a comprehensive answer, I would add some findings on the topic:
As you suggested, I would try with Web Components. According to Custom Elements Everywhere the support for Web Components is fairly high for both frameworks. Vue states that the support is 100% although the site shows less so there is some discrepancy. But basic tests pass 100%. Svelte is also at 100%. This paints a fairly positive picture.
There is another question on SO that refers to consuming Web Components in Svelte.
Here is another reference article on how to create web components with Vue 3.
Note: I will try to update the answer as I learn more. I will be testing this out on a migration of a PWA from Vue to Svelte, where I plan first to use Svelte components in an existing Vue app and then perhaps switch to using Vue components in a Svelte app, depending on how things go with rewriting.
Angular 2+ offers Modules (NgModule)s that "configure the injector and the compiler and help organize related things together." They are another layer of code organization, to facilitate modularity of parts of large scale applications.
I am NOT talking about Node modules. Angular has those too. NgModule is unrelated to that.
So far in learning Vue.js, I'm not coming across anything that is analogous to NgModule. Searching for this information was not fruitful on search engines. Is there anything? Or does Vue.js in some way make them not necessary?
They are another layer of code organization, to facilitate modularity of parts of large scale applications.
No, ngModule is the only way the Angular ahead-of-time compiler can discover, walk and tree shake providers that are not required for the project. This includes things like components, directives, services, etc that you would define in modules.
So far in learning Vue.js, I'm not coming across anything that is analogous to NgModule.
You shouldn't because this is an Angular specific feature. Vue has no dependency injection or lazy loading as a core feature.
Or does Vue.js in some way make them not necessary?
You might be confusing Angular NgModules with JavaScript modules. The two are not the same, because Angular uses NgModules to make it's dependency injection system work. Without the DI there really is no need for NgModule. Angular would then work the same way Vue and React work, and use the JavaScript import to resolve dependencies.
Angular is an opinionated (I don't mean that as a negative) and monolithic framework. It uses ngModules for organization. They are a benefit by default. Vue is a progressive framework that allows you to include as much or as little as you want.
Vue Plugins allow for mass registration of components if you need it, but you can just as easily narrow your dependency tree using explicit import/export statements.
Vue Bootstrap has a Vue Plugin mechanism that allows you to include all of the features outright including the custom elements it provides but also allows you to import each component individually if that is what you want.
Angular Powered Bootstrap provides an ngModule in much the same way but also allows you to include components piecemeal if you want.
The key thing here is that Vue tries to be as non-opinionated as possible and lets you configure how you want dependencies included whereas Angular wants you to do everything its way. Neither way is outright better than the other. You benefit from knowing how do to things by default with the opinionated way vs having way too many choices with the non-opinionated way.
Consider this question, how do you perform network requests with each of these frameworks? The answer is obvious for Angular: HttpClient. However, you can use whatever request library you want in Vue, be it fetch, axios, jQuery.get() or anything else as long as you appropriately deal with Vue's reactivity model. You can likely do the same thing in Angular, but you're going outside of Angular's suggested approach.
You likely don't see a lot of documentation about comparable things to ngModule because Vue doesn't really push for organization in that manner. Again, not a judgement, it's just a difference in how the frameworks are intended.
What is the most elegant way to get a riot based UI today?
i'd love the following points to be addressed:
A proper code-mapping for easy debugging
A good way to bundle the application (so far i used Webpack and JSPM)
It would be lovely if it would work elegantly with Typescript.
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
If you have more items for consideration - please add them....
Thanks for asking these questions. I have tried to answer to all your questions hoping they could be useful also to other Riot.js users
A proper code-mapping for easy debugging
the riot compiler generates simply javascript code without modifying too much the structure of your original source code. Any modern browser should be able to provide with debugger breakpoints and console calls all the debugging tools you need. Check for example the stack trace of this error you don't need much more to figure out where it's coming from.
A good way to bundle the application (so far i used Webpack and JSPM)
In this repo we provide 3 different javascript bundle examples: rollup, webpack, riot-compiler. I personally prefer rollup but you can (and should) use whatever works best for you and your team.
It would be lovely if it would work elegantly with Typescript.
The riot public methods are already available as Typescript interfaces:
- https://www.npmjs.com/package/#types/riot
- https://www.npmjs.com/package/#types/riot-route
I am not a typescript user and that's why I will not invest time in making examples in a technology I don't use but PR are welcome
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
I recommend you to just use Tag files because riot was designed as component library and it embraces completely the philosophy of components composition vs class inheritance. If you have code you share across several components you can either use mixins or import it with your bundler directly in your tags see for example
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
Riot 3 will be not compatible with Riot 4. (that will be a full rewrite) I can't recommend any best practice to make your code portable to Riot 4. Remember that Riot 3 will be still supported and your code will run even on IE9 for the next 10 years. Once riot 4 will be released and the API will be stable I can provide more hints about a migration path.
I have been trying Vue.js with ASP.Net Core for the last week and it seems quite powerful.
However, I have seen different approaches in the way how files are organized and modules written.
In the javascript spatemplate, they use, I would say this structure with ts, html, css files:
|_components
|_counter
*counter.ts
*counter.css
*counter.html
In other starter Vue.js templates, we have this structure with one single vue file:
|_components
|_counter.vue
Is there a limitation/advantage in using one over the other? Is one being more recent and should superseed the other format?
I have also see that they are different way of writing component for Vue in Typescript.
The default one presented on the Vue website and the other way using the vue-class-component or the vue-property-decorator which looks more natural to me and is recommended on the Vue website as it seems to solve some issues: link.
Again if it is that good, why shouldn't it become the standard? Does the default style gives more flexibility compared with the 'vue-class-component' style?
Sorry for the basic questions, just trying to get the good directions from the beginning.