关于前端:关于后台管理系统前端项目的思考

开发后盾管理系统是大部分前端开发人员接触过的我的项目，如何更好的进行我的项目的搭建、组件的开发、数据结构的设计等等，这些都是须要思考的问题。以下是我联合一些我的项目的经验和其余大佬的我的项目代码与技术分享，做出了对于后盾管理系统中前端我的项目的思考

这一要求无论是对于前端开发人员或是其余端的开发人员，都是可能顺利开发我的项目的前提。在开发我的项目之前，需对 PM 的需要了然于胸，对原型设计可能充沛把握。了解每一个操作逻辑的含意，并且扩散思维思考如何进行组件和数据结构的设计。然而独自只是对需要文档和原型进行浏览是比拟容易脱漏某些性能点的，最好可能对我的项目从新设计一张 思维导图 ，从开发本人的角度进行设计，从我的项目整体的根节点登程，细分每一个模块，每个模块下设计好对应的需要，确保每一个性能不被脱漏。尽管多花了设计思维导图的工夫，但我感觉这是值得的，这样不仅仅可能减少对于整体我的项目的了解，也能更好的及时发现我的项目的难点和纳闷点。

后盾管理系统的支流技术选型为 Vue+ElemetUI，不过集体感觉在组件设计上 Ant Design Vue 的 UI 框架设计得好一些，更多的是采取数据驱动组件的设计模式，在我的项目开发中能够更不便的解耦逻辑函数。不过 UI 框架的抉择还是得联合开发人员团队本身对于某一个的熟练程度和是否有对应的 UI 框架能更好的解决我的项目中存在的难点进行综合比拟。
全局按需引入 element-ui 组件：

import Vue from "vue";
···
import {Input} from "element-ui";
Vue.use(Input);

组件应用：

<el-input
  v-model="user"
  clearable
  @keyup.enter.native="search"
  @clear="search"
></el-input>

通过 Vue 脚手架工具搭建的前端我的项目在 src 文件夹下可分为以下几局部：

路由层 router
动态文件层 assets
页面结构层 views
组件结构层 components
全局状态管理层 store
性能逻辑解决层 util
常量管理层 constants

在 Vue 我的项目中还能够引入更多的配置如混入层 mixins、过滤层 filtters 等。
在我的项目开发中，须要辨别开业务性能和非业务性能的逻辑设计，对于一些能够解耦进去的非业务性能函数，个别不间接在开发页面的业务逻辑中间接定义此函数，而是须要抽离进去，可供多个业务性能函数进行调用。
组件结构层 components 中个别也只开发非业务性能相干的页面组件或性能组件，以供多个页面构造进行调用，若一个页面需分成几个组件开发，且此子组件属于业务性能的，倡议间接在页面结构层 views 中定义，开发和保护同一个页面也比拟不便。
src 文件夹下构造如下：

├─assets
├─components
├─constants
├─mixins
├─request
├─router
├─store
├─utils
└─views

个别我的项目中对于数据申请的形式都是基于 methods 钩子或其余生命周期钩子中调用申请办法，也存在一些我的项目中是通过发送一个 disptach 异步申请办法在 actions 中调用申请函数。应用后者的说法是便于对立治理申请接口，并对申请返回的数据进行对立的治理。
综合以上两种做法，能够优化我的项目中的申请形式，若申请接口收回后返回的数据须要在多个页面或多个不同的组件中共享和应用，则举荐在须要发申请的函数中 dispath 触发，在 actions 中发送申请，返回的数据保留在全局状态治理 state 中。
methods 中发送申请形式：

getGraphicCode () {
  let vm = this;
  api.login.getCheckCode({type: '2'}).then(res => {if (res.code === '000') {
      vm.graphicCode = 'data:image/png;base64,' + res.data.img;
      vm.imgId = res.data.imgId;
    } else {vm.$message.error(res.msg);
    }
  })
}

actions 中发送申请形式：

findAllRoles({commit}) {return new Promise((resolve, reject) => {api.systemAccount.findAllRoles().then(response => {if (response.code === "000" && response.success) {commit(MUTATIONS_TYPE.AllROLES, response.data)
        resolve(response);
      } else {reject(new Error(response.code, response.msg))
      }
    })
  })
},

