idea - bind resolved data to controller

[GabiGrin]

I'm trying to make everything in my app a component(directive), and resolve as much as possible in the ui-router state, to ensure the component has all it needs when the state is loaded.
This is an example of what I'm referring to:

.state('my-state', {
  template: '<my-component data="ctrl.data" type="ctrl.type"></my-component>',
  resolve: {
    data: function($http) {
      return $http.get('/api/getMyData');
    },
    type: function(myService) {
      return myService.getType();
    }
  },
  controller: function(data, type) {
    this.data = data;
    this.type = type;
  },
  controllerAs: 'ctrl'
});

I find my self needing to repeat the this.data = data, this.type = type parts for almost all my states.

I think that supporting a bindToController option, that will insert resolved data in the controller will be helpful here, similar to a directive's definition object.

What do you guys think? if this sounds right I can even try to implement it, as it looks like a simple addition.

[eddiemonge]

I think it might be harder then you think it is. Have you looked to see if the feature-1.0 branch does this yet? If not, you can try taking a stab at it to see if its possible.

[nateabele]

If you're writing ES6, you can just do angular.extend(this, { data, type }).

[GabiGrin]

I am, but I'm want to remove the need to even to that.
I might be missing something, but it makes sense to me while attempting to treat each state as a component that receives data solely via resolves when it comes to external state.

It'll probably look like that:

.state('my-state', {
  template: '<my-component data="ctrl.data" type="ctrl.type"></my-component>',
  resolve: {
    data: function($http) {
      return $http.get('/api/getMyData');
    },
    type: function(myService) {
      return myService.getType();
    }
  },
  controller: angular.noop,
  controllerAs: 'ctrl'
});

The angular.noop + controllerAs might be dropped if the resolve params are added to the created $scope.

I'll fork and try to do achieve it. Will update so you guys can decide wether it fits the main branch or not. Worst case I'll stick to the fork :)

[nateabele]

You could probably combine controllerProvider with some state introspection to do this automatically.

[christopherthielen]

Huh, I thought I commented already...

I think the idea behind this request is reasonable. I've considered something very similar myself. This is something we may want to consider post-1.0

[amcdnl]

I'd love to see this make it in too. I think a bindToController option would be great here. My controllers often directly take all those arguments and attach them right away to the controller.

[juristr]

👍

[christopherthielen]

In 1.0, resolves are now much lazier than they are in 0.2.15. For example, if a resolve is defined but never requested for injection, the resolve fn may never be called (we're calling this the "JIT" resolve policy). We'd have to decide on some rules for behavior.

In 1.0, we've got a few building blocks that could help implement this idea:
We have a Resolvable object, which has a .get() fn which returns the resolved data, or a Promise for the resolved data.
We have a ResolveContext object, which has a .getResolvables() fn, which returns a map of all the resolvables for that context.
We have a Path object for the path in the state tree that is being entered. Each node in the path corresponds to a nested state, and has its own ResolveContext.

I think we could expose the ResolveContext object as an injectable object for all the ui-router injection points (similar to $stateParams), then let the callers explicitly use the resolve data. I think I'd prefer this over another configuration option

Perhaps something like this:

.state({ 
  name: 'foo', 
  resolve: { 
    resolve1: ($http) => $http.get("/foo.json").then((resp) => resp.data) ,
    resolve2: ($http) => $http.get("/bar.json").then((resp) => resp.data)
  },
  resolvePolicy: { resolve2: "JIT" },
  controller: ($resolve$) => {
    let keys = Object.keys($resolve$); // [ "resolve1", "resolve2" ]
    let resolvedFoo = $resolve$.resolve1; // data is fully resolved
    let resolveBar = $resolve$.resolve2; // a JIT promise for the resolved data?
  }
})
.state({ 
  name: 'foo.bar', 
  resolve: { 
    resolve3: ($http) => $http.get("/baz.json").then((resp) => resp.data) ,
  },
  controller: ($resolve$, resolve2) => {
    let keys = Object.keys($resolve$); // [ "resolve1", "resolve2", "resolve3" ]
    let resolvedFoo = $resolve$.resolve1; // data is fully resolved
    let resolveBar = $resolve$.resolve2; // data is fully resolved because of injection 
    let resolveBaz = $resolve$.resolve3; // data is fully resolved
    angular.extend(this, $resolve$); // resolved data is on controller
  }
})

Another possible approach would be to resolve everything (even JIT resolves) if $resolve$ is injected anywhere.

[christopherthielen]

summon @nateabele @wesleycho @eddiemonge

[nateabele]

I think we could expose the ResolveContext object as an injectable object for all the ui-router injection points (similar to $stateParams), then let the callers explicitly use the resolve data. I think I'd prefer this over another configuration option

Concur 100%.

resolve: { 
    resolve1: ($http) => $http.get("/foo.json").then((resp) => resp.data) ,
    resolve2: ($http) => $http.get("/bar.json").then((resp) => resp.data)
},
resolvePolicy: { resolve2: "JIT" },

I think I'd prefer a structure that involved less repetition, but that's sort of a minor thing.

[wesleycho]

I feel like users should explicitly choose to bind data in the controller.

bindToController, if implemented, should probably match how bindToController works in the DDO as part of the Angular API itself, and not handle resolves that way.

[uetkaje]

+1

[wesleycho]

I would like to add that if one is using TypeScript, one can easily bind to the controller by declaring public or private in the constructor for the controller.

IMO this shouldn't be supported in the library itself. UI Router is already very config heavy, and adding more minor config bloats up the library with what is supported & can potentially hurt extendibility down the road.