A Vue "Native" component set Vs. "JS" Component set
-
Question for those who are deep into Vue & Quasar (The Experts).
When I started reading up on Vue (Not too long ago) and trying to learn it, is how Vue creates it’s virtual DOM and all the Vue parts/components are under the supervision of the Vue system. So when a third party like Quasar builds components, I assume the guidelines ad strategy of Vue how to behave in that Virtual DOM.
But I also see many other third party kits that “claim” they run in Vue, but when I look at their samples, they look like they are manipulating the original DOM (similar to jQuery) but now through JS and NOT how how Vue works.
Vue has data modeling & binding built into it, where as those samples I saw, they were doing it manually via event and methods directly to the DOM.
So my question is, is there such a thing being a “Native” vue component like Quasar, or ALL js components work in Vue like the same?
And secondly, how can one to check if a set of components are true native Vue components or just JS. components? How can we verify if the vendor isn’t telling the truth?
I need some light to be shed on this, because I needed to defend Quasar of being a “Native” framework for Vue.
Thanks!
-
As I understand Vue and Quasar, and I’m far from an expert btw, the basic answer to the question of “is it Vue native” can be answered with a question. Is the code using Vue’s render function? Naturally, this can be done either through SFC’s/ components, which get compiled down to the Vue render function or, as Quasar does it, use it directly. Here is a snippet of code from QBtn.
Notice the render function and the “h”. I believe h is the createElement function.
If the code being used isn’t using the render function in some way and it is manipulating the DOM directly through some other method (like with jQuery or with JS directly), then it isn’t Vue native code. It might be a mix, but that would make their app, component/ component system or framework much harder to understand and reason about and thus, work with. Basically, everything Vue boils down to is the render function and createElement functions and the data object.
These are the things needed to build out the Virtual DOM used by Vue. Oh, and the Virtual DOM is key to the speed and performance of Vue. If anyone uses anything else, they are sidestepping good performance too. Hope that helps.Scott
p.s. Anyone with more knowledge do correct me if I am wrong. I’m learning too.
-
Scott, what you explained, concurs with what I’ve learned about Vue’s strategy and how it works.
The summary of my question was, when we see a kit from vendor XYZ and claims it works with Vue, how do we verify if it is a true “Native” component and follows the true ue guidelines?
Because a lot new beginners can fall into adopting some kits that is just a generic JS or a wrapper to jQuery (like Telerik Kendo UI Vue), which is a bloated library and they claim it’s a Vue component.
I’m hoping that Vue site will have a list of all the true native vendors.
-
These are the things needed to build out the Virtual DOM used by Vue. Oh, and the Virtual DOM is key to the speed and performance of Vue
-
@ماشین-شناس
Of Course.
BTW, what kind of cars do you know?
-
@Ben-Hayat - I answered your question, I thought.
I’ll put it another way. If a framework is doing anything other than manipulating the Vue virtual DOM (with either SFCs/ components or the render function), then it isn’t a “Vue-Native” framework.
Maybe they are using Vue’s render function/ component system and some other DOM manipulation method. If they are, that would be like tag lining up a Vue speed boat to an oil tanker and saying “it’s still a Vue boat”. Yeah, it might be using Vue, but all the crap hanging on to it (the oil tanker) is slowing it down, making it hard to understand, etc.
Whoever is doing that kind of DOM manipulation mix doesn’t understand Vue or reactive component UI systems and I’d stay far, far, far away from any such system.
Scott
-
excuse me mr ben hayat whera are you from
-
US!
-
I hear you Scott, and I agree fully. It’s just I need a rich Data Grid, Scheduler and Kanban and mostly are from the old jQuery wrapped to run with Vue.
I was reading an statement from DevExpress that was very interesting about “Reactive Component”
“Unlike the wrappers, DevExtreme Reactive Components are native Vue components.”
https://js.devexpress.com/Documentation/Guide/Getting_Started/Widget_Basics_-_Vue/
-
Yeah, the wrappers I wouldn’t touch. Although I haven’t looked, they have to be a bunch of bloat.
Scott
-
I’d just like to add that it’s not necessarily a bad thing to mix direct dom manipulating components/widgets into your Vue app, as long you understand the potential problems and can verify that those components won’t cause such problems. The only thing you need to be careful about are situations in which both Vue and the non-Vue stuff are trying to update the same pieces of dom. When that happens, they’ll each overwrite each other’s changes because neither are aware of what the other is doing. But in many cases, the non-vue components (such as some jquery components) ‘own’ the sections of dom that are rendering that particular component, particularly if they’re configured to execute in Vue’s mounted hook, when Vue is done doing its thing for that render cycle, then they’re not stepping on each others toes.
For example, I’ve used utilities like stickybits in more than a few Vue apps to aid in sticky positioned elements. StickyBits works by directly manipulating the dom and adding/removing classes to targeted elements. It’s completely safe to do so, so as long as you’re utilizing things like that in a Vue safe way. My point is, although there is a difference between vue rendered components and vue safe components, limiting yourself to only vue rendered components might unnecessarily prevent you from taking advantage of a vast library of useful stuff out there.
-
Sure, you CAN use the components/ features of other frameworks, but then you are adding the bloat of an extra framework to your site/ app just for those one or two features. That sort of defeats the purpose of having “A” framework. Right? So, there are two concerns to have, when mixing frameworks. One is the side-effects they may have. The other is the bloat.
Better to use Vue’s version of sticky as a directive: https://github.com/rguanghui/vue-sticky
Edit: There are times, where you need other “frameworks”. But, they should be specialized in doing things outside of DOM manipulation. One example was in another thread here in the forum, where a user was adding Apex Charts to their application. That is an SVG Charts framework. Sure, it manipulates the screen, but it isn’t a DOM manipulation system per se. I think you get my point.
Scott
-
Hah! Forget the Vue directive. Quasar has it’s own Sticky feature. Should have known that.
https://quasar-framework.org/components/page-sticky.html
Scott
-
I think you’re confusing the terms “framework” and “library”. I don’t think anyone was advocating mixing together frameworks. That would be a bit… crazy. But utilizing libraries is a very different thing. And not to get off topic, but vue-sticky does not have the desired features.
-
No. I was under the impression that Stickybits was needing jQuery to function. I see that it doesn’t looking deeper. My statement is still true about mixing frameworks.
Scott
