Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add to Breaking Changes: stateConfig.views[0].resolve object is never used #3208

Closed
Maximaximum opened this issue Dec 17, 2016 · 4 comments
Closed

Comments

@Maximaximum
Copy link

While updating from ui-router v0.3.0 to v1.0.0-beta.3 I've experience the following issue.

With v0.3.0, I was using view resolves like this:
$stateProvider

     $stateProvider
        .state('_.shop.search.item', {
          url: '/item/{itemId:int}',
          views: {
            "itemView@_.shop": {
              templateUrl: 'templates/shop/shop-item/shop-item.html',
              controller: 'ShopItemController',
              resolve: {
                product: function (server, $stateParams) {
                  return server["Shop/GetProductDetails"]($stateParams.itemId).then(function (response) {
                    return response.data;
                  })
                },
                productImages: function (server, $stateParams) {
                  return server["Shop/GetProductImages"]($stateParams.itemId).then(function (response) {
                    return response.data;
                  });
                }
              },
            }
          }

The ShopItemController looks like this:

.controller('ShopItemController', function ($scope, product, productImages, $anchorScroll, server, $compile, $interpolate, toaster, $stateParams, $state) {
}

After the update, I was getting "Unknown provider: productProvider <- product <- ShopItemController".

I've fixed this by moving the resolve property from the view object to the state object:

      $stateProvider
        .state('_.shop.search.item', {
          url: '/item/{itemId:int}',
          resolve: {
            product: function (server, $stateParams) {
              return server["Shop/GetProductDetails"]($stateParams.itemId).then(function (response) {
                return response.data;
              })
            },
            productImages: function (server, $stateParams) {
              return server["Shop/GetProductImages"]($stateParams.itemId).then(function (response) {
                return response.data;
              });
            }
          },
          views: {
            "itemView@_.shop": {
              templateUrl: 'templates/shop/shop-item/shop-item.html',
              controller: 'ShopItemController'
            }
          }
        });

I've figured out how to fix this issue myself, but I guess it would be helpful for others if you could add this issue to the Breaking Changes section of the UI Router migration guide (https://ui-router.github.io/guide/ng1/migrate-to-1_0)

@diegodesouza
Copy link

I have the same issue, but haven't been able to get past it. I've created a plnkr if you'd like to play with it. Maybe it will shed some light on this matter. You can find the plnkr here. Thanks @Maximaximum

@diegodesouza
Copy link

Figured it out, I had to remove the controller instance in my home.template.html as I was already calling it in my routes.

@leosprikryl
Copy link

Is this intentional change? I hit the same problem and haven't found any information about it anywhere except of this issue. I would consider it a bug.

@christopherthielen
Copy link
Contributor

christopherthielen commented Jan 10, 2017

resolve inside views was never explicitly documented as part of the API. It used to invoke them, but "we've since fixed the glitch". 😉

The reason we don't allow resolve on views is that it implies extra scoping. However, the resolves on views were scoped to the state, not the view. As an example, this would be completely undefined behavior:

views: {
  foo: { 
    resolve: { data: () => 'foodata' }
  }, bar:  {
    resolve: { data: () => 'bardata' }
  }
}

I'll add a small blurb in the migration guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants