"Data down, actions up" implications


#1

Ember-cli-selectize is a project I maintain. @sandstrom came up with this PR: https://github.com/miguelcobain/ember-cli-selectize/pull/34

This made me to try to understand the implications of “Data down, actions up”. Basically, we won’t let the component change our data and instead use an action to allow us to change it ourselves (within the data owner’s scope).

So, how would a select box work with this paradigm?

{{select options=model on-change='updateSelection'}}

Everything looks ok so far. But then I started thinking about the implications this would have on my existing apps and on ember-cli-selectize users. There’s one in particular that has a very complex model. Let’s say I have 10 belongsTo relationships and each of them is set by the user using a select box.

  • Current approach - I just use 10 select components on my template. Each component updates my model.
  • “Data down, actions up” approach - Do I need to write 10 actions on my controller plus the 10 select components in my template?

What would be the correct way to do this with “Data down, actions up” paradigm?


#2

Looks like two way bindings

https://github.com/emberjs/rfcs/pull/15

It also eliminates the boilerplate associated with an event-based style when working with form controls. Instead of copying state out of a model, listening for callbacks, and updating the model, the input helper can be given an explicit mutable binding.

<input value={{mut firstName}}> 
<input value={{mut lastName}}> 

This is similar to the approach taken by React.Link, but we think that the use-case of form helpers is sufficiently common to make it ergonomic.


#3

So, I assume that “Data down, actions up” may not apply to every kind of component?

Also, this quote from React.Link is interesting:

In React, data flows one way: from owner to child. This is because data only flows one direction in the Von Neumann model of computing. You can think of it as “one-way data binding.”

However, there are lots of applications that require you to read some data and flow it back into your program. For example, when developing forms, you’ll often want to update some React state when you receive user input. Or perhaps you want to perform layout in JavaScript and react to changes in some DOM element size.

Thanks a lot for this info!


#4

Yah, my take is the form saving should be an action up whereas the actual form data, assuming selects / inputs etc, should probably just be a two way binding.

Cool looking lib by the way, I haven’t looked to deeply but if I need a more sophisticated drop down I’ll definitely be checking it out.


#5

I’m also curious about the implications of data down, actions up as it pertains to arrays and objects. In ember 2.0, a binding that looks like this will be “one-way” by default.

  value={{anArray}}

What exactly does this mean for an array? Will the array value itself be immutable in the sense that changes to it are not propagated upstream, or is it merely the array reference that is bound one-way?

What about an ember object?

  value={{anEmberObject}}

#6

This comment from @samselikoff made some things clearer to me.