Another solution that was popular a few years ago was to use a broadcasting mechanism, through which application code would simply emit custom global events, along with arbitrary data. The rest of the application was then able to retrieve the data and react to the changes by listening to those global events.
The advantage of broadcasting is that different and unconnected application components can easily communicate without us having to introduce strong coupling and without us needing many unrelated components to participate in the data exchange.
Broadcasting was actually supported in Vue.js 1.x through $broadcast, as well as in older AngularJS versions through $rootScope.$broadcast. These were never heavily recommended and have been deprecated/removed during the evolution of their respective frameworks.
For instance, the official migration guide from Vue 1.x to 2.0 proposed that we should use the following pattern to let distant components communicate with each other:
var eventHub = new Vue();
// Somewhere in the application eventHub.$emit('add-todo', { text: this.newTodoText });
// Elsewhere in the application eventHub.$on('add-todo', this.addTodo);
The idea simply consists of using a separate instance of Vue and using it as an event hub. This is possible because the Vue instance can be made global and it includes methods that we can use publish and react to events:
Broadcasting is compelling, but has important drawbacks to be aware of.
If you start broadcasting events, then you're actually introducing the equivalent of global variables to your code base. Any application component can broadcast the same events and wreak havoc in the application.
Also, the more events you broadcast, the harder it'll become to track the application's logical flow.
Finally, broadcasting does not scale and rapidly makes application code hard to reason about (for example, what emitted an event and why?).
For those reasons, broadcasting only makes sense for very small applications.