文档

原理

很多用户可能对现在比较流行的文档以及编辑器技术不太了解。

当前比较主流的做法是，用 Json 描述一篇文档。可以这样描述：

{
  "documentName": "测试文档",
  "blocks": [
    {
      "type": "h1",
      "content": "这是标题"
    },
    {
      "type": "paragraph",
      "content": "这是段落"
    }
  ]
}

然后编辑器，在拿到了上面描述文档的Json之后，就可以将其渲染成这样的结果:

<div>
    <h1>这是标题</h1>
    <p>这是段落</p>
</div>

这就是当前比较流行的编辑器，或者文档技术的本质。业内将其成为 基于 块 的设计。

Gable 的尝试

如果我们基于上面的理论，多做一点设计，比如设计一个这样的 Json:

{
  "documentName": "测试文档",
  "blocks": [
    {
      "type": "http",
      "content": {
        "define": {
          "method": "GET",
          "protocol": "https",
          "host": ["www", "gable", "org"]
        }
      }
    }
  ]
}

我们要求，文档编辑器（或者文档渲染引擎）在拿到 type 值为 http 的 块时，把界面渲染成这样的效果:

注意

这个尝试非常重要，它让我们的文档发生了本质的变化。

原本文档只是传播信息的媒介。而如果我们把执行API测试这样的工具面板放进文档之后

文档就变成了可以提供了服务的工具。

但是这样做不是没有副作用的，因为这样复杂的界面是无法打印到纸张上的。

但是从文档协同的角度来说，这也是值得的。

Gable 是怎么做的

我们使用一个开源的库 editor.js (opens new window)

然后，我们把 我们的 Http 执行面板打包成了 WebComponent, 最后使用 editor.js (opens new window)

渲染html节点。

效果图：

商业畅想

做出一款好用的文档编辑器，是需要实力大量精力的。

我们做的是 API 协作工具，而不是文档系统和编辑器。

直觉告诉我，我应该开放一套 API UI，然后，让市场上的各大文档产品，集成兼容我们Gable。

Gable单纯负责执行API,如何优雅的渲染文档，交给专业的文档产品会不会是一个更好的选择呢？

这样做的一个优点是，我们可以把精力放在其它协作上，而不用担心文档的功能没有做好而被动。

同时，专业的文档产品的集成，可以帮助我们Gable走的更快。

对于此，有见解的人可以与我交流。