Avoiding Event Chains in Single Page Applications
code-experience.com
Avoiding Event Chains in Single Page Applications
1–10 of 64 posts
Re: Avoiding Event Chains in Single Page Applications
#2Complex.
Re: Avoiding Event Chains in Single Page Applications
#3OT but I'm looking for a comparison between Angular and React/Flux, preferably with a real case study. Working with templates that update themselves without having to bother with anything else just seems to much easier...
Re: Avoiding Event Chains in Single Page Applications
#4it's amazing how JavaScript is becoming the new java.
everyone thinks that adding a ton of extra complexity in the guise of a simpler api will make it more maintainable.
in this example you now have 4 events under the hood and two event dispatchers. but it seem simpler because you only "see" two and one dispatcher.
while it may make things just a little bit simpler to maintain you may enter debug hell when there's bugs on that added under the hood complexity... which will often be a code you're unfamiliar. making the article main argument (helping on debugging edge case bugs) kind of two edged
Re: Avoiding Event Chains in Single Page Applications
#5OT but I'm looking for a comparison between Angular and React/Flux, preferably with a real case study. Working with templates that update themselves without having to bother with anything else just seems to much easier...
I have had lots of problems trying to understand and use Angular. Most people don't. The TODO MVC site has comparisons for a simple app:
The main problem is that a TODO app is too simple. But if the app were more complicated it would be much harder to prepare and read the examples.
Re: Avoiding Event Chains in Single Page Applications
#6it's amazing how JavaScript is becoming the new java. everyone thinks that adding a ton of extra complexity in the guise of a simpler api will make it more maintainable. in this example you now have 4 events under the hood and two event dispatchers. but it seem simpler because you only "see" two and one dispatcher. while it may make things just a little bit simpler to maintain you may enter debug hell when there's bu…
The thing is that the hidden complexity will not appear, as rendering and state management are now separate. Both can be unit tested in separation. Components are modular and composable.
Re: Avoiding Event Chains in Single Page Applications
#7it's amazing how JavaScript is becoming the new java. everyone thinks that adding a ton of extra complexity in the guise of a simpler api will make it more maintainable. in this example you now have 4 events under the hood and two event dispatchers. but it seem simpler because you only "see" two and one dispatcher. while it may make things just a little bit simpler to maintain you may enter debug hell when there's bu…
writer of the article here:
I simply cannot follow the argument about "added complexity"
The use case defines the minimum amount of links you have to make, in this case 4.
Now you have two options: You just roll with it (we used to do that), or you try to abstract away a few steps (we do this now with the dispatcher).
The dispatcher here is roughly 100 lines of fairly simple, unittestable code, so I really cannot see where the elusive bugs come from. 100 lines that you will easily save if your app is complex enough by the way.
With the dispatcher, you can abstract away a couple of steps consistenly over your app. Now I fully agree that you need a certain threshold of complexity to make it worthwile.
But you cannot avoid the original complexity of your usercase.
There is no alternative to decent abstraction if you reach a certain level of complexity, because it is given externally.
Other concepts like two-way databinding do exactly the same.
Re: Avoiding Event Chains in Single Page Applications
#8OT but I'm looking for a comparison between Angular and React/Flux, preferably with a real case study. Working with templates that update themselves without having to bother with anything else just seems to much easier...
My comparison is here: http://noelwelsh.com/programming/2014/08/17/angularjs-vs-rea...
It isn't a 100% fit for what you're looking for -- there is no case study -- but it might be useful to you.
Re: Avoiding Event Chains in Single Page Applications
#9Complex.
How? Everything about this seems incredibly straightforward
Re: Avoiding Event Chains in Single Page Applications
#10OT but I'm looking for a comparison between Angular and React/Flux, preferably with a real case study. Working with templates that update themselves without having to bother with anything else just seems to much easier...
I do not have much experience with Angular, however, I feel the arguments over different frameworks depend a lot on the specific nature of your app.
two-way databinding is perfectly fine and really helpful for a lot of apps. However, it will screw you for certain use cases.
In my opinion, it really boils down to how much global interaction you have in your app. If you simply render a lot of models that can only be changed trough the view, then I don't really see a reason for a Flux like architecture. Two-way databinding is perfectly fine there. (React vs whatever then boils down to performance vs toolset)
If you do a lot of graphical stuff that allows for heavy interaction, filtering and other kinds of stuff, I believe that two-way databinding will be your downfall. You need to clearly and explicitly map out on how data flows through your app. That is the time where an architecture like Flux shines.
So ask yourself this question:
"How often can a user do something in your app, and a lot of Views need to rerender?"
If the answer is "often", then you should consider something like Flux. If not, Angluar might be a better fit, especially if you already know it.