将angular.js项目整合到.net mvc中的方法详解
前言
之前的开发选择的是完全舍弃服务端,仅保留最简单web服务器提供angular经打包的静态资源,此外所有的业务与数据请求都访问一个分离的WebApi来实现。不过最近碰到一个需求,有必要使用多个客户端,而各客户端本身都是webpack打包出来的js而已,没必要每个客户端都自己建一个站点,这就有必要搭建一个服务端,根据参数动态渲染不同客户端的脚本来服务多个客户端了。主要需要解决两个问题,一是防止前后端路由冲突各自有效工作,二是如何实现一套比较合理的部署方案。笼统一点看待这个问题,无非就是要实现如题目所描述的,如何将专注前端的强大框架(angular)整合到一个健壮的现有服务端(.Net)项目中去。
Webpack配置
第一步必然是要先得到前端项目的打包资源,由强大的webpack来完成,目标是将angular的所有依赖以及应用主代码分别打包到polyfill.js、vendor.js、main.js三个脚本中,以及异步懒加载的模块各自打包成一个chunk.js。webpack博大精深,刚接触会摸不着头脑,好在其终究是用来给我们带来方便的一个工具而已,使用起来是很有条理的。其主要的介绍可以移步webpack的官方文档【 】,认真吸收完远远足够写出angular-webpack-starter【 】这样完善的启动项目来了。
简单来说webpack配置有四部曲:
一、 定义入口文件 包含angular的依赖,angular框架代码以及项目的启动代码即可,比如angular-webpack-starter中的配置:
entry: { 'polyfills': './src/polyfills.browser.ts', // 依赖项 'main': AOT ? './src/main.browser.aot.ts' : './src/main.browser.ts' // 主程序 },
二、 定义打包规则
打包规则有好一些需要配置的,包括了各种文件类型的打包,angular模块的打包等,配置方式见官方文档或直接参照现成的启动项目,直接看难免懵逼,但不要怕,规则其实就那么点,眼熟就成功了大半。
三、配置插件
webpack有非常多的插件,用来强化打包能力以及规则的扩展,可以看看启动项目中用到了哪些,这些插件在官方文档里都能找到介绍。
四、 定义输出规则
输出要分生产环境和开发环境,本文只讲生产环境。先明确webpack打包好的项目是要交给服务端使用的,给出的输出要有几个需求:
1) 转义兼容浏览器和ES5并压缩。
2)输出文件名附带哈希值,代码发生更改重新打包时要有不同的哈希值,保证此时替换的资源不会被浏览器缓存而得不到第一时间更新。
3)列出资源打包清单,因为附带了哈希值导致每次文件名都是很长一串奇怪字符,使用合适的webpack配置附带一个manifest清单列出都输出了哪几个文件,进一步在使用时动态读取其中的清单来操作输出的文件。
作为静态脚本添加到服务端
顺利的话开发完成的项目能得到类似下图的打包资源:
其中webpack-assets.json中列出了三个依赖文件:
以0、1、2、3打头的四个chunk文件是由angular动态引入的懒加载模块,不需要手动引入自然也不需要列出来,只需要保证angular能访问到它们即可。
把这些东西全都放到一个.Net MVC项目中去:
然后在View视图中引入三个脚本并配置base url:
现在运行MVC项目,定位到这个视图可以顺利渲染出angular项目来。问题在于手动输入前端路由的url时,此url会被MVC路由视为404错误(因为MVC路由中确实未定义这一规则,真正使用此规则的angular客户端还没有机会解析这个url就被一个错误页取代了)。
MVC路由配置
angular官方给出的指南是给服务端配置404的重定向,将所有的404错误都重定向到index.html,这样前端就能顺利开始解析输入的url了。在MVC中做法也类似,只要在MVC的路由规则中,将必要路由(比如还定义了其他的Api或者错误页)之外的所有请求都指向指定的Action,比如笔者的这条规则,将所有其他请求都指向AppController下的Index:
这样除了/page/打头的url外所有不满足默认路由的请求都会定位到/App/Index。
使用MVC的View取代index.html
下一步是要在这个/App/Index中读取前端打包生成的webpack-assets.json清单,将需要的文件渲染到视图中,笔者项目添加了一个academyid来区分多客户端,每个客户端都有以自己id命名的一个资源目录,实现如下图所示:
笔者的C#比较抠脚,所以定义了一个class来解析json文件,然后才把解析到的文件名放到ViewData中以供前端使用。现在视图中就可以使用Razer语法来渲染脚本依赖:
这样子配置下来,服务端其实不需要再关心客户端的更改,只关心从webpack-assets.json中解析要加载的依赖,并渲染这些依赖即可,每当客户端代码更改重新打包时,webpack-assets.json清单也会更新,毫不影响服务端。
总结
水平有限导致本文存在许多的不足之处,包括一直未涉及的SEO方案以及其他的隐藏问题,笔者还有很多需要学习完善的地方。
好了,以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流,谢谢大家对狼蚁SEO的支持。