告别笨重框架：1KB级声明式UI库Rea的设计与实操指南

在React生态称霸前端的这几年，很少有人还记得当初那种“写个组件还要引入一整套框架”的笨重感。直到我无意中翻到一个叫“Rea”的小项目，才想起来：原来声明式UI不一定非得背着庞大的运行时，还能有一种轻到只有1KB左右的姿势。这玩意儿没有虚拟DOM、没有复杂的协调机制，却能让你用React那种思维写原生DOM操作，简直像在Buffalo鸡翅店里吃到一碗纯正牛肉面——路子野，但真香。

这篇文章不是要踩React，也不是劝你放弃主流框架跳到某个犄角旮旯的玩具库里。我想结合自己用Rea做了一个小型跨平台系统模拟项目的过程，聊聊这类迷你声明式UI库的核心设计思路、上手实操、在什么场景下真正能打，以及我在实际使用中踩过的一些坑。如果你是个React老手，或者刚搞懂组件概念的初学者，只要你偶尔写点前端小工具、浏览器插件、纯原生项目，这篇文章里的一些思路大概率能帮你省下一大坨不必要的依赖。

1. 内容整体设计与思路拆解

1.1 Rea到底是什么

“Rea”这个名字我第一反应还以为是React的缩写或者Realm的简称，实际上它就是一个极简的声明式UI库。它的核心理念很简单：用JavaScript对象描述界面结构与行为，库本身在运行时帮你把这些说明翻译成真正的DOM操作。你不需要自己从头去createElement、appendChild，也不需要一个庞大的框架运行时在那里反复做虚拟DIFF对比。

具体来说，Rea的用法长这个样：

import { createApp, h } from 'rea'; const app = createApp({ state: { count: 0 }, view: (state, actions) => h('div', { class: 'counter' }, [ h('span', {}, state.count), h('button', { onClick: () => actions.increment() }, '+') ]), actions: { increment(state) { return { count: state.count + 1 }; } } }); app.mount('#root');

这段代码做的事情，一眼就能看懂：一个计数器组件，状态里有个count，界面上有个数字和一个加号按钮，点击按钮就更新状态。每一次点击，Rea都会根据最新的state重新执行view函数，然后把新旧界面的差异应用到DOM上。注意这里没有虚拟DOM，它直接生成新的真实DOM节点与旧节点做对比，有差异的才更新。React那种先更新内存再统一提交的方式，在这里变成了更直接的“就地替换”。

1.2 为什么会有这种库的存在

你可以把Rea理解为介于“手写原生DOM操作”和“重量级框架”之间的过渡产物。很多项目并不需要React那样完整的组件生命周期、Suspense、并发特性，只需要一个能简单绑数据、更新视图的小工具。在这种情况下塞一整个React进去，光打包体积就是个巨大的成本。

以一个我实际接触过的某跨平台系统为例，这个系统要在嵌入式的WebView里跑，设备性能比较有限，加载一个React runtime本身不算大问题，但在低端设备上，首屏渲染速度和内存占用直接影响体验。用Rea之后，整个UI库加业务代码只有十几KB，首屏几乎是秒开的。这种场景下，1KB左右的库体积，对比动辄40KB以上的React runtime，优势不言而喻。

1.3 选型核心思路对比

有个细节我想单独拎出来说：Rea没有虚拟DOM，这是刻意为之的。虚拟DOM解决的核心问题是“如何以最小代价更新页面”，但它本身也付出了“构建对象树、diff比较”的时间与内存成本。如果界面结构本身不复杂，节点数量有限，直接用真实DOM做diff反而更直接高效。

我整理过一张选型对比表，方便你直观感受：

从表中能看出来，Rea更像是给“简单页面+一点交互”量身定做的方案。它不解决复杂状态管理、服务端渲染、代码分割这些框架级问题，相反，它把“简单场景做大做精”这件事做到了极致。

2. 核心细节解析与实操要点

2.1 声明式view函数的写法要领

Rea的view函数是整个使用体验的灵魂。写得好不好，直接影响后续维护成本。我自己的经验是：把view当成一个纯函数来写，给它什么state，它就应该返回什么结构，不做任何副作用操作。你要是想在里面直接改DOM或者调接口，那这个库最舒服的那个点就被破坏了。

举个例子，假设我们要做一个待办事项列表，最自然的写法是这样：

const app = createApp({ state: { todos: [], input: '' }, view: (state, actions) => h('div', {}, [ h('input', { value: state.input, onInput: (e) => actions.updateInput(e.target.value) }), h('button', { onClick: () => actions.addTodo() }, '添加'), h('ul', {}, state.todos.map(todo => h('li', { key: todo.id }, h('span', {}, todo.text), h('button', { onClick: () => actions.removeTodo(todo.id) }, '删除') ) ) ) ]), actions: { updateInput(state, value) { return { input: value }; }, addTodo(state) { if (!state.input.trim()) return state; return { input: '', todos: [...state.todos, { id: Date.now(), text: state.input }] }; }, removeTodo(state, id) { return { todos: state.todos.filter(todo => todo.id !== id) }; } } });

