标签：push 导航 control 客户端 切换 cti main title 简单介绍
笔者的学习进度比较慢，直到两年以前写的网站都还是以服务端为主导的，即网站的所有视图都由服务器视图模板来渲染，笔者使用的是 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应用还不怎么友好。
一、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请求重定向了也没什么不妥的。
二、简单介绍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的路由其实没多少东西，但是却问题重重，通常要解决的不是路由路配置，而是如何让这个还比较新的前端路由体系适应于当前已有的互联网服务的大环境。
标签：push 导航 control 客户端 切换 cti main title 简单介绍
原文地址：http://www.cnblogs.com/yulei126/p/6804007.html
