Slate 是一个低级别的编辑器框架，可帮助你在构建编辑器级时处理故障的部分，例如事件处理程序、元素、格式、命令、渲染、序列化、规范化等。

当尝试构建自己的编辑器时，它仍然需要很多技能来制作类似于 Quill 或 ProseMirror 的东西。该存储库网求允许您以 最少的Slate 知识立即构建你的编辑器。

@udecode/plate 建立在 Slate 之上，用于处理插件和状态管理应用最佳开发体验。这个存储库带有许多插件，如元素、标记、序列化器、规范化器、查询、转换、组件等。

简单的开始

您只需要一个组件开始使用： <Plate>

zustand 存储在内部用于支持多个编辑器状态

该 API 对设计系统是友好的。我们提供了一个默认的设计系统用于快速启动，但你可以使用一个单一的函数插入你自己的设计系统。

40+ 包

我们通过打包每个功能来执行关注点的分离，以实现构建优化和版本管理。

所有的插件都接受可扩展的选项，如果你需要 fork 一个插件，它的所有功能都被导出了。

Tree-shaking / ES 模块

TypeScript 类型

使用 slate@0.63.0 和 slate-react@0.65.2 进行单元测试

看了 wangEditor 的公告，如鲠在喉。去年七月，我在一篇《关于剔除 layedit 组件》的公告中，还推荐了几款 editor 组件用于替代，其中就包括了 wangEditor, 转眼之间，仿若时空交错，不免有些感慨。 在国内由个人发起的开源项目，似乎都很难跳出相同的宿命，不断有人走进这个赛道，但能抵达终点并完成突破的却屈指可数。Layui 曾经同样倒在了赛道，2021 年宣布关站之前，Layui 的百度指数还一度领先 Bootstrap, 如此一个拥有广泛用户群体的 UI 库，本该迎来新的突破，却在疾跑中戛然止步，至今令人迷惑。人们看到的，是一篇充满悲情色彩的公告，而公告的背后，是创作者在面对内外交织的困境中不得已做出的举措，当我们没有足够的力量冲破眼前的障碍，除了停下来避开它，还有别的更优选择么。你很难想象除此之外还有多少历史包袱… 譬如，也是由于种种原因，当初 Layui 在 Github 和 Gitee 待处理的 Issue 数量，不下于 2000，各种议题参次不齐，我差不多花了半年时间去逐一审阅，多少个日夜消耗，多少次自我情绪的对抗… 就不多提了。 尽管这两年来，Layui 的受众者已呈断崖式流失，但正因为小众，反而如释重负，甚至让我重新找回了一些开源的纯粹。 共勉 🙂 本人原创作者，在此解释声明一二： 1. 我的父母还没有无耻到做这种无耻的事情，我也对我的能力有信心，目前也不需要这些偷鸡摸狗的见不得光的东西来造假，请各位不要以小人之心度君子之腹。 2. 我今年初三，项目是从初一开始做的，各位不相信的欢迎上github看提交记录，可以看一下初版和现在的区别，UI和js都有不小更改。 3. 团队组成：今年一位初三，一位初一，一位5+4制的初一。更新记录中明确记录了哪些功能是哪位所开发的。 4. 我在github上，bilibili上没有受到过任何一个人的质疑，我对中国的网络环境表示蔑视。 5. 本项目的初中只是为了兴趣，没有想到火了起来。 我不理解你们是如何通过代码读出作者年龄的？难道是语文考试要加入代码阅读赏析的题目了吗？真心觉得很厉害。 6. 不愿与某些人同流，也无众位深厚阅历经验，只望能得清白之名。感谢大家让我懂得了何乃人情世故，孰谓世态炎凉，世俗红尘。你们给我的人生上了重要的一课。人间哪有什么真善美啊，呵。社会的病胎罢了。 专门登录写个评论，为了信创而信创没有任何意义。 如果开源的spring被认为是非自主可控不安全的，那请问Linux和Java属于自主可控吗？那些大数据和人工智能的组件属于自助可控吗？Docker和K8s属于自主可控吗？ 真要完全安全自主的话，国内的计算机行业应该从汇编开始发展。 师夷长技以制夷，我支持自主研发、自主可控的信创策略，但应该是更底层的芯片、操作系统、虚拟机、容器化这些基础组件的研发。像中间件、应用框架这些东西，就算一夜之间所有github的代码全部消失了，集合几家大厂的能力，开发出来又能花多少时间呢？况且现在大厂本身就有很多自研的中间件和框架。 本身东西就不复杂，现在spring、redis这些东西流行只是因为它们诞生的早生态好罢了，而不是难度。为此单独再搞一套轮子我觉得大可不必。 Thread-local variables Virtual threads support thread-local variables (ThreadLocal) and inheritable thread-local variables (InheritableThreadLocal), just like platform threads, so they can run existing code that uses thread locals. However, because virtual threads can be very numerous, use thread locals only after careful consideration. In particular, do not use thread locals to pool costly resources among multiple tasks sharing the same thread in a thread pool. Virtual threads should never be pooled since each is intended to run only a single task over its lifetime. We have removed many uses of thread locals from the JDK's java.base module in preparation for virtual threads in order to reduce memory footprint when running with millions of threads. The system property jdk.traceVirtualThreadLocals can be used to trigger a stack trace when a virtual thread sets the value of any thread-local variable. This diagnostic output may assist with removing thread locals when migrating code to us