Both methods $broadcast and $dispatch are now merged in the $emit method with the same syntax as the old version. Unfortunately, replacing every instance of $broadcast and $dispatch with $emit is not guaranteed to always work because the pattern used to manage events is a little different now.

In Vue 1, you had events follow a path either downward (for $broadcast) or upward (for $dispatch), and horizontally (for $emit) through the hierarchical tree.

To be honest, I never liked having two (three if you count the old $emit) methods for emitting events. It was confusing even in the smallest contexts because you had to ask yourself is this event for parents or children? Most of the time it was not that important of a distinction, you just wanted your method to fire. But there is no such thing as a free lunch; we have to add a moving part to our system to make everything work in the new paradigm.

Now all events should pass through one or more central hubs. The role of this central hubs can be taken by a Vue instance since they implement the necessary interface.

When emitting an event consumed by v-on, you're good to go by replacing $broadcast with $emit, since the event doesn't have to travel far. On the other hand, if you are defining an interface for a component in terms of events, you will have to say goodbye to the events option since it will not work anymore. This is the direct consequence of having all the events passing through a hub--the events option wouldn't know where to register all the events. This is the trade off for having a single emitting method: it fires in every direction but only in a precise piping.

Let's say you have a dedicated empty Vue instance that will act as an event hub:

var eventBus = new Vue()

If you are writing a teapot component and you want to register the brew event, you will write in the created hook something like the following:

new Vue({ 
  el: '#app', 
  components: { 
   comp1: { 
         template: '<div/>', 
         created () { 
         eventBus.$on('brew', () => { 
         console.log('HTTP Error 418: I'm a teapot') 
        }) 
      } 
    }, 
    comp2: { 
         template: '<div/>', 
         created () { 
         eventBus.$emit('brew') 
      } 
    } 
  } 
})

And with the HTML:

<div id="app"> 
  <comp1></comp1> 
  <comp2></comp2> 
</div>

Every time the brew event is emitted with eventBus.$emit('brew'), the console will output a message.

Any component you'll write can act as an event hub. You also have the API methods $off which deletes listeners, and $once, which listens for an event but only once.

If you had a lot of filtered v-for lists, I have bad news for you. Even if in the wild the most common use for filters was with v-for, the community chose to remove this feature. The reason is mainly because having a lot of filters, often piped together, was hard to reason about and thus to maintain.

The new recommended way to filter a list is with a computed property. Luckily for you, we have an entire recipe on how to do that. See the recipe Filtering a list with a computed property in the next chapter.

Custom delimiters are not at the component level. If you want, you can have two different components using different delimiters.

This is fairly easy to upgrade and allows you to write components intended to be used inside other template engines:

<div id="app"> 
  {!msg!} 
</div>

new Vue({ 
 el: '#app', 
 data: { 
   msg:'hello world' 
 }, 
 delimiters: ['{!','!}'] 
})

Life cycle have now a more consistent naming that will help with remembering their names in the long run: