Avoiding Event Chains in Single Page Applications

In the example from the article we are talking about, it would be easy to mock out the one function call for modules A, and B. There's no DOM manipulation in the article.

Keeping DOM modifying code separate is good practice in either case. Then you don't need to involve the DOM in much of your code. Doing end to end testing is also completely ok to do.

It's worth repeating, so I'll say it again... It's better to keep DOM manipulation code separate. Then you don't need to mock, or simulate anything. Except where needed. You do need to test DOM manipulating code somehow.

AngularJS also uses the DOM in their tests: https://github.com/angular/angular.js/blob/master/test/ngAni... Here's a jquery-ui test for comparison: https://github.com/jquery/jquery-ui/blob/master/tests/unit/s...

The code I mentioned is definitely smaller than in the article.

It is faster, because it is just a function call. It doesn't create any event objects, or have to go through six layers of other function calls.

It's simpler because there is less code, and there are less concepts.

No, it's not novel or new. Messages as function calls, and MVC comes from 70s smalltalk.

It's not strongly coupled because of a few reasons. Firstly because in JavaScript it is simple to dynamically reassign objects and functions. The receiving object does not care where it got the function called from. Only the sending object knows where it is sending to. However, from Coupling theory in Software Engineering, we know that if there are a small amount of outputs then the strength of the coupling is still low. Luckily in many apps there are often only a few places where you want to send a message. http://en.wikipedia.org/wiki/Coupling_%28computer_programmin...

Yes, if there are lots of outputs it may be useful to reduce the coupling. In my experience, even with large apps (100 person teams), this is often not the case.

It is often useful to know what your app is doing by looking at where the events are going. Just using function calls makes this very easy, both in source code and in the debugger. So this also needs to also be weighed up in the decision of how you are passing events around.

A model listening to other models? Yuck, that's just wrong. In an MVC application, only controllers should update models. Just because Backbone lets you listen to model events from anywhere doesn't mean it's a good idea.

IMHO Application events should simply bubble up through the DOM, and get caught by appropriate controllers (Backbone.View class in backbone parlance) that then modify the appropriate models. If need be it's the top-level controller for the app, eg:

document.body.addEventListener(function(e) { modelA.doSomething(e.data) modelB.doSomethingElse(e.data) });

I'd take a simple approach like that over an event bus/dispatcher/coolest-new-pattern-since-sliced-bread - any day, and sleep at night knowing if something happens to me, any employee will be able to parse and debug my code.

PS And no, I don't use Backbone, but my own 500 LOC MVC framework that's got zero dependencies and is about 100x faster.

>The code I mentioned is definitely smaller than in the article.

Yeah, so this is a first sign of misreading the dangers.

Of course the code you mentioned is "smaller than in the article". The code in the article is a toy example to illustrate a specific point.

It's when you start to build a full app, with all the (necessary for the requirements) complexity that it's gonna get much more and more unyieldy that the code one would write on top of React.

>It is faster, because it is just a function call. It doesn't create any event objects, or have to go through six layers of other function calls.

Again: premature optimization. After you build your colossal temple of function calls in a NON TOY example, it will either be slow (because you'll have re-introduced abstractions and layers by yourself) or it would a complex spaghetti of cross-calls.

>It's simpler because there is less code, and there are less concepts.

Less concepts != simpler. Assembly has less concepts too.

And it's only "less code" because you're comparing a "toy example + framework" with a "toy example without framework". It's after that level that it gets hairy.

>No, it's not novel or new. Messages as function calls, and MVC comes from 70s smalltalk.

Yeah, and it's what all these coders going to React etc have tried already for a decade and found out that it doesn't cut it with modern apps, because the environment they run in is nothing like a Smalltalk MVC application.

I'm with you, bub.

The people arguing against you don't know what they're talking about. They're stuck in a paradigm where "de-coupled event-driven architecture" is a holy goal and can't see their feet on the ground anymore.