I'm confused of Classic Mode and Module Mode of Vuex Store, I dont have the difference between this both. Now I'm using Classic Mode and I have intend to switch to Module Mode.
https://nuxtjs.org/guide/vuex-store/
Please show me the difference of two modes and what is the better choice?
Vuex https://vuex.vuejs.org/guide/modules.html explains this quite clear:
"Vuex allows us to divide our store into modules. Each module can contain its own state, mutations, actions, getters, and even nested modules"
Module mode of vuex is confusing because official documentation is clear.
I searched for proper documentation, but couldnt find one, however come across this video on youtube.
Though language is not English, you still get the idea.
The concept is explained with'a simple example.
https://www.youtube.com/watch?v=chnHCJz6xK8&t=896s
Hope this will help.
Related
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.
I wanted to know how to use Microfrontends with Nuxt or at least Vue.
Is there a plug & play simple solution to have it working quickly?
I've heard about Webpack's v5 ModuleFederationPlugin for example, is this a valid thing to start my Nuxt project?
As of today, Nuxt2 is still using Webpack4 so ModuleFederationPlugin will not be a possible solution.
Nuxt v3 will come with Webpack's v5 support and you'll probably be able to try it then. I also heard that the same could be used with Vite btw.
As a general answer, you need to understand that a Microfrontend is not something simple to do. It is more about how you do structure your app in the larger scope.
It's like having a micro-service on the backend: it can be done is multiple ways and it all depends of the needs of the company/team.
If you do create a Vue2 or Vue3 project with the Vue CLI, you'll still have Webpack v4. You can probably try to make the upgrade yourself if planning to use ModuleFederationPlugin.
As an alternative, there is single-spa. This is a way of doing it (probably not the only one).
Here is a podcast show talking about the subject in depth: https://devchat.tv/views-on-vue/building-micro-frontends-with-lawrence-almeida-vue-160/
It may be relevant to understand the general way this is working and also the pro/cons.
If you're not satisfied with this approach, there are a lot of articles on the Web talking about Microfrontends and some Google-fu will be enough to give you an alternative way.
Is it possible to install Vue 3, but still do things the "Vue 2" way? In other words, I see that Vue 3 has the new Composition API, but is that optional or the required way of doing things in Vue 3?
For some reason, I was thinking that Vue 3 still allowed you to do things the Vue-2 way, using the Options API instead. Is that not the case? Thanks.
Vue 3 does not require using the Composition API. The Options API is still available and will not be removed, as explained by two Vue core team members:
Thorsten Lünborg in Vue 3: Data down, Events up (19-MAY-2020):
IMPORTANT: The composition API is additive, it’s a new feature, but it doesn’t and will not replace the good ole “Options API” you know and love from Vue 1 and 2. Just consider this new API as another tool in your toolbox that may come in handy in certain situations that feel a little clumsy to solve with the Options API.
Ben Hong in Enjoy the Vue #48: "New in Vue 3: The Composition API" (19-JAN-2021):
[00:01:03] T: Yeah. Well, the first thing I remember hearing was that it was replacing the options API.
[00:01:08] BH: Big disclaimer. That isn’t happening. Big disclaimer.
...
[00:09:10] BH: [...] this is not something you need to go and rewrite your app in. [...] the composition API is not like, drop the options do composition. It's an additive thing that when you have a problem that it can solve, it's really great for that.
An early RFC for the Composition API had only considered deprecating the Options API:
A previous draft of this RFC indicated that there is the possibility of deprecating a number of 2.x options in a future major release, which has been redacted based on user feedback.
The Vue docs also confirm this:
Will Options API be deprecated?
No, we do not have any plan to do so. Options API is an integral part of Vue and the reason many developers love it. We also realize that many of the benefits of Composition API only manifest in larger-scale projects, and Options API remains a solid choice for many low-to-medium-complexity scenarios.
I'm wondering if there's someone knowledgeable in Vue(2 or 3)'s reactivity that might be able to answer this question and explain reasons.
This is regarding features such as data() reactivity (getters & setters), computed properties, a global Vue instance, and even a Vuex store.
Is there a way I could tap into just these non-browser javascript features for use in a backend-only Node.js application?
I need a way to have a global store holding temporary data that can update "components" in other files via mapState/mapGetters.
I'm using lowdb currently for this because it suits my needs in terms of shapeable JSON objects, where something like redis is key:value-only. (Don't want to get into a more complex redis/rejson setup.)
Basically I need a globally accessible relatively-full-featured reactivity system on the backend, without global variables or needing to set up a custom Rxjs system, which is a bit over my head and will take too much momentum away from my goals, time-wise.
I'd appreciate any input. Thanks 🙂
Vue is designed to run inside Node to support SSR (server side rendering). There is already a good post here on SO with simple sample for Vue 2 (using Vue + Vuex)
But it seems overkill to me. If you want something much simpler and lightweight, you can use package #vue/reactivity which is normally part of the Vue 3 but can be used completely standalone. It is basically Vue 3 reactivity system based on JS proxies
Why would I choose this approach:
No Vue 2 Change Detection Caveats
More "functional" API (designed for their new Composition API) with much better support for TypeScript and type inference (even without TS)
I think Vuex API is super bad (using string constants for data mapping - especially with modules. It's pain...)
As it is part of Vue 3, you can use it's documentation:
Basic Reactivity APIs
Refs
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