从Angular2路由引起的先后端路由浅谈

笔者的学习进度比较慢，直到两年之前写的网站都仍是以服务端为主导的，即网站的全部视图都由服务器视图模板来渲染，笔者使用的是 DotNet MVC，开发套路就是在Controller里面写Action，在Views里写对应的Action.cshtml，使用ajax发起请求已是比较前端的事情了。这种时候因为DotNet MVC框架继承的微软风格的懒人模式，甚至不须要去知道其路由是如何实现的，给人一种感受是只要在浏览器里敲进去Controller名与Action名，就访问到视图了。

后来笔者开始使用ng1前端框架，起初的开发彻底放弃其路由功能，而使用服务端MVC路由来区分页面，在各自页面内写ng1代码。如今想来这样作实在是浪费了ng1的能力，由于.Net MVC的视图能力虽然说有布局页这些概念，但其仍然是多页面的应用，视图间的切换都会形成页面的刷新，这会致使每切换一个页面都会从新加载一次ng1近两万行的代码。根本缘由是没有利用这个强大的前端框架的精髓之一——前端路由。

抛开前端路由的底层，其所作的事情就是动态操做DOM来模拟页面的切换，带来的好处是巨大的，首先是不用再页面切换时重复加载大量的脚本依赖了，还有就是页面切换再也不是白屏读条，而是能够加上接近原生应用的切换效果。而使用了前端路由后要解决的最大问题，天然是如何与服务端路由分离，至少不形成冲突。

前端路由有两种形式，一种是Html5的pushState风格，一种是使用#符号实现与服务端路由的分隔，笔者在基于微信公众号开发的时候涉及到了使用前端路由的SPA与微信API交互的各类状况，发现这两种形式各有问题，只能说微信以及传统的web服务器(至少IIS这个毒瘤)对如今这些先后端分离的SPA应用还不怎么友好。

 

1、ng2项目的部署

因为ng2采用了各类web新特性，包括TypeScript语法特性以及基于SystemJS或者webpack的代码模块化，已是个完全的客户端web体系，能够说若想要使用ng2来开发项目的话，就摆脱不了先后端分离的架构了。而说到web的先后端分离，其前端(客户端)虽然说跟服务端(WebApi)分离了，但却也仍然须要一个服务器来支撑前端入口页面以及框架脚本的文件分发。这就涉及到如何部署ng2的网站了，笔者获得的总结是只要ng2使用webpack打包编译获得目标文件后，放到任何服务器上均可以——由于获得的全都是静态资源，须要的只是架设成一个静态网站就足够了。一种选择是直接使用node圈子提供的服务器，并使用nginx完成反向代理等工做，因为某些历史缘由笔者将ng2网站部署到了IIS服务器上，也是能够运行的。

 

可是在IIS上部署ng2项目会有一个最直接的问题，那就是先后端路由冲突了(使用html5 pushState风格的状况下)！解决的办法有两个：

1. 老老实实使用#风格来区分先后端路由。其实先后端分离后没有了后端路由，此时的网站地址永远是 domain/#/url 格式的。

2. 笔者在使用#方式时发现此方式下发起微信网页受权的话会发生很尴尬的问题。

　　配置给微信那边的回调地址应该是这样的格式：

domain/#/url?code=xxxxx&state=xxxxx

　　可是至少目前的微信受权接口，会自做聪明处理#符号，致使其会回调到这样的路径： 

domain/?code=xxxxx&state=xxxxx/#/url

也就是说微信这厮竟然认为#后边的参数再也不参与路由了，强行把回调参数提到#号以前，简直蛋疼。

因此使用pushState是不可避免了。(但其实在pushState风格下，微信的支付url配置又会有点问题，说多了都是泪)

 

网上大体有两种办法来防止被服务端路由影响：

1) 重写url(没去试过)

2) 笔者最后采用的办法是修改404的重定向到网站入口文件

　　虽然感受有一些暴力，可是仔细一想这也只是服务端的404页面，自己也没有任何意义了，真正的404页面也应该是在前端路由中导航才是，因此把全部的服务器端的404请求重定向了也没什么不妥的。

 

2、简单介绍ng2下的路由配置

