问题描述
我相信我对这些术语嵌套参数化路由"的理解是正确的，但还没有找到我要找的东西.
I believe I'm on the right track with these terms, "nested parameterized routes", but haven't found what I'm looking for yet.
我的目标是为我的 API 创建直观的路由，类似于以下示例:
My objective is to create intuitive routes for my API, something like the following example:
/api/v1/project/list
/api/v1/project/1/item/list
/api/v1/project/1/item/1/edit
/api/v1/project/2/item/3/delete
如何设置项目状态相对简单明了，但不是每个项目内的项目状态.
It's relatively easy and clear how to setup project states, but not the item states within each project.
{
state: 'project'
config: {
url:'/project'
}
},
{
state: 'project.list'
config: {
url: '/list'
}
},
{
state: 'project.detail'
config: {
url: '/:project_id'
}
}
我不清楚从那里去哪里，以便项目是相对的或嵌套在项目中.
It's not clear to me where to go from there so that items are relative or nested within projects.
推荐答案
我假设您有一个想要公开的 REST api(基于包含 /api/v1 的示例)/作为 UI 并行.我假设您希望允许用户向下钻取一些分层数据模型.
I'll assume you have a REST api (based on your example containing /api/v1) which you want to expose/parallel as a UI. I'll assume you want to allow the user to drill down some hierarchical data model.
对于这种向下钻取列表/详细信息模式，您可以通过多种方式组织您的状态.没有一个是正确"的方式，但有些可能比其他方式更好.我将重点介绍我使用过的两种方法:
There are many ways you could organize your states, for this drill-down list/details pattern. None is the "correct" way, but some are probably better than others. I will highlight two approaches that I've used:
一种方法是将项目列表"状态和项目详细信息"状态保持为兄弟状态.这就是您对 project.list 和 project.details 所做的.这种方法可以在 UI-Router Extras Demos 源代码中看到.
One approach is to keep the "item list" states and "item details" states as siblings. This is what you did with project.list and project.details. This approach can be seen in the UI-Router Extras Demos source code.
采用这种方法时
- 在向下钻取时，您必须注意将用户从列表状态移动到详细信息状态.
- 这种方法的好处是易于理解的 UI 视图嵌套.在向下钻取时，详细视图的 ui-view 替换列表视图的 ui-view，因为您正在导航到同级状态.
- 您选择实体的详细信息是否还检索子实体列表(项目的详细信息是否也显示该产品的项目列表?)
- you must take care to move the user from the list state to the detail state when drilling down.
- This approach has the benefit of easy-to-understand nesting of UI-Views. The ui-view for the detail view replaces the ui-view for the list view, when drilling down, because you are navigating to a sibling state.
- Your choice whether or not the detail for an entity also retrieves the list of sub-entities (does the detail for a project also show the items list for that product?)
状态:
projectlist//模板插入父 ui-viewprojectdetail//模板插入父ui-view，替换projectlistprojectdetail.itemslist//模板插入父 ui-view (@projectdetail)projectdetail.itemdetail//模板插入父ui-view(@projectdetail)，替换itemslist
projectlist// template plugs into parent ui-viewprojectdetail// template plugs into parent ui-view, replacingprojectlistprojectdetail.itemslist// template plugs into parent ui-view (@projectdetail)projectdetail.itemdetail// template plugs into parent ui-view (@projectdetail), replacingitemslist
另一种方法是使详细状态成为列表状态的子级.它的组织方式类似于您的 REST 路由.
Another approach is to make the detail state a child of the list state. This is organized similar to your REST routes.
采用这种方法时
- 状态层次结构与暴露的 REST 路由非常相似
- 向下钻取简单直观
- 您必须管理列表/详细信息的可视化显示.
- 当从列表状态向下钻取到详细信息子状态时，您可能想要隐藏列表.
- 我们使用命名视图和绝对命名来替换父列表状态的模板与详细信息状态的模板.这称为视图定位".
- States hierarchy closely resembles the REST routes being exposed
- Drilling down is simple and intuitive
- You must manage the visual display of list/detail.
- When drilling down from list state to the details substate, you probably want to hide the list.
- We use named views, and absolute naming in order to replace the parent list state's template with the template for the the detail state. This is called "view targetting".
状态:
top//理论父状态top.projects//列出项目.插入父 ui-view (@top)top.projects.project//项目详情.它的命名视图针对祖父 ui-view (@top)，替换了top.projects列表中的模板状态.top.projects.project.items//列出项目.插入父 ui-view (@top.projects.project)top.projects.project.items.item//项目的详细信息.它的命名视图针对祖父 ui-view (@top.projects.project)，替换了top.projects 中的模板.project.items列表状态.
top// theoretical parent statetop.projects// lists projects. Plugs into parent ui-view (@top)top.projects.project// details for project. Its named view targets the grandparent ui-view (@top), replacing the template fromtop.projectslist state.top.projects.project.items// lists items. Plugs into parent ui-view (@top.projects.project)top.projects.project.items.item// details for item. Its named view targets the grandparent ui-view (@top.projects.project), replacing the template fromtop.projects.project.itemslist state.
以下是使用命名视图定位来完成第二种方法的示例:
Here's an example of using named view targeting to accomplish the second approach:
$stateProvider.state('top', { url: '/', template: '<ui-view/>', }); $stateProvider.state('top.projects', { url: '/projects', resolve: { projects: function(ProjectsRoute) { return ProjectsRoute.getProjects(); } }, controller: function($scope, projects) { $scope.projects = projects; }, template: '<li ng-repeat="project in projects"> <ui-view/>' }); $stateProvider.state('top.projects.project', { url: '/:projectid', resolve: { project: function(ProjectsRoute, $stateParams) { return ProjectsRoute.getProject($stateParams.projectid); } } views: { '@top': { controller: function($scope, project) { $scope.project = project; }, template: 'Project details: {{ project.name }} <a ui-sref=".items">view items</a> <ui-view/>' } }); $stateProvider.state('top.projects.project.items', { url: '/projects', resolve: { items: function(ItemsRoute, project) { return ItemsRoute.getItemsForProject(project.id); } }, controller: function($scope, items) { $scope.items = items; }, template: '<li ng-repeat="item in items"> <ui-view/>' }); $stateProvider.state('top.projects.project.items.item', { url: '/:itemid', resolve: { item: (ItemsRoute, $stateParams) { return ItemsRoute.getItem($stateParams.itemid); } }, views: { '@top.projects.project': { controller: function($scope, item) { $scope.item = item; }, template: 'Item details: {{ item.name }}' } });这篇关于在 AngularJS 中使用 ui-router 嵌套参数化路由的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！