最近在Plate实习，老板让我先充分学习之后再去做功能，所以就有了这篇文章，搞清楚两个版本的对比，才能知道我现在正在做的事情到底是什么事情（个人理解，会有差错）

Slate 和 Plite

[!TIP] V1 V2 不是指Plate包的版本，而是因为重构了底层编辑器引擎，所以我称之为V1 V2版本，但是我刚刚参与进来，很多底层我还不了解，内容请勿计较

Slate是Plate v1 一开始使用的Rich-text editor 的框架和编辑引擎，但是Slate只做了很基础的底层的事情，并没有直接实现好富文本编辑器，富文本编辑器更多的功能，Plate选择使用一种插件体系去构成。需要什么功能就去使用什么插件。所谓的插件，可以理解为后端中很解耦的Modal层，需要什么功能就注册什么功能那种感觉，所以上我们的编辑器可以做到非常的轻，要什么就自己加什么插件就行，嫌麻烦可以一键使用Plate的基本工具包，我们称其为Kit。

v1的由于是基于Slate的，但是slate核心包里面是没有常用的Block Selection，只有最基础的Text Selection，想要在Plate使用Block Selection就需要加插件。为什么使用Slate好好的，要换成自研的Plite呢？老实说，我也不知道，我猜测方向可能是跟性能（Plite编辑引擎性能不应该比Slate差），便捷性（Plite把编辑器的一次修改组织成一个事务，里面可能包括多次的操作，类似数据库那样，提交事务后修改完成，也能方便进行Undo操作），归一性（让零碎的API归一起来，所以这一个版本API会有很大的变更，还有统一model，DOM选区和浏览器的输入），有可能有些历史原因吧（某些Pr）。都是我我的猜测和思考，不过话说我为什么不直接去问老板（🥲）

v2，也就是现在我们正在开发的Plate的新版本，团队把底层核心由Slate换成了自研的Plite。Plite在M层几乎有跟Slate几乎一样的数据结构，一样的思路。都是的Slate节点树，使用Text 去表示文字节点，页面有tpye表示文本的类型，还有属性去控制它的样式，Element底下是children，有节点在树中的位置Path，Range表示Text选区（anchor，focus，offset）等。得益于Plite和Slate有非常多相同的地方并且有这么好的数据结构去描述，所以它的理解起来很容易。但是Plite还有一个很大的变化就是它把之前的Selection的部分之前移动编辑器引擎层了，也就是它的core包里面，把Text Selection和Block Selection 和在了一起，由底层统一去管理Selection = TextSelection | NodeSelection | null，这样我们无需插件便可享受到Block Selection这项当好样的功能（当前我写文章这个版本的Lexical编辑器还不支持Block Selection，新版支持），当然这样做的坏处就是上层的功能需要重新的去做适配，不过显然这个改动是长期正确的改动。另外改动就是上端的猜测部分括号内的改动。

Radix UI 和 Base UI

去年的12月，shadcn/ui支持将Base UI作为底层的primitive方案；今年的12月，shadcn/ui 正式将Base UI设为默认的方案。2020年，Radix UI 发布，快速推广，成为了最广泛使用的Headless组件库之一，23年，shadcn/ui发布，一开始就默认基于Radix UI 构建。我在网上搜寻了Base UI出现的原因和shadcn/ui愿意去默认使用Base UI的原因，Radix UI 在被 WorkOS 收购后维护放缓，而由 MUI 团队（包含Radix UI 的创始人--Colm Tuite）全职开发的 Base UI 在 React 19 兼容性、包体积和复杂组件支持方面展现出更强的竞争力。我感觉就是Radix UI被收购后，更新太慢了，太不稳定了，对于React 19的关键性功能支持迟迟不落地，完全看不懂前景了（当前Blog的前端还是Innei当年基于Radix UI 自研的组件库，还是Next 14版本，感叹时间真的飞速）

话说回来，这跟我们Plate有什么关系呢？其实早在今年5月份，Plate的discussions里面就有人询问了有关BaseUI 的问题，后续在8月份的讨论中阐明了真正的落地的时间

https://github.com/udecode/plate/discussions/4974

zbeyens回复”It will be supported. Note that our components depend on shadcn components, so you could replace those with the base ones.“ 后续还补充到 ”Probably for the end of the year.“。

那么显然，我们新的一个版本就是要增加对于Base UI的支持，这也就是Plate v2正在做的事情。让Astra读仓库之后可知

所以大概就是这样的情况

新功能

我目前感知，可能就多了分页视图的功能，Details，别的更多的是底层和还有性能上的优化吧。分页视图功能可以想象为类似于Word那样的，有一张纸，有页边距和页间距的纸，内容根据排版来跨页展示结果，但是这里肯定是可以配置，符合Plate一贯插件式可配置式的风格。

下面是Details，其实早在V1版本的时候就有一个Toggle了，不过Toggle大道至简，功能很简单，就是一个可折叠的组件，里面能放子段落去展示内容，不支持一个Toggle里面又嵌套一个Toggle，要是你非要这样做的话，只能使用table制表符模拟，本身的节点还是平行结构的，也不可改Summary的样式，达不到Notion那种水平。

这次把Toggle 重构成了Details 组件，也为他新增了许多的新功能，真正意义上支持多级嵌套Details，因为他底层的节点树的结构就是支持嵌套的，不过现在还不支持改Summary的type，不支持把Text直接改成任意的Heading。当前如果你去把原本是Summary的Text改成Heading的话，那么Summary会直接变成其中一个子段落，然后又由于Details的插件规则自动生成一个空白内容的Summary，就是让你的Details变成类似于下面这样。

现在这种情况应该是说，如果不支持改变Summary改成Heading的行为，应该是要禁用这个改成Heading的功能才对，或者可以通过配置关闭这个功能（暂时没有实现），或者说我们应该支持这个功能，至少Noton是支持，我认为我们应该支持，不过现在我还没跟老板去说，或许他早有打算也不一定。

还有一些听GPT说的旧功能的重新设计和重写，还有我一些我暂未感知到的功能

老实说，跟rich-text editor 还有一定缘分的，上课的时候听过10多年前的老家伙说过，“要是觉得你很技术，你就去开发一个富文本”，Innei在大学的时候也独自摸索过rich-text editor，改过Lexical，看他的文章也学到了rich-text editor另外的价值，自己也在摸索如何在长列表中渲染出更好的文本格式，OpenAI前几日全面开放GPT6 Sol 的时候推出了他们的Intelligent UI 让Chat 模式下的回复更加的好。

希望能在Plate中学到更多的东西，我很荣幸能参与到Plate的开源建设中，作为我第一个参与的开源项目，我会拿出很多的时间和精力去对待它，不仅仅是因为是公司的项目，更多的还是我对开源的喜爱。