$routeProvider
的resolve
属性允许在相应视图呈现之前执行一些任务。
如果我想要在执行这些任务时显示一个旋转图标以增强用户体验怎么办?
确实,否则用户会感觉应用程序已被阻塞,因为一些毫秒内没有显示任何视图元素,例如大于600毫秒。
当然,有一种方法是定义一个全局的div
元素在当前视图之外,以便在使用$scope.$rootChangeStart
函数显示旋转图标。
但我不想仅仅通过将中间的旋转图标隐藏来隐藏整个页面。
我希望我的Web应用程序的某些页面在加载方式方面有所不同。
我看到了这篇有趣的帖子,其中包含了我上述描述的确切问题:
这种方法会导致可怕的UI体验。用户点击一个按钮以刷新列表或其他内容,因为库无法仅针对受状态更改影响的视图显示旋转图标,所以整个屏幕都被覆盖了一般的旋转图标。拒绝。
无论如何,在我提交此问题之后,我意识到"resolve"特性是一种反模式。它等待所有承诺都解决,然后动画化状态更改。这是完全错误的-您希望状态之间的转换动画与数据加载并行运行,以便后者可以被前者覆盖。
例如,假设您有一个项目列表,并且单击其中一个项目将隐藏该列表并在不同的视图中显示该项目的详细信息。如果我们为项目细节进行异步加载,平均需要400毫秒,那么我们可以通过在列表视图上设置300毫秒的"离开"动画和在项目详细信息视图上设置300毫秒的"进入"动画来几乎完全覆盖加载。这样我们就提供了更流畅的感觉。
在大多数情况下,通过将异步加载逻辑放在控制器中来避免使用resolve
可以避免在UI上显示旋转图标。 然而,这需要我们同时启动异步加载和状态更改动画。如果使用 "resolve",则整个异步动画会在动画开始之前发生。用户点击后会看到旋转图标,然后才会看到过渡动画。整个状态更改需要花费约1000毫秒,太慢了。
如果"Resolve"有不等待Promise的选项,它可能是缓存不同视图之间依赖关系的有用方法,但当前行为总是在状态更改开始之前解析它们,几乎没用,在我看来应该避免任何涉及异步加载的依赖关系。 所以,你是否真的应该停止使用resolve
来加载一些数据,而是直接在相应的控制器中加载它们?这样可以使得任务执行的时候及时更新视图,并且可以在视图中指定位置进行更新,而不是全局更新。