搜了一下，好像开源免费的富文本编辑器也没几个（如果有麻烦推荐），所以 trix star 数很高，接近一万了。

不过 trix 一直不合我意的地方是回车插入 br，没有 p tag 全部是 div。要用的话得自己改了 https://github.com/basecamp/trix/issues/202

试过 trix，最后还是用了 summernote

https://github.com/ianstormtaylor/slate 认为 slate 才是心目中的完美的富文本编辑器

插入 br 才是完美，不然在 div 框里面（比如引用内容）按回车也生成一行一行的 div，很难用。

还有一个 https://quilljs.com/

一个回车用 br，两个回车应该用 p

完美！

准备加入 Rails 全家桶 https://weblog.rubyonrails.org/2018/10/30/introducing-action-text-for-rails-6/

好像有一点超出 web framework 的范畴，但是看着真不错：https://www.youtube.com/watch?v=HJZ9TnKrt7Q

看来 DHH 是铁了心要带着 Rails 在 Monolith 上一条路走到黑了🤔

相比 trix 更喜欢 quill 一些，现代富文本编辑器，不直接产出 html 或者 md 而是中间格式，这个好处很多

看了源码和调试 demo，发现两个有趣的地方：

1. Rich text 是独立一个 model，关联到原有 model 上面，类似 ActiveStorage 的设计。这是为了表很大时加速查询做的设计。
2. html 内容 post 到后端时，ActionText 会对 attachment 做处理，替换为元信息的 element，这样就可以调整渲染时的模版。

这是全栈框架才能提供的功能，有助于新建项目时快速实现富文本编辑。

我们团队正在开发中的一个项目采用的是 Slate。📝

这样看 Active Text 已经是半个 Medium 了 , 感觉上 Rails 6 將有很多好东西，

我们做文档管理平台的时候，早期正文都是存在主表里面的，后来发现那个表因为大量正文越来越大，而主表又时常因为业务调整，调整结构（加字段、调索引之类），由于表大，DDL 特别困难，后面也是将正文拆成了一个独立的 contents 表。

这样主表只有我 meta 信息，尺寸小了很多。而 contents 表结构固定，设计好以后几乎不会再调整。

另外，查询主表列表，关联查询之类不需要正文的场景也不再需要排除正文字段了。

跟 @hooopo 研究表单数据存储的时候，第一条优化这个

如果 State 不依赖 React 简直完美，那作者对富文本编辑的现状思考很多啊

之前研究过 wangeditor、ckeditor、kindeditor，一直有个问题比较困扰。我们现在的这些编辑器，运营总是对编辑器给的功能不满意。当时都是针对图片上传，图片的居左居右，行高，字体字号等一些功能，去改他们的配置和源码。感觉挺麻烦的，想请教一下大家伙，这个问题都是怎么看待的？Trix 这个我也试了一下，默认的功能很简洁，其实就我来说比较喜欢简单的风格，但是针对编辑者来说，他们提出的要求，只能去给改源码改配置吗？