Avoiding Event Chains in Single Page Applications • Hacker News Board

Re: Avoiding Event Chains in Single Page Applications

#41

Post by regularfry » Sun, Aug 31, 2014, 5:46 PM UTC

Retozi wrote: post #29

regularfry wrote: post #26

It looks to me like the case where this is required is actually screaming out for a new event type, not fixed dependency order. B shouldn't be listening for the same event as A is if B depends on A getting something done. A should be firing a new event which B can listen for. Is there some subtlety I've missed here?

The flaw with such a strategy is that it does not scale. (We used to do exactly what you described). In a big "eventful" app, you will have way too many events to keep track, and you will constantly be browsing trough different modules to understand the chain. Lets assume the user clicks somewhere, so an event is fired "user-clicked-x" that model A listens to. So you know that model B needs to change as well and you…

This I can well believe, but I'm interested in this bit:

> you fire a new event type from model A, say "model-a-changed-because-of-user-clicked-x" or a more generic event, say "model-a-changed".

These two seem to be on opposite ends of a spectrum where I'd try to pick a middle point. I wouldn't want the semantics of "this is a reaction to a UI event" anywhere past the first event, it's way too detailed. I'd try to pick something like "model A's date field changed ", or ideally something more meaningful like "The User updated their address".

Re: Avoiding Event Chains in Single Page Applications

#42

Post by kaonashi » Sun, Aug 31, 2014, 5:46 PM UTC

msy wrote: post #14

It took me a while to come round to it but this kind of madness is something that Ember's event/render loop and implicit property dependency graph makes really, really easy to solve. People knock Ember for its complexity but in reality it's simply a complete/coherent solution for the kind of problems people like this are iterating towards - and watching their code get more complex as they do.

Having built large Ember and Flux apps, Ember seems a big opaque mess.

Computed properties which depend upon other computed properties never seem to update quite right. The object system is tightly coupled to the template system. It's a monolithic framework that depends upon hidden magic to bind the pieces together.

Re: Avoiding Event Chains in Single Page Applications

#43

Post by regularfry » Sun, Aug 31, 2014, 5:48 PM UTC

btipling wrote: post #31

regularfry wrote: post #26

It looks to me like the case where this is required is actually screaming out for a new event type, not fixed dependency order. B shouldn't be listening for the same event as A is if B depends on A getting something done. A should be firing a new event which B can listen for. Is there some subtlety I've missed here?

At floobits we use "actions" in addition to model events for our flux like implementation. Views trigger usually actions, modifying models triggers events on the model. Views in themselves do not usually trigger model updates. So think about opening up a file in a web editor, that's an action. Many things might care about when a file is opened. The tab UI, maybe a log, other users connected to your session. Sometimes…

This makes sense. I've thought for a while that separating commands and events was the right thing to do, even if they use the same distribution mechanism.

Re: Avoiding Event Chains in Single Page Applications

#44

Post by kaonashi » Sun, Aug 31, 2014, 5:50 PM UTC

illumen wrote: post #22

sehr wrote: post #9

Earlier quoted context omitted.

How? Everything about this seems incredibly straightforward

Call me old fashioned, but function calls are pretty nice events. Rather than heaps of code, and weird concepts, you can just implement firing the event into the A, and B models by calling a method on each. Simple! A.getFilteredDays(payload); B.getFilteredDays(payload); That's only two lines of code compared to 30 or so. This scales up because with more models, you have less code. In practice these are easier to debu…

Oh boy, jQuery soup. Sounds fun to unit test.

Re: Avoiding Event Chains in Single Page Applications

#45

Post by illumen » Sun, Aug 31, 2014, 6:06 PM UTC

kaonashi wrote: post #44

illumen wrote: post #22

Earlier quoted context omitted.

Call me old fashioned, but function calls are pretty nice events. Rather than heaps of code, and weird concepts, you can just implement firing the event into the A, and B models by calling a method on each. Simple! A.getFilteredDays(payload); B.getFilteredDays(payload); That's only two lines of code compared to 30 or so. This scales up because with more models, you have less code. In practice these are easier to debu…

