架构

前言 前面一章我们详细讲述了，基于请求库的封装，从系统角度来说，基本满足正常的使用功能以及扩展能力。对于不同的业务平台，可以进行数据的处理、定制以及异常的处理且支持多种不同的请求方式。 今天我们要讲的

前言 项目中，对于接口请求，一般有三种方式，Ajax、Fetch、Axios 三者之间的关系如下： 简单理解： Ajax - 异步请求 Javascript和XML,XMLHttpRequest 是浏

前言： 我们今天讲解的设计是框架层对于权限管理的包装。 提供给应用层使用。 设计思路： 和上述几个设计大同小异 系统中，对于菜单的数据，在应用层一般作为路由权限控制以及菜单的显示。 但是在实际开发中，

前言： 这一章也比较简单，主要是对系统的用户信息获取做统一管理。 使用统一的API进行用户的相关信息获取。 设计思路： API 标题 updateUserInfo 更新用户信息 updateAppIn

前言 这一集非常简单，思路简单，代码也少。模块配置设计这个词多少有点太专业，我们来具体阐述下，这个配置相关的设计的来源和目的 大家在日常开发中，肯定遇到过这种场景： 上面是针对业务场景，但是实际中，大

前言 字典设计，可能有的小伙伴还不清楚，字典是什么？项目里面的字典又是什么？ 一般中小类项目，不会去做字典的管理，因为这类项目的讲求就是快、稳定。 项目稍微大一些的时候，具备一定的规模，需求庞大、人员

设计定位： 所属框架层，主要面向系统应用层服务，提供通用接口、状态、方法。 设计目的： 在日常开发中，对于功能开发来说，一些基础的系统层功能，如： 权限数据管理 请求库二次封装 接口API管理 全局配

前言 前端的工具库，常用的也都比较多，一些数据转换、格式化、存储等，也都比较杂，我们试着进行一个大的归类 文字复杂、文件下载 全屏处理公用方法 图片下载以及转换 base64/blob等 copy.j

前言 前端的工具库，常用的也都比较多，一些数据转换、格式化、存储等，也都比较杂，我们试着进行一个大的归类 ` 订阅/取消订阅 EventEmitter 前端消息事件订阅方法 页面通信/卸载 Event

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第18天，点击查看活动详情 前言 前端的工具库，常用的也都比较多，一些数据转换、格式化、存储等，也都比较杂，我们试着进行一个大的归类

前言 前端的工具库，常用的也都比较多，一些数据转换、格式化、存储等，也都比较杂，我们试着进行一个大的归类 字符串Base64转换 数据格式的转换，从扁平化数据结构，转换为树形数据结构 日期转换函数集合

设计思路： 对于项目开发来说，长期的积累，总结出一个常用的工具库，可能是每一个开发者心之所想的事情。 随着时间的流逝和经验的积累，会发现其实没有想象那么难 做之前需要思考一些问题： 通用性 扩展性 简

名称：useQueryParams 处理URL请求后参数截取和转换 设计来源： 之前项目中大量模块传递参数，大部分都是路由的query提取或者直接location.search，需要写一堆代码，设计这

架构思路： 构建应用框架之时，对框架进行了结构化构思，需要有一层设计，可以为业务公共层服务 Loader的想法，有点像webpack中的加载器，但两者不太一样 设计目的： 1、穿梭与底层框架与业务，服

设计思路： 这一节比较简单，因为来源于，系统应用层，主要整体控制一二级菜单的展示，所有提供的API较少 1、提供响应扩展能力，获取菜单类别等 设计动机： 针对ToB类的系统，大多类似于后台管理类系统。

设计思路： 前期经过1~2周的预研工作，试了socket相关的方案，因架构组大佬要求比较高，要实现一个大而全的整体方案 比如支持TCP/HTTP/WS等协议的。套件就定位到了MQTT 设计动机： 系统

设计思路： 系统应用级别，目前简单的路由方式，无法满足平台级别的应用。 设计动机： 注册动态路由 动态路由数据的存取 进入页面前/中/后的逻辑注入 多端路由访问和拦截 API 名称 含义 loader

设计思路： 本来这块的逻辑不多，都在应用管理器AppLoader里面写着，因为应用管理器中有关于接口服务注册和监听相关，最后做的东西会越来越多，面临如下问题： 业务不断扩展，对接口请求拦截部分要求也越

设计思路： 此管理器，主要是为登录页面服务和首页退出系统服务，支持子系统登录和多客户端登录 而且封装后 设计实践: 生产环境模式： 开发环境模式 暴露出这么多，看起来有点烦躁，不过还是要耐下心来，聊聊

名称：useHistoryStretch 需求来源 这个和路由操作相关的hooks，比较特殊一下，有点业务高度定制化的感觉， 业务扩展性，不通用 答案是没有什么不可以，但是出现了一个问题： 在开发功能