Are there any best practice sources for component engineering using component refs="" within VueJs 3?
For example:
Should refs be used to reference components or solely for HtmlDom references?
Should you expose component methods to using components, i.e., Component A uses Component B; where Component B exposes MethodA, that
Component A calls?
When is it not acceptable or not recommended to use refs; and when would the use of refs be advocated for?
Related
1 I see a some times that a vuex action collects information from other vuex modules using dispatch from other modules. With this it looses its "modulair" flexibility. What is the best practise in this case?
2 Also do you agree that Vue components needs to be kept clean from alot of fetch and formcheck logic and better move this logic to vuex?
isolate the common code between 2 modules into a pure function, then import this function in both modules. You can even use a Class with static methods.
yes, Vue components should be a pure presentation/view layer - the logic must stay into reusable non-visual classes. The form validation checks are especially suitable for pure functions. And fetches could be extracted as static methods into separate Service class (or several such classes, if you want to follow the Modules pattern).
When I started working with vue 3, I saw these notions :
Object-based API
Function-based API
Class-Based API
Composition API
Options API
Reactivity API
Can some one tell us the definitions of these?
Update 2021
I added Options API and Reactivity API
Note that the main docs mention Options-based, and not Object-based, but even in references by Evan, they seem to be interchangeable.
Option-based API is Class-based and Function-based API is Composition API.
Option-based vs Function-based express, what I would call, the theoretical model of how to differentiate the APIs. Whereas Class-based vs Composition differentiate between the implementation.
Options-based/Class-based API
You have the old way used by vue1 and vue2, called class-based, which is referred to as Option-based API.
The naming implies that the component is defined by options. You may think of the options as data, computed, methods etc... They define how a component works by using a set of pre-defined options that you overload.
The downside of this way of defining functionality is that you have the actual component logic distributed between various "options", which makes it harder to understand from the code what the component actually does.
Function-based/Composition API
Function implies that we're declaring functionality of the component (not that it's using functional components). The Composition API makes the code easier to reuse (since you don't need to tightly-couple aspects of functionality to a component) and easier to read and maintain (since you can encapsulate functionality in smaller, dedicated units)
I have just read about functional components in Vue.js 2. (Documentation)
The major benefits of function components seems to be performance improvement:
Since functional components are just functions, they’re much cheaper
to render.
It seems like that for emitting events from functional components an event listener has to be added manually. However props are fully accessable.
What is a good rule of thumb when to use a functional component instead of a class component? Should I prefer using the functional components when I implement a stateless component in general? Or are there any other limitations to functional component in Vue.js?
I was just thinking about this the other day. ..
There are some additional caveats to functional components (e.g. passing classes requires custom handling How to apply classes to Vue.js Functional Component from parent component?)
The rule of thumb I'd use is when the component is when you are using many instances of the component, (so you get a tangible performance benefit) and preferably it's not too complicated in terms of interaction (since you lose most Vue magic)
Is there any other way to pass data between 2 siblings without using event bus or parent component in vue js?
I know that it can be passed with the help of Props and event emission. It can also be passed with the help of event buses.
If it is complex you would go you Vuex is the best solution in my opinion. However, if you just want a simple way to communicate between the components, you can simply go for OO Shared State. This is just a class that maintain your data that you can access from any components just pass it though, similar to singleton concept it OOP. There is a good example how to do this in Laracast website; have a look here https://laracasts.com/series/learn-vue-2-step-by-step/episodes/24.
A general question is going to get a general answer. You need to ask yourself why your siblings need to talk to each other. Most often it's because you're not using a store. It would be a mistake to think of vue components like objects in an OO language. Vue components are fed via reactive pipes from a store, the store is not a vue component. If you're doing this correctly, you don't often need to pass stuff between vue components.
I encounter a situation where component A needs to know about the state of component B when A is asked to perform certain actions (for example, if edit menu is toggled, the save action on the save button should not be performed). My application is structured like a tree with nested components.
I have tried passing all the components I need into the constructor of other components. I find this quite tedious whenever I add more component to the application, I have to pass them all the way down. Furthermore, some components are instantiated under the same constructor, but they need to know about each other. I cannot pass say component A and B into each other since I need to instantiate them in order.
I have also tried using event system to signal between components. (Observer pattern ?) It seems to be more of an overkill and not intended to be used like this.
3rd thing I try is to use singleton through dependency injection. Components register themselves on init to the provider and the provider can be injected to provide access to other components.
The 3rd approach is the most effortless and it is working for me. But I google that Singleton is not a recommended approach since it is just global variable and it entangles the code. But Unity game engine seems to have the same thing ( FindComponentByTag ). What is the general practice for this ?
The standard pattern for handling things like this is MVC (Model View Controller) which usually makes use of the Observer pattern. Components (I guess that you are having GUI components in mind) should not directly access the state of other components. Instead, state should be handled by the model. The components that need to know about the state are registered as observers of the model.