Oh boy, jQuery soup. Sounds fun to unit test.

Unit testing has been done with jQuery since it came out in 2006. Rather than one giant monolithic app, jQuery promotes putting things into plugins or separate libraries.

What stops you from unit testing function calls? Nothing.

Re: Avoiding Event Chains in Single Page Applications

#46

Post by kaonashi » Sun, Aug 31, 2014, 6:12 PM UTC

illumen wrote: post #45

kaonashi wrote: post #44

Earlier quoted context omitted.

Oh boy, jQuery soup. Sounds fun to unit test.

Unit testing has been done with jQuery since it came out in 2006. Rather than one giant monolithic app, jQuery promotes putting things into plugins or separate libraries. What stops you from unit testing function calls? Nothing.

It also promotes procedural code for modifying DOM, not declarative. This makes unit testing much harder imo, since you're into the realm of either working against a real DOM, or mocking everything.

Re: Avoiding Event Chains in Single Page Applications

#47

Post by coldtea » Sun, Aug 31, 2014, 6:41 PM UTC

illumen wrote: post #39

coldtea wrote: post #36

Earlier quoted context omitted.

Hmm, this answer seems to have missed 7-8 years of the web's development, and shows a preference for convoluted, messy codebases with huge conginitive overload...

Explain how smaller, simpler and faster code is worse.

Smaller: Not really. You just avoid some K of helper code already build (by the React team). Your code will end up being more than the one you'd have written on top of React -- because it will also have to reimplement and handle all common cases (either poorly, or time-consumingly).

Faster: could be, could be not. Without profiling this is an empty statement. Besides, "premature optimization is the root of all evil".

Simpler: Noope. You have to manually track all the interactions, and you strongly couple things together with your "OO and functions" idea. It might be simpler to just churn out code initially (instead of understanding an architecture), but it becomes an ad-hoc mess soon.

Let me put it this way: it's not like you have discovered a novel way of building stuff compared to these coders that overcomplicate things. What you propose is what these engineers have already tried, used for a decade or so, and found unscalable and wanting.

It can work for small and not complicated pages, but it's not a solution to modern single page web apps.

You might think that you are proposing a clear and simple way of coding as opposed to something like overengineered J2EE patterns mess.

But what you describe is more like the "Why use procedural code etc, GOTOs for flow are simpler and faster", or "why use functional programming, imperative is simpler and faster".

Re: Avoiding Event Chains in Single Page Applications

#48

Post by Illniyar » Sun, Aug 31, 2014, 6:44 PM UTC

If ModelB needs to wait for ModelA, and it already is aware of ModelA (which your code requires) - why not make ModelA into an eventDispatcher, have ModelB listen to ModelA, and have ModelA dispatch an event when it's done (Or write a small onX function in ModelA).

It's also clearer, easier to implement, already implemented in tons of frameworks and easier to unit test (since you no longer need to mock the appDispatcher).

You should probably try to avoid using a global eventDispatcher (as any other global), whether you can specify order of execution or not.

Re: Avoiding Event Chains in Single Page Applications

#49

Post by coldtea » Sun, Aug 31, 2014, 6:44 PM UTC

regularfry wrote: post #40

coldtea wrote: post #33

Earlier quoted context omitted.

That this works automatically and assures all events will be seen appropriately. That is, now he just has to declare it in the interested party -- whereas in your case, the programmer will have to fully manually manage who gets what.

Well, right now, he has to explicitly listen for one event in two places, and annotate the order correctly. With two separate events types, he would only have to listen for the events.

Nope, he doesn't have to annotate the order correctly. Except if you mean locally, in which case it's trivial.

Re: Avoiding Event Chains in Single Page Applications

#50

Post by lukasm » Sun, Aug 31, 2014, 6:57 PM UTC

rational-future wrote: post #38

lukasm wrote: post #24

Does anyone know how this dispatcher is different from WPF dispatcher? Maybe that's the way to sell it.

IMHO WPF doesn't have so much of a good reputation, to be used to market other products.

not for marketing per se, but to sell to understand what is it and why is it good. A lot of people know WPF and you could use the analogy.