fes.js/packages/fes-doc/test.md

FES 文档

建议解决方案

• 更新日志可以接入 commit 工具，根据 commit msg 自动生成更新日志
• 国际化描述有点过时，根据 fes-ui 的国际化需求，及时更新
• 组件文档需要及时更新，为了避免后续文档割裂问题
  • 将 fes-ui 下的 example 切换成 doc 一样的格式，通过脚本一键同步文档

fes 文档

fes 主要解决的问题在于：

• 构建：一键完成中后台系统的脚手架
• 组件库：提供一套比较完善的组件库支持
• 路由：开发者不需要关心路由的实现
• 国际化：开发者不太需要管计划怎么实现
• 权限：对路由级别的权限控制又比较好的支持
• filer: 提供多种 filer、map 做内容的映射
• api Mock: 提供 api mock 的能力
• 静态文件：提供静态文件的能力
• 登录：内置 sso 登录功能
• 内置 eslint 规范
• 数据存储
• 状态管理

对未来的期望

• 分析 fes 构建并进行优化
  • 不支持高版本的 node
  • 构建输出需要优化，目前只改一个文件，几乎更新了每一个文件。理论上我只更新一个业务 js，只更新一个 chunk
• 模块化
  • 目前的实现 page 下面的组件都会解析成 page，但是之前看外包代码的时候，很多外包还是会把页面级别的模块放在 page 下面。
  • page 页面也有很多需求需要进行组件拆分，建议在 page 下加个 components 目录的支持，components 下的模块不会解析成 page。
  • 比如 page/a/components 那么这些 components 只能放 a 页面的 components，这样不会全部放在 src/components 下，显的比较乱
• 路由
  • 对路由的规则能进一步梳理，避免出现死循环。（现在已有三个参数控制、需要注释才能理解代码了）。
• 页面 API
  • 对于写 fes 的用户，他们必须要了解 vue 的基本语法。又需要知道 fes 语法，会增加用户理解 fes 负担。
  • 对于 fesData | fes 生命周期等，我认为可以直接使用 vue。没必须再造一套概念。
• FesApp ｜ FesUtil | FesApi 傻傻分不清？
  • 建议可以把这些概念化整为零。像 vue | koa 等的设计、所有的 API 注入到一个地方。用户通过统一的接口调用就行。
  • 不需要关心: 这个 API 是那个暴露的
• FesFesx
  • 建议进行优化，使其表现的更为 vuex，复合大部分人的认知。
• fesHeader | fesLeft
  • 这两个组件为非必填项，应该可以自行决定是否删除
  • 可以根据是否存在 fes-left, fes-header 来决定是否显示，这样还可以减少 fes.config 的两个配置
• 提供更为丰富的模版，逐步逼近 fes 愿景
• 上单元测试，改代码不方