Related
I'm creating a Vue3 web app and I was wondering what is the best way to pass data from parent to nested components (more specific, from parent to child of children).
Let's say I have this schema:
Card
|
|
CardHeader CardBody
|
|
BodyHeader BodyParams BodyResponse
And I want to know the best way to pass data from Card to BodyHeader, BodyParams and BodyResponse
On Card Component I will be fetching some data from an API. Lets say that i fetch a json like this:
{
header: {
title: 'hello header'
},
body: {
headers: ['authorization', 'anotherheader']
params: ['currency', 'hair'],
response: ['200', '401']
}
}
I know I just could do this:
<Card/> :
<template>
<CardHeader :header="hedaer"></CardHeader>
<CardBody :body="body"></CardBody>
</template>
Then, in <CardBody/> :
<template>
<CardBodyHeader :headers="body.headers"></CardBodyHeader>
<CardBodyParams :params="body.params"></CardBodyParams>
<CardBodyResponse :responses="body.responses"></CardBodyResponse>
</template>
<script>
import CardBodyHeader from "./CardBodyHeader.vue";
import CardBodyParams from "./CardBodyParams.vue";
import CardBodyResponse from "./CardBodyResponse.vue";
export default {
components: { CardBodyHeader, CardBodyParams, CardBodyResponse },
props: {
body: {type: Object}
}
};
</script>
But I don't know if that would be the optimal solution.
I guess there are many ways, you could do that.
Easiest one would be state management, and you can use something like Pinia and Vuex to do so or maybe even write your own store (But why do that when you have Pinia).
Second one would be the usage of props, but you should keep in mind that props should never be mutated.
==> https://vuejs.org/guide/components/props.html
Third one would be the use of Vue3 (Provide / Inject) as seen on the docs ==> https://vuejs.org/guide/components/provide-inject.html
You can also send data from a child to a parent component Vue's built-in $emit() method.
But of course each and every one of these is solving different problems, so try to have a quick read on docs about each and every one of them to solve the issue you're facing, and to know which to use on the upcoming issues you might face.
If you don't use any state management library like Vuex or pinia.
I suggest you to use provide/inject to prevent props drilling.
You need to provide the data from the most parent component, and in the child components that need these data, just use inject
Ex parent:
export default {
provide: {
message: 'hello!'
}
}
Ex: nested child
export default {
inject: ['message'],
created() {
console.log(this.message) // injected value
}
}
I'm learning Vue and trying to test out how I'd pass a user input from one function to another.
My use case is this. I want to take a users input, store it and then supply that to a second function as a variable that it can use to make an API call.
In isolation the two code sections are:
User Input
<div id="v-model-basic" class="demo">
<input v-model="message" placeholder="edit me" />
<p>Message is: {{ message }}</p>
</div>
Vue.createApp({
data() {
return {
message: ''
}
}
}).mount('#v-model-basic')
API Call
import axios from 'axios';
/* API call for the weather data */
export default {
name: "Weather",
data() {
return {
weatherList: []
};
},
methods: {
getweatherData() {
axios.get("https://anAPIpath.com/that-I-want-to-add-user-input-to").then(response => (this.weatherList = response.data));
}
}
};
Is there a way to do this in Vue where they are both methods within that export function, or is that just the wrong approach? As mentioned, new and learning Vue and I want to ensure I approach this the "Vue way" so things are as neat and tidy as possible.
Vue has several options for passing variables between components.
props
You can make the variable a prop of the other:
props: {
message: String
}
The prop is accessed with this.message but it is recommended you copy it to a variable in data and reflect changes with $emit (see documentation link, and $emit section below).
See documentation: https://v3.vuejs.org/guide/component-props.html#props
$emit
You can let a parent component know about the other component's changes with $emit. You can just name an event yourself and pass the value as the first parameter.
this.$emit('messageUpdate', this.message);
See documentation: https://v3-migration.vuejs.org/breaking-changes/emits-option.html#emits-option
VueX
With the VueX data storage you can transfer variables from any component across your app to any other.
This takes a little more finess to set up. I suggest going with the above first.
If you are interested (definitely worth to learn), here is the link:
https://vuex.vuejs.org/guide/#getting-started
I see you are doing well, you just need to add the API call to a script tag in the same file and then access the input message like this:
axios.get("https://anAPIpath.com/"+ this.message)
We need to use $emit to update the parent data in a vue component. This is what has been said everywhere, even vue documentation.
v-model and .sync both use $emit to update, so we count them $emit here
what I'm involved with is updating the parent data using reference type passing
If we send an object or array as prop to the child component and change it in the child component, changes will be made to the parent data directly.
There are components that we always use in a specific component and we are not going to use them anywhere else. In fact, these components are mostly used to make the app codes more readable and to lighten the components of the app.
passing reference type values as prop to children for directly change them from children is much easier than passing values then handle emitted event. especially when there are more nested components
code readability is even easier when we use reference type to update parent.
For example, suppose we have grand-parent, parent and child components. in parent component we have a field that change first property of grand-parent data and in child component we have another field that change second property of grand-parent data
If we want to implement this using $emit we have something like this : (we are not using .sync or v-model)
// grand-parent
<template>
<div>
<parent :fields="fields" #updateFields="fields = $event" >
</div>
</template>
<script>
import parent from "./parent"
export default {
components : {parent},
data(){
return {
fields : {
first : 'first-value',
second : 'second-value',
}
}
}
}
</script>
// parent
<template>
<div>
<input :value="fields.first" #input="updateFirstField" />
<child :fields="fields" #updateSecondField="updateSecondField" >
</div>
</template>
<script>
import child from "./child"
export default {
components : {child},
props : {
fields : Object,
},
methods : {
updateFirstField(event){
this.$emit('updateFields' , {...this.fields , first : event.target.value})
},
updateSecondField(value){
this.$emit('updateFields' , {...this.fields , second : value})
}
}
}
</script>
// child
<template>
<div>
<input :value="fields.first" #input="updateSecondField" />
</div>
</template>
<script>
export default {
props : {
fields : Object,
},
methods : {
updateFirstField(event){
this.$emit('updateSecondField' , event.target.value)
},
}
}
</script>
Yes, we can use .sync to make it easier or pass just field that we need to child. but this is basic example and if we have more fields and also we use all fields in all component this is the way we do this.
same thing using reference type will be like this :
// grand-parent
<template>
<div>
<parent :fields="fields" >
</div>
</template>
<script>
import parent from "./parent"
export default {
components : {parent},
data(){
return {
fields : {
first : 'first-value',
second : 'second-value',
}
}
}
}
</script>
// parent
<template>
<div>
<input v-model="fields.first" />
<child :fields="fields" >
</div>
</template>
<script>
import child from "./child"
export default {
components : {child},
props : {
fields : Object,
}
}
</script>
// child
<template>
<div>
<input v-model="fields.second" />
</div>
</template>
<script>
export default {
props : {
fields : Object,
}
}
</script>
as you see using reference type is much easier. even if there was more fields.
now my question :
should we use reference type for updating parent data or this is bad approach ?
even if we use a component always in the same parent again we should not use this method ?
what is the reason that we should not use reference type to update parent?
if we should not use reference type why vue pass same object to children and not clone them before passing ? (maybe for better performance ?)
The "always use $emit" rule isn't set in stone. There are pros and cons of either approach; you should do whatever makes your code easy to maintain and reason about.
For the situation you described, I think you have justified mutating the data directly.
When you have a single object with lots of properties and each property can be modified by a child component, then having the child component mutate each property itself is fine.
What would the alternative be? Emitting an event for each property update? Or emitting a single input event containing a copy of the object with a single property changed? That approach would result in lots of memory allocations (think of typing in a text field emitting a cloned object for each keypress). Having said that, though, some libraries are designed for this exact purpose and work pretty well (like Immutable.js).
For simple components that manage only small data like a textbox with a single string value, you should definitely use $emit. For more complex components with lots of data then sometimes it makes sense for the child component to share or own the data it is given. It becomes a part of the child component's contract that it will mutate the data in certain circumstances and in some particular way.
what is the reason that we should not use reference type to update parent?
The parent "owns" the data and it knows that nobody but itself will mutate it. No surprises.
The parent gets to decide whether or not to accept the mutation, and can even modify it on-the-fly.
You don't need a watcher to know when the data is changed.
The parent knows how the data is changed and what caused the change. Imagine there are multiple ways that the data can be mutated. The parent can easily know which mutation originated from a child component. If external code (i.e. inside a child component) can mutate the data at any time and for any reason, then it becomes much more difficult for the parent to know what caused the data to change (who changed it and why?).
if we should not use reference type why vue pass same object to children and not clone them before passing ? (maybe for better performance ?)
Well yes, for performance, but also many other reasons such as:
Cloning is non-trivial (Shallow? Deep? Should the prototype be copied too? Does it even make sense to clone the object? Is it a singleton?).
Cloning is expensive memory- and CPU-wise.
If it were cloned then doing what you describe here would be impossible. It would be silly to impose such a restrictive rule.
#Vue Detailed usage of $refs, $emit, $on:
$refs - parent component calls the methods of the child component. You can pass data.
$emit - child components call methods of the parent component and pass data.
$on - sibling components pass data to each other.
Overview
In Vue.js 2.x, model.sync will be deprecated.
So, what is a proper way to communicate between sibling components in Vue.js 2.x?
Background
As I understand Vue.js 2.x, the preferred method for sibling communication is to use a store or an event bus.
According to Evan (creator of Vue.js):
It's also worth mentioning "passing data between components" is
generally a bad idea, because in the end the data flow becomes
untrackable and very hard to debug.
If a piece of data needs to be shared by multiple components, prefer
global stores or Vuex.
[Link to discussion]
And:
.once and .sync are deprecated. Props are now always one-way down. To
produce side effects in the parent scope, a component needs to
explicitly emit an event instead of relying on implicit binding.
So, Evan suggests using $emit() and $on().
Concerns
What worries me is:
Each store and event has a global visibility (correct me if I'm wrong);
It's too wasteful to create a new store for each minor communication;
What I want is to some scope events or stores visibility for siblings components. (Or perhaps I didn't understand the above idea.)
Question
So, what is the correct way to communicate between sibling components?
You can even make it shorter and use the root Vue instance as the global Event Hub:
Component 1:
this.$root.$emit('eventing', data);
Component 2:
mounted() {
this.$root.$on('eventing', data => {
console.log(data);
});
}
With Vue.js 2.0, I'm using the eventHub mechanism as demonstrated in the documentation.
Define centralized event hub.
const eventHub = new Vue() // Single event hub
// Distribute to components using global mixin
Vue.mixin({
data: function () {
return {
eventHub: eventHub
}
}
})
Now in your component you can emit events with
this.eventHub.$emit('update', data)
And to listen you do
this.eventHub.$on('update', data => {
// do your thing
})
Update
Please see the answer by alex, which describes a simpler solution.
Disclaimer: this answer was written a long time ago and it may not reflect latest Vue development or trends. Take everything in this answer with a grain of salt and please comment if you find anything that's outdated, no longer valid, or unhelpful.
State scopes
When designing a Vue application (or in fact, any component based application), there are different types of data that depend on which concerns we're dealing with and each has its own preferred communication channels.
Global state: may include the logged in user, the current theme, etc.
Local state: form attributes, disabled button state, etc.
Note that part of the global state might end up in the local state at some point, and it could be passed down to child components as any other local state would, either in full or diluted to match the use-case.
Communication channels
A channel is a loose term I'll be using to refer to concrete implementations to exchange data around a Vue app.
Each implementation addresses a specific communication channel, which includes:
Global state
Parent-child
Child-parent
Siblings
Different concerns relate to different communication channels.
Props: Direct Parent-Child
The simplest communication channel in Vue for one-way data binding.
Events: Direct Child-Parent
Important notice: $on and $once were removed in Vue version 3.
$emit and v-on event listeners. The simplest communication channel for direct Child-Parent communication. Events enable 2-way data binding.
Provide/Inject: Global or distant local state
Added in Vue 2.2+, and really similar to React's context API, this could be used as a viable replacement to an event bus.
At any point within the components tree could a component provide some data, which any child down the line could access through the inject component's property.
app.component('todo-list', {
// ...
provide() {
return {
todoLength: Vue.computed(() => this.todos.length)
}
}
})
app.component('todo-list-statistics', {
inject: ['todoLength'],
created() {
console.log(`Injected property: ${this.todoLength.value}`) // > Injected property: 5
}
})
This could be used to provide global state at the root of the app, or localized state within a subset of the tree.
Centralized store (Global state)
Note: Vuex 5 is going to be Pinia apparently. Stay tuned. (Tweet)
Vuex is a state management pattern + library for Vue.js applications.
It serves as a centralized store for all the components in an
application, with rules ensuring that the state can only be mutated in
a predictable fashion.
And now you ask:
[S]hould I create vuex store for each minor communication?
It really shines when dealing with global state, which includes but is not limited to:
data received from a backend,
global UI state like a theme,
any data persistence layer, e.g. saving to a backend or interfacing with local storage,
toast messages or notifications,
etc.
So your components can really focus on the things they're meant to be, managing user interfaces, while the global store can manage/use general business logic and offer a clear API through getters and actions.
It doesn't mean that you can't use it for component logic, but I would personally scope that logic to a namespaced Vuex module with only the necessary global UI state.
To avoid dealing with a big mess of everything in a global state, see the Application structure recommandations.
Refs and methods: Edge cases
Despite the existence of props and events, sometimes you might still
need to directly access a child component in JavaScript.
It is only meant as an escape hatch for direct child manipulation -
you should avoid accessing $refs from within templates or computed properties.
If you find yourself using refs and child methods quite often, it's probably time to lift the state up or consider the other ways described here or in the other answers.
$parent: Edge cases
Similar to $root, the $parent property can be used to access the
parent instance from a child. This can be tempting to reach for as a
lazy alternative to passing data with a prop.
In most cases, reaching into the parent makes your application more
difficult to debug and understand, especially if you mutate data in
the parent. When looking at that component later, it will be very
difficult to figure out where that mutation came from.
You could in fact navigate the whole tree structure using $parent, $ref or $root, but it would be akin to having everything global and likely become unmaintainable spaghetti.
Event bus: Global/distant local state
See #AlexMA's answer for up-to-date information about the event bus pattern.
This was the pattern in the past to pass props all over the place from far up down to deeply nested children components, with almost no other components needing these in between. Use sparingly for carefully selected data.
Be careful: Subsequent creation of components that are binding themselves to the event bus will be bound more than once--leading to multiple handlers triggered and leaks. I personally never felt the need for an event bus in all the single page apps I've designed in the past.
The following demonstrates how a simple mistake leads to a leak where the Item component still triggers even if removed from the DOM.
// A component that binds to a custom 'update' event.
var Item = {
template: `<li>{{text}}</li>`,
props: {
text: Number
},
mounted() {
this.$root.$on('update', () => {
console.log(this.text, 'is still alive');
});
},
};
// Component that emits events
var List = new Vue({
el: '#app',
components: {
Item
},
data: {
items: [1, 2, 3, 4]
},
updated() {
this.$root.$emit('update');
},
methods: {
onRemove() {
console.log('slice');
this.items = this.items.slice(0, -1);
}
}
});
<script src="https://unpkg.com/vue#2.5.17/dist/vue.min.js"></script>
<div id="app">
<button type="button" #click="onRemove">Remove</button>
<ul>
<item v-for="item in items" :key="item" :text="item"></item>
</ul>
</div>
Remember to remove listeners in the destroyed lifecycle hook.
Component types
Disclaimer: the following "containers" versus "presentational" components is just one way to structure a project and there are now multiple alternatives, like the new Composition API that could effectively replace the "app specific containers" I'm describing below.
To orchestrates all these communications, to ease re-usability and testing, we could think of components as two different types.
App specific containers
Generic/presentational components
Again, it doesn't mean that a generic component should be reused or that an app specific container can't be reused, but they have different responsibilities.
App specific containers
Note: see the new Composition API as an alternative to these containers.
These are just simple Vue component that wraps other Vue components (generic or other app specific containers). This is where the Vuex store communication should happen and this container should communicate through other simpler means like props and event listeners.
These containers could even have no native DOM elements at all and let the generic components deal with the templating and user interactions.
scope somehow events or stores visibility for siblings components
This is where the scoping happens. Most components don't know about the store and this component should (mostly) use one namespaced store module with a limited set of getters and actions applied with the provided Vuex binding helpers.
Generic/presentational components
These should receive their data from props, make changes on their own local data, and emit simple events. Most of the time, they should not know a Vuex store exists at all.
They could also be called containers as their sole responsibility could be to dispatch to other UI components.
Sibling communication
So, after all this, how should we communicate between two sibling components?
It's easier to understand with an example: say we have an input box and its data should be shared across the app (siblings at different places in the tree) and persisted with a backend.
❌ Mixing concerns
Starting with the worst case scenario, our component would mix presentation and business logic.
// MyInput.vue
<template>
<div class="my-input">
<label>Data</label>
<input type="text"
:value="value"
:input="onChange($event.target.value)">
</div>
</template>
<script>
import axios from 'axios';
export default {
data() {
return {
value: "",
};
},
mounted() {
this.$root.$on('sync', data => {
this.value = data.myServerValue;
});
},
methods: {
onChange(value) {
this.value = value;
axios.post('http://example.com/api/update', {
myServerValue: value
});
}
}
}
</script>
While it might look fine for a simple app, it comes with a lot of drawbacks:
Explicitly uses the global axios instance
Hard-coded API inside the UI
Tightly coupled to the root component (event bus pattern)
Harder to do unit tests
✅ Separation of concerns
To separate these two concerns, we should wrap our component in an app specific container and keep the presentation logic into our generic input component.
With the following pattern, we can:
Easily test each concern with unit tests
Change the API without impacting components at all
Configure HTTP communications however you'd like (axios, fetch, adding middlewares, tests, etc)
Reuse the input component anywhere (reduced coupling)
React to state changes from anywhere in the app through the global store bindings
etc.
Our input component is now reusable and doesn't know about the backend nor the siblings.
// MyInput.vue
// the template is the same as above
<script>
export default {
props: {
initial: {
type: String,
default: ""
}
},
data() {
return {
value: this.initial,
};
},
methods: {
onChange(value) {
this.value = value;
this.$emit('change', value);
}
}
}
</script>
Our app specific container can now be the bridge between the business logic and the presentation communication.
// MyAppCard.vue
<template>
<div class="container">
<card-body>
<my-input :initial="serverValue" #change="updateState"></my-input>
<my-input :initial="otherValue" #change="updateState"></my-input>
</card-body>
<card-footer>
<my-button :disabled="!serverValue || !otherValue"
#click="saveState"></my-button>
</card-footer>
</div>
</template>
<script>
import { mapGetters, mapActions } from 'vuex';
import { NS, ACTIONS, GETTERS } from '#/store/modules/api';
import { MyButton, MyInput } from './components';
export default {
components: {
MyInput,
MyButton,
},
computed: mapGetters(NS, [
GETTERS.serverValue,
GETTERS.otherValue,
]),
methods: mapActions(NS, [
ACTIONS.updateState,
ACTIONS.saveState,
])
}
</script>
Since the Vuex store actions deal with the backend communication, our container here doesn't need to know about axios and the backend.
Okay, we can communicate between siblings via the parent using v-on events.
Parent
|- List of items // Sibling 1 - "List"
|- Details of selected item // Sibling 2 - "Details"
Let's assume that we want update Details component when we click some element in List.
In Parent:
Template:
<list v-model="listModel"
v-on:select-item="setSelectedItem"
></list>
<details v-model="selectedModel"></details>
Here:
v-on:select-item it's an event, that will be called in List component (see below);
setSelectedItem it's a Parent's method to update selectedModel;
JavaScript:
//...
data () {
return {
listModel: ['a', 'b']
selectedModel: null
}
},
methods: {
setSelectedItem (item) {
this.selectedModel = item // Here we change the Detail's model
},
}
//...
In List:
Template:
<ul>
<li v-for="i in list"
:value="i"
#click="select(i, $event)">
<span v-text="i"></span>
</li>
</ul>
JavaScript:
//...
data () {
return {
selected: null
}
},
props: {
list: {
type: Array,
required: true
}
},
methods: {
select (item) {
this.selected = item
this.$emit('select-item', item) // Here we call the event we waiting for in "Parent"
},
}
//...
Here:
this.$emit('select-item', item) will send an item via select-item directly in the parent. And the parent will send it to the Details view.
How to handle communication between siblings depends on the situation. But first I want to emphasize that the global event bus approach is going away in Vue.js 3. See this RFC. Hence this answer.
Lowest Common Ancestor Pattern (or “LCA”)
For most cases, I recommend using the lowest common ancestor pattern (also known as “data down, events up”). This pattern is easy to read, implement, test, and debug. It also creates an elegant, simple data flow.
In essence, this means if two components need to communicate, put their shared state in the closest component that both share as an ancestor. Pass data from parent component to child component via props, and pass information from child to parent by emitting an event (example code below).
For example, one might have an email app: the address component needs to communicate data to the message body component (perhaps for pre-populating "Hello <name>"), so they use their closest shared ancestor (perhaps an email form component) to hold the addressee data.
LCA can be annoying if events and props need to pass through many "middlemen" components.
For more detail, I refer colleagues to this excellent blog post. (Ignore the fact that its examples use Ember, its concepts are applicable to many frameworks).
Data Container Pattern (e.g., Vuex)
For complex cases or situations where parent–child communication would involve too many middlemen, use Vuex or an equivalent data container technology.
Use namespaced modules when a single store becomes too complicated or disorganized. For example, it might be reasonable to create a separate namespace for a complex collection of components with many interconnections, such as a complex calendar.
Publish/Subscribe (Event Bus) Pattern
If the event bus (i.e. publish/subscribe) pattern makes more sense for your app (from an architecture standpoint), or you need to remove Vue.js's global event bus from an existing Vue.js app, the Vue.js core team now recommends using a third party library such as mitt. (See the RFC referenced in paragraph 1.).
Miscellaneous
Here's a small (perhaps overly simplistic) example of an LCA solution for sibling-to-sibling communication. This is a game called whack-a-mole.
In this game the player gets points when they "whack" a mole, which causes it to hide and then another mole appears in a random spot. To build this app, which contains "mole" components, one might think , “mole component N should tell mole component Y to appear after it is whacked”. But Vue.js discourages this method of component communication, since Vue.js apps (and html) are effectively tree data structures.
This is probably a good thing. A large/complex app, where nodes communicated to each-other without any centralized manager, might be very difficult to debug. Additionally, components that use LCA tend to exhibit low coupling and high reusability.
In this example, the game manager component passes mole visibility as a prop to mole child components. When a visible mole is "whacked" (clicked), it emits an event. The game manager component (the common ancenstor) receives the event and modifies its state. Vue.js automatically updates the props, so all of the mole components receive new visibility data.
Vue.component('whack-a-mole', {
data() {
return {
stateOfMoles: [true, false, false],
points: 0
}
},
template: `<div>WHACK - A - MOLE!<br/>
<a-mole :has-mole="stateOfMoles[0]" v-on:moleMashed="moleClicked(0)"/>
<a-mole :has-mole="stateOfMoles[1]" v-on:moleMashed="moleClicked(1)"/>
<a-mole :has-mole="stateOfMoles[2]" v-on:moleMashed="moleClicked(2)"/>
<p>Score: {{points}}</p>
</div>`,
methods: {
moleClicked(n) {
if(this.stateOfMoles[n]) {
this.points++;
this.stateOfMoles[n] = false;
this.stateOfMoles[Math.floor(Math.random() * 3)] = true;
}
}
}
})
Vue.component('a-mole', {
props: ['hasMole'],
template: `<button #click="$emit('moleMashed')">
<span class="mole-button" v-if="hasMole">🐿</span><span class="mole-button" v-if="!hasMole">🕳</span>
</button>`
})
var app = new Vue({
el: '#app',
data() {
return { name: 'Vue' }
}
})
.mole-button {
font-size: 2em;
}
<script src="https://cdnjs.cloudflare.com/ajax/libs/vue/2.5.17/vue.js"></script>
<div id="app">
<whack-a-mole />
</div>
What I usually do if I want to "hack" the normal patterns of communication in Vue.js, specially now that .sync is deprecated, is to create a simple EventEmitter that handles communication between components. From one of my latest projects:
import {EventEmitter} from 'events'
var Transmitter = Object.assign({}, EventEmitter.prototype, { /* ... */ })
With this Transmitter object you can then do, in any component:
import Transmitter from './Transmitter'
var ComponentOne = Vue.extend({
methods: {
transmit: Transmitter.emit('update')
}
})
And to create a "receiving" component:
import Transmitter from './Transmitter'
var ComponentTwo = Vue.extend({
ready: function () {
Transmitter.on('update', this.doThingOnUpdate)
}
})
Again, this is for really specific uses. Don't base your whole application on this pattern, use something like Vuex instead.
In my case i have a table with editable cells. I only want one cell to be editable at a time as the user clicks from one to another to edit the contents.
The solution is to use parent-child (props) and child-parent (event).
In the example below i'm looping over a dataset of 'rows' and using the rowIndex and cellIndex to create a unique (coordinate) identifier for each cell. When a cell is clicked an event is fired from the child element up to the parent telling the parent which coordinate has been clicked. The parent then sets the selectedCoord and passes this back down to the child components. So each child component knows its own coordinate and the selected coordinate. It can then decide whether to make itself editable or not.
<!-- PARENT COMPONENT -->
<template>
<table>
<tr v-for="(row, rowIndex) in rows">
<editable-cell
v-for="(cell, cellIndex) in row"
:key="cellIndex"
:cell-content="cell"
:coords="rowIndex+'-'+cellIndex"
:selected-coords="selectedCoords"
#select-coords="selectCoords"
></editable-cell>
</tr>
</table>
</template>
<script>
export default {
name: 'TableComponent'
data() {
return {
selectedCoords: '',
}
},
methods: {
selectCoords(coords) {
this.selectedCoords = coords;
},
},
</script>
<!-- CHILD COMPONENT -->
<template>
<td #click="toggleSelect">
<input v-if="coords===selectedCoords" type="text" :value="cellContent" />
<span v-else>{{ cellContent }}</span>
</td>
</template>
<script>
export default {
name: 'EditableCell',
props: {
cellContent: {
required: true
},
coords: {
type: String,
required: true
},
selectedCoords: {
type: String,
required: true
},
},
methods: {
toggleSelect() {
const arg = (this.coords === this.selectedCoords) ? '' : this.coords;
this.$emit('select-coords', arg);
},
}
};
</script>
Overview
In Vue.js 2.x, model.sync will be deprecated.
So, what is a proper way to communicate between sibling components in Vue.js 2.x?
Background
As I understand Vue.js 2.x, the preferred method for sibling communication is to use a store or an event bus.
According to Evan (creator of Vue.js):
It's also worth mentioning "passing data between components" is
generally a bad idea, because in the end the data flow becomes
untrackable and very hard to debug.
If a piece of data needs to be shared by multiple components, prefer
global stores or Vuex.
[Link to discussion]
And:
.once and .sync are deprecated. Props are now always one-way down. To
produce side effects in the parent scope, a component needs to
explicitly emit an event instead of relying on implicit binding.
So, Evan suggests using $emit() and $on().
Concerns
What worries me is:
Each store and event has a global visibility (correct me if I'm wrong);
It's too wasteful to create a new store for each minor communication;
What I want is to some scope events or stores visibility for siblings components. (Or perhaps I didn't understand the above idea.)
Question
So, what is the correct way to communicate between sibling components?
You can even make it shorter and use the root Vue instance as the global Event Hub:
Component 1:
this.$root.$emit('eventing', data);
Component 2:
mounted() {
this.$root.$on('eventing', data => {
console.log(data);
});
}
With Vue.js 2.0, I'm using the eventHub mechanism as demonstrated in the documentation.
Define centralized event hub.
const eventHub = new Vue() // Single event hub
// Distribute to components using global mixin
Vue.mixin({
data: function () {
return {
eventHub: eventHub
}
}
})
Now in your component you can emit events with
this.eventHub.$emit('update', data)
And to listen you do
this.eventHub.$on('update', data => {
// do your thing
})
Update
Please see the answer by alex, which describes a simpler solution.
Disclaimer: this answer was written a long time ago and it may not reflect latest Vue development or trends. Take everything in this answer with a grain of salt and please comment if you find anything that's outdated, no longer valid, or unhelpful.
State scopes
When designing a Vue application (or in fact, any component based application), there are different types of data that depend on which concerns we're dealing with and each has its own preferred communication channels.
Global state: may include the logged in user, the current theme, etc.
Local state: form attributes, disabled button state, etc.
Note that part of the global state might end up in the local state at some point, and it could be passed down to child components as any other local state would, either in full or diluted to match the use-case.
Communication channels
A channel is a loose term I'll be using to refer to concrete implementations to exchange data around a Vue app.
Each implementation addresses a specific communication channel, which includes:
Global state
Parent-child
Child-parent
Siblings
Different concerns relate to different communication channels.
Props: Direct Parent-Child
The simplest communication channel in Vue for one-way data binding.
Events: Direct Child-Parent
Important notice: $on and $once were removed in Vue version 3.
$emit and v-on event listeners. The simplest communication channel for direct Child-Parent communication. Events enable 2-way data binding.
Provide/Inject: Global or distant local state
Added in Vue 2.2+, and really similar to React's context API, this could be used as a viable replacement to an event bus.
At any point within the components tree could a component provide some data, which any child down the line could access through the inject component's property.
app.component('todo-list', {
// ...
provide() {
return {
todoLength: Vue.computed(() => this.todos.length)
}
}
})
app.component('todo-list-statistics', {
inject: ['todoLength'],
created() {
console.log(`Injected property: ${this.todoLength.value}`) // > Injected property: 5
}
})
This could be used to provide global state at the root of the app, or localized state within a subset of the tree.
Centralized store (Global state)
Note: Vuex 5 is going to be Pinia apparently. Stay tuned. (Tweet)
Vuex is a state management pattern + library for Vue.js applications.
It serves as a centralized store for all the components in an
application, with rules ensuring that the state can only be mutated in
a predictable fashion.
And now you ask:
[S]hould I create vuex store for each minor communication?
It really shines when dealing with global state, which includes but is not limited to:
data received from a backend,
global UI state like a theme,
any data persistence layer, e.g. saving to a backend or interfacing with local storage,
toast messages or notifications,
etc.
So your components can really focus on the things they're meant to be, managing user interfaces, while the global store can manage/use general business logic and offer a clear API through getters and actions.
It doesn't mean that you can't use it for component logic, but I would personally scope that logic to a namespaced Vuex module with only the necessary global UI state.
To avoid dealing with a big mess of everything in a global state, see the Application structure recommandations.
Refs and methods: Edge cases
Despite the existence of props and events, sometimes you might still
need to directly access a child component in JavaScript.
It is only meant as an escape hatch for direct child manipulation -
you should avoid accessing $refs from within templates or computed properties.
If you find yourself using refs and child methods quite often, it's probably time to lift the state up or consider the other ways described here or in the other answers.
$parent: Edge cases
Similar to $root, the $parent property can be used to access the
parent instance from a child. This can be tempting to reach for as a
lazy alternative to passing data with a prop.
In most cases, reaching into the parent makes your application more
difficult to debug and understand, especially if you mutate data in
the parent. When looking at that component later, it will be very
difficult to figure out where that mutation came from.
You could in fact navigate the whole tree structure using $parent, $ref or $root, but it would be akin to having everything global and likely become unmaintainable spaghetti.
Event bus: Global/distant local state
See #AlexMA's answer for up-to-date information about the event bus pattern.
This was the pattern in the past to pass props all over the place from far up down to deeply nested children components, with almost no other components needing these in between. Use sparingly for carefully selected data.
Be careful: Subsequent creation of components that are binding themselves to the event bus will be bound more than once--leading to multiple handlers triggered and leaks. I personally never felt the need for an event bus in all the single page apps I've designed in the past.
The following demonstrates how a simple mistake leads to a leak where the Item component still triggers even if removed from the DOM.
// A component that binds to a custom 'update' event.
var Item = {
template: `<li>{{text}}</li>`,
props: {
text: Number
},
mounted() {
this.$root.$on('update', () => {
console.log(this.text, 'is still alive');
});
},
};
// Component that emits events
var List = new Vue({
el: '#app',
components: {
Item
},
data: {
items: [1, 2, 3, 4]
},
updated() {
this.$root.$emit('update');
},
methods: {
onRemove() {
console.log('slice');
this.items = this.items.slice(0, -1);
}
}
});
<script src="https://unpkg.com/vue#2.5.17/dist/vue.min.js"></script>
<div id="app">
<button type="button" #click="onRemove">Remove</button>
<ul>
<item v-for="item in items" :key="item" :text="item"></item>
</ul>
</div>
Remember to remove listeners in the destroyed lifecycle hook.
Component types
Disclaimer: the following "containers" versus "presentational" components is just one way to structure a project and there are now multiple alternatives, like the new Composition API that could effectively replace the "app specific containers" I'm describing below.
To orchestrates all these communications, to ease re-usability and testing, we could think of components as two different types.
App specific containers
Generic/presentational components
Again, it doesn't mean that a generic component should be reused or that an app specific container can't be reused, but they have different responsibilities.
App specific containers
Note: see the new Composition API as an alternative to these containers.
These are just simple Vue component that wraps other Vue components (generic or other app specific containers). This is where the Vuex store communication should happen and this container should communicate through other simpler means like props and event listeners.
These containers could even have no native DOM elements at all and let the generic components deal with the templating and user interactions.
scope somehow events or stores visibility for siblings components
This is where the scoping happens. Most components don't know about the store and this component should (mostly) use one namespaced store module with a limited set of getters and actions applied with the provided Vuex binding helpers.
Generic/presentational components
These should receive their data from props, make changes on their own local data, and emit simple events. Most of the time, they should not know a Vuex store exists at all.
They could also be called containers as their sole responsibility could be to dispatch to other UI components.
Sibling communication
So, after all this, how should we communicate between two sibling components?
It's easier to understand with an example: say we have an input box and its data should be shared across the app (siblings at different places in the tree) and persisted with a backend.
❌ Mixing concerns
Starting with the worst case scenario, our component would mix presentation and business logic.
// MyInput.vue
<template>
<div class="my-input">
<label>Data</label>
<input type="text"
:value="value"
:input="onChange($event.target.value)">
</div>
</template>
<script>
import axios from 'axios';
export default {
data() {
return {
value: "",
};
},
mounted() {
this.$root.$on('sync', data => {
this.value = data.myServerValue;
});
},
methods: {
onChange(value) {
this.value = value;
axios.post('http://example.com/api/update', {
myServerValue: value
});
}
}
}
</script>
While it might look fine for a simple app, it comes with a lot of drawbacks:
Explicitly uses the global axios instance
Hard-coded API inside the UI
Tightly coupled to the root component (event bus pattern)
Harder to do unit tests
✅ Separation of concerns
To separate these two concerns, we should wrap our component in an app specific container and keep the presentation logic into our generic input component.
With the following pattern, we can:
Easily test each concern with unit tests
Change the API without impacting components at all
Configure HTTP communications however you'd like (axios, fetch, adding middlewares, tests, etc)
Reuse the input component anywhere (reduced coupling)
React to state changes from anywhere in the app through the global store bindings
etc.
Our input component is now reusable and doesn't know about the backend nor the siblings.
// MyInput.vue
// the template is the same as above
<script>
export default {
props: {
initial: {
type: String,
default: ""
}
},
data() {
return {
value: this.initial,
};
},
methods: {
onChange(value) {
this.value = value;
this.$emit('change', value);
}
}
}
</script>
Our app specific container can now be the bridge between the business logic and the presentation communication.
// MyAppCard.vue
<template>
<div class="container">
<card-body>
<my-input :initial="serverValue" #change="updateState"></my-input>
<my-input :initial="otherValue" #change="updateState"></my-input>
</card-body>
<card-footer>
<my-button :disabled="!serverValue || !otherValue"
#click="saveState"></my-button>
</card-footer>
</div>
</template>
<script>
import { mapGetters, mapActions } from 'vuex';
import { NS, ACTIONS, GETTERS } from '#/store/modules/api';
import { MyButton, MyInput } from './components';
export default {
components: {
MyInput,
MyButton,
},
computed: mapGetters(NS, [
GETTERS.serverValue,
GETTERS.otherValue,
]),
methods: mapActions(NS, [
ACTIONS.updateState,
ACTIONS.saveState,
])
}
</script>
Since the Vuex store actions deal with the backend communication, our container here doesn't need to know about axios and the backend.
Okay, we can communicate between siblings via the parent using v-on events.
Parent
|- List of items // Sibling 1 - "List"
|- Details of selected item // Sibling 2 - "Details"
Let's assume that we want update Details component when we click some element in List.
In Parent:
Template:
<list v-model="listModel"
v-on:select-item="setSelectedItem"
></list>
<details v-model="selectedModel"></details>
Here:
v-on:select-item it's an event, that will be called in List component (see below);
setSelectedItem it's a Parent's method to update selectedModel;
JavaScript:
//...
data () {
return {
listModel: ['a', 'b']
selectedModel: null
}
},
methods: {
setSelectedItem (item) {
this.selectedModel = item // Here we change the Detail's model
},
}
//...
In List:
Template:
<ul>
<li v-for="i in list"
:value="i"
#click="select(i, $event)">
<span v-text="i"></span>
</li>
</ul>
JavaScript:
//...
data () {
return {
selected: null
}
},
props: {
list: {
type: Array,
required: true
}
},
methods: {
select (item) {
this.selected = item
this.$emit('select-item', item) // Here we call the event we waiting for in "Parent"
},
}
//...
Here:
this.$emit('select-item', item) will send an item via select-item directly in the parent. And the parent will send it to the Details view.
How to handle communication between siblings depends on the situation. But first I want to emphasize that the global event bus approach is going away in Vue.js 3. See this RFC. Hence this answer.
Lowest Common Ancestor Pattern (or “LCA”)
For most cases, I recommend using the lowest common ancestor pattern (also known as “data down, events up”). This pattern is easy to read, implement, test, and debug. It also creates an elegant, simple data flow.
In essence, this means if two components need to communicate, put their shared state in the closest component that both share as an ancestor. Pass data from parent component to child component via props, and pass information from child to parent by emitting an event (example code below).
For example, one might have an email app: the address component needs to communicate data to the message body component (perhaps for pre-populating "Hello <name>"), so they use their closest shared ancestor (perhaps an email form component) to hold the addressee data.
LCA can be annoying if events and props need to pass through many "middlemen" components.
For more detail, I refer colleagues to this excellent blog post. (Ignore the fact that its examples use Ember, its concepts are applicable to many frameworks).
Data Container Pattern (e.g., Vuex)
For complex cases or situations where parent–child communication would involve too many middlemen, use Vuex or an equivalent data container technology.
Use namespaced modules when a single store becomes too complicated or disorganized. For example, it might be reasonable to create a separate namespace for a complex collection of components with many interconnections, such as a complex calendar.
Publish/Subscribe (Event Bus) Pattern
If the event bus (i.e. publish/subscribe) pattern makes more sense for your app (from an architecture standpoint), or you need to remove Vue.js's global event bus from an existing Vue.js app, the Vue.js core team now recommends using a third party library such as mitt. (See the RFC referenced in paragraph 1.).
Miscellaneous
Here's a small (perhaps overly simplistic) example of an LCA solution for sibling-to-sibling communication. This is a game called whack-a-mole.
In this game the player gets points when they "whack" a mole, which causes it to hide and then another mole appears in a random spot. To build this app, which contains "mole" components, one might think , “mole component N should tell mole component Y to appear after it is whacked”. But Vue.js discourages this method of component communication, since Vue.js apps (and html) are effectively tree data structures.
This is probably a good thing. A large/complex app, where nodes communicated to each-other without any centralized manager, might be very difficult to debug. Additionally, components that use LCA tend to exhibit low coupling and high reusability.
In this example, the game manager component passes mole visibility as a prop to mole child components. When a visible mole is "whacked" (clicked), it emits an event. The game manager component (the common ancenstor) receives the event and modifies its state. Vue.js automatically updates the props, so all of the mole components receive new visibility data.
Vue.component('whack-a-mole', {
data() {
return {
stateOfMoles: [true, false, false],
points: 0
}
},
template: `<div>WHACK - A - MOLE!<br/>
<a-mole :has-mole="stateOfMoles[0]" v-on:moleMashed="moleClicked(0)"/>
<a-mole :has-mole="stateOfMoles[1]" v-on:moleMashed="moleClicked(1)"/>
<a-mole :has-mole="stateOfMoles[2]" v-on:moleMashed="moleClicked(2)"/>
<p>Score: {{points}}</p>
</div>`,
methods: {
moleClicked(n) {
if(this.stateOfMoles[n]) {
this.points++;
this.stateOfMoles[n] = false;
this.stateOfMoles[Math.floor(Math.random() * 3)] = true;
}
}
}
})
Vue.component('a-mole', {
props: ['hasMole'],
template: `<button #click="$emit('moleMashed')">
<span class="mole-button" v-if="hasMole">🐿</span><span class="mole-button" v-if="!hasMole">🕳</span>
</button>`
})
var app = new Vue({
el: '#app',
data() {
return { name: 'Vue' }
}
})
.mole-button {
font-size: 2em;
}
<script src="https://cdnjs.cloudflare.com/ajax/libs/vue/2.5.17/vue.js"></script>
<div id="app">
<whack-a-mole />
</div>
What I usually do if I want to "hack" the normal patterns of communication in Vue.js, specially now that .sync is deprecated, is to create a simple EventEmitter that handles communication between components. From one of my latest projects:
import {EventEmitter} from 'events'
var Transmitter = Object.assign({}, EventEmitter.prototype, { /* ... */ })
With this Transmitter object you can then do, in any component:
import Transmitter from './Transmitter'
var ComponentOne = Vue.extend({
methods: {
transmit: Transmitter.emit('update')
}
})
And to create a "receiving" component:
import Transmitter from './Transmitter'
var ComponentTwo = Vue.extend({
ready: function () {
Transmitter.on('update', this.doThingOnUpdate)
}
})
Again, this is for really specific uses. Don't base your whole application on this pattern, use something like Vuex instead.
In my case i have a table with editable cells. I only want one cell to be editable at a time as the user clicks from one to another to edit the contents.
The solution is to use parent-child (props) and child-parent (event).
In the example below i'm looping over a dataset of 'rows' and using the rowIndex and cellIndex to create a unique (coordinate) identifier for each cell. When a cell is clicked an event is fired from the child element up to the parent telling the parent which coordinate has been clicked. The parent then sets the selectedCoord and passes this back down to the child components. So each child component knows its own coordinate and the selected coordinate. It can then decide whether to make itself editable or not.
<!-- PARENT COMPONENT -->
<template>
<table>
<tr v-for="(row, rowIndex) in rows">
<editable-cell
v-for="(cell, cellIndex) in row"
:key="cellIndex"
:cell-content="cell"
:coords="rowIndex+'-'+cellIndex"
:selected-coords="selectedCoords"
#select-coords="selectCoords"
></editable-cell>
</tr>
</table>
</template>
<script>
export default {
name: 'TableComponent'
data() {
return {
selectedCoords: '',
}
},
methods: {
selectCoords(coords) {
this.selectedCoords = coords;
},
},
</script>
<!-- CHILD COMPONENT -->
<template>
<td #click="toggleSelect">
<input v-if="coords===selectedCoords" type="text" :value="cellContent" />
<span v-else>{{ cellContent }}</span>
</td>
</template>
<script>
export default {
name: 'EditableCell',
props: {
cellContent: {
required: true
},
coords: {
type: String,
required: true
},
selectedCoords: {
type: String,
required: true
},
},
methods: {
toggleSelect() {
const arg = (this.coords === this.selectedCoords) ? '' : this.coords;
this.$emit('select-coords', arg);
},
}
};
</script>