Authors: BEF Team + Wang Fupeng

Last week, we had the pleasure of welcoming wang fupeng, the author of wangEditor. Talk to us about some of the problems we’ve encountered in the process of developing the editor. It also answers questions about some of our recent research. The following is a summary of all the questions at the conference.

Question 1

For SLATE, do you currently recognize any converters/plug-ins for DOCX

Four points: Among the closed issues of V4 version, there are the most problems about pasting. No third party has been found that can recognize Word or copy directly from the web, because it is difficult to guarantee the effect of pasted documents.

So what I would suggest is that you enumerate the scenes that you really need to do, and then leave the rest behind, or you can do it slowly. If you want to find a doc or a web page and paste it, you can’t. Word paste, you also have to find a scene, such as a title, a text, or say a picture, or say a table in Word, or a picture inserted into a picture, these requirements have to be refined. Therefore, this requirement should be a use case first, test-driven development approach is more reliable. If you write the code first, it’s probably going to get messy. Test driven development, do a separate module, and then write a single test. Because if you make any changes, it could get messy. The paste, conversion module, function, out with a single test run, is very good.

So the conclusion of this problem is: 1. Paste can not meet all needs. Test first, use case first, scenario first.

Question 2

Does the SLATE editor have lazy rendering function? When there are too many JSON nodes (such as the red Mansions), does the page have performance problems? Is there a solution?

Four points: I have a demo here that I can take a look at. The latest version of my editor has a big file, and it’s 100,000 words long. 100,000 or so is fine, but if you want to do something else, like select all, like undo, select all and then undo, you’re going to get some lag, which is a lot of word processing, you’re going to get lag. This problem, should worry about the rendering part of the ability. As the SLATE kernel itself, it doesn’t include rendering itself. I wrote my own rendering scheme, which is definitely not as good as react.

Tens of thousands of words, tens of thousands of words, even to the level of tens of thousands of words are no problem. This is my feeling, but I can’t guarantee it, because the operations are also not enumerable, and the normal input operation is not the same as the operation after the direct mass selection.

Question 3

What attributes are supported by the Paragraph node in wangEditorV5? TextAlign /lineHeight is supported in the d.ts file, but the textAlign/lineHeight is supported in the d.ts file.

The definition of paragraph in the source code

export type ParagraphElement = {
type: 'paragraph'
children: Text[]
}
Copy the code

Four Points: That’s a detail. The text alignment of the Paragraph node, and the line height, it’s a separate thing. Because of the line height of this text, it doesn’t just apply to paragraph, it might also use headings, it might also use cells in a table. So you can’t define it in a paragraph, and if you do, the other elements in a paragraph have to be redefined, so they are defined separately. The source code is here. As you can see, there are basic Models in the source code, there are a lot of models, models actually have line-height. This custom type is defined by itself. Any element can have a line-height attribute. [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] [img] Not runtime constraints. So, as long as we don’t do line-height in paragraph, we don’t have to do it. But when we’re at runtime, we can stuff all kinds of properties into it, because runtime doesn’t limit you. Like titles, quotes, tables… , can extend the line-height attribute. All modules are defined in custom types.ts. Things like text alignment are in the upper justify directory. Finally, all custom types are aggregated under the Package. Under the package directory, there is a custom types.d.ts. You can see all the definitions.

Question 4

Can SLATE support the input component of ANTD and support the interface in ANTD?

Four Points: Yes. API must support, are JS code, why not support his API? There is just one catch: if you render input box components like textarea in the editor, you need to strictly consider or validate focus. For example, if you click on text and focus on the editor, but click on input, is the editor in focus or out of focus? You have to define that for yourself. I’m going to show you an example here, which is a video plus an input field

Question 5

Compared with draftJS and other similar competitors, is SLATE editor stable and can meet the needs of word editor? (Background: The SLATE editor has less than 1W lines of code.)