这段代码里的key属性很重要，Rea依赖它来追踪列表项的身份。如果你在渲染列表时不加key，或者用数组下标当key，插入或删除中间项的时候会出现状态错乱的问题，跟React里的表现是一模一样的。我一开始写的时候偷懒没加，结果在删除前几个待办时，输入框的位置和内容乱跳，排查了半天才发现是key的问题。

有一点必须说清楚：view函数每次都会被完整执行，所以不能在里面写一些昂贵的操作，比如每次都重新生成一个大数组或者做大量计算。需要记忆化的中间结果，可以在actions里处理成state的一部分，而不是在view里临时算。

2.2 actions里面的状态更新逻辑

Rea的actions设计跟Redux的reducer有点像，每个action都是纯函数，接收当前的state和额外参数，返回一个新的state。这里有个重要的规则：不要直接修改原state对象，而是返回一个全新的对象。这个库内部会做一个浅比较，如果你原样返回同一个引用，就会判定为“没有变化”，从而跳过视图更新。

实际写的时候，我遇到过一种情况：在action里直接push了某个数组，然后返回了同一个数组的引用。从代码逻辑上，数据确实变了，但视图始终不刷新。这个坑的根源就是因为浅比较机制判断引用没变，直接认定没更新。解决办法也很简单：

// 错误示范：改了原数组 addTodo(state) { state.todos.push({ id: Date.now(), text: state.input }); return state; // 引用没变，视图不更新 } // 正确示范：返回新数组 addTodo(state) { return { ...state, todos: [...state.todos, { id: Date.now(), text: state.input }] }; }

2.3 事件的绑定与原理

Rea的h函数支持的事件属性都是on开头，比如onClick、onInput、onChange。它在内部将这些事件直接绑定到生成的DOM元素上，没有事件代理机制。这意味着：如果你在某个父元素上动态删除了一个子节点，且没有正确清理，事件监听器可能会随着节点一起被垃圾回收机制处理掉，一般情况下不会内存泄漏。但反过来，如果你在view里给同一个事件反复赋新函数，得注意别意外覆盖掉别处的监听逻辑。

对于动态插入的节点，我建议在数据层面控制结构，不要在DOM层面手动操作。比如说要给列表项加一个“编辑”状态，应该通过state里某个字段去判断显示什么内容，而不是事后在某个节点上补事件：

view: (state, actions) => h('ul', {}, state.todos.map(todo => h('li', {}, todo.editing ? h('input', { value: todo.text, onInput: (e) => actions.editTodo(todo.id, e.target.value) }) : h('span', {}, todo.text), h('button', { onClick: () => actions.toggleEdit(todo.id) }, todo.editing ? '保存' : '编辑') ) ) )

这样写，事件的绑定和销毁都交给了Rea处理，你只需要关心数据和状态流转。

3. 实操过程与核心环节实现

3.1 从零搭一个小型项目

我之前提到用Rea做了一个模拟项目，这里还原一下实操过程。这个项目是一个“简易任务看板”，功能不复杂：左侧是任务列表，右侧是任务详情，支持添加任务、标记完成、删除任务，还有个筛选所有/未完成/已完成的状态切换。

首先需要初始化一个项目环境。我用的是Vite，因为它启动快、配置少，跟这类轻量库搭配很顺手：

npm create vite@latest task-board -- --template vanilla cd task-board npm install rea

安装完之后，项目结构大概是这样的：

• index.html
• src/main.js
• src/state.js

Rea本身没有强制要求目录结构，但为了维护方便，我习惯把状态、视图和入口分开。main.js里做初始化，state.js里定义初始数据和actions，视图部分直接写在main.js的createApp里，或者拆成一个view.js导出对象。

3.2 看板核心逻辑的实现

接下来看完整的看板实现思路。首先是状态结构的设计：

// state.js export const initialState = { tasks: [], filter: 'all' }; export const actions = { addTask(state, title) { if (!title.trim()) return state; return { ...state, tasks: [...state.tasks, { id: Date.now(), title, done: false }] }; }, toggleTask(state, id) { return { ...state, tasks: state.tasks.map(task => task.id === id ? { ...task, done: !task.done } : task ) }; }, removeTask(state, id) { return { ...state, tasks: state.tasks.filter(task => task.id !== id) }; }, setFilter(state, filter) { return { ...state, filter }; } };

然后是视图与交互逻辑。这一步最需要留意的是如何根据filter筛选列表。如果直接在view里算，每次状态更新都要重新执行一遍，数据量大了会有点压力。我的做法是在state里维护一个visibleTasks，只要filter或tasks变化，就在action里同步更新它。这样视图层只负责展示，不掺和计算：

