My Storefront application have more than 50 custom CMS components.
SSR build creates separate JS files for each CMS component when applying LAZY LOADING OF CMS COMPONENTS approach.
Does it won't create any performance impact?
Generally speaking, using lazy loading of modules is recommended over lazy loading of components.
Historically, components lazy loading mechanism was created at a time where lazy loading of modules was not yet available.
But now lazy loading of modules is the preferred way to go.
Related
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)
I'm using Nuxt.js v2 for my project. Right now, I've enabled nuxt.js auto import for components by setting components: true in my nuxt.config.js file. I'm wondering if using components auto import has any negative effect on performance of my site in production?
Should I import components manually like what you do in vue.js?
The auto-import feature is just for some DX (developer experience) to not have to type the whole thing. The template will be scanned when you're shipping your code (or during compilation maybe) but the performance will be exactly the same as if you're importing the component manually.
At the end, the parsing needs to be done by the Vue render engine anyway. So, here the Nuxt team is providing a tool that helps you code faster, it's not doing more compilation on the template itself but ahead of time.
Hence why no performance penalty.
There is actually quite a lot of libraries (Nuxt3, Vitesse, etc...) with the auto import of components and Composition API hooks done for you. Don't worry since if it had any impact, it would not be used that widely.
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.
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
I'm already familiar with Knockout, Angular, Sammy, jQuery, a little breeze, and a little ember. The tutorials and getting started for Durandal all seem to be saying... well first add jQuery and maybe knockout.
Does it handle something entirely different than all of these?
What need does it address such that it is likely to be used with knockout?
Is it just a hodgepodge of client side routing and ui components?
What does it do on its own conceptually?
Durandal is similar to Angular in that it provides a MV* framework for client-side SPA web applications.
Angular is mostly, if not all, custom code, whereas Durandal takes existing libraries, mainly Knockout and RequireJS (Sammy dependency has been obviated with the 2.0 release), and provides the plumbing to provide full SPA functionality, including view/view model composition and hash-tag (spa) navigation.
As for Knockout, Durandal relies heavily on Knockout to compose the views and view models. Your view and view model are automatically data-bound when the view is injected into the DOM. The advantage to this is that I can use Knockout to provide the V/VM data-binding, and let Durandal do the work of figuring out which v/vm to use, retrieving it from the server, and composing it into the current screen.
Restated, Durandal provides a way to map views/view models to hash-tag based routes, which give you the SPA navigation. By specifying a shell, or layout, view as the main view, a placeholder can be added which Durandal uses to implement what is basically a "screen presenter" pattern. Durandal listens to the URL changes, and can automatically activate, data-bind (using Knockout), and display the view that matches the current URL route.
If you're familiar with WPF, you may think of Durandal as providing Prism-like functionality as its main offering, along with other goodies designed to support building single-page-applications for the web.
Durandal has several benefits, but also builds on existing libraries. It has a dependency on
RequireJS
Knockout
jQuery
These are not "maybes." They are hard dependencies. Durandal cannot work without them.
At it's core, Durandal add's the very powerful compose binding to knockout. This binding will automatically locate the view (an HTML file) when passed a viewmodel, retrieve it from the server, bind it to the viewmodel, and insert them into the DOM. Similar behavior can be achieved using the knockout template binding, but managing the templates can become cumbersome. Composition also adds lifecycle events to the process, which can help ensure that viewmodels are setup and torn-down correctly. It also provides optional DOM caching.
Durandal also provides some framework structure. It provides a simple plugin API, which is used by its router to give SPA navigation via hash or push-state. It encourages the organization of viewmodels and views by overridable convention, as well as the use of Require AMD modules. It also provides a simple event module to allow application wide events to be created and consumed.
Durandal is a "full featured" SPA framework, whereas Knockout is just data-binding. It is similar in scope to Angular.
Magento 2 stand on Knockout and RequireJS.
Durandal can be added on top of it so more possibility come with use latest features (components, templates etc).
It is better because:
it is more stable and major than other framework, less errors occur
great documentation
simple api
more SEO friendly! (you can have all html seved and use it like component, mixed situation). Angular 2 stand on mixing logic with presentation.
html5 standard data and binding with better code redability (just try read html in react)
still maintained
creator of Durandal was for some time Angular Developer (3 month) so there is some similarity going on there in thinking.
Work in old browser ! (IE6 >)
There also cons but mainly because it don't give so much function in one pack and not newly, cutting edge technology, was adopted.
Pleas share more point about Durandal :)
More there: https://johnpapa.net/compare-durandal-to-angular-not-knockout-to-angular/