企业级前端研发框架的演进与实践

最新推荐文章于 2024-06-23 20:43:56 发布

peixiancccc

最新推荐文章于 2024-06-23 20:43:56 发布

阅读量704

点赞数 25

分类专栏：程序员文章标签：前端

本文链接：https://blog.csdn.net/peixiancccc/article/details/137528947

版权

程序员专栏收录该内容

302 篇文章 0 订阅

订阅专栏

微前端

一键开启

Serverless 一体化

插件支持

???

框架提供了哪些能力

一张大图

下面是一张 icejs 框架的大图，共分为四层从上到下依次是 基础设施 -> 研发标准 -> 性能体验 -> 研发模式 。

基础设施

基础设施主要包括依赖的社区方案如 UI 框架 React 、路由库 react-router 、构建工具 webpack、测试工具 jest 等，以及基于 webpack 封装的上层工程构建工具 build-scripts 等。这一层主要为 icejs 的基础依赖，同时我们基于这些基础依赖做了一定程度上的封装，让业务不需要关心底层的细节以及版本变更等，使用 icejs 时即可开箱即用。

研发标准：

研发标准主要包括通过框架提供完整的标准化的 React 应用开发最佳实践，其中主要分为：

标准化的研发流程：规划和约束了项目开发完整流程，包括基础规范的目录结构、样式方案、代码规范，路由规范、状态管理、以及大部分场景的业务方案等，最终形成完整的标准化的一套最佳实践方案；
插件生态：提供插件机制和常用插件，其能力基于工程构建工具 build-scripts 封装，因此在插件能力上也完整继承了 build-scrtips。除了通过插件定制工程能力以外，框架还为插件扩展了运行时定制的能力，这让插件拥有更多的想象空间；
自研体系：主要包括面向大型应用的微前端解决方案，简单友好的状态管理方案，场景复用的 Hooks 工具库，这部分能力会作为基础能力集成在框架中，只需简单配置即可按需开启。

性能体验

性能体验是衡量一个框架的重要指标，对框架而言。体验可以分为开发者体验和用户体验。其中开发者体验主要包括构建速度，错误调试，智能提示、开发文档等。对用户而言，则主要包括首屏渲染速度，预加载能力等，目前框架已支持 SSR 、Code Splitting 用于优化性能。

业务场景

不同的业务场景又不同的技术诉求，框架已支持 SPA、MPA、SSR、微前端、Serverless 一体化（仅限内部）等多种不同的业务场景。

配套模板

除了上述能力，我们还为框架提供了高质量的不同类型的的配置模板，在实际生产中可以根据业务情况进行使用。

更轻量的应用入口

框架只需要通过调用 createApp 即可启动一个包括路由、状态管理、数据请求等功能的 React 应用，同时在创建应用时你可以根据实际的业务需求进行自定义配置。相比传统的 React 应用开发而言，无需在手动去调用 ReactDOM.render() 、去创建路由 createHistory() 等繁琐而重复的应用入口的配置。

import { createApp, IAppConfig } from ‘ice’;

// 应用配置

const appConfig: IAppConfig = {

// 启动项配置

app: {},

// 路由配置

router: { },

// 状态管理配置

store: { },

// 数据请求配置

request: {},

// 日志配置

logger: {}

};

createApp(appConfig);

更灵活的导出方式

在 React 项目开发中，诸如 react-router 等第三方依赖是每个项目开发中都会重复出现的，因此在 icejs 中也进一步对这些依赖进行了收敛，减少项目的依赖项和版本的管理问题。同时还框架支持了通过插件往 ice 包里面注册新的 API，这意味着你可以编写某个插件将业务的通用能力集成到框架之中，在多个项目之间都可使用，且对业务开发者无感，这是值得令人兴奋的。

import {

//插件扩展的接口

store,

request,

loggger,

config,

helpers,

…

// 内置组件

Link,

NavLink,

ErrorBoundary

…

// 内置 Hooks

useHistory

useSearchParams

…

// etc

} from ‘ice’;

更简单的路由配置

路由是应用开发中必不可少一部分。从社区看 next.js、 umijs 等框架都在推崇使用约定式路由，但经过实践后我们发现约定式路由在一些简单的应用场景下是比较适合的，根据目录自动生成路由可以减少路由配置的工作，但当应用复杂的时候，需要增加各种标识和目录结构来判断，如嵌套路由、动态参数使用 $ 等，这时目录结构会变的很不优雅，对开发者来讲需要遵循约定式路由带来的新的规则和学习成本，因此在 icejs 框架设计中以及配套的模板里默认推荐使用配置式路由，但同时也支持了完整的约定式路由能力，这是可选的。

