Angular ui-router 中的 Promise 依赖解析顺序
我已经设置了一个顶级控制器,它仅在成功解决承诺(由 Config
工厂返回)时实例化.该承诺基本上是下载 Web 应用配置,带有 RESTful 端点等.
I have set up a top-level controller that is instantiated only when a promise (returned by a Config
factory) is successfully resolved. That promise basically downloads the Web app configuration, with RESTful endpoints and so on.
$stateProvider
.state('app', {
url: '/',
templateUrl: 'views/_index.html',
controller: 'MainCtrl',
resolve: {
config: 'Config'
}
});
此设置允许我在任何较低的控制器有机会使用它之前断言配置已正确加载.
This setup allows me to kind-of assert that the configuration is properly loaded before any lower controller gets a chance to use it.
现在我需要在更深的嵌套控制器中注入另一个 factory
,它使用 Config
并且仅在它被解析时才起作用(看它像 $resource
包装器,需要一些 Web 服务 URL).如果我这样做:
Now I need to inject, in a deeper nested controller, another factory
that uses Config
and only works when it is resolved (look at it like a $resource
wrapper that needs some Web service URLs). If I do:
$stateProvider
.state('app.bottom.page', {
url: '/bottom/page',
templateUrl: 'views/_a_view.html',
controller: 'BottomLevelCtrl',
resolve: {
TheResource: 'MyConfigDependingResource'
}
});
看起来 resolve
评估顺序不是从上到下,而是从下到上,因此:
it looks like the resolve
evaluation order does not follow the controller hierarchy from top to bottom, but from bottom to top, therefore:
app.bottom.page
已输入ui-router
尝试解析MyConfigDependingResource
,但是注入失败,因为Config
从未被初始化过ui-router
解析因错误而停止(甚至没有抛出Error
,但这是另一个问题),并且Config
是从未被顶级控制器初始化
app.bottom.page
is enteredui-router
attempts to resolveMyConfigDependingResource
, but the injection fails, becauseConfig
has never been initialized- The
ui-router
resolution stops because of an error (without even throwingError
s, but that's another issue), andConfig
is never initialized by the top level controller
为什么 ui-router
以相反的顺序解析依赖关系?如何轻松解决我的 TheResource
对象 在 顶级 MainCtrl
已解决 Config
(不依赖 $inject
,当然)?
Why is ui-router
resolving dependencies in a reverse order? How can I easily resolve my TheResource
object after the top level MainCtrl
has resolved Config
(without relying on $inject
, of course)?
更新:从 这个 plnkr 的日志你可以看到只有在嵌套控制器开始自己的解析过程后才会尝试顶级 resolve
.
UPDATE: from this plnkr's log you can see that the top level resolve
is attempted only after the nested controller has started its own resolving process.
推荐答案
类似于@Kasper Lewau 的回答,可以指定对单个状态的解析的依赖.如果您的一个解析依赖于同一解析块中的一个或多个解析属性.在我的情况下 checkS
依赖于另外两个解决方案
Similarly to @Kasper Lewau's answer, one may specify a dependency on resolves withing a single state. If one of your resolves depends on one or more resolve properties from the same resolve block. In my case checkS
relies on two other resolves
.state('stateofstate', {
url: "/anrapasd",
templateUrl: "views/anrapasd.html",
controller: 'SteofsteCtrl',
resolve: {
currU: function(gamMag) {
return gamMag.checkWifi("jabadabadu")
},
userC: function(gamUser, $stateParams) {
return gamUser.getBipi("oink")
},
checkS: ['currU', 'userC', 'gamMag', function(currU, userC, gamMag) {
return gamMag.check(currU, userC);
}]
}
})
<小时>
**PS:**检查以下文档 了解更多关于 resolve
的内部工作原理.
**PS: **Check the "Resolves" section of the following document for more details about the inner-workings of resolve
.
相关文章