setFilter(state, filter) { const visibleTasks = state.tasks.filter(task => { if (filter === 'active') return !task.done; if (filter === 'completed') return task.done; return true; }); return { ...state, filter, visibleTasks }; }

不过同一时间还需要在addTask、toggleTask、removeTask里一起维护visibleTasks，容易漏。后来我退了半步，把筛选逻辑放在view里。Rea的view函数每次都会执行，对一个任务列表来说，几十个项做个filter，性能完全无所谓，反而代码简单了。这也是一个取舍的经验：性能优化永远要基于真实瓶颈，不要为了“优雅”徒增复杂度。

3.3 和原生DOM操作的结合

Rea并没有把原生DOM操作封死。官方设计上，你可以在view里返回任意DOM节点，也可以是字符串、数字这类基本类型。这给了开发者很大的自由度去融合老代码或者做特殊处理。

举个例子，如果项目里已经有一段用原生JavaScript写好的canvas绘图逻辑，可以直接在Rea的视图树里插入一个canvas节点，然后在mount之后、或者某个action里拿到这个节点引用，继续做原生的canvas操作：

view: (state, actions) => h('div', {}, h('canvas', { id: 'chart', width: 400, height: 300 }) )

接着在组件挂载完成后去初始化canvas绘图上下文。Rea没有暴露一个标准的生命周期钩子，但你可以借助app.mount()返回的根元素自己找时机。

const app = createApp({ ... }); app.mount('#root'); const canvas = document.querySelector('#chart'); const ctx = canvas.getContext('2d'); // 继续绘制你的图表...

这种混合模式我用过几次，最大的感受是：遇到特别底层的需求时，Rea不会成为你的绊脚石，它不会强制你按某个风格写代码，你随时能打开一道口子去碰原生DOM。这种克制，是很多重量级框架做不到的。

3.4 全局状态共享方案

如果你有多个组件需要共享状态，比如一个头部一个列表，Rea也支持嵌套组件，每个组件可以有自己的state和actions。共享状态则有更简朴的做法：直接封装一个模块级的对象，在多个组件里引用同一个state。

我的做法是把全局数据挂在一个普通对象上，再用Rea的actions去修改它。由于Rea的组件数量少，这种做法并不别扭：

const store = { user: null, tasks: [] }; const headerApp = createApp({ state: store, view: (state, actions) => h('div', {}, `当前用户：${state.user ? state.user.name : '未登录'}`), actions: { login(state, user) { state.user = user; return { ...state }; } } }); const listApp = createApp({ state: store, view: (state, actions) => h('ul', {}, state.tasks.map(task => h('li', {}, task.title))), actions: { addTask(state, title) { state.tasks.push({ title }); return { ...state }; } } });

这里有个细节值得注意：两个组件操作同一个store，但是它们各自的视图绑定的是自己的状态副本。当我调用headerApp的login action后，listApp里的tasks没变，所以列表组件不会重新渲染。这其实是合理的——如果你只想改头部，那就不要碰列表的数据。但如果你想一次改动让多个组件更新，就需要把两个组件放到同一个createApp下面，用嵌套子组件的方式去传递数据。

4. 常见问题与排查技巧实录

4.1 列表不更新的经典坑

前面提到过，直接在action里修改原state并返回同一个引用，是Rea使用中最常见的“视图不更新”问题。这类问题最典型的表现是：页面上数据源明明已经变了，但界面纹丝不动。我自己遇到时的排查顺序是这样的：

• 先看action返回的对象引用是否发生了变化
• 再看视图函数里是不是有缓存过的中间结果
• 最后看事件绑定是否正确传递到了对应节点

绝大多数情况下，问题出在第一个环节。尤其当你习惯用对象里的数组属性直接push时，最容易踩中。建议在脑子里刻一套反射弧——在Rea里改状态，永远用展开运算符创建新对象和新数组。

4.2 事件绑定失效的三种情况

我在实际项目中遇到的事件“失效”现象，总结下来有三类原因：

第一种，节点被动态替换时，事件也跟着丢失。这通常是因为你在key管理上出了问题，导致Rea错误地复用了旧节点。解决办法是给列表项加上稳定、唯一的key，不要用index。

第二种，事件函数内部引用了旧的state。这个坑比较隐蔽：Rea的actions内部能获取到最新state，但如果你在view函数里直接给事件属性绑定了一个闭包，而这个闭包引用了本次渲染时的state值，等下次渲染时，旧闭包可能还在持有过期数据。我的解决办法是：一律通过actions来更新状态，不要在闭包里直接操作state数据。

