一个完全可定制的框架
用于构建丰富的文本编辑器。
为什么？ ·原理·演示·示例·文档·贡献！
slate允许您构建像中等，Dropbox Paper或Google文档的丰富，直观的编辑器一样，即在网络上成为应用程序的表赌注，而没有您的代码库变得复杂。
之所以可以这样做，是因为它的所有逻辑都是用一系列插件实现的，因此您永远不会受到“核心”中的或不限制的。您可以将其视为在React之上构建的可满足的可扎能实施。它的灵感来自Draft.js，Prosemirror和Quill等图书馆。
slate目前正在Beta。它的核心API现在可使用，但是您可能需要为高级用例提取请求改进或修复某些错误。它的某些API并未“最终确定”，随着我们发现更好的解决方案，随着时间的推移会发生破坏。当前没有1.0发布时间表，我们仍将架构正确。
? slate也是贡献者驱动的。它不是任何庞大的公司的支持，这意味着所有捐款都是自愿的，需要他们的人做。如果您需要改进，添加或固定的东西，请自己做出贡献，或者没有人会做出贡献。而且，如果您想成为一个更活跃的维护者，请在Slack频道中告知我们。
为什么？
为什么要创建slate ？好吧... （当心：本节有我的一些意见！）
在创建slate之前，我尝试了许多其他丰富的文本库 - draft.js ， prosemirror ， quill等。我发现的是，一旦您开始尝试构建诸如Medied，Dropbox Paper或Google Docs之类的内容，您就会遇到更深入的问题，您便遇到了更深的问题...
编辑的“架构”是硬编码，很难自定义。开箱即用的大胆和斜体之类的东西，但是评论或嵌入，甚至更特定于领域的需求呢？
以编程方式转换文件非常令人费解。作为用户的写作可能已经起作用，但是进行程序化更改对于构建高级行为至关重要，这是不必要的复杂。
序列化到HTML，Markdown等似乎是事后的想法。简单的事情，例如将文档转换为HTML或Markdown涉及编写大量样板代码，这似乎是非常常见的用例。
重新发明视图层似乎效率低下和限制。大多数编辑都推出了自己的观点，而不是使用诸如React之类的现有技术，因此您必须学习一个具有新的“ Gotchas”的全新系统。
协作编辑不是事先设计的。通常，编辑器的内部表示数据使得无需重写编辑器而无法用于实时，协作编辑用例。
存储库是单片的，不是很小且可重复使用。许多编辑的代码库通常不会揭露开发人员本来可以重复使用的内部工具，从而不得不重新发明轮子。
建造复合物，嵌套的文件是不可能的。许多编辑都是围绕简单化的“平坦”文档设计的，使桌子，嵌入和字幕之类的东西难以推理，有时甚至是不可能的。
当然，并非每个编辑者都会表现出所有这些问题，但是如果您尝试使用另一个编辑器，则可能会遇到类似的问题。要解决其API的局限性并实现您追求的用户体验，您必须求助于非常骇人听闻的事情。一些经验是不可能实现的。
如果听起来很熟悉，您可能会喜欢slate 。
这使我想到了slate如何解决所有这些...
原则
slate试图解决“为什么？”的问题。有一些原则：
一流的插件。 slate最重要的部分是插件是一流的实体。这意味着您可以完全自定义编辑体验，以构建Medium或Dropbox等复杂的编辑器，而不必与图书馆的假设作斗争。
无模式的核心。 slate的核心逻辑对您将要编辑的数据的模式很少，这意味着在库中没有假设，当您需要超越最基本的用例时，您会绊倒您。
嵌套文档模型。 slate使用的文档模型是嵌套的递归树，就像DOM本身一样。这意味着，对于高级用例，可以创建复杂的组件或嵌套块引号。但是，仅使用单个层次结构，也很容易保持简单。
平行于DOM。 slate的数据模型基于DOM - 文档是嵌套树，它使用选择和范围，并揭示所有标准事件处理程序。这意味着可以进行高级行为或嵌套块引号。您几乎可以在DOM中做的任何事情，您可以在slate中做。
直观命令。使用“命令”编辑slate文档，这些文档被设计为高级且非常直观的写入和读取，因此自定义功能尽可能地表现力。这大大提高了您推理代码的能力。
合作的数据模型。数据模型slate使用（特别是如何将操作应用于文档）旨在允许将协作编辑放在顶部，因此，如果您决定进行编辑器协作，则无需重新考虑所有内容。
清晰的“核心”边界。借助插件优先的架构和无模式的核心，在“核心”和“自定义”之间的边界之间变得更加清晰，这意味着在边缘情况下，核心体验不会被陷入困境。
演示
查看所有示例的现场演示！
例子
为了了解您如何使用slate ，请查看一些示例：
- 纯文本- 显示最基本的情况：荣耀