token 验证是目前大部分前后端拆散的 Web 我的项目做登录验证比拟常见的办法。前端通过发送账号和明码或账号和验证码给到后端后，后端验证通过会返回一个惟一的 token 作为该用户的登录凭证，在之后的每个申请当中，申请头中都需带上这个 token 作为后端的登录校验。token 有过期的机制，能够在申请拦挡中做逻辑判断解决，若以后工夫靠近了过期工夫，则通过更新 token 的接口申请更新 token，在之后的申请中带上新的 token。以此循环，若用户过长时间无操作，则可认为用户为离线状态，在用户之后的第一次申请时，因为 token 曾经过期，拜访后端接口会产生谬误，依据后端返回的谬误状态码作为判断，将零碎定向至登录页面。
通过带有 token 申请头的申请办法，后端能够判断到是哪一个用户，前端也能够通过获取权限接口取得该用户的权限列表，依据权限列表做一份路由映射表，如果后端返回的数据结构与前端的路由设置的数据结构不同，此时还需编写此映射路由的业务性能函数。如果该用户领有此路由权限，则通过在全局路由监控中 router.beforeEach 进行 router 中的 addRoutes 办法将有权限的路由配置增加到路由当中，侧边栏也可依据路由列表中的 meta 字段中关键字的判断进行相应的渲染。如果权限的颗粒度小到一个按钮，则可依据后端返回的权限列表映射出的权限参数，通过 v-if 进行判断该性能组件是否渲染。
在路由治理中通过 router.beforeEach 钩子中判断以后的路由权限是否为空，是的话则可执行获取权限路由的接口：

store.dispatch("getUserInfoAndAuthorityInfo").then(res => {
  // 依据后端返回的路由权限格局转成前端路由配置格局
  const rolesRoute = setAsyncRouterMap(res.menuList, asyncRouterMap, mainChildrenAsyncRoutes)
  store.commit(Vue.VUEX_TYPES.ROLESROUTE, rolesRoute);
  // 增加路由
  router.addRoutes(rolesRoute);
  next({...to})
}).catch(() => {Message.error("验证失败")
  next('/login')
})

在我的项目当中对要害的常量枚举值进行治理是十分有必要的。比方在我的项目当中后端用某个状态码 1 代表账号为启用状态，如果在我的项目当中屡次应用 ===1 去判断账号是否为启用状态，当须要更改这个状态码的时候，对于前端来说是一件非常麻烦的事件，所以能够通过把 1 赋值给一个常量，在我的项目代码中援用这个常量，如果须要更改状态码的时候，则间接扭转这个赋值给常量枚举值的状态码即可，常量的配置也可揭示开发人员此参数不可轻易批改，便于我的项目的保护和对立治理。个别常量枚举值的治理写在 constants 层中，常量的变量名应用大写字母编写。
状态枚举值得配置如下：

/**
 * 账号状态对照表
 * "0" 未启用 NOTUSED_CODE
 * "1" 已启用 ENABLE_CODE
 * "2" 已停用 DISABLE_CODE
 */

const NOTUSED_CODE = "0";
const ENABLE_CODE = "1";
const DISABLE_CODE = "2";

const ACCOUNT_TYPE = {[NOTUSED_CODE]: "未启用",
  [ENABLE_CODE]: "已启用",
  [DISABLE_CODE]: "已停用"
};

export default Object.freeze({
  NOTUSED_CODE,
  ENABLE_CODE,
  DISABLE_CODE,
  ACCOUNT_TYPE
});

前端我的项目当中能够把展现组件分为两局部，别离为页面组件和性能组件。对于页面组件，罕用于展示页面的整体内容，承当着业务逻辑的失常运行，与业务比拟有强的耦合性。性能组件是用于展示和解决某一繁多或某一模块的性能，性能组件并不关怀页面的业务逻辑，充当着一个函数的作用，只有有输出便有对应的输入，并可在多个页面组件或性能组件中被调用。综上，在设计页面组件的时候，不仅应该思考该组件可能失常的实现业务的性能，还要思考其是否可能脱离业务成为一个性能组件，对于内容比拟多的页面组件，能够在其同级目录下新建多个子页面组件独特构建。在设计性能组件时，需思考组件的布局、逻辑、视图，性能组件的设计难度在于其要思考到满足不断更新的需要变动，可扩展性，灵活性是设计的一大挑战。
页面组件目录格局如下：

我的项目的开发文档可编写为 md 文件格式寄存于我的项目的根目录，一份好的开发文档可能对我的项目的背景进行介绍，阐明我的项目的构造和开发的步骤，更有利于其余开发人员参加或接手我的项目。对于我的项目当中应用到的与业务性能耦合的逻辑函数，较为简单的，编写函数的介绍以及应用办法，做好边界条件判断，示范输出数据以及对应的输入后果，可在我的项目中新建 docs 文件夹寄存开发过程中的应用文档。对于非简单性能的业务逻辑函数或非业务逻辑函数，可间接在定义函数之前编写正文，阐明函数作用性能，以及对应的输出和输出参数的类型。

每次的开发过程都可当做是一个学习和总结经验的过程，比照以往的代码，咱们能够思考代码构造是否能设计得更加欠缺，逻辑函数是否清晰且思考边界条件，性能是否能够更加的优化。

关于前端:关于后台管理系统前端项目的思考

对于后盾管理系统前端我的项目的思考

1. 理解需要，相熟把握需要

2. 确定技术选型

3. 设计我的项目构造

4. 数据申请 methods 中 OR actions 中

5. 登录与权限治理

6. 常量枚举值治理

7. 组件设计

8. 必要的开发文档或正文