一旦你'；我为你的应用程序选择了一个富文本库，切换到一个新的；这并不容易，而且有很多风险。我们最近更改了Ashby使用的富文本库，通过研究和规划，我们能够在生产中以最小的问题完成这项工作。我们想分享这项研究和过程，希望它能帮助你做出类似的转变。
这篇文章是关于我们如何从Slate切换到tiptap的两部分系列文章的第一部分。今天，我们'；I’我将解释我们决定使用tiptap的过程，我们的后续帖子将描述我们是如何切换的。
2019年，我们在阿什比增加了富文本编辑功能。我们评估了多种解决方案以做出决定（包括Quill和Draft.js），最终选择了Slate。
和当时的许多图书馆一样，Slate也处于测试阶段，但正在迅速改进和扩展。我们希望Slate能够支持更多浏览器，并且它的API能够保持稳定（尽管维护人员强烈建议这两种情况都不可能发生！）。不幸的是，我们的赌博没有'；但这并没有带来回报，维护人员在0.50版本中对API和文档模型进行了重大突破性的更改。x、 这些变化是Slate未来的正确方向，但我们需要大量工作才能迁移到我们无法'；作为一个小型工程团队（即使有社区提供的巨大支持），我也做不到。
我们保持在0.47。x尽可能长，但我们的用户在增长，我们需要升级Slate以解决问题并支持更多浏览器。自2019年以来，有更多的富文本编辑器库可供选择，因此我们决定在升级Slate的同时，评估切换到新库的情况。
我们创建了一个全面的富文本编辑器库列表来进行评估。虽然谷歌很有用，但在谷歌搜索中排名是一场人气竞赛，而不是质量测试。为了详尽起见，我们从2019年找到的图书馆的初始列表开始，并在其他图书馆的文档中使用参考文献来查找更多信息。例如，Slate列出了草稿。js、Prosemirror和Quill在他们的介绍文档中作为灵感。鹅毛笔：编辑、TinyMCE、草稿。js、Prosemirror和Trix。使用这种方法，我们收集了十多位候选人的名单。
我们仔细检查了候选人，并使用可用的文档、博客帖子和我们能找到的其他信息列出了关键的库属性。我们全面收集的一些关键属性包括：
Beta或稳定：它'；如果一个库是beta版的，那么它不是一个showthepper，但是它'；有必要知道使用它是否会带来破坏更改的风险。
GitHub上的明星：这绝对不是一个质量衡量标准，但它让你感觉到了图书馆'；s社区及其活跃程度。
React支持：我们使用React构建应用程序，因此在React中轻松使用库至关重要。
浏览器支持：这是Slate 0.47的主要难点之一。x、 因此，我们希望确保桌面和移动设备上的所有主要浏览器都有良好的支持。
上一次发布的时间：这显示了库的维护有多积极。不管是否稳定，javascript库周围的环境都在不断发展，因此'；It’总有事情要做。没有一款应用程序是"；完成了"
上一次提交的时间：与上一次发布的时间一样，这会让你感觉到社区有多活跃，即使最新发布的版本已经过时，也能反映问题修复的速度有多快。
当前版本：如果我们回顾我们的笔记，我们就知道我们评估了什么版本，看看从那时起情况是否发生了变化。
除了关键属性之外，我们还注意到所有库的一些共同特性。当我们查看每一个图书馆时，这个数字都在增加'；我经常在一个图书馆里找到一些突出的东西，看看其他图书馆是否支持它。例如，tiptap中可用的扩展满足了我们的大部分需求（包括提到的内容），并开始在各个库之间进行比较。
我们以五个库的短名单退出了这个阶段：Slate、Quill、Prosemiror、ReMirror和tiptap。
我们没有'；在这之前，我们不会编写一行代码，但现在是时候开始构建快速原型，以便更好地了解每个库了。
每个原型的目标是尽可能接近编辑器的当前状态（视觉上和功能上）。将每个原型保持在半个工作日左右，并得出一个严密的声明：
我们没有'；不实现自定义扩展——如果是'；这不是一个随时可用的功能，我们忽略了它（例如，@提及）。
我们没有'；t实现与当前编辑器及其文档模型的互操作性。每一个原型都只能独立工作，使用图书馆的新文档#39；这是文件。
有了这些经验，我们根据自己的需求列出了每一个图书馆的优缺点。这些可能在你读到这篇文章的时候是无效的，或者你可以考虑一些我们认为是优点的缺点（反之亦然）。
我们在2021年5月收集了数据（包括版本号和GITHUB星）。所有结论都是根据名字旁边列出的图书馆版本得出的。从那时起，这些图书馆可能已经有了很大的发展。
我们确信，迁移到最新版本类似于从头开始。一个显著的缺点是我们不能'；I don’我两个都没有0.47。x和0.63.0同时出现在我们的应用程序中。如果不同时使用这两种功能，我们就无法逐步迁移功能，我们'；d需要做一个完整的撕裂和更换。
我们喜欢Slate是为React而构建的（不需要包装器），拥有庞大的用户群，得到了积极的维护，并且有过使用它的经验。然而，它'；android仍处于测试阶段，android支持处于试验阶段，维护人员仍在警告用户不要破坏API更改。
Quill在知名品牌中很受欢迎，并由Slab正式维护，Slab是我们用于内部文档（和爱！）的维基。羽毛笔'；它的主要优势在于它的受欢迎程度、在我们的网络中的推荐以及它的稳定发布。
羽毛笔本身没有'；我们不提供任何React支持，对于我们的原型，我们使用了React quill，这是beta版中的第三方依赖项。虽然它'；目前稳定的版本是2019年发布的（目前正在努力开发新的主要版本）。
我们考虑直接使用ProseMirror（用于在web上构建富文本编辑器的工具包）而且不是一个现成的富文本编辑器。Prosemiror将'；我们已经对编辑体验进行了最大程度的控制，但我们认为使用ProseMirror工具包实现编辑器的开销太大。
对我们来说，Prosemirror是最强大的解决方案。我们不会'；我们不需要任何第三方依赖项（React集成除外），并且能够从头定义我们的文档模式。我们没有'；我不同意，因为它需要很多代码才能开始（甚至官方的ProseMirror指南也说明了这一点），而定义我们的定制模式虽然强大，但不值得付出努力，因为我们没有'；我没有很多定制要求。
我们仍然喜欢ProseMirror，这让我们找到了两个可用的React集成：ReMirror和tiptap。
我们喜欢雷米罗的很多东西。它'；它是一个ProseMirror编辑器，建立在React的基础上，并提供了涵盖我们大部分需求的扩展。
因为我们很喜欢TIPTAP，所以很难不去重新镜像，但是在2021年5月评估这两个框架时，TIPPTAP感觉有点成熟。
Tiptap为我们勾选了很多方框。该库（如ReMirror）建立在ProseMirror之上。虽然它最初是为Vue创建的，并且依赖于第三方的React包装，但它在2.0.0中获得了官方的React支持。Tiptap处于测试阶段，因此仍然有可能进行突破性的更改，而维护人员几乎每天都在更改内容。它的API是我们在原型阶段使用的所有库中最简单的一个，我们还希望在必要时可以使用原生ProseMirror代码。
与ProseMirror和ReMirror一样，tiptap通过其可用的扩展满足了我们的大部分需求，因此我们只需要实现一手完整的扩展。所有基于ProseMirror的编辑器（以及ProseMirror本身）的一个缺点是ProseMirror不是React库，因此需要在vanilla javascript和React之间架起桥梁。
库在沙盒环境中可以很好地工作，但将其与现有代码库集成可能会暴露问题。我们希望尽早发现这些问题，因此我们实施了Ashby'的初稿；s的富文本编辑器和我们最喜欢的库tiptap。
我们将初稿与通常的写作过程和技术规范配对，以梳理出更多的问题和任务。规范涵盖了动机、目标、研究，以及我们如何'；d实施新的编辑器，并在生产中进行切换。
我与团队分享了规范和实现初稿（通过拉式请求），以获得反馈。
一旦我们回答了所有问题并回复了所有评论，很明显tiptap将是满足我们需求的最佳解决方案，我们准备将其用作Ashby'；新的富文本库。
在第二部分中，我们'；我将分享我们从一个库到另一个库的迁移计划，以及我们在执行该计划并发布到生产环境中所面临的挑战。