How to communicate to child components

As in, instead of communicating back up via actions you just pass down the data and change it in the child component which will automatically update the parent without sending actions up. This surely means that you can tell at the top whether a field has changed in real time. Sorry I am replying via mobile doing code will be awkward.

Data Down, Actions Up means that you pass data down into your components, but you never mutate (change) this data in the children. To make a data change, you pass actions up back to the parent, which changes its “own” data which triggers a state change in the child component(s) via data bindings (as data belonging to the parent is passed in to the components).

For an example, see Mistake #8 in my post, The 8 Most Common Mistakes that Ember.js Developers Make.

Ok Balint, this is concerned with the reusability of the component but I’m guessing that as ember goes down the path of rendering components directly from routes this will be less of a concern.

What If I wanted a component that is designed to mutate some data sent to it or designed to “manage” a dataset in the parent? It just sounds like view/model to me. Sometimes you just need the job done.

Also are you saying that parent components have to know the implementation details of everything under it. I think as long as you define clearly what that component is designed to do (and not get confused with calling it “rating” instead of “points score”). I can’t see a problem. There’s nothing wrong with saying, ok this component will take a list of objects and it’s visual interface will manage the data within it. If I insert another component, insert a different array into it… I have the same thing somewhere else, separated. I really can’t see the problem.

Just my opinion. Saying that you could go around bubbling up actions all over the place which will accomplish the same thing. So stick with that if it makes you feel better,

You can totally write components that mutate data passed into them.

Ember was there and the reason it shifted toward a uni-directional data flow (called DDAU in Emberland) is because it leads to scenarios where it’s hard to see what’s going on and what data changes trigger what state changes. I also experience the pain first-hand and my developer experience has been remarkably improved by DDAU.

Furthermore, components have two main goals, isolation and reusability and I’d argue that the former is more important than the latter. If a component directly changes data passed in, I think it violates the isolation part which is not just a fluffy thing but can actually vastly increase debugging time (see first paragraph).

The only thing on the plus side is that it’s easier to directly manipulate data than to trigger actions and handle them outside. That simplicity, however, comes at a great cost, I think. Your mileage may differ, though.

Thanks for your reply, I will bear what you say in mind. I find talking up to parent components isn’t as simple as it should be and find it a bit of a faff…

e.g If I have a click Action on a child component, it seems like Ember doesn’t let you respond to that click in the parent without writing a function to handle it in the child component then having that function delegate to the parent with sendAction() or this.get(‘mfunc’)(). Why is this do you think? I can’t understand why they don’t simplify the code to do this. I should be able to do something like {{my-helper clickButton=(action “parentClickButton”)}} and not have to handle that click in the child but have it bubble straight up to the parent but it seems like it doesn’t work that way I get errors saying “blah blah has no handling of so and so action”.

As much as I like Ember.js I think sometimes it over emphasizes theory over practicality. It is Ember that makes it so that you need to create a component if you want your content to have a class, and you want a class simply to catch events on an item basis say (items in a list perhaps), yet then you have to deal with the insistent separation and reusability ideas… yet that isn’t always the reason you have the component. Sometimes you have a component simply because Ember forces it and the more talking up and down you have to do the more of a pain in the ass it seems to do.