Four points: There should be no problem with stability. SLATE is divided into three packages, one core package. The second is the stability package, and the third is the factory package. WangEditor uses the SLATE kernel. Second, react’s view layer. So said. Its stability is not a problem, and it is relatively featureless, the view layer does not do much. Can basically meet the needs of word class. But you’re going to have to do a lot of defining yourself in the view layer, you’re going to have to write a lot of extension features in the view layer, like text mash-ups, like the ability to do something like a block editor.

SLATE has been in production since 2018, with an update in between. Version 0.50 is more user-friendly and better. We have seen SLATE’s test cases, and they are written more fully. Overall, there is no problem with stability. Of course, it guarantees basic functionality and scalability. But there’s no guarantee he’ll have everything. His advantage is that SLATE is an up-and-comer, combining the best of his predecessors. Then his data model is relatively clear, the source code is not much. Less source code is a good thing, less source code, it is very convenient to continue to expand above, good controllability. There is really what problem, you change the source code on the line, more streamlined. It’s not as big and expensive as Prose Mirror. I chose SLATE as the kernel because it is a classic kernel and I haven’t found any bugs with it yet.

Question 6

During the development process, did you encounter a particularly big hole?

Fopeng: What impressed me most was pinyin. Because foreigners do not have pinyin, there is no problem entering letters and numbers, but once entering pinyin, there are all the problems. For example, the conflict between pinyin and the electoral district, such as all input pinyin, such as all delete after the input pinyin and so on these scenes, anyway, our pinyin that part of the code, is also written quite messy. I can send you the source code. I have done a function, is the maximum length of Max length problem. Because pinyin card for a long time. The Max length is easy to judge if you enter alphanumeric characters. But once you type in pinyin, it’s hard to tell. And after interception, there may also be truncated Chinese characters.

In addition to the pinyin pit, there is a pit, is recently we use wangEditorV5 latest version, feedback is more, such as: we create an editor, and then edit write content, write content save, it must be a Json structure. When we compile again, we return the JSON structure, display it in the editor, and edit it again. However, as for the users of my previous version, they saved HTML structure, which was edited by HTML structure in the previous version. Therefore, they asked me whether I could transfer my HTML structure to your new editor for editing. I did not dare to allow them to do so, and now I do not support it.

A lot of editors, what is the impression that it gives to the user? His demo allows you to enter HTML for initialization. But if you think about it, 100% HTML is definitely not possible. For example, bold, using HTML and CSS, can be written in at least 5 different ways. 100% echo to editor is definitely not possible. If the requirement is to insert HTML, I can consider providing a dangerous insert interface later. This allows the user to insert some general tags, but does not guarantee that all tags will be recognized. Regardless of whether I use SLATE or draftJS, it should be the same, but I have to stick to the bottom line that my stored data must be JSON data. But if the data store is in JSON format, what happens when you render it? Yeah, when you render, the browser doesn’t recognize JSON, so if you turn JSON into HTML, when does HTML render? Is the stored JSON downloaded from the server and rendered in the front end? That can be very troublesome. Why is it a hassle? Because the first rendering takes time and the second rendering is based on the same editor, the editor can be quite bulky. Now wangEditer is packed and compressed to hundreds of kilobytes. So, if the front-end rendering, the cost is relatively high. If you want to convert json to HTML on the server rendering side, you need at least Node to do the stack, and if you use Java, you need to develop the conversion logic. And as the transformation logic expands, there are more and more different types of components. What’s another way to do it? When editing in the editor, save directly to save two sets of data, one is JSON, one is HTML. But then there’s the problem of data redundancy. I have written about this in the V5 version of the article, which is the same as what I said, you can go to have a look.

Another scenario that you need to think about ahead of time is if I edit a document and then publish or share it. The content I share is plain text with no editing function. Do you still need to load the editor?

Question 7

Wangeditor-v5 is based on SLATE, what are the key optimizations?

Not really optimization. My kernel is based on SLATE, but I wrote the view layer myself, so REACT, Vue, and jquery are supported. Take a look at the architecture diagram using the MVC pattern (see figure below). I also have a few summaries of my nuggets

Question 8

Wangeditor-v5 online collaboration, is there a mature solution?

