001

## 前言 本文主要摘录了前端工程化可能会涉及到的一系列问题，并针对其中一些问题提供了完整的场景说明，期望以及可能的解决方案。 ## 问题列表 ### 高频因为业务修改公共组件 **问题：** 项目在开发的时候用大量的时间去造了轮子，在轮子的使用上有点过于死板不够灵活，总是在高频率的修改组件，尤其是根据业务场景不断的调整基础组件。而基础组件的部分，大部分团队成员不清晰其使用，其存在的问题。 **建议 ：** 这种建议把公共组件的部分抽离出来，抽出时间，然后做的方式应该是依赖引入的组件去实现特定的功能，对于组件中未实现的，或者需要灵活处理的，给出足够的解决方案，然后根据业务的部分做出更好的方案，比如项目里的业务组件。 **具体可执行方案 ：** - 抽离可用度高的公共组件库，脱离出项目，优化约定其使用以及迭代方式 - 针对业务中特殊修改的组件，开发为业务组件，如果需要或者希望完善公共组件，应该前置一个项目周期完成开发上线ui组件，或者后置一个周期，从业务组件中提炼公共组件 - 简化公共组件的使用方式与依赖方式，对于其具体的使用提供完整的api - 与设计、产品达成从开发到审美到产品交互的积累的同认知 ### api请求 **问题：** 目前的实现是使用mockjs请求easymock的部分，后端未完成的接口返回一个指定的错误然后去请求mock的服务器，需要单独起mock的服务指令，不够灵活，对于service的api生成没有较大的优化，参数还是需要校对的。 **具体可执行方案 ：** 1 利用easymock本身的可配置化，配置接口部分请求哪个接口 2 生成的api的部分只是整理了其方法类型，路径以及其出参和入参，还不够理想，如果这部分做进一步处理，需要axios做拦截器处理，对请求格式正确以及返回格式正确的做处理 3 mock服务内置到项目的启动命令中，不要增加开发成本 4 对于mock假数据的生成没有相关的工具类，无法按照自己预期生成想要的数据 5 需要建立一个easymock的服务器，可以灵活切换不同环境的api，可以新建以及修改不同的文件 ### 过量的前端枚举字段 **问题：** 前端中存了跟多枚举字段 ，每次项目启动的时候都去拉一边配置的字段，而且是全量的。 **具体可执行方案 ：** 1 按照需求去加载前端的枚举字段 2 将枚举的部分通过模块或者接口的形式实现 3 枚举字段要建立一定的规则，比如检查机制，更新机制，使用机制等。尤其像权限的部分，定义的比较不合理。 ### 双语方案 **问题：** 前端中存了大量的双语重复字典，每个页面都会重复维护，改动比较麻烦，而且其唯一的key是不便于使用的。 **具体可执行方案 ：** **分析** 1双语方案应该是一个产品同一个页面做的策略，做一个英文网站，一个中文网站也可以，但作为功能性、业务性很强的站点，创建两个站点意味着很大的工作量。所以第一个决策就是做的是一个站点，然后做双语翻译 2 双语策略应该是一个公开模块，支持练高的灵活配置，可以实现不同项目的双语需求 3 双语方案应该是开放的，由需求或者产品优化或者专业人士不断根据需求可以在ui界面进行长期维护和便利性查询的 4 双语模块应该实现基本的双语数据同步，可以定期或者人为同步发布新版本。 5 双语方案针对没有翻译策略的语言提供容错方案，项目使用时也应该注意到这点。 **具体技术方案** 1 创建数据库，提供表结构，支持id 中文字段双唯一索引，支持主体双语分类，包括常用，系统，考勤，考试，查寝类似的主题双语方案，支持同条唯一字段里为之提供具体的中英文翻译甚至更多需要版本，提供字段描述，使用场景。 2 提供双语平台，可以进行双语的维护，以及各种高级查询 3 发布双语模块，基本数据结构与数据库匹配，可以进行数据库双语数据的同步以及发布新版本，支持npm加载，提供公开api，提供中文字段或者其他字段的标准翻译方法以及翻译配置，提供常规中英文翻译工具，具有容错策略 4 基本的三大框架中都有过滤器实现，拟目前方案根据双语模块进行过滤器处理，使用方便，直接需要的字段后面加|就可以。稍微国际化的方案可以根据，i18n的方案。 5 后续会根据阿里国际以及一些大型站点的双语策略做具体的技术方案调整。 ###