3 ms·

It doesn't look like $emit is removed, just the functions to bind event handlers on a component ($on, $off, $once): https://github.com/vuejs/docs-next/pull/167/

It doesn't look like $emit is removed, just the functions to bind event handlers on a component ($on, $off, $once): https://github.com/vuejs/docs-next/pull/167/files https://github.com/vuejs/docs-next/pull/167/files

IgorPartola 6y ago
Why would they do that? Having an event bus can be incredibly useful.
- mmis1000 6y ago
  And also incredibly messy, often result in non maintainable code. For one shot small project, this is fine. For a big complex project, If you see they already use this. You are mostly already screwed.
  - IgorPartola 6y ago
    So the way I’ve been using it is pretty much for toaster notifications and asynchronous updates that are sent from the server to the client. Any component can subscribe to async updates on the shared bus and it will know when a particular object has been updated and can choose what to do with it. We don’t use the global store for all the objects because we deal with a lot of large page-specific state. Toaster notifications are also really nice this way: a lowly modal can send a top page “an error happened” notification without having to do the plumbing for this through every page and component. I don’t see any of that as an anti pattern.
    - mmis1000 6y ago
      And FB suffered from this due to undebuggable double notification bug because it could be really hard to debug when any component can send any event to other without any restriction. They eventually moved to flux pattern due to this. That said. It is possible to avoid such situation with strong lint rule. Like you did here. But you can avoid it completely with ~~JUST DON'T~~ . Why should a framework encourage people to do bad things?
      - IgorPartola 6y ago
        Um, no. That’s the whole thing is that the components don’t have to know how it is implemented. They do this.$bus.showError(‘Oops’). The bus implementation under the hood sends a message to the top level App component which in turn has the toaster notification implementation. I don’t need a linter to make this work.
        mmis1000 6y ago
        You do need a guide to prevent people from sending random unrelated message to random handler hide deep inside some random component and emit again to other random component. It `is` fine to use it and only use on notification purpose, but there is no way to enforce everyone to do so. More of time it `will` be used in a terrible way that I just described (something like .emit('login') and trigger some random function causing xhr and emit notification everywhere). You can't really assume everyone will use them nicely instead of resulting in spaghetti code. It is not the case most of time. The experience I learned from I start coding is. `Anything designed to be easy to mess up will eventually mess up`
        IgorPartola 6y ago
        Maybe this is what happens when you’ve been coding for years and years but the thing is I was using this particular foot gun and it was working well. I don’t need a framework developer to babysit me and prevent me from misusing a feature. I know when it is a foot gun and I can treat it as such. It sounds like the Vue devs simply removed this feature that was in some ways useful and didn’t replace it with anything better. They removed it because it enabled people to do something they didn’t like, which yes as a maintainer of a popular framework is kind of your responsibility to be help people figure out. But this is like if C removed the ability to dereference pointers because it’s dangerous to do. Of course it’s dangerous, that’s why it’s so powerful. If you can’t use it responsibly, that’s on you, not on the framework developers. Basically, it’s not like they added a formalized way to create notification buses. They simply removed a useful and widely used feature because they didn’t like how people were using it. This is exactly the kind of shit that killed Angular and honestly makes me reevaluate the trust I’ve placed in Vue. Improvements are always welcome. Wholesale removing useful features without providing an alternative, not so much.

IgorPartola 6y ago

Why would they do that? Having an event bus can be incredibly useful.

mmis1000 6y ago
And also incredibly messy, often result in non maintainable code. For one shot small project, this is fine. For a big complex project, If you see they already use this. You are mostly already screwed.
- IgorPartola 6y ago
  So the way I’ve been using it is pretty much for toaster notifications and asynchronous updates that are sent from the server to the client. Any component can subscribe to async updates on the shared bus and it will know when a particular object has been updated and can choose what to do with it. We don’t use the global store for all the objects because we deal with a lot of large page-specific state. Toaster notifications are also really nice this way: a lowly modal can send a top page “an error happened” notification without having to do the plumbing for this through every page and component. I don’t see any of that as an anti pattern.
  - mmis1000 6y ago
    And FB suffered from this due to undebuggable double notification bug because it could be really hard to debug when any component can send any event to other without any restriction. They eventually moved to flux pattern due to this. That said. It is possible to avoid such situation with strong lint rule. Like you did here. But you can avoid it completely with ~~JUST DON'T~~ . Why should a framework encourage people to do bad things?
    - IgorPartola 6y ago
      Um, no. That’s the whole thing is that the components don’t have to know how it is implemented. They do this.$bus.showError(‘Oops’). The bus implementation under the hood sends a message to the top level App component which in turn has the toaster notification implementation. I don’t need a linter to make this work.
      - mmis1000 6y ago
        You do need a guide to prevent people from sending random unrelated message to random handler hide deep inside some random component and emit again to other random component. It `is` fine to use it and only use on notification purpose, but there is no way to enforce everyone to do so. More of time it `will` be used in a terrible way that I just described (something like .emit('login') and trigger some random function causing xhr and emit notification everywhere). You can't really assume everyone will use them nicely instead of resulting in spaghetti code. It is not the case most of time. The experience I learned from I start coding is. `Anything designed to be easy to mess up will eventually mess up`
        IgorPartola 6y ago
        Maybe this is what happens when you’ve been coding for years and years but the thing is I was using this particular foot gun and it was working well. I don’t need a framework developer to babysit me and prevent me from misusing a feature. I know when it is a foot gun and I can treat it as such. It sounds like the Vue devs simply removed this feature that was in some ways useful and didn’t replace it with anything better. They removed it because it enabled people to do something they didn’t like, which yes as a maintainer of a popular framework is kind of your responsibility to be help people figure out. But this is like if C removed the ability to dereference pointers because it’s dangerous to do. Of course it’s dangerous, that’s why it’s so powerful. If you can’t use it responsibly, that’s on you, not on the framework developers. Basically, it’s not like they added a formalized way to create notification buses. They simply removed a useful and widely used feature because they didn’t like how people were using it. This is exactly the kind of shit that killed Angular and honestly makes me reevaluate the trust I’ve placed in Vue. Improvements are always welcome. Wholesale removing useful features without providing an alternative, not so much.