La Communication entre frère composants dans VueJs 2.0

Avec Vue 2.0, je suis en utilisant le eventHub mécanisme tel que démontré dans le la documentation.

1. Définir centralisée des événements hub.

   const eventHub = new Vue() //Single event hub
   
   //Distribute to components using global mixin
   Vue.mixin({
       data: function () {
           return {
               eventHub: eventHub
           }
       }
   })

2. Maintenant dans votre composant, vous pouvez émettre des événements avec

   this.eventHub.$emit('update', data)

3. Et à écouter vous ne

   this.eventHub.$on('update', data => {
   //do your thing
   })

Mise à jour
Veuillez voir la réponse par @alex, qui décrit plus simple solution.

Je sais que c'est une vieille question, mais je voulais exposer d'autres canaux de communication et la manière de voir de l'application et de la communication à partir d'un point de vue plus élevé.

---

Types de Communication

La première chose à comprendre lors de la conception d'une Vue de l'application (ou, en fait, n'importe quel composant en fonction de l'application) est qu'il existe différents types de communication qui dépend des préoccupations que nous avons affaire à et ils ont besoin de leurs propres canaux de communication.

Logique d'entreprise: fait référence à tout ce spécifique à votre application et à son objectif.

Logique de présentation: rien de ce que l'utilisateur interagit avec ou résultant de l'interaction de l'utilisateur.

Ces deux préoccupations sont liées à ces types de communication:

• L'état de l'Application
• Parent-enfant
• Enfant-parent
• Frères et sœurs

Chaque type doit utiliser le bon canal de communication.

---

Canaux de Communication

Un canal est un terme général que je vais utiliser pour se référer à des implémentations concrètes pour l'échange de données autour d'une Vue app.

Accessoires (Présentation de la logique)

Le plus simple canal de communication en Vue directe Parent-Enfant de la communication. Il doit surtout être utilisé pour transmettre des données relatives à la présentation de la logique ou d'un ensemble limité de données au bas de la hiérarchie.

Refs et les méthodes (Présentation de la logique)

Quand il ne fait pas de sens d'utiliser un support pour permettre à un enfant de gérer un événement à partir d'un parent, la configuration d'un ref sur le composant enfant et en appelant ses méthodes est tout simplement parfait.

Certaines personnes peuvent dire que c'est un couplage étroit entre le parent et l'enfant, mais c'est le même couplage de l'aide d'accessoires. Si nous pouvons être d'accord sur un contrat d'accessoires, nous pouvons convenir d'un contrat pour l'utilisation de méthodes.

Événements (Présentation de la logique)

$emit et $on. Le plus simple canal de communication direct de communication entre Parents et Enfants. De nouveau, doit être utilisé pour la présentation de la logique.

Événement de bus (les Deux)

La plupart des réponses donner de bonnes alternatives pour bus d'événement, qui est l'un des canaux de communication disponibles pour les composants, ou quoi que ce soit en fait.

Cela peut être utile lors du passage d'accessoires tous plus de l'endroit de loin, de haut en bas de profondément imbriqués les enfants composants, avec presque pas d'autres composants ayant besoin de ces intermédiaires.

Attention: à la suite de la création de composants qui lient eux-mêmes à l'événement de bus sera tenu plus d'une fois-conduisant à plusieurs gestionnaires déclenchée et les fuites. J'ai personnellement jamais ressenti le besoin pour un événement de bus dans tous les single page applications que j'ai conçu dans le passé.

Le suivant montre comment une simple erreur conduit à une fuite où le Item composant déclenche toujours, même s'il est retiré de la DOM.

JS:

//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);
    }
  }
});

HTML:

<script src="https://unpkg.com/[email protected]/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>

N'oubliez pas de retirer les auditeurs dans le destroyed cycle de vie du crochet.

Banque centralisée (logique)

Vuex est le chemin à parcourir avec Vue pour la gestion de l'état. Il offre beaucoup plus que juste des événements et il est prêt pour l'application intégrale.

Et maintenant vous vous demandez:

[S]ois-je créer vuex de stocker pour chaque mineur de communication?

Il brille vraiment quand:

• de traiter avec votre logique métier,
• communiquer avec un backend

