-
redux
-
mobx
-
immer
-
rematch
-
icestore
-
…
-
100+
没有约定的团队，沟通和跨团队协作成本，以及长期的维护成本是非常高的，这时候统一一套开发模式就显得尤为重要。而 icejs 正是在这种背景下诞生的，通过框架强约束和提供完整的标准化的 React 应用开发模式和最佳实践。旨在使前端开发更加的快捷、高效，以及收敛技术栈、屏蔽底层差异和统一开发体验，帮助开发团队和开发人员降低开发和维护成本。
因此在这一阶段，核心从工程体系的脚手架演进成完整的标准化的 React 研发框架，在工程插件的基础之上支持并扩展了运行时的能力。通过运行时的能力我们可以非常简单的将业务开发中的最佳实践方案通过框架的插件机制进行实现和强约束，并预设一套的默认的最佳实践的插件集。
下面是演进的差异对比图：
| 纬度\版本 | icejs 1.x | ice-scripts 2.x | ice-scripts 1.x |
| — | — | — | — |
| 定位 | 研发框架 | 构建工具 | 构建工具 |
| 配置文件 | build.json | ice.config.js | package.json(buildConfig) |
| 发布时间 | 2020.02 | 2019.06 | 2018.02 |
| 可渐进升级性 | 好 | 不好 | 不好 |
| 插件能力 | 工程+运行时 | 工程 | 无 |
| 工程配置 | 强 | 强 | 弱 |
| 运行时配置 | 默认支持 |
-
|
-
|
|
SPA
|
默认支持
|
支持
|
支持
|
|
MPA
|
一键开启
|
-
|
-
|
|
SSR
|
一键开启
|
-
|
-
|
|
微前端
|
一键开启
|
-
|
-
|
|
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)
更多其他的能力
最后
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！
如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
mport { createApp } from ‘ice’
const appConfig = {
icestark: {
type: ‘child’,
},
};
createApp(appConfig)
更多其他的能力
最后
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。
因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-wn1djIzJ-1715822652455)]
[外链图片转存中…(img-6XfVQDkb-1715822652456)]
[外链图片转存中…(img-dyJtlEML-1715822652456)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！
如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
181
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
