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.
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'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
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've been reading about Durandal and Aurelia every time I read something new on Javascript. I hear developers asking to upgrade from Durandal to Aurelia, or similar, on so many blogs. Although I do have an idea, I am confused about what the two really are and how they are related, or if at all they even are related.
Here's how I see it. Durandal is a lightweight SPA framework that allows you to leverage the best of other JS libraries and utilities to build an app. So it's not really a whole package in itself (unlike Angular), but can use different external JS libs - such as Knockout for binding, jQuery for DOM, Sammy for routing, etc.
Aurelia, on the other hand, is where the confusion comes in. Is it also an SPA framework? Or is it limited to being a client-side (front end) framework only? To add to my confusion there is a Durandal blog that talks only about Aurelia. I know from the internet that Rob Eisenberg worked on Durandal before he started working on Aurelia. So is Aurelia an upgrade of Durandal, or something completely unrelated?
I still have some questions but I'm guessing the structure of my question so far will be only asking for opinionated answers. So before this question is closed, any description, links and references in regard will be amazing. I'll be sure to update and add useful links here too.
According to Rob Eisenberg:
"Aurelia is just a vNext of Durandal. On occasion we've even called it Durandal Aurelia. Much like XBox 360 vs. XBox One. The web is significantly evolving, so we're evolving Durandal into Aurelia to match."
Aurelia, on the other hand, is where the confusion comes in. Is it
also an SPA framework? Or is it limited to being a client-side (front
end) framework only?
Yes, it is a SPA framework. Actually, it is a framework for building Javascript clients, it means you can develop apps for Browser, Desktop and Mobile. Take a look at this video https://channel9.msdn.com/Events/Seth-on-the-Road/DevIntersection-2015/Rob-Eisenberg-on-Aurelia
Different from Durandal, Aurelia comes with the full package, everything you need is there. However, it is perfectly pluggable and extensible, and you can combine any other technologies if necessary.
Here is description provided by the official site www.aurelia.io
What is Aurelia?
Well, it's actually simple. Aurelia is just JavaScript. However, it's not yesterday's JavaScript, but the JavaScript of tomorrow. By using modern tooling we've been able to write Aurelia from the ground up in ECMAScript 2016. This means we have native modules, classes, decorators and more at our disposal...and you have them too.
Not only is Aurelia written in modern and future JavaScript, but it also takes a modern approach to architecture. In the past, frameworks have been monolithic beasts. Not Aurelia though. It's built as a series of collaborating libraries. Taken together, they form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia's libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS."
Some of the greatest advantages of Aurelia (in my opinion) are:
Powerful Data-binding. Different from others frameworks like Angular, Aurelia uses new features of Javascript. So, all data-binding stuffs are usually faster in Aurelia (source http://blog.durandal.io/2015/12/04/aurelia-repaint-performance-rules/)
Simple Conventions and Simple Syntax. It is really easy to develop in Aurelia. There are a lot of features ready to use. If you want to overwrite some convention, usually 1 line of code is enough. (see http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.3/doc/article/getting-started)
Hope it helps!