Vue 架构网站思维逻辑梳理

vue的项目做了好几个了,在这里梳理一下我的思路和一些心得

首先是我现在用的项目结构目录

项目架构简介

  • api文件 --》 项目接口方法,文件名与pages的文件名对应,每个页面一个接口文件
  • assets --》 js --》 config.js 定义交互状态码和一些数据转换方式
  • assets --》 js --》 http.js 用Promise来封装axios,并统一处理交互的token权限
  • assets --》 js --》 uri.js 用来控制项目的本地路径和接口路径列表
  • assets --》 js --》 util.js 自己封装的常用工具方法
  • assets --》 less --》 变量设置和样式重置
  • components --》 公共组件
  • pages --》 页面文件
  • router --》 路由文件
  • store --》 vuex
  • store --》 index --》 vuex 的对外暴露
  • store --》 state --》 vuex 的状态变量
  • store --》 mutations --》 vuex 状态变量的操作方法
  • store --》 mutation-types --》 vuex 状态变量操作方法的对应列表
  • theme --》 UI框架的css样式
  • vendor --》 扩展插件的存放

在网站架构上,我认为一般分为这么三个线:

  • 1.前后端交互
  • 2.数据存储更新处理
  • 3.前端业务逻辑处理

前后端交互

在这里,每次在页面内发起交互,走的流程是:页面发起交互请求--》 api文件中对应的交互方法--》 api文件在uri.js中获取对应的接口地址--》 api文件调用http文件中封装axios方法--》 http文件校验是否有token,并将token统一 附值在headers中--》 http文件发起接口请求--》 http文件返回Promise并将返回值带回--》 页面接收到返回数据,并根据config.js中定义的状态码进行统一判断交互是否成功。

看起来太长了,用列表在罗列一次

  • 1.页面发起交互请求
  • 2.api文件中对应的交互方法
  • 3.api文件在uri.js中获取对应的接口地址
  • 4.api文件调用http文件中封装axios方法
  • 5.http文件校验是否有token,并将token统一附值在headers中
  • 6.http文件发起接口请求
  • 7.http文件返回Promise并将返回值带回
  • 8.页面接收到返回数据,并根据config.js中定义的状态码进行统一判断交互是否成功

虽然逻辑看起来很麻烦,但我认为我这样做有很多优点,稍微列举一下

  • 1.每个文件对应一个api交互方法文件,查找某个页面的接口的时候非常方便。
  • 2.全部uri列表统一管理,涉及到接口迁移或者ip变化的时候,可以统一管理,不怕测漏。
  • 3.封装http模块,统一校验token并附加在headers中,这样处理接口的时候可以不用再管token了,一劳永逸。
  • 4.在config.js中统一定义状态码,可以根据与后端的沟通统一判断返回状态。

数据存储更新处理

由于webapp变成了无刷新操作,对于数据更新和存储、文件缓存处理等这些压力就都变成前端的了。

首先要对数据进行分类,我分为下面几类

  • 1.固定不会变更的数据:直接放在前端,不去交互
  • 2.展示内容不固定,但是数据固定:原则是:在缓存中获取--》 在本地存储中获取--》 调接口获取。通过这样来减少对服务器的请求。但是这只适用于那些基本不需要更新的数据。比如这类文件比如客户权限等。这些对于不同账号,权限不同。所以要在登录的时候向后端获取数据,这点毋庸置疑。但是获取到数据之后,本次登录过程中基本就没有必要再去获取了, 所以可以存在本地存储中,然后放在vuex中进行缓存。vuex的天敌就是刷新。所以vuex中要默认获取存储中的数据。这样,刷新的时候,vuex就会将存储中的数据加载过来,放到缓存中,不再需要向后端请求数据
  • 3.数据基本固定,缺失时影响不大:这类数据也很多,比如总账户的子账户列表。一般情况下,子账户列表是固定的,变更的可能性不大。但是也存在着操作的可能性。所以这部分数据我放在 vuex中,在每次获取数据前,判断vuex中是否存在值,存在的话就直接用,不存在就向后端获取。在总账户对子账户列表进行修改时,我更新vuex的数据。这样基本上只需要向后端请求一次。但是如果多人同时登录总账户 修改了子账户列表,那么vuex的数据就不一定准确了。这时候客户可以通过刷新来更新子账户列表。刷新的时候vuex中没有数据,会向接口请求,然后更新数据。这类数据,出现小几率误差影响不大。
  • 4.不固定的数据:这类数据,没有悬念,每次操作都直接去加载,不要缓存。

前端业务逻辑处理

前端业务逻辑处理,就比较杂了,业务需求不同。但是也有一些可以归类的想法

  • 1.组件的提取,需要明确智能组件和木偶组件,我也不是觉得越多越好。我的提取原则功能独立行强,重复性高的。虽然组件化有它的优势,但为了组件化而组件化,反而提升了维护难度,得不偿失。
  • 2.对于前端数据的处理逻辑,个人感觉还是前端数据处理逻辑越少越好。可以优化交互、渲染,但是对数据的处理,放到前端来做,显得很臃肿。不是做不了,第一数据处理逻辑放在前端明文操作暴露的数据会增多。第二会让 前端页面结构变得很大。前阵子处理的那个区域运力配置的页面,这个问题就很严重。虽然前端处理能力增强了,但是后端如果只是select * 然后扔过来,要后端作甚。
  • 3.前端业务逻辑方法,还是推荐每个函数处理自己独立的一个功能,然后把备注写好。这样遇到业务修改的时候,省不少事。data也不要填的太乱,分好类,比如表单校验,那就一个form,一个formReg,form中的所有数据都挂在form下, 不然真是容易眼花缭乱。

随机浏览