3 ms·

I don't want to rail on the author here - lord knows I've written some JavaScript that I regret now - However, putting things on an event bus does not make modu

I don't want to rail on the author here - lord knows I've written some JavaScript that I regret now - However, putting things on an event bus does not make modules independent, testable, or re-usable. You get those things from careful planning. You are still going to introduce conceptual dependencies between modules. I'd personally rather have explicit control over those dependencies and their interfaces rather than passing it through a bus. But anyway, y'all, if class A depends on class B, formalize the interface between the two (throw an error when expectations aren't met) and then inject the instance!

wesleytodd 10y ago
Hey John!! Couldn't agree more. We had an event bus in an early implementation of our application and it was a huge pain later when we didn't know every place that was using and relying on a given event. We switched to a much more explicit structure with defined dependencies and more boilerplate to reduce the "magic". It is much easier to debug and maintain over the long haul. The boilerplate stuff sucks to write, but when you are going to maintain the application for more than a few months, it takes MUCH less time to go back and understand than the alternatives.
- pheeney 10y ago
  Would it be possible to write some pseudocode on how you converted some of your code? I am trying to avoid some "magic" as well but not certain how to handle some of these dependencies.
pheeney 10y ago
> But anyway, y'all, if class A depends on class B, formalize the interface between the two (throw an error when expectations aren't met) and then inject the instance! Do you have a simple example of this for something like https://mbasso.github.io/refraction/docs/basics/Publishing.html https://mbasso.github.io/refraction/docs/basics/Publishing.h... in react? Would you hard code in the dependencies if you have "multiple" modules that respond to "onUserLogin" "event".

wesleytodd 10y ago

Hey John!! Couldn't agree more. We had an event bus in an early implementation of our application and it was a huge pain later when we didn't know every place that was using and relying on a given event. We switched to a much more explicit structure with defined dependencies and more boilerplate to reduce the "magic". It is much easier to debug and maintain over the long haul. The boilerplate stuff sucks to write, but when you are going to maintain the application for more than a few months, it takes MUCH less time to go back and understand than the alternatives.

pheeney 10y ago
Would it be possible to write some pseudocode on how you converted some of your code? I am trying to avoid some "magic" as well but not certain how to handle some of these dependencies.

pheeney 10y ago

> But anyway, y'all, if class A depends on class B, formalize the interface between the two (throw an error when expectations aren't met) and then inject the instance! Do you have a simple example of this for something like https://mbasso.github.io/refraction/docs/basics/Publishing.html https://mbasso.github.io/refraction/docs/basics/Publishing.h... in react? Would you hard code in the dependencies if you have "multiple" modules that respond to "onUserLogin" "event".