第三种，事件绑定在不可冒泡的事件类型上。Rea不会为你做事件委托，所以像scroll、resize这类事件，你绑定在某个元素上是正常的；但如果你把它绑定在动态生成的canvas上，可能因为canvas重绘导致绑定丢失。这种情况下，我更建议用原生addEventListener挂到外层容器上管理。

4.3 性能表现的实测记录

有朋友问过我，Rea这种每次全量重建节点再diff的方式，性能到底够不够？我在那个模拟项目里测试过一个包含500个列表项的页面：每次点击按钮更新一项，整体耗时在个位数毫秒级别，Perception上完全无感。但如果数据量上升到5000条，每次全量重建DOM树的时间就到了几十毫秒，在低端设备上能感觉到轻微卡顿。

这个库的性能边界，说白了跟它的定位是一致的——适合小规模、轻交互的界面。如果你要做的是表格百页、复杂拖拽、实时图表这类重度交互，建议还是老老实实用React或者直接上canvas。Rea再怎么优化，也不可能用真实DOM的全量diff去跟虚拟DOM的细粒度复用比拼大型场景。

4.4 内存泄漏与订阅清理

Rea本身没有生命周期钩子，所以如果你在组件里手动添加了事件监听器或者定时器，离开页面时得自己清理。这个问题在传统页面里不突出，但在做成单页或多标签切换时很致命。

我习惯的应对方式是：在初始化某个组件时，把所有的监听器和定时器存到一个数组里，在组件销毁时统一清除。比如切换任务看板里的筛选项时，我会有一些动画效果用到了requestAnimationFrame，如果不清除，页面切走之后动画还在跑，CPU白耗。

const animations = []; function addAnimation() { const id = requestAnimationFrame(tick); animations.push(id); } function cleanupAnimations() { animations.forEach(id => cancelAnimationFrame(id)); animations.length = 0; }

这种代码跟Rea无关，任何前端项目都适用，但特别是Rea这类极简库不会帮你做这件事，责任全在开发者自己身上。

5. 工具链、扩展与个人体会

5.1 配合Vite等构建工具的体验

Rea对构建工具没有任何特殊要求。你用Vite、Webpack、Rollup都行，它就一个JS文件，不依赖任何运行时环境。在Vite里，冷启动几乎是瞬时的，修改代码刷新也比我预想的快得多。因为没那么多编译插件，整个开发链路很朴素，有点像回到最初写原生JavaScript的感觉。

打包方面，我用Vite打了一个生产包，开启压缩后，整个bundle只有几KB（业务代码除外），在弱网环境下的加载体验非常爽。这个优点在当下的前端环境里尤其难得——各种框架动不动几百KB起步，一个1KB的库简直就是清流。

5.2 怎么基于Rea扩展自己的小框架

用了一段时间后，我其实摸出了Rea的一套扩展路子。由于它的核心就是h函数和createApp，你可以在这之上封装出自己的组件层、路由层和数据层。

比如我经常需要一个“带标题的卡片”组件，就可以写成：

function Card({ title, children }) { return h('div', { class: 'card' }, [ h('h3', {}, title), h('div', { class: 'card-body' }, children) ]); } function MyApp() { return h('div', {}, h(Card, { title: '标题1' }, '这是内容'), h(Card, { title: '标题2' }, '这是另一个内容') ); }

这里的h函数支持把自定义函数当作组件标签传入，Rea会递归调用它们。这个能力跟React的函数组件非常像，所以如果你有React基础，用Rea几乎是无缝迁移。

再往上，你可以自己封装一个mini router，监听hashchange事件，根据路由映射去切换不同的顶层组件。这些逻辑加起来也不过几十行代码，还不到打个包出门的时间。

5.3 我对这种“小而美”工具的最终评价

从这次实际用到Rea做小项目，我的整体感受是：它解决了我长期以来一个悬而未决的痛点——在轻量场景下，想要声明式UI就得背个框架，想要体积小就得手撸DOM。Rea把这两个需求同时满足了，还顺手把学习成本压到极低。

当然，得承认它的边界很清晰。团队合作、大型项目、复杂状态管理，这些场景它并不适合。但反过来，如果你在写一个浏览器插件、一个简单的统计页、一个给领导看的内部小工具，或者嵌在某个嵌入式环境里的控制界面，用Rea正合适。它的存在提醒了我一件事：前端不是只有“上React”和“上Vue”这两条路，有时候退一步，用一个微小的工具解决刚好的问题，反而更清醒。

最后分享一个我自己的小技巧：如果你想把一个陈旧的原生DOM项目渐进式地迁移到声明式思维，不用直接把所有代码重写，可以挑一个交互密集的小模块，用Rea把它包起来，其他部分保持原样。这样风险可控、收益直接，还能让你在迁移过程中体会到Rea的状态管理思路和DOM更新策略到底是怎么运作的。我那个模拟项目就是这么一步步“啃”下来的，整个过程连一天都没花完，效果比我预想的好不少。