2016-08-13 98 views
0

当开发具有角度js的Web应用程序时,开发人员花费的部分时间是实现路由的时间。使用UI路由器在角度js应用程序中路由

当在应用程序中使用的用户界面的路由器,有两个“阶段”考虑与问候路由:

  1. 用户浏览里面的应用程序:当点击上一些键进行,用户被转移到另一个州使用$ state.go(“somestate”)。参数可以发送等,并相应地更改网址。

  2. 用户通过网址直接导航。

可以说,应用程序有这样的路线: /mythings/{thingid}/mysubthings/{mysubthingid}

如果用户通过将其粘贴到浏览器窗口导航到该网址直接,应用程序需要处理它。我的问题是最好的做法是什么?

我在想的是:如果查看上面的url示例,当用户在浏览器中输入该URL时需要完成的操作: 从url获得{thingid}(来自$ stateParams),然后从{state}获得{mysubthingid} $ stateParams(可能通过在定义状态时使用resolve(ui-router功能)),然后将已解析的内容注入到控制器,然后对api进行查询并获取关于“subthing”的数据并使用该数据在ui中呈现视图。所以这应该适用于“导航类型”:当用户点击并转移到状态时,或者当用户直接在浏览器中输入url时。这是正确的道路吗?

我想,当你点击应用程序中的任何网址时,你应该能够将该网址粘贴到浏览器中,并在不重定向到其他任何地方的情况下看到相同的结果。如果应用程序无法以这种方式处理每个网址,那么应用程序的架构是否需要重新考虑?

谢谢

回答

1

在UI-Router中,路由的主要组件是状态。 URL本质上只是一个指向应用程序特定状态的地址。我认为将两种导航方式分开是不一定有效的;他们只是同一枚硬币的两面。应该没有不是由状态处理的URL。任何与状态不匹配的网址都应该在$stateProviderotherwise定义中捕获,并可能重定向到您的主页或404页面。

在您的示例中,thing/:thingId/subthing/:subthingId url应该映射到预定义的状态,就像任何其他状态一样。假设这个状态是main.subthing。无论您是通过拨打$state.go('main.subthing', {thing: 123, subthing: 456})ui-sref='main.subthing({thing: 123, subthing: 456})'还是将myapp.com/thing/123/subthing/456粘贴到浏览器中,加载数据,启动控制器和呈现UI的过程都应该完全相同。通过调用完全相同的逻辑(最有可能加载事件123和事务456解析并将其注入到控制器中),它们都将以完全相同的数据完全结束。

你说得对,如果一个url不能被应用程序处理,这是一个迹象表明某些事情是错误的。就像我说的那样,在设置状态时应该通过定义otherwise来处理坏的URL。但是,如果您的状态被正确定义,则将URL粘贴到浏览器中不应该需要任何额外的工作。默认情况下,URL处理会被烧入UI-Router。

0

我部分同意你的看法。我不同意的观点是,URL是由不应该访问它的用户获得的。通常一些网站实施授权代码来检查当前正在访问该页面的用户是否有权这样做。

此外,我认为路线可能有点不同。喜欢的东西:

{thingid}/{} mysubthingid

我认为这是一个更清洁的URL和参数可能会以同样的方式作为一个在你的例子来处理。

我建议这样做是为了让未经授权的用户有点困难。

无论如何,它绝对取决于您正在实施的应用程序的种类。如果应用程序的要求是能够通过在浏览器中粘贴URL访问该页面,那么我认为你的方法要好得多。