After one year and two big changes in architecture design, the basic design of TBus rich text editor is basically stable so far. I decided to open source the TBus rich text editor, under the sharp eyes of various gods, can go further.

Why should I write my own rich text editor when there are so many rich text editors?

Personal too dish!!

This is not self-deprecating, as our company uses a UI component library THAT I wrote. Initially, quill was packaged as a component, but Quill didn’t support tables well and couldn’t find a suitable plug-in online. Later, I thought of UEditor, but UEditor hadn’t been updated for a long time and wasn’t friendly to the front toolchain. I also tried wangEditor, but the Angular CLI reported an error when packing… .

After experimenting with a series of rich texts, my wheelbuilding heart began to flutter again.

The first edition

So, within a few months, I wrote the first version of TBus. Like most rich text editors, based on contentEditable, after a rough prototype, they are increasingly uncertain. Mainly found in the following problems:

  • Content is not controllable, and the flexibility of HTML multiplies the complexity of rich text. So, I don’t know what kind of content will be generated when users use it.
  • The content is too dirty, a paragraph of text in bold, can be a strong, can be a strong word, can also be other tags with CSS, etc.
  • Expansion difficulties, basically add a new function, to face the problem is the whole rich text problem, it is difficult to do a good shielding of the bottom pit.

Because of the above problems, I went to the Internet, including Zhihu, to search for articles related to rich text. As far as rich text is concerned, I read all of them. At this time, I found rich text frameworks such as draft.js and Slate.js, which separate data and view. I think that’s a good way to do it. But we also see some limitations of this structure. At that time, many articles said draft. js was not friendly to tables, binding React and other performance issues.

Performance problems may be solved by optimization, but if the architecture is not friendly to complex structure support or binding to technology selection, it basically means that the application scenarios of this thing are limited.

Although I didn’t quite agree with the results of draft.js, I was inspired by its design ideas.

The second edition

Therefore, I started the research and development of the second version of TBus. This release abandons contentEditable and adopts a data-to-view architecture. And because I had considered complex data structures like tables from the beginning, the results were pretty much as expected.

The second edition addresses the following issues:

  • Content is controlled, and because you’re manipulating data, everything the user does is actually hijacked.
  • The content is not dirty, which is the highlight of TBus so far. In TBus, if you bold a paragraph of text, there must be only one strong tag, and there will not be multiple strong parallel situations.
  • Scaling is relatively easy, as long as the data is processed properly, TBus will automatically render and generate the most concise content.

At this point, the general rich text editor is about enough, but I still found some problems:

  1. How do you make sure ul is li?
  2. How to ensure that tbody is under table and tr is under tbody?

If I want to fix a structure, no matter what the user does, it doesn’t affect the stability of that structure, right?

How do you make sure that only one part of your content is editable and the other part is not?

This needs to be designed so that, ideally, this part of the data is not visible to the editing operation.

The third edition

The third edition, the current edition. TBus abstracts rich text into two parts, Fragment and Template.

Fragment is used to store editable Fragment data.

Template is used to hold data that cannot be edited or fixed.

Based on the above design, it is easy to extend the functionality of TBus, and you can even easily customize your own templates, allowing TBus to support a wide variety of formats, rather than being limited to the common typesetting style of the browser. If you have to summarize the highlights of TBus, I think there are the following points.

  • The output is clean, with no redundant labels and styles
  • Support code real-time highlighting
  • Support table box selection operation, batch formatting, split, merge and so on
  • Drag pictures and videos to zoom in and out
  • Supports custom templates, which can be extended to any format
  • Typescript development, all features are plug-in, easy to customize and extend

The demo address of TBus is posted below. If you think it is still very good, you can also click a star on Github to show your encouragement.

www.tanboui.com/tbus/home

By the way, a follow-up:

  • Fixed various bugs
  • Optimize diff algorithm to make it more efficient
  • Optimize the template extension to make it as automatic as possible
  • Develop more quality templates for regular use
  • Perfect documentation for easy understanding
  • Improve unit testing so that TBus can grow stronger