从绫开始的后台管理系统（三）
这一章我们开始对若依的前端工程进行分析。
ruoyi的前端主要包括登录验证，路由转发，dev模式这几个模块。
工程结构
ruoyi的前端主要包括api(service)、layout、router、store(vuex)、view几个部分。
组件视图
assets是存储一些静态图片资源的地方；
components内放了一些抽象的、可复用的组件，可以放在具体的视图中直接使用。
layout是存储布局文件。菜单、内容区域、导航栏、用户设置都是数据布局的一部分。
views中存储的是内容视图，内容视图会在那layout的内容区域进行渲染。
directive存放的是vue指令。ruoyi仅将指定用于角色验证和权限验证。
资源管理
api负责http资源管理，其实这里叫做service更恰当，因为资源不仅仅有api。
路由访问
router中存的是组件的路由数据，页面内导航都依赖于vue-router进行跳转。
工具集合
utils中是一些工具类，静态变量。比如权限验证工具类，错误代码常量。
store中是用来放置vuex的配置文件。若依在一些组件联动中使用了vuex，比如左侧菜单栏的伸缩。
注：vuex严格来说只是一个状态管理的工具，它不产生数据，只是做数据的搬运工
资源聚合
资源管理的主要对象是http服务。因为现在的前端都是基于webapp的概念开发，对于一个app来说，数据来源不止一种http，它可以到一个资源服务器去拿用户信息，去另一个资源服务器拿订单信息等等。
基于这个理念，http服务资源就必须要管理起来。并且每种资源客户端都要作为一个单例提供（比如单例化的axios）。
组件管理
组件部分分为视图组件和指令组件，他们会一起参与渲染流程，控制页面的表现。这里视图组件和指令组件不在赘述，使用方法等可以自行查询vue文档。
指令设计
ruoyi的指令主要用绝角色验证和权限验证，他们控制着某个组件是否显示，某个页面是否有权限访问。举例来说：
如果当前用户没有monitor:job:edit这项权限，则会移除修改按钮。若仅使用指令而未设置操作权限值，则会直接抛出异常。
状态管理
状态管理ruoyi使用了vuex。它被使用在一些组件菜单数据的路由维护，组件之间的状态联动，tabs上右键菜单的联动，还有用户信息的更新联动。这一块有兴趣的同学可以学习一下vuex的状态管理。
这里我们会用ng的rxjs来做，相比于rxjs，vuex，rxjs的写法会简明一些。
渲染流程
程序从index.html进入，从layout/index.vue开始渲染布局，布局渲染完毕后会渲染views下的内容视图。布局渲染和内容视图渲染的过程中会使用到components中的组件，这就是layout、views、components三者的关系和渲染流程。
接口验证
接口验证这里ruoyi是使用axios的拦截器做的。
请求拦截
在进行请求时，会检查接口是否需要token将token注入头文件。
响应拦截
在得到响应后，如果有错误代码axios拦截器会抛出异常并选择是否进行重定向。
路由转发
路由转发这里分为两部分，路由配置和路由转发。路由配置又分为静态配置和动态配置。路由转发一般使用router.push或<router-link>这里不再进行赘述，可以去看一下官方文档。
静态配置
使用下图这样的配置方式，将一些公共路由提前配置好。
动态配置
根据一些条件向router对象中添加路由配置。在ruoyi中是结合vuex向router对象中添加动态路由
路由模式
路由模式这个并不是vue独有，这是目前实行的一种标准。目前我们默认使用history模式。
hash: 使用 URL hash 值来作路由。支持所有浏览器，同时也支持在不部署到前端服务器，直接访问文件来进行跳转。history: 依赖 HTML5 History API 和服务器配置。此模式依赖于浏览器实现，要求必须部署在服务器，如node，nginx等。abstract: 支持所有 JavaScript 运行环境，如 Node.js 服务器端。如果发现没有浏览器的 API，路由会自动强制进入这个模式
dev模式
dev模式是为了方便我们在开发时解决跨域问题而产生的，它会将我们访问的接口进行代理访问从而解决跨域问题。
核心配置在我们红框部分：
被代理的接口范围。一般来说是使用前缀匹配要代理的api。
# 若依管理系统/开发环境 VUE_APP_BASE_API = '/dev-api'目标地址。api服务器的地址
是否重写api。由于1的原因，可能改写了部分api，这时要将api重写覆盖。
其他设计
代码检查
因js的写法非常灵活，开发人员很容易写出bug，比如变量提升、内存泄漏等。这里采用eslint和husky进行代码检查。eslint在ide编辑时就会提是，husky则是做了一个git的钩子，在commit前会调用相应的方法进行代码检查。
语法转译
因为浏览器兼容性的问题，需要将一些es6语法转译为es5。ruoyi是使用babel进行转译。
环境变量
在打包时会根据不同的配置注入不同的环境变量，这也是兼容多环境比较重要的一个点
总结
ruoyi的前端设计解析到此就结束了。
其实前端框架性的配置本身就比较少，加上我们要用ng来实现，我们可利用的部分就更少了，基本都要重写，所以分析一些库的使用方法也意义不大。
前端的重点难点在于视图渲染和兼容。比如说要flow布局的兼容性，css在不同浏览器的兼容等等。这些都是要在我们正式编码中要解决的，在这里更希望关注一些宏观上，设计上的思路，而非到具体的兼容性和实现。