配置式路由（推荐）：标准路由协议，理解直观易懂

const routerConfig = [

// 分组路由，children 里的路由会将父节点的 component 作为布局组件

{

path: ‘/user’,

component: UserLayout,

children: [

{

path: ‘/login’,

exact: true,

component: UserLogin,

// 配置路由的高阶组件

wrappers: [wrapperPage]

{

path: ‘/’,

// 重定向

redirect: ‘/user/login’,

{

// 404 没有匹配到的路由

component: NotFound,

// 非分组路由

{

path: ‘/about’,

component: About,

];

配置式路由（可选）：约定目录规范，无需配置自定生成路由。

更智能的状态管理

状态管理是应用开发和技术选型最重要的一环，从 React 生态来看，目前主要的状态管理方案大致可以分为三类，响应式状态管理方案类 MobX 系列、单向数据流类 Redux 系列、以及在 React Hooks 之后的基于 Hooks 系列，而在这些之上衍生的方案估约不下 100+，如果你有选择困难症，那么你可以选择使用 icejs，因为你不再需要关心眼花缭乱的状态库、概念繁多的 API、重复的模板代码等问题。

在做状态管理方案的时候，我们核心关心的是什么，这里主要抽象四个维度：

怎么去定义一个模型
视图怎么跟模型绑定
视图怎么去消费模型
模型之间如何取联动

在进一步抽象，其实本质就是 UI 视图和 DATA 模型如何交互，基于此考虑在 icejs 中内置集成了自研的 icestore 状态管理方案，并在此基础上进一步遵循 “约定优于配置” 原则，进行抽象和封装，使得状态管理变得非常容易。

你只需要 定义模型 和 视图消费 即可，其他模型与视图绑定的工作由框架去做。
你只需要 写更少且更优雅 的代码即可，其他重复的模板工作由框架去做。

模型定义

export default {

state: 0,

reducers: {

increment:(prevState) => prevState + 1,

decrement:(prevState) => prevState - 1,

effects: () => ({

async asyncDecrement() {

await delay(1000);

this.decrement();

})

};

视图消费

import { store } from ‘ice’;

function Counter() {

// model 名称即文件名称，如 src/models/counter.ts -> counter

const [ count, dispatchers ] = useModel(‘counter’);

const { increment, asyncDecrement } = dispatchers;

return (

{count}

);

}

更友好的工程配置

框架提供了绝大部分的工程配置项，值得一提的是只需要使用 JSON 格式配置工程即可，相比 react-scripts 以及社区其他的工程方案，JSON 配置能够极大的简化工程配置的复杂度，也更加简单。

{

“alias”: {

“@”: “src”

“outputDir”: “dist”,

“publicPath”: “./”,

“sourceMap”: true,

“minify”: false,

“proxy”: {

“/**”: {

“enable”: true,

“target”: “http://127.0.0.1:6001”

}

更简洁的微前端接入

基于 icestark 微前端方案和 icejs 的插件机制，我们封装了 build-plugin-icestark 插件，通过该插件可以大大降低接入微前端方案的成本。只需简洁的配置即可接入。

配置框架应用

import { createApp } from ‘ice’

const appConfig = {

icestark: {

type: ‘framework’,

getApps: async () => {

appRouter: {

};

createApp(appConfig)

配置微应用

import { createApp } from ‘ice’

const appConfig = {

icestark: {

type: ‘child’,

};

createApp(appConfig)

更多其他的能力

除了上述能力之外，框架还抽象提供以下常用的功能，具体请查看文档：

规范化的数据请求方案
通用场景的页面配置能力
简单的的环境构建/运行时配置
友好的代码分割、错误边界处理能力
支持 SPA、MPA、SSR、微前端、Serverless 等应用类型

???

框架是如何设计的

框架架构

框架的核心架构主要包括 运行时 和 工程能力 两部分：其中运行时部分主要提供扩展运行时能力，在 icejs 中称之为运行时模块，通过模块提供的 API 可以非常简单的将通用逻辑插件化，以便在不同的项目间进行抽象和复用，如我们可以通过 AddProvider 在应用最顶层添加自定义的 Provider 能力，通过 wrapperRouter 为每个路由包装一个组件等等。而工程部分则主要提供插件扩展和生成器的职位。