I have two instances of a component on the same parent component and this child component makes an API call in the created lifecycle hook to populate a drop-down list. The list data will be the same for both instances of the child.
So the result is that when my parent component is loaded I'm actually calling the API twice which is unnecessary.
My question is if I want to just call the API once should I either move the API call to the parent and pass the drop-down list items to the child or use vuex and have the parent call an action that calls the API. The action would then save the items to state and the child component will access items via a store getter.
I'm tempted to use the vuex store as the list is small and might be needed elsewhere outside this current parent.
TLDR;
If you want to use it outside of the Parent-> child relationship use Vuex
If you know it will be simple and small, passing it down as a prop works just as well and reduces complexity of setting up the store.
Another option is to store it in localStorage, but this may be less reliable than you want as someone clearing their cache will lose functionality of the dropdown.
You can store it in a Vuex store allowing it to persist for anywhere in the application, however, if the parent is getting the list and it just needs to pass the list of dropdowns to the children, you could also just create a Prop in the children and pass the dropdown list that way.
The Children will have access to the dropdown items and you would not need to add the complexity of Vuex for a simple dropdown in a small app?
You mentioned the list not being very big, and if the dropdown is not something that the User is required to click every time or use, then having it as two API calls is not necessarily bad. You can just load the data when they attempt to access the dropdown at that point, which in some cases may save you and the customer the bandwidth of requesting a dropdown list when not needed.
You should go for Vuex store if you need to render same data to multiple components. Vuex store increases code complexity at initial setup level, but afterwords it is so simple and effortless to use API data in to the multiple components. It doesn't mean that use Vuex store in each application. If you are developing application that is progressive in nature and it will get more complex in future then start using Vuex store. It will help you in future developemnt. Here is all Vuex store details.
Related
I was hoping I could get some feedback on something I'm working on. I'm building an application that is essentially a bunch of data tables. Part of my requirement is not to use any additional frameworks (vuetify) or any type of store (vuex).
Currently, my application is constructed as follows:
API call upon creation of app
That data get's passed into a component where I would like to do all my searching/filtering
From there the next component is built specifically for Pagination
Then to the component that builds the data tables.
My question is, since I have this top down approach, how do I build both the search and filter functionality to where I don't have to pass anything back up to the parent components?
I am using scoped slots to pass/inject data into child components. My first thought was that I would have a computed property that returns an array in the control component and then pass that down to the pagination component, which works, but how do I also use that same array if I want to be able to filter results and also search filtered and none filtered items? Essentially to be able to mock the functionality of some of the Vuetify tables.
I assume you don't want to pass data/prop-drill between 3 component layers?
You can use provide/inject.
You can provide a "setArrayData" method to the child components (2 and 3 levels deep) and also provide "arrayData" data property.
You can also an event bus (see vue docs). In Vue 2 an event bus is built in, in Vue 3 it's not.
In my vue cli project I have a route Settings with 3 child components SettingsA, SettingsB and SettingsC. Each child component has ca. 15 input fields, so it would be too many input fields for one single component.
The goal is to get data from a REST backend with an an axios call when the Route Settings is loaded, and populate some of the input fields with the data;
the user can then navigate between the child components and fill/change the input fields, without triggering the axios call which would reload and overwrite the users input field changes.
Since there are 3 child components I use vuex as store. That way the users inputs should not change when he navigates between the child components.
My question is: Where and with what hook should I make the axios call? With beforeMounted on the Settings Component?
Maybe there is also a better, already tried design than mine?
Thanks for your help!
Solution using custom events
You actually not necessarily need vuex. Basic idea is to have parent component Settings, which includes SettingsA, SettingsB and SettingsC, which are displayed conditionally using v-if. The Settings component is holding your state. Changes in the child components form fields trigger events with this.$emit(). The parent component listens to the events and updates its state. The state of the form is passed down via props.
Solution using Vuex actions
If you go the Vuex route, you will trigger actions instead of using this.$emit() and update the global store. You should import the actions using mapActions. In your components you then have access to the global store using this.$store.
I have two Vue.js parent components.
In one component, it shows available names list which are its child components and in other it shows already selected names list.
What I want to do is that when I click on an available name, it should hide from that component and show it in the other component. And the same if I remove from a selected it should appear in available list.
But these two components are completely unrelated. How can I do this?
Option 1
Create a vuex store:
https://vuex.vuejs.org/guide/
This will allow you to share information between components.
Vuex is a state management pattern + library for Vue.js applications. It serves as a centralized store for all the components in an application
Options 2
Use something called an event bus:
https://blog.logrocket.com/using-event-bus-in-vue-js-to-pass-data-between-components/
With this method you can create events in one component and catch them in another component and they don't have to have a parent/child relationship.
Which option to go for depends on your preference and you will have to determine which is best suited for you.
I'm confused about best practices for passing data from parent to child components and modularity strategies.
As I know there are 2 ways:
Fetching data in parent component and send Array/object to the child via props
Send parent_id to the child via props and fetching data within the child component
Let's assume a use case working with a product edit view, having:
A parent component product
A child form component to edit basic product information
A child related_products component where other products can be linked/unlinked.
As per my experience, the first way works smoothly since it's all done in 1 request to the API: fetching a product object in parent component and passing through props the product itself to the form component and the nested objects to the related_products component. In addition, it can be done in beforeRouteEnter guard so the parent and all its children are shown with all the information at once. The cons I see here is that we have to send the correct object structure to the child component to avoid any error, having a strong dependency between components.
On the other hand, by sending the parent_id to every child component through props we release the parent from any logic. In this case, every child component acts as a "black box" and fetch/handles the information. The cons I see here is that we would have to perform 2 API requests for getting the product and the related products. In addition, the beforeRouteEnter is not viable at all, so we get an empty form/table until the data is retrieved.
This is not about how to code it, it's just about what's the best implementation as per your experience.
As far as my experience is concerned, 1-st way is better. Parent component acts as "smart" and you have access to it's life cycle hooks in order to trigger your api-requests, reset timers, e.t.c... I would also suggest to use vuex, as it allows you to make clean interface of communication between your parent component and "outer world", utilizing actions and getters.
With that being said, your "dumb" child component communicates with it's parent through props and emits interface. And because it is "dumb" - it's easier to test it or utilize something like "storybook".
we have to send the correct object structure to the child component to avoid any error
I guess, at the end of the day, you'll need correct object structure anyway, right? It could not be just random...
I have a VueX state that contains a list of items. E.g.:
{
operations: Operation[]
}
We need to display each Operation as an item in a list. So we have an OperationList component and an OperationItem component.
When it comes to rendering the list (v-for), would it be recommended to pass the entire item as a prop or just the id and have the OperationItem read the data from VueX?
Basically:
<operation-item v-for="operationId in operationIds" :id="operationId" :key="operationId"/>
vs
<operation-item v-for="operation in operations" :operation="operation" :key="operation.id"/>
I think it might be a preference choice but in my projects I usually pass all the prop of the components that way :
<operation-item
v-for="operation in operations"
:key="operation.id"
:prop1="operation.prop1"
:prop2="operation.prop2"
:prop3="operation.prop3"
/>
I'm not sure if that's a good practice or not but in this case, it's more flexible, you don't need to give a structured object for it to render, you just have to give it all it's properties.
A bit like for a class constructor, I would pass all the necessary parameters separately instead of passing them in an $option array or Settings class.
For some components, it also doesn't make sense for them to be aware of the store, they should juste be "stupid" rendered components.
I hope it's clear enough that you get my point !
I'd say pass the entire item. That way your component doesn't need to know where the data came from and you would be able to reuse the component in situations where the data didn't come from Vuex.