Related
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>
I am new to React and I don't know what's the best way to do this.
I have a list of cars and on clicking each row it should show slide to full page details of that car.
My code structure is:
I have App which renders two components. CarList and CarDetails. Car Details is hidden initially. The reason I rendered carDetails in app is because it's a massive fix template so I would like to render this once when app is loaded and only update it's data when each row clicked.
CarList also renders CarRow component which is fine.
Now my problem is I have a getDetails function on CarRow component which is making a call to get the details based on the car id. How to get carDetails component data updated ? I used
this.setState({itemDetails:data});
but seems state of the carRow is not the same reference as state in carDetails.
Any help?
This is a fundamental issue that lots of thought and man-hours has gone into in order to try and solve. It probably can't be answered, except on a surface level, in a StackOverflow post. It's not React-centric, either. This is an issue across most applications, regardless of the framework you're using.
Since you asked in the context of React, you might consider reading into flux, which is the de-facto implementation of this one-way data-flow idea in concert with React. However, that architecture is by no means "the best". There are simply advantages and disadvantages to it like everything else.
Some people don't like the idea of the global "event bus" that flux proposes. If that's the case, you can simply implement your own intermediate data layer API that collects query callbacks and A) invokes the callbacks on any calls to save data and B) refreshes any appropriate queries to the server. For now, though, I'd stick with flux as it will give you an idea of the general principles involved in having the things that most people consider to be "good", like a single source of truth for your data, one way flow, etc.
To give a concrete example of the callback idea:
// data layer
const listeners = [];
const data = {
save: save,
query: query
};
function save(someData) {
// save data to the server, and then...
.then(data => {
listeners.forEach(listener => listener(data));
});
}
function query(params, callback) {
// query the server with the params, then
listeners.push(callback);
}
// component
componentWillMount() {
data.query(params, data => this.setState({ myData: data }));
},
save() {
// when the save operation is complete, it will "refresh" the query above
data.save(someData);
}
This is a very distilled example and doesn't address optimization, such as potential for memory leaks when moving to different views and invoking "stale" callbacks, however it should give you a general idea of another approach.
The two approaches have the same policy (a single source of truth for data and one way data flow) but different implementations (global "event bus" which necessitates keeping track of events, or the simple callback method, which can necessitate a form of memory management).
Where do sockets fit into the Flux unidirectional data flow? I have read 2 schools of thought for where remote data should enter the Flux unidirectional data flow. The way I have seen remote data for a Flux app fetched is when a server-side call is made, for example, in a promise that is then resolved or rejected. Three possible actions could fire during this process:
An initial action for optimistically updating the view (FooActions.BAR)
A success action for when an asynchronous promise is resolved (FooActions.BAR_SUCCESS)
An error action for when an asynchronous promise is rejected (FooActions.BAR_ERROR)
The stores will listen for the actions and update the necessary data. I have seen the server-side calls made from both action creators and from within the stores themselves. I use action creators for the process described above, but I'm not sure if data fetching via a web socket should be treated similarly. I was wondering where sockets fit into the diagram below.
There's really no difference in how you use Flux with WebSockets or plain old HTTP requests/polling. Your stores are responsible for emitting a change event when the application state changes, and it shouldn't be visible from the outside of the store if that change came from a UI interaction, from a WebSocket, or from making an HTTP request. That's really one of the main benefits of Flux in that no matter where the application state was changed, it goes through the same code paths.
Some Flux implementations tend to use actions/action creators for fetching data, but I don't really agree with that.
Actions are things that happen that modifies your application state. It's things like "the user changed some text and hit save" or "the user deleted an item". Think of actions like the transaction log of a database. If you lost your database, but you saved and serialized all actions that ever happened, you could just replay all those actions and end up with the same state/database that you lost.
So things like "give me item with id X" and "give me all the items" aren't actions, they're questions, questions about that application state. And in my view, it's the stores that should respond to those questions via methods that you expose on those stores.
It's tempting to use actions/action creators for fetching because fetching needs to be async. And by wrapping the async stuff in actions, your components and stores can be completely synchronous. But if you do that, you blur the definition of what an action is, and it also forces you to assume that you can fit your entire application state in memory (because you can only respond synchronously if you have the answer in memory).
So here's how I view Flux and the different concepts.
Stores
This is obviously where your application state lives. The store encapsulates and manages the state and is the only place where mutation of that state actually happens. It's also where events are emitted when that state changes.
The stores are also responsible for communicating with the backend. The store communicates with the backend when the state has changed and that needs to be synced with the server, and it also communicates with the server when it needs data that it doesn't have in memory. It has methods like get(id), search(parameters) etc. Those methods are for your questions, and they all return promises, even if the state can fit into memory. That's important because you might end up with use cases where the state no longer fits in memory, or where it's not possible to filter in memory or do advanced searching. By returning promises from your question methods, you can switch between returning from memory or asking the backend without having to change anything outside of the store.
Actions
My actions are very lightweight, and they don't know anything about persisting the mutation that they encapsulate. They simply carry the intention to mutate from the component to the store. For larger applications, they can contain some logic, but never things like server communication.
Components
These are your React components. They interact with stores by calling the question methods on the stores and rendering the return value of those methods. They also subscribe to the change event that the store exposes. I like using higher order components which are components that just wrap another component and passes props to it. An example would be:
var TodoItemsComponent = React.createClass({
getInitialState: function () {
return {
todoItems: null
}
},
componentDidMount: function () {
var self = this;
TodoStore.getAll().then(function (todoItems) {
self.setState({todoItems: todoItems});
});
TodoStore.onChange(function (todoItems) {
self.setState({todoItems: todoItems});
});
},
render: function () {
if (this.state.todoItems) {
return <TodoListComponent todoItems={this.state.todoItems} />;
} else {
return <Spinner />;
}
}
});
var TodoListComponent = React.createClass({
createNewTodo: function () {
TodoActions.createNew({
text: 'A new todo!'
});
},
render: function () {
return (
<ul>
{this.props.todoItems.map(function (todo) {
return <li>{todo.text}</li>;
})}
</ul>
<button onClick={this.createNewTodo}>Create new todo</button>
);
}
});
In this example the TodoItemsComponent is the higher order component and it wraps the nitty-gritty details of communicating with the store. It renders the TodoListComponent when it has fetched the todos, and renders a spinner before that. Since it passes the todo items as props to TodoListComponent that component only has to focus on rendering, and it will be re-rendered as soon as anything changes in the store. And the rendering component is kept completely synchronous. Another benefit is that TodoItemsComponent is only focused on fetching data and passing it on, making it very reusable for any rendering component that needs the todos.
higher order components
The term higher order components comes from the term higher order functions. Higher order functions are functions that return other functions. So a higher order component is a component that just wraps another component and returns its output.
I have a global data object I update and then I call React.renderComponent() again on the top/main component.
Is this the right pattern for triggering this update?
You should generally pass the data object into the component as a prop, even if it's a global variable. This lets you test the component, and also use it elsewhere without being tied to that global.
As Mike said, there's nothing wrong with using React.renderComponent to update it.
He also mentioned flux, but that's overkill for this. A simple event emitter where you do something like .emit('change', newData), and the component is listening for the change event tends to be better for simpler cases. See my answer to this question for an example of how that can be done.
This is the correct pattern. React.renderComponent will either mount a component for the first time, or get an already mounted component to update.
If you're using a global object though, you might want to look in to the Flux architecture here:
http://facebook.github.io/flux/docs/overview.html
I had the same problem and asked myself if I really needed to re-render the component.
You can do so with this.forceUpdate() but it's not advisable. As React docs states:
You should try to avoid all uses of forceUpdate() and only read from this.props and this.state in render(). This makes your component "pure" and your application much simpler and more efficient.
So what I did was create a data property like exists and test it:
// renderDeleteButton() is being called on render()
renderDeleteButton () {
if (!this.props.store.exists) {
return;
}
return(
<DeleteButton
...
deleteAction={this.delete} />
);
}
Whenever I delete/save, I toggle exists and component will show up or hide based on that. React handles that for me.