Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoiding Event Chains in Single Page Applications

code-experience.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Avoiding Event Chains in Single Page Applications

#31

Post by btipling »

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 views correlate well to model updates, like a form, but many times they do not in which case a different event type can be useful.

Re: Avoiding Event Chains in Single Page Applications

#33

Post by coldtea »

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?

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.

Re: Avoiding Event Chains in Single Page Applications

#34

Post by coldtea »

rtpg wrote: post #20
Retozi wrote: post #15

Earlier quoted context omitted.

yep, that's all it does. It just inverted the sequence dependency. You call it "worse". But I argue that it is a much better mental model in the specific use case of updating state given an external disruption from the user. You see, what you call a clear sequential path is what I call evil :). We had tons of those in our app, and it was so hard to keep track of them, and everytime I didn't look at it for a while, I…

> A updates because "user-clicked-x", and B updates because A updates. But if you're working on B, you ask yourself why the heck did A update in the first place? Stack traces are a thing. Chrome even has asynchronous stack-traces. A updates because "user-clicked-x", but it might also update because "user-clicked-y". Or because "user-clicked-z". So now I have 3 things to add to A and to B, because B needs to refresh e…

>Stack traces are a thing. Chrome even has asynchronous stack-traces.

Now this argument line has dissolved into plain sillyness.

He showed how he made the congnitive load less and the dependencies more explicit and locally evident IN THE CODE, and you tell him to use "stack traces" for that?

Re: Avoiding Event Chains in Single Page Applications

#36

Post by coldtea »

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…

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...

Re: Avoiding Event Chains in Single Page Applications

#37

Post by rational-future »

coldtea wrote: post #35
rational-future wrote: post #30

So Flux is poor man's BizTalk.

Yes -- but only if you half-understood Flux, didn't read the article, and just wanted to make a snark comment.

Now that's a reassuring yes :)

What I meant is it seems (I've never used or seen it before) to be closer to a message broker than a bus - http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-dif...

Re: Avoiding Event Chains in Single Page Applications

#39

Post by illumen »

coldtea wrote: post #36
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…

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.

Re: Avoiding Event Chains in Single Page Applications

#40

Post by regularfry »

coldtea wrote: post #33
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?

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.

Post reply on HN