文中所有
https://prosemirror.xheldon.com的链接均可换成https://prosemirror.net的链接以查看原文中的原始引用。
两年前，我启动了 ProseMirror 项目，因为我想尝试[一种更好](/tech/ProseMirror.html)的所见即所得式的编辑方法。今天，我发布了该库的 1.0 版本。项目的架构和它的内部实现在其生命周期中发生了相当大的变化，但我觉得最初的目标已经实现了。
ProseMirror 是一个 Web UI 库，尽管它所解决的一些挑战是针对 Web 平台的优势和（特别是）弱点的，但不要把它看成是另一个 TinyMCE 的替代品。相反，它是一种更通用的富文本编辑方式，而恰好是在浏览器上用 JavaScript 实现的（意即你可以根据该库的逻辑翻译成其他语言版本的富文本编辑器，如 OC 版本等—译者注）。
基于 Scheme 约束的编辑
ProseMirror 中最重要的是，其与实际的文档内容无关，这使得在这个库的基础上建立应用程序成为可能，而在过去，这需要一个完全自定义的编辑器实现。
我所说的与文档内容无关是指 ProseMirror 的 Scheme 约束功能。核心编辑器对文档的具体内容不做任何要求，而是看一段可配置的数据（scheme）来确定允许什么样的内容以及它组成什么样的结构。ProseMirror 将精确地与您所需要的自定义语义文档格式一起工作，同时仍然给您提供用户习惯的所见即所得的编辑风格。
例如，一个科学写作应用可以使用一个包括章节、脚注和参考文献的 scheme—两个这样的应用，SciFlow 和 Fidus Writer 已经建立在 ProseMirror 之上。或者一个新闻机构可以建立一个反映其内容模型的 scheme，为记者提供一个可以写作的编辑器。例如，《纽约时报》正在其 CMS 中使用 ProseMirror。或者，如果你的公司有一些不同的内容模型的编辑器，使用 ProseMirror 与不同的 scheme 可以使你的编辑器代码更容易统一。Atlassian 正在他们的产品中推广 ProseMirror，从 wiki 到 bug 追踪器到源码托管。
协作
对[协作编辑](/tech/Collaborative-Editing-in-ProseMirror.html)的支持从一开始就是 ProseMirror 的一个重点。该系统的几个方面，如文档更新的表现方式，或撤销历史模块的工作方式，都受到了协作编辑需求的强烈影响。我已经确信，这不是一个你可以在现有编辑器上扩展出来的功能。
幸运的是，这些限制并没有把设计逼到一个不舒服的角落，而是帮助推动它向一个普遍有益的方向发展。其他几个棘手的功能，如变化跟踪和回滚过去的变化的能力，都是由于协作编辑相关的设计决定而得以实现的。
事务性的状态更新
试图将协作编辑的要求与一个功能性的单向数据流架构结合起来，导致了我们的设计，其中编辑器，而不是单方面更新其状态，而是发出事务。一个事务可以用来计算一个新的状态，用它来更新编辑器。
这使得如果你想的话，几乎可以在你的应用程序的数据流循环中无缝集成编辑器。此外，将更新作为第一类值使得保持外部状态与编辑器同步变得更加容易，这使得新的、强大的扩展类型成为可能。
总结
经过多年的疯狂实验和不断变化，从 1.0 版本开始，我们的目标是稳定。核心模块将尽可能长时间地停留在 1.x 上，这意味着新版本不需要你改变你的代码。有一个 RFC 进度，我们会用它来获取社区对新功能的反馈。
如果你正在寻找一个简单的插件式富文本编辑器组件，ProseMirror 可能不是你需要的东西。(我们确实希望这样的组件能够用 ProseMirror 构建)。这个库是为要求高的、高度集成的用例而优化的，以简单为代价。但是，如果你的应用程序正在挑战所见即所得编辑器的极限，那么可以考虑使用一下。
博主说：
我常常希望在面对人生中一些关键抉择的时候，有人可以告诉我最佳的做法，让我不至于白白浪费宝贵的时间。推己及人，我因此经常写博客，以期在浩渺无垠的互联网中的这个小小角落里记录下对于我来说只有一次的人生经历，希望能够帮到那些希望得到帮助的人。
