Rationale for Data Down, Actions Up?

@shull wrote:

Hello Ember community!

I have a question about the rationale behind “Data down, actions up”. All the posts I’ve come across promise vaguely that reliance on two-way bindings “creates difficult-to-debug problems in large applications,” however I’ve never seen a concrete example.

Indeed, the post that comes back first in Google (and is often referenced in other posts) links to an Ember Twiddle that simply could use computed properly (ie, computed('expenses.@each.amount')) instead of passing actions around. Here’s a simpler version of the twiddle without DDAU. Check it out and compare it to the original and explain to me the value of the additional code.

From my point of view, less code is—with a few notable exceptions—invariably easier to read, understand, debug and change. DDAU necessarily results in more code. Furthermore, a large app will have a proliferation of highly nested components, sometimes even recursive components. When you pass actions down, it’s common to rename those actions (sometimes out of necessity to avoid clobbering local vars). I even see actions being renamed in example posts (the one above does it). This can make it extremely confusing to trace back what methods are actually being called, not to mention extremely tedious to pass these actions down to the umpteenth-nested component.

This proliferation of highly nested components and necessary action-passing seems like it would also create a difficult situation in large, complex apps.

But I can’t be sure! I haven’t seen a satisfying explanation or example that really feels simpler or easier to understand or change with DDAU. I really want that “aha!” moment where it becomes obvious that DDAU is better.

Have you seen any posts that do a good job explaining the rationale behind DDAU? Or do you have such an explanation you could share with me?

Thanks!

Posts: 3

Participants: 3

Read full topic