Slate – 用于构建富文本编辑器的完全可定制的框架

Slate 可让您构建丰富、直观的编辑器，如 Medium、Dropbox Paper 或 Google Docs 中的编辑器（这些编辑器正在成为网络应用程序的桌面），而您的代码库不会陷入复杂性。它可以做到这一点，因为它的所有逻辑都是通过一系列插件实现的，因此您永远不会受到“核心”中存在或不存在的内容的限制。您可以将其视为构建在 React 之上的 contenteditable 的可插入实现。它的灵感来自于 Draft.js、Prosemirror 和 Quill 等库。 🤖 Slate 目前处于测试阶段。它的核心 API 现在可用，但您可能需要为高级用例拉取请求改进，或修复一些错误。它的一些 API 尚未“最终确定”，随着我们发现更好的解决方案，它们会随着时间的推移发生重大变化。目前没有 1.0 发布时间表，我们仍在完善架构。 🤖 Slate 也是贡献者驱动的。它不受任何大公司的支持，这意味着所有贡献都是自愿的，由需要它们的人完成。如果您需要改进、添加或修复某些内容，请自己贡献，否则没人愿意。如果您想成为更积极的维护者，请在 Slack 频道中告诉我们。在创建 Slate 之前，我尝试了很多其他的富文本库——Draft.js、Prosemirror、Quill 等。我发现虽然让简单的示例工作很容易，但一旦你开始尝试构建类似Medium、Dropbox Paper 或 Google Docs，你遇到了更深层次的问题……编辑器的“架构”是硬编码的，很难定制。像粗体和斜体这样的东西是开箱即用的，但是评论、嵌入甚至更多特定领域的需求呢？以编程方式转换文档非常复杂。以用户身份进行编写可能会奏效，但进行程序更改（这对于构建高级行为至关重要）是不必要的复杂。

序列化为 HTML、Markdown 等似乎是事后的想法。像将文档转换为 HTML 或 Markdown 之类的简单事情涉及编写大量样板代码，用于看起来非常常见的用例。重新发明视图层似乎效率低下且受到限制。大多数编辑都推出了他们自己的视图，而不是使用像 React 这样的现有技术，所以你必须学习一个带有新“陷阱”的全新系统。协作编辑不是预先设计的。通常，编辑器的内部数据表示无法在不基本上重写编辑器的情况下用于实时协作编辑用例。存储库是整体式的，不小且可重用。许多编辑器的代码库通常没有公开可以被开发人员重用的内部工具，导致不得不重新发明轮子。构建复杂的嵌套文档是不可能的。许多编辑器都是围绕简单的“平面”文档设计的，这使得表格、嵌入和标题等内容难以推理，有时甚至是不可能的。当然，并非每个编辑器都会出现所有这些问题，但如果您尝试使用其他编辑器，您可能会遇到类似的问题。为了绕过他们 API 的限制并实现您所追求的用户体验，您必须求助于非常hacky 的东西。而有些经验是完全不可能实现的。一流的插件。 Slate 最重要的部分是插件是一流的实体。这意味着您可以完全自定义编辑体验，构建复杂的编辑器，如 Medium 或 Dropbox 的，而不必与库的假设作斗争。

无模式核心。 Slate 的核心逻辑对您将要编辑的数据的架构几乎没有假设，这意味着库中没有任何假设会在您需要超越最基本的用例时绊倒您。嵌套文档模型。 Slate 使用的文档模型是一个嵌套的递归树，就像 DOM 本身一样。这意味着可以为高级用例创建复杂的组件，如表或嵌套块引用。但是也很容易通过只使用一个层次结构来保持简单。与 DOM 平行。 Slate 的数据模型基于 DOM — 文档是一个嵌套的树，它使用选择和范围，并公开所有标准事件处理程序。这意味着诸如表格或嵌套块引号之类的高级行为是可能的。你可以在 DOM 中做的几乎任何事情，你都可以在 Slate 中做。直观的命令。 Slate 文档使用“命令”进行编辑，这些命令设计为高级且非常易于编写和阅读，因此自定义功能尽可能具有表现力。这极大地提高了您对代码进行推理的能力。协作就绪数据模型。 Slate 使用的数据模型——特别是如何将操作应用于文档——旨在允许将协作编辑置于顶部，因此如果您决定让编辑器协作，则无需重新考虑所有内容。清晰的“核心”边界。使用插件优先的架构和无模式的核心，“核心”和“自定义”之间的边界变得更加清晰，这意味着核心体验不会陷入边缘情况。要了解如何使用 Slate，请查看一些示例：

如果您对展示常见用例的示例有想法，请拉取请求！如果您是第一次使用 Slate，请查看入门演练和概念以熟悉 Slate 的体系结构和思维模型。如果这还不够，你总是可以阅读源代码本身，它被大量评论。 Slate 的代码库是由 Lerna 管理的 monorepo。它由少数软件包组成——尽管您不会总是使用所有这些软件包。他们是：