3 ms·

> 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

by rtpg 12y ago

> 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 everytime A does. So if you forget about one of these, then suddenly B is out of sync. A "solution" to this problem already exists in terms of event listeners. If B listens to any change on A, then A doesn't have to deal with B, but B updates properly and doesn't have to deal with all event types A has to deal with.

Retozi 12y ago
Well, I remember all these things just too well from our Backbone App (not Backbones fault, but ours!), and I would never go back there again. So now I have 3 things to add to A and to B, because B needs to refresh everytime A does We used to do this. A lot. It was a big mess. Because in reality (for us), it is never that clear cut. You almost never have full dependencies so that thight coupling is the right way to do model it. There are always exceptions that you need to be aware of. We found that decoupling reduces cognitive load greatly, and changing the relationships can be done a magnitude quicker because "listen to except if this and that happens" doesn't scale. There are just too many this and thats if your app is big. I know that the status quo method always looks easier than something new, because its unfamiliar. But restriction of communication flow is, in my opinion, the ONLY way to keep order in a big, complex app. Just consider this: I've tried both ways extensively, and I favor the Flux way. I might be an idiot, but there is a possibility that I'm not. This should encourage people to really try this once to avoid status quo bias.
coldtea 12y ago
>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?
- rtpg 12y ago
  From what I understand, this methodology increases code duplication, which leads to higher risks of bugs later on. I'm trying to understand whether this is truly the case, or if I'm missing something.

by rtpg 12y ago

Retozi 12y ago

Well, I remember all these things just too well from our Backbone App (not Backbones fault, but ours!), and I would never go back there again. So now I have 3 things to add to A and to B, because B needs to refresh everytime A does We used to do this. A lot. It was a big mess. Because in reality (for us), it is never that clear cut. You almost never have full dependencies so that thight coupling is the right way to do model it. There are always exceptions that you need to be aware of. We found that decoupling reduces cognitive load greatly, and changing the relationships can be done a magnitude quicker because "listen to except if this and that happens" doesn't scale. There are just too many this and thats if your app is big. I know that the status quo method always looks easier than something new, because its unfamiliar. But restriction of communication flow is, in my opinion, the ONLY way to keep order in a big, complex app. Just consider this: I've tried both ways extensively, and I favor the Flux way. I might be an idiot, but there is a possibility that I'm not. This should encourage people to really try this once to avoid status quo bias.

coldtea 12y ago

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

rtpg 12y ago
From what I understand, this methodology increases code duplication, which leads to higher risks of bugs later on. I'm trying to understand whether this is truly the case, or if I'm missing something.