Could we get a component binding option of '>' for one way binding up to a parent?

[sonicblis]

I'm submitting a ...

• bug report
• feature request
• other (Please do not submit support requests here (see above))

Current behavior:

Right now, the only option for passing values out of a child component to a parent is the '=' two way binding which everyone agrees should be avoided. Parent values will overwrite child values in this case.

Expected / new behavior:

With a '>' binding, an author could explicitly communicate that the child is going to be providing this value and whenever it changes, it should be set to this parent property. You also avoid the performance hit of the two way binding.

Minimal reproduction of the problem with instructions:

This fiddle gives an idea of what I'm suggesting.

Angular version: 1.6.3

Browser: all

[Narretz]

We recommend that you use & ( provides a way to execute an expression in the context of the parent scope), which is more verbose but gives you more flexibility. I don't think a new > binding is necessary. It also fits better with the idea that children raise events to which the parent reacts, whereas the parent pushes bindings down to the child.

[sonicblis]

What I implemented in the fiddle is somewhat the opposite of '&'. Instead of the parent providing an expression to the child, I want the child to be able to provide a callback pointer to the parent without using two way binding. A key difference is that then the parent can trigger a child defined function without having to know any of the internals of the child, and we can get further away from having to use $watch.

I realize there are currently ways to accomplish what is in my fiddle (since it's functional), but I believe there's room for clearer intent when creating a component binding structure that can communicate that a value is intended to be provided to the parent context from the child which currently doesn't exist.

[sonicblis]

As another example, writing a filter/data display set of components could be as easy as something like this without the need for $scope.$watch in the child component or two-way binding.

angular.module('newBinding', [])
  .component('filterableData', {
    controller: function() {},
    template: `<div>
                 <select ng-change="$ctrl.triggerQuery(selectedSource)" 
                         ng-options="sourceKey in $ctrl.sourceKeys" 
                         ng-model="selectedSource"></select>
    	         <data refreshItems="$ctrl.triggerQuery"></data>
               </div>`
  })
  .component('data', {
    bindings: {
      refreshItems: '>',
      items: '<',
    },
    controller: function(resource) {
      this.$onInit = function() {
        this.refreshItems = (which) => this.items = resource.query(which);
      };
    },
    template: `<div ng-repeat="item in $ctrl.items">{{item.displayName}}</div>`
  });

[gcaaaaaa]

yes

[frederikprijck]

So if I'm looking at this correctly, you want your child components to expose an API in such a way that a parent can call it and execute the component's internal code to, in this case, update its content, right?

I don't really see the benefit over using items as the only binding (input binding) and update the array from outside the component when necessary. This API has no need to be included in the same component that's used to visualize them.

When using a unidirectional data flow together with some kind of smart and dumb components I don't think this even has any use-case (or at least not one that necessarily needs this new binding). But feel free to correct me if I'm wrong here!

From a reusability point of view, you'll want a component to represent the items (only have an items binding) which would be known as a "dumb" component (one that is only responsible for visualizing state and has no knowledge of where the data is coming from). You'll also want a parent component whose responsibility is to provide the data to its child (this one is smart, it knows where to retrieve the data from), so this also means being responsible for refreshing.

[Narretz]

@sonicblis I see what you mean now, but I tend to agree with @frederikprijck that this is not something we actually want people to do. In your filter example, I'm not sure why the filter component should be responsible for resetting te data, if you can just pass in an array from the parent.

[sonicblis]

@frederikprijck, thanks for thinking this through. I should have left out the items: '<' binding to make the example more clear that the component isn't meant to be a dumb component.

With your solution (moving data access higher), I can't ever have a child component that's also a smart component (that does display and has parent triggerable functionality) without continuing to $scope.$watch (or $broadcast =\).

I find myself solving this problem with a $scope.$watch on some arbitrary binding and running logic in a child component in the $watch function. If, in general, I had two one-way bindings (one in '<', and one out '>'), I could be done with $scope.$watch in child components I think.

As one more simple example, if I have a graph component that displays a common roll up of data, and I want to use it multiple times, I could avoid every parent being responsible for data access, but instead encapsulate data access in the graph component itself with the ability to trigger a refresh from any parent if necessary.

Thanks again for looking at this. Happy to contribute a PR if there's any hope.

cc: @Narretz

[frederikprijck]

With your solution (moving data access higher), I can't ever have a child component that's also a smart component (that does display and has parent triggerable functionality) without continuing to $scope.$watch (or $broadcast =).

That's incorrect, I don't see why that would be impossible. You could perfectly move the data-access in the dumb component I mentioned, making it both responsible for data-access and visualisation (not a bad thing, just not that dumb/reusable). You can, if you want, later abstract the data visualisation part into a dumb component (but the data-access stays out of the dumb component).

But that's about the new feature you're proposing, I personally don't see any use-case yet.
About what you're trying to do, what about using something like:

angular.module('newBinding', [])
  .component('filterableData', {
    controller: function() {},
    template: `<div>
                 <select
                         ng-options="sourceKey in $ctrl.sourceKeys" 
                         ng-model="selectedSource"></select>
    	         <data which="selectedSource"></data>
               </div>`
  })
  .component('data', {
    bindings: {
      which: '<'
    },
    controller: function(resource) {
       this.$onChanges = function(changes) {
         if(changes.which) {
            this.items = resource.query(this.which);
         }
      }
    },
    template: `<div ng-repeat="item in $ctrl.items">{{item.displayName}}</div>`
  });

Here's a modified plunkr to demonstrate it: https://plnkr.co/edit/qb1NCLSeZgGPuRVDqnpg?p=preview

[langdonx]

@frederikprijck $onChange doesn't do deep watches, so we have $watch for that, but $watch won't trigger when nothing has changed (a re-query). This is a common problem I run into developing components and why I thumbs'd up 4 posts ago.

Your example works and all, but outside of Angular demos, I feel like allowing binding like that to flow through as DOM changes is an anti-pattern.

https://plnkr.co/edit/PzNasQKuWVe0G4K4RfZw?p=preview

Here I've taken your example, added an extra field, and put a search button on it. I've got skip/take already set on my search object, so when the user clicks the search button, I'm only changing the properties that need changing. This is good because we haven't fired any unnecessary watchers as the user builds up their search criteria. Unfortunately if you try to search for the same thing twice, the search object hasn't changed, so nothing happens. Imagine searching the same value on Google but the second time nothing happens. 😢

So you're forced to re-create the search object or set some other property on it to like changed = Date.now() so that the $watch will fire, which isn't very intuitive.

[sonicblis]

@langdonx, not to mention the search that will take place with default params since the $watch will fire once initially. Imagine if google did a search the first time you opened it but before you provided a search string.

@frederikprijck, $onChange and $watch is what I'd like to avoid in my child when not necessary. My main point is still that there is a difference between a child component responding to a change in the parent and a parent being able to explicitly read child data without unnecessary two-way binding (up to this point, so that the child can provide a function to the parent to call explicitly, but the intent is for a more global capability of child to parent one way binding).

Here's another example of where it would be nice to have a '>' binding as a form is providing edits on a provided object, but the parent is triggering the action to take on the edits:

https://jsfiddle.net/sonicblis/p630v7uf/3/

And then here, where the child is running some complex logic before returning a complete and valid edited entity.

https://jsfiddle.net/sonicblis/p630v7uf/4/

All doable with the current bindings, but would be better with one-way binding from child to parent. It seems like such a win to be able to define "out params" in the child's interface that you can then access from the parent.