The V5 version of wangEditor is still in public beta, and you can view documentation, demo, or submit issues. The V5 is expected to be released in spring 2022.

background

For the last two weeks or so, I’ve been working on the wangEditor “echo HTML” feature, which initializes content with HTML when you create the editor. JSON support, HTML support (including V4).

const editor = createEditor({
  selector: '#editor-container'.// content: [...] .
  html: '
hello  world
'.// Select either 'content' (JSON format) or 'HTML' (HTML format)
})
Copy the code

Previously, V5 initialized content only supported JSON format, not HTML format. This caused a lot of confusion for users

  • Often, you need to store BOTH JSON and HTML, resulting in data redundancy
  • You cannot upgrade V4 to V5 because V4 is entirely HTML-based

I wrote a long document detailing how to get content, how to store it, how to convert it… — It’s trouble for me to write and trouble for everyone to read. Everything that needs to be explained is not beautiful. Beauty is simple by nature. It never needs explanation. So when I supported HTML, I deleted that smelly, long document.

Once the “echo HTML” is done, the rendering logic of wangEditor is almost closed loop, so take the opportunity to summarize. Not just this “echo HTML”, but a summary of wangEditor’s entire rendering logic.

Why did you stick with JSON?

In fact, support for HTML has been requested from users since V5’s public testing. Before, I always refused, but then more people proposed, I slowly realized the importance of this matter.

There are two main reasons I have rejected HTML in the past.

Slate. js is only in JSON format

WangEditor V5 is developed based on slate.js kernel. The input and output data of slate.js is always in JSON format, not HTML format. So, for that reason, I’ve always stuck with JSON.

However, it slowly became clear to me that slate.js works in JSON format because it relies entirely on the React framework to render pages using React. React itself is a framework for “data-driven views”, so it makes sense that Slate.js provides JSON data to React to render views.

While wangEditor is based on slate.js as its core, it is not based on any framework such as Vue React. Since there is no framework requirement, you need to think about the rendering logic yourself, which is HTML.

The HTML format is too flexible to support fully

Rich text editor itself is a highly complex software, which requires its internal data structure to be simplified, standardized, unified, and can not be messed with.

Unfortunately, HTML is a byword for “messed up.” For example, if I want to write a text hello in bold, I can write it in an infinite number of ways, please notice:

<b>hello</b>
<strong>hello</strong>
<span style="font-weight: bold;">hello</span>
<span><b>hello</b></span>
<p style="font-weight: bold;"><span>hello</span></p>
<div><strong>hello</strong></div>
<! -... There's more... -->
Copy the code

If the editor allows the user to enter HTML (and since it is user input, there is no control over the format of the input), should it support all of these formats? B: The cost is too high. Also, this is a rich text editor, with selection, style changes, etc. In short, once the data structures are complex, combined with the complexity of the rich text editor itself, it is unimaginable.

Using JSON format is easy, I can define the JSON format specification, make a DSL. JSON is defined and people don’t want to change it because they don’t necessarily understand all the rules of DSL. But HTML is not easy to say, users will use HTML, maybe arbitrarily change the source code, add a little style, what is not good control.

However, HTML support was imperative, so I thought about this for a long time and came up with an imperfect but workable solution: HTML only supports the wangEditor output format (including V4 and V5), and the rest is guaranteed. I also highlighted it in the document

JSON data, what is it

JSON data is the editor’s Model. You can think of the editor as a black box, with HTML input and output, but JSON data in a specified format.

For example, for a normal line of text, HTML and JSON would look like this:

The models of modern rich text editors are based on a DSL, not directly on HTML. The HTML format is too flexible to control, while your own DSL is completely controllable.

Render Model to editor

Inside the editor, the Model (i.e., JSON data) needs to be rendered in real time into the editor View, rendering the Model as a View. And different components are rendered to different DOM types, such as

Data-driven views are the same as Vue React, so we did a similar design: first, we converted the Model to vDOM; Second, patch the VDOM into the real DOM (using snabbdom.js). In contrast, the Model here is equivalent to data in Vue and state in React.

However, consider that each component is rendered to a different DOM type, so you need to have each module register its own Render function and Render it uniformly. If you’re developing third-party components, you’ll need to use these Render functions as well, see the documentation.

The Model generates HTML

The editor Model generates and outputs HTML, and different components need to generate different HTML formats. It also requires each module to register its own toHtml function, and then generate HTML uniformly. If you are developing third-party components, you will need to use these toHtml functions as well, refer to the documentation.

Convert HTML to Model

User input HTML is converted to Model (JSON data), and different components need to generate different JSON formats. It also requires each module to register its own parseHtml function, and then generate the Model uniformly. If you want to develop third-party components, you will also need to use these parseHtml functions, refer to the documentation.

conclusion

Up to now, the relationship between Model DOM AND HTML has been basically clarified. The overall logic is shown as follows:

Finally, any questions about the use of wangEditor V5 are welcome to submit an issue.