Four points: I haven’t done online collaboration yet. I might try it next year. There are a number of technical solutions on the market that can be implemented. A few people recommended Prose Mirror for a better solution. SLATE’s solution is demo level. But from SLATE’s atomic opration, there is no problem in theory.

If you have people who need to co-edit, do it from the beginning, and think about it every time you design. For example, if you make A table, you can’t just change it randomly and cover all of B’s table. Or you could just change it and delete the number. Try to change properties, not delete them. Next year I plan to do cell merge, I was thinking, should we do cell merge first, or first run the collaborative edit demo, and then take a merge function, because the implementation of collaborative, may find that the previous cell merge is not good, and then overturn and redo, it will be troublesome. General color modification, input text, are not a big problem. Once you have forms, cells, complex content, and collaborative editing, it’s very risky.

Question 9

WangEditor’s render layer is self-implemented, would you like us to encapsulate it in your editor? Or is it better to write your own view layer?

Four Points: wangEditor is no longer recommended if you have the manpower to do your own research and the requirements are complex. Because you are not making a small editor, you have a lot of needs for what you want to make. If you use my editor, you may make four different things. There was a collection of plugins for SLATE, so take a look. He implemented some of the more basic functions, such as links, lists, tables, paragraphs, and sections. If you have a need for customization, build your own SLATE.

Question 10

Why did I choose Vue’s diff algorithm for the diff part?

Fopeng: BECAUSE I have only studied SNabbDOM, I am familiar with it. It has a large audience and has been verified by VUE2. Snabbdom is third-party, independent, and can be used any way.

Question 11

Have you had any experience with wangEditor’s support for forms? Is there a ready-made component library on the market?

Four Points: Your requirements sound very much like a block compiler. This is one of the most popular block editor repositories right now. The idea is that you can customize a block, and a block can be thought of as a component; A rich text content; A form content. And then you can drag and drop between the blocks, you can set them up, like 2/3 on the left, 1/3 on the right.

Q: Our requirements are almost always custom forms, meaning that users can define the components, format, and content of the presentation. Therefore, based on the cost, I would like to consider directly using the components on the market.

Fopeng: Component libraries, on the other hand, are customizing forms. How to integrate them with the editor is the difficulty. My advice is to insert form types in the traditional editor way if the requirements are not clear at first. Is typesetting some freedom, let the user do, want to enter enter, want a line. If later requirements are clarified and you have a fixed form component or template, you can consider making a web editor. Like I did before, generate some polls, games, things like that.

Question 12

The span node itself has no structural attributes. Its attributes are set for the text inside the SPAN. However, in order to preserve the style, we must create a paragraph block. Do we have a non-Paragraph block code structure, or do we have to manually implement a new type block definition that does not break lines?

Ffour: Why convert a paragraph from a node that should be converted to a text?

A: Because a span might have a span inside it, the HTML might be messy.

Of course, my idea is more general and simple, that is, I will analyze the labels THAT I can recognize through attributes, and then what to do. The labels that I can’t recognize, I will process them in plain text.

In the span tag example you used, you can set a standard for what structure your editor should produce, and do the basic processing according to that standard. For example, what structure should your HTML output in your editor look like, and then you invert it. You don’t have to deal with anything else. With 400 tags, it’s as semantic as possible. The idea should be divided into two layers, first do a bottom, and then do a layer is icing on the cake.

Question 13

After doing this project, do you have any design patterns, including architecture, that you can share

Four points: Go see my nuggets. It’s got a lot on it.

Then, I will show you a core interface, and the last interface is the definition of all modules. I have four parts right now. The first part is menu registration. It’s the menu at the top of my editor. The second part is to render the model, which is to render the Json into the virtual DOM inside the edit area. The third part is to HTML, so I can get json, and I can get HTML. Part iv of SLATE plugin registration. I’ll probably do an extension next month to convert the source code to Json via HTML.

One last question

Long-term plans for the future?

Four Points: I’ve considered the idea of going commercial, but it’s a step by step. 1 is the current situation in China. My energy is also limited. There’s a lot of demand, so take your time. I hope to make an open source, free and good editor in the next one or two years, so that everyone can use it comfortably and conveniently. That’s my goal.