Kontext
Vue 3 provides a way to create "Custom-Elements": https://vuejs.org/guide/extras/web-components.html#building-custom-elements-with-vue
The idea as far as I understand it, is to create Custom Elements, that can be used anywhere, as a Web component.
Here (https://vuejs.org/guide/extras/web-components.html#building-custom-elements-with-vue) the developers specifically recommend using custom elements for component libraries.
Environment/Motivation
A client has a bigger UI Project that is based on other frameworks. He wants to switch to vue, but doesn't have the resources to completely rewrite/replace everything with a normal vue application. Therefore he wants to replace everything step by step by using webcomponents or more specifically, vue-components (with all the advantages of vue) that are compatible with his project.
Problem
The custom elements don't have global vue instance, because you don't mount a custom element, rather you mount a vue application.
However many libraries and packages like i18n, primevue, vuetify, (vuex), ... assume, that they are used in a global instance. At least their documentation requires adding them to the global app instance, otherwise, various features don't work.
Question
How can I use libraries that require a global vue instance to work, in the context of multiple custom elements?
Implicit Expectation
As a developer, I assumed, that major libraries like the ones I mentioned work for custom elements as well. I know that this requires each element to include a small "app instance", which I would guess could lead to performance issues.
For E.g. you create a Website with 100 custom elements with each having an app instance.
If these performance issues I worry about are not essential, then I still could create a classic Webcomponent where I mount a vue app on it. (Following this comment, which I tested and it worked with some adjustments: https://github.com/vuejs/vue-web-component-wrapper/issues/93#issuecomment-909136116)
Related
I am newer to programming and looking at Vue.js. I understand that an API is basically a software intermediary that allows two pieces of software to talk to each other? I don't understand why in Vue.js the system for setting up the component with data, methods, etc. is known as "Options API". Isn't is just part of Vue? What exactly are the 2 pieces of software the Options API are connecting?
Perhaps I need a better understanding of what API means in a more modern context as well!
TL;DR: options API it's a Vue lifecycle connector.
Options API of course is part of Vue. Is the way we use to communicate with Vue's core, so we can manipulate the app. They have their own structure, like React.
Vue has his own lifecycle:
Knowing that, we can start building our app around Vue.
We use Options API in a Vue application to write and define different components. With this API, we can use options such as methods, watchers, mounted, created, beforeMounted, etc...
Compare it with a normal JS app and you will see WHY it's called "API"
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'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
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 exactly are the differences between the following (when to use what):
Vue Components
Vue Plugins
Vue Mixins
Components are elements. They are like Blocks of functionality and layout that you would use to build an application or UI. Components can be extended, doing so uses aspects of the original component while giving you the ability to add other functionality.
Similar to extending existing component, you can use a mixin, which is much like a component you'd extend, but it adds functionality to an existing component.
A plugin adds top-level functionality that can be accessed by any component.
The use depends on what you're trying to achieve. Things like routes and state management are a good fit for plugin, because it allows you to affect/listen to changes across the application without setting up props or listeners. But you wouldn't use them for a component-specific functionality, because they would pollute your app.
Mixins is a controversial feature that some argue should not be used. The idea is that Component wrapping or Higher Order Components can implement in a more robust way. more info here:(https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html)
The components are fundamental to building a vue app, so you can't get around using them, but there are ways you can get more out of them. Vue allows use of slots, which help cover some of the functionality, that the react community prefers higher order components does.
If you're relatively new to Vue, I would advise that you don't use mixins, hold off on Plugins until, and spend time with implementing functionality using components and if you're creating re-usable components utilise scoped slots. https://v2.vuejs.org/v2/guide/components-slots.html