本来写本文时只打算写点ng2路由是如何代码实现的，可是其实ng2的路由配置也就那么一点内容，感受更麻烦的反而是整个的前端路由这个概念，因此到后半段才来说讲ng2的路由配置。

路由的目标

首先要明确路由的目标，就是组件。

ng2的页面都是基于组件的，而路由要作的就是切换各个组件，其须要依赖的就是<router-outlet>标签，并在ng2模块的定义中声明便可。

好比通常咱们的根模块作的事情除了加载核心依赖以外就是要作好根路由的配置，决定页面首先要显示哪一个页面，以及哪几个url对应哪几个组件，当url匹配时就加载这些组件。而根组件中也是，除了其余全局标签以外，必不可少的就是一个<router-outlet>标签，全部的路由都是由这个路由插座展开的。

 

路由的跳转与参数

路由的跳转有两种方式，一是在界面中使用路由指令：

<a [routerLink]="['/url',参数]">Click Me</a>

二就是在脚本中手动跳转：

router.navigate(['/url', 参数])

而在新页面中获取路由参数也很简单，只要使用angular2的系统路由模块提供的ActivatedRoute服务便可。

 

懒加载路由

ng2的路由是支持懒加载的，确切的说懒加载的对象是ng2模块。

由于ng2应用规模变大之后会有多个模块，而这些模块不可能同时被使用，确定是当路由指向到模块包含的某个组件(页面)后才真正须要加载这个模块，这时就要用到路由的懒加载能力了。其实现方式很简单：

{ path: 'url', loadChildren: '目标模块的文件路径#目标模块名' }

这样在url匹配时，才会先找到此模块文件的位置，而后加载此模块，好处就是不须要再应用一开始就加载全部模块，能节省资源，ng2甚至有模块预加载的能力，即后台异步提早加载好指定的懒加载模块，这样在须要此模块时，模块其实已经加载完毕，速度更加提高了。

 

至此笔者使用的路由配置通常是这样的形式：

1. 在应用的根模块中配置根路由，根路由只配置子页面所属模块的懒加载配置，以及必要的入口页面对应组件的直接加载。

 1 const routes: Routes = [
 2     { path: 'directive', loadChildren: './directive/directive.module#DirectiveModule' },
 3     { path: '', redirectTo: '/', pathMatch: 'full'},
 4     { path: '**', redirectTo: '/', pathMatch: 'full' }
 5 ];
 6 
 7 @NgModule({
 8     imports: [RouterModule.forRoot(routes)],
 9     exports: [RouterModule],
10     declarations: [ ],
11     providers: [ ]
12 })
13 export class AppRoutingModule { }

2.具体的模块中配置子路由，在子路由中详细指定自路径对应的子组件

const routes: Routes = [
    {
        path: '', component: DirectiveComponent, children: [
            { path: 'home', component: DirectiveHomeComponent }
        ]
    },
    { path: '**', component: DirectiveHomeComponent }
];

@NgModule({
    imports: [RouterModule.forChild(routes)],
    exports: [RouterModule],
    providers: []
})

具体的路径匹配规则与路由模块的声明方式等这里就不提了，没有什么难度可言，关键在于其路由方式的理解。

 

路由动画的问题

笔者遇到的目前ng2的路由体系的一个很大的问题就是路由动画。

因为ng2的路由依赖于一个<router-outlet>标签，而实际的组件(页面)的切换过程都是：

初始化页面1 -> 定向到页面2 -> 销毁页面1 -> 初始化页面2

ng2的路由组件切换很是尽职的会先销毁前一个组件再建立后一个组件，这致使即便你给组件配置了很酷炫的切换动画，前一个被销毁的组件也会直接蒸发，然后一个组件会正常按动画来出现。看到的效果就是，每次路由切换，页面都会先变成一片空白，而后新页面姗姗来迟，滑动进来也好，淡出显示也好，都给人一种尴尬的感受。StackOverflow上有大牛给出了很厉害的解决方案，但给笔者的感受是，仅为了路由的切换这也太不优雅了，期待ng2官方在将来的更新中给出一套更优雅的路由切换动画方案。

 

总结：

如本文的篇幅同样，ng2的路由其实没多少东西，可是却问题重重，一般要解决的不是路由路配置，而是如何让这个还比较新的前端路由体系适应于当前已有的互联网服务的大环境。