Si vos composants peut vraiment se concentrer sur les choses qu'ils sont censés être, la gestion des interfaces utilisateur.

Cela ne signifie pas que vous ne pouvez pas l'utiliser pour le composant logique, mais je voudrais champ d'application de cette logique à un espace de noms Vuex module avec seulement le nécessaire mondial de l'INTERFACE utilisateur de l'état.

Pour éviter de traiter avec un gros gâchis de tout dans un état global, nous devons diviser le stocker dans de multiples espaces de modules.

---

Types de composants

Pour orchestre tous ces communications et à la facilité de réutilisation, nous devons penser de composants de deux types différents.

• Application des conteneurs spécifiques
• Composants génériques

Encore une fois, cela ne veut pas dire qu'un composant générique doivent être réutilisés ou d'une application conteneur spécifique ne peut pas être réutilisée, mais ils ont des responsabilités différentes.

Application des conteneurs spécifiques

Ce sont juste simple Vue de composant qui encapsule autre Vue des composants (générique ou d'autres applications, des conteneurs spécifiques). C'est là que le Vuex magasin de la communication qui doit arriver et ce conteneur doit communiquer à l'aide d'autres simples comme des accessoires et des écouteurs d'événement.

Ces conteneurs peuvent même pas natif des éléments du DOM et de laisser les composants génériques face à cela.

portée en quelque sorte events ou stores visibilité pour les frères et sœurs des composants

C'est où la détermination de la portée qui se passe. La plupart des composants ne sais pas à propos de la boutique et ce composant de l' (pour la plupart) utiliser un espace de noms module boutique avec un ensemble limité de getters et actions appliquée avec le Vuex mappeurs.

Composants génériques

Ceux-ci devraient recevoir leurs données à partir d'accessoires, de faire des changements sur leurs propres données, et émettent de simples événements. La plupart du temps, ils ne devraient pas connaître une Vuex magasin existe.

Ils pourraient aussi être appelés conteneurs comme leur seule responsabilité pourrait être à l'expédition à d'autres composants de l'INTERFACE utilisateur.

---

Frère de communication

Alors, après tout cela, comment devrions-nous communiquer entre deux frère composants?

Il est plus facile de comprendre avec un exemple: disons que nous avons une zone de saisie et de ses données doivent être partagées à travers l'application (frères et sœurs, à différents endroits dans l'arbre) et a persisté avec un backend.

En commençant par le pire des cas, notre composant mélange de présentation et affaires logique.

//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
                    })
                    .then((response) => {
                        this.$root.$emit('update', response.data);
                    });
            }
        }
    }
</script>

De séparer ces deux préoccupations, nous devons appliquer notre composant dans une application conteneur spécifique, et de garder la logique de présentation dans notre générique composant d'entrée.

Notre composant d'entrée est maintenant réutilisables et ne sait pas sur le backend, ni les frères et sœurs.

//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>

Notre application conteneur spécifique, peut-être le pont entre la logique métier et la présentation de la 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.updateState,
        ])
    }
</script>

Depuis le Vuex magasin actions traiter avec le backend de la communication, notre conteneur, ici, n'a pas besoin de savoir à propos de axios et le backend.

Ce que j'ai l'habitude de le faire si je veux "hack" de la structure normale de la communication en Vue, spécialement maintenant que .sync est obsolète, est de créer une simple EventEmitter qui gère la communication entre les composants. De l'un de mes derniers projets:

import {EventEmitter} from 'events'

var Transmitter = Object.assign({}, EventEmitter.prototype, { /* ... */ })

Avec cette Transmitter objet que vous pouvez ensuite le faire, en tout composant:

import Transmitter from './Transmitter'

var ComponentOne = Vue.extend({
  methods: {
    transmit: Transmitter.emit('update')
  }
})

Et de créer une "réception" de la composante:

import Transmitter from './Transmitter'

var ComponentTwo = Vue.extend({
  ready: function () {
    Transmitter.on('update', this.doThingOnUpdate)
  }
})

Encore une fois, c'est vraiment des utilisations spécifiques. Ne pas la base de l'ensemble de votre demande sur ce modèle, utilisez quelque chose comme Vuex à la place.