大家好。本文我们来分析一下AngularJS项目到Angular项目的转化问题。我们会着重探讨三种方案。

【背景】

AngularJS是指Angular 1.x的所有版本的共有Logo。从比较早的0.0.1到比较新的1.7.6等等都隶属于AngularJS体系。

Angular 2之后的版本，我们统一称之为Angular。Angular的版本体系里面有2, 没有3， 有4，5，6，7，8，9等等。目前最新的是9。从Angular2到9的发展过程来看，这套技术体系是非常稳定的。组件这一级的代码基本是通用的。顶多有些package需要替换一下，比如http到httpClient。这些都是比较小的改动。除此之外，没有太多的变化。

AngularJS到Angular的技术跨度就比较大一些。相信用过这两个架构的朋友都会感概Angular真的简单很多。

这里说一个现实生活中的真实情况， 有家公司在招聘程序员的时候，说他们有很多的AngularJS的项目，大约是7个的样子，需要找程序员来维护。我就问他们，为什么不想着把AngularJS的项目转化为Angular呢？他们的回答是现有的AngularJS的项目都有客户在用，需要不停的改BUG， 需要不停的加Feature。这家公司不是互联网行业的公司，是做房地产管理业务的，属于服务类的公司。这些项目是请外部的外包团队开发的，项目开发完就拿回来了。

这种现象在外包市场中非常普遍，项目方很少关心承包方用什么技术，是否以后方便维护。这就导致承包方会使用一些老旧的技术来开发项目，因为这种方式对他们来讲最省钱，他们也没有心思去培训员工学习新的技术。如果没有项目做了，就会想法子：要么要求现有员工快速学习掌握新技术，要么再招一批新的工程师。

再回到上面那家公司AngularJS项目上，那个时候AngularJS技术已经是老旧技术了，AngularJS程序员非常难找了。最接近的是Angular程序员，但是Angular跟AngularJS有很大的不同，维护这种AngularJS项目对Angular程序员来说是个很大的挑战。

【转换概述】

接下来就谈一谈如何把AngularJS项目转化为Angular项目，变废为宝。根据AngularJS的代码现状我们可以采用不同的方案进行转化。决定转化难易程度的因素很多，其中比较重要的一个就是JavaScript部分的代码，这一部分主要看语言的版本。因为Angular使用的TypeScript语言是基于ES6的class 组件概念。如果你的AngularJS项目代码使用的是ES5，那没有简便的办法可用，只能先重写ES5到ES6或者TypeScript。

接下来，我们就来分析下具体的三种转化方案。

【方案一：Migration Assistant】

这种方法是使用ngma(Angular Migration Assistant)工具来分析检测当前项目的复杂度信息。

关于这个工具的安装链接如下：

https://www.npmjs.com/package/ngma

这个工具分析完成之后，会提供如下几个重要的信息：

项目的复杂度；

代码行数；

不支持转化的模式；

项目的版本；

运行转化命令之前必要的准备步骤；

这个工具指出的问题解决以后，就可以运行下面这个命令进行转化ngUpgrade。

更多相关资料可以参考如下链接：

https://github.com/angular/ngMigration-Forum/wiki

【方案二：混合模式过渡转化】

对于代码规模比较大的项目，混合模式过渡转化也是一个可以考虑的方案。在这种模式下，AngularJS代码与Angular代码共存，两种组件和Service通过upgrade Module来进行通信。

这种方案的思路是，在很长的一段时间里，这两种模式会共存，随着时间的推移，逐渐的把AngularJS组件改成Angular组件，直至最后完全的去除AngularJS组件。

可以看得出来，这种模式会增加整个项目的复杂度，我个人不推荐使用。但是作为一种过渡方案可以讨论。

参考项目链接：

https://github.com/mweimer/ng-migration

【方案三： 创建一个新的Angular工程，逐步迁移】

这个方案的基本理念就是创建一个新的Angular工程，在这个新的工程里逐步的迁移现有工程的组件。具体步骤如下：

1.   创建一个新的Angular工程；

2.   把现有AngularJS的业务层要理清楚，把现有页面的结构管理整理出来；

这些信息包括：有多少个页面，这些页面的关联关系，父页面，子页面，要是有条件的话，可以使用工具创建一个Mock流程，可以做到每个页面之间的切换。

没有Mock也没有关系，页面关系搞清楚就行了。

3.   把对应页面的API搞清楚；

API的方法类型，路径，参数，加载的数据，返回的数据。这样的模拟数据一定要有。

有了这些模拟数据，你就可以写出一个非常简单的后端服务，供你的前端使用。这样可以脱离真正的后端，可以大大提高前端的开发进度。

尤其是在微服务环境下，整套系统的配置非常消耗时间和资源，这种短小精干的模拟后端服务非常有用。

4.   程序框架的建立；

结合步骤2中的页面关系，写出整个工程的页面跳转，每个页面这个时候只是placeholder没有实际的内容。这一步的主要目的是搭好整个工程的页面跳转框架。

5.   页面的填充；

这一步，我们需要对具体的页面就行内容的填充，可以使用静态的模拟数据来测试填充后的页面，不调用任何API。这里要注意，静态数据不要写在HTML模板里面，要写在TypeScript中。

6.   API的调用和数据的填充；

当步骤五中页面填充完成以后，我们可以通过调用API来获取模拟后端的数据填充动态数据。至此，绝大部分的工作就完成了。

7.   收尾阶段，查漏补缺；

到了这个阶段，我们已经把所有的页面组件重新创建完成。下一步我们要做的就是把整个前端放到大环境中去检验，如有问题既修改后再验证，以此类推，直至满意为止。

好了，总结一下，上面把三种方案都简略的分析了一下，

不管用哪种方案来做，有两个关键的点要做好：

需要懂现有项目操作流程的人来:

*业务关联的页面关系的梳理，这一点在开发过程和验证中都需要用到。

*API模拟数据的整理,可在操作页面的时候抓取API调用，这一点可以用来快速开发出独立小巧的模拟后端。

希望大家对从AngularJS到Angular的项目转化有个大体的了解,欢迎讨论。

【更多文章】

Jet Ding文章归类索引表