Tui.editor: TOAST UI Editor 3.0 RoadMap

[js87zz]

Introduction

TOAST UI Editor is planning a v3 major update for 2021.

The v2 major update happened at the beginning of this year, and in this release, we developed the ToastMark and replaced the parser in order to address the issues that occurred with the Markdown editor. The typical issues one faces with a Markdown editors including Syntax Highlighting, Live Preview Sync, Toolbar button synchronization, and more have been resolved, but we realized that the 'Custom Syntax' that we set out to support with versions after v2 has a variety of restrictions in development under the current structure. Upon numerous prototyping, we decided to replace the core module that we have been using for TOAST UI Editor, and the v3 major update will revolve around this change. The main tasks with the v3 are as follow.

Changing the Core Editor Module (with ProseMirror)

Currently, we are using CodeMirror for the Markdown editor and Squire for the WYSIWYG editor as respective dependencies. Since the two editors are completely different in structure to begin with, it was difficult using a common abstract class or method. Furthermore, when we used the converter to transform data to share between two editors, it required an excess of convoluted pre/post processing code. Especially, the WYSIWYG editor called for a large amount of pre/post processing code for the DOM manipulation and it also created more issues with internal code management and testing. In order to address this issue, we attempted introducing an editor with an abstract model. The main goal was creating a common core editor that can unify the Markdown editor with the WYSIWYG editor in terms of model, API, and the plugin structure. While the internal processing logic will be different because of the intrinsic difference between the Markdown editor and the WYSIWYG editor, it will be easier to maintain and to read the source because we can carry the common structure internally.

Through research and prototyping we decided that ProseMirror would be the right choice to bring the aforementioned benefits as a core editor. The reason is as follows.

• Model Abstraction: ProseMirror maintains the edit contents as an abstract model. This model can be used to make selections, contents edit and control, and command processing easier. Especially, a significant bulk of DOM manipulation pre/post processing code can be made obsolete using these abstractions.
• Schema Customizing: The ProseMirror provides an option that allows users to define the schema that is used to construct the model abstraction. We can use this option to define and manage schemas that is appropriate for Markdown and WYSIWYG editors.

Plugin Improvement

One of the goals that we set when deciding to use ProseMirror was plugin improvement. The current method of creating plugins by accessing the editor's internal properties or by directly manipulating DOM complicates the code and creates high level of coupling between the editor and the plugin. However, if there is an abstract model, we can simply this problem. Being able to define the format of the plugin according to a specified specs and applying the parsing logic in the editor can open a whole new world of possibilities. To take it even further, we will be able to support not only the commonmark specs but also the Markdown custom syntax by extending the plugin system. While this plan has no concrete specifications, we plan on solidifying the idea by improving the toastMark parser and unifying the internal editor models.

Dependency Removal and Feature Enhancement

Uniting the Markdown editor and the WYSIWYG editor core modules brings even more benefits. Codemirror and Squire dependencies that have been used in both of the editors can be removed along with its dependent codes. Removing the dependent codes allows us to be able to pass around a uniform structure, and it significantly benefits code maintenance. Lastly, we plan on improving features of the editor where it always suffered. We plan on making the custom toolbar and the options and APIs regarding command processing more user-friendly, especially. If we can make the internal commands or the APIs more readily accessible by the users, the custom commands and user defined toolbars will see an increase in versatility. Furthermore, the customization will be enhanced. There have been periodic inquiries about customizing the Editor UI, but under the current structure, it is difficult because the user would have to build an implementation like defaultUI or maintain it themselves. With v3.0, we intend to provide Editor's content editing area completely separate from the other UI, which will enable the users who just want the content editing area to adopt the feature into whatever UI the user wants.

Closing Remarks

Aside from the aforementioned features, v3.0 will change everything include internal structures and test codes. The changes are tracked in the PR or in the next branch. If you have any other feature suggestion or possible improvements, please let us know in the comments section.

[ats1999]

Please bring the nextJs support for at least _Viewer_ component.

[jack9603301]

Looking forward to preparing for major version upgrades at any time

[taurenshaman]

I hope there will be some plan about Attributes:
e.g. 45
e.g. 46

[codingcn]

Looking forward to v3!

[jack9603301]

Looking forward to v3!

[bdevg]

Is there any plan to support SSR?

[l5jh]

Is TOC directory supported

[ats1999]

Is TOC directory supported

TOC ??

[jack9603301]

Is TOC directory supported

TOC ??

Is the meaning of the article directory system

Table Of Contents

[ats1999]

Is TOC directory supported

TOC ??

Is the meaning of the article directory system

Table Of Contents

This would be a good feature.

[jack9603301]

Is TOC directory supported

TOC ??

Is the meaning of the article directory system
Table Of Contents

This would be a good feature.

This feature should be optional, and it has the style and ability to let users specify the location. Otherwise, when it matches the main style of the website, there will be problems, especially when I combine it with wordpress (wordpress has other TOC plugin)

[ats1999]

Is TOC directory supported

TOC ??

Is the meaning of the article directory system
Table Of Contents

This would be a good feature.

This feature should be optional, and it has the style and ability to let users specify the location. Otherwise, when it matches the main style of the website, there will be problems, especially when I combine it with wordpress (wordpress has other TOC plugin)

Right!

Does anyone know, SSR(server side rendering) will be supported or not (Viewer)?

This would be a great improvement.

[jack9603301]

The server usually runs in php, not js. Generally speaking, the server is suitable for pre-rendering markdown (displaying the rendering result of the lowest result), and the browser front end is suitable for full-function rendering

The rendering of markdown should not happen when editing, but when rendering

This is also a way to enhance compatibility. WP-ReliableMD only saves raw markdown data in the database

[ats1999]

The server usually runs in php, not js. Generally speaking, the server is suitable for pre-rendering markdown (displaying the rendering result of the lowest result), and the browser front end is suitable for full-function rendering

The rendering of markdown should not happen when editing, but when rendering

That's way i mentioned (Viewer).
I'm not talking about CDN version of this editor. When we use react or nextjs, then this creates problem in server side rendering.

If we remove browser dependency,like window object, etc. Then this will automatically rendered on server in nextjs or reactjs, or any other js framework..

[jack9603301]

The server usually runs in php, not js. Generally speaking, the server is suitable for pre-rendering markdown (displaying the rendering result of the lowest result), and the browser front end is suitable for full-function rendering
The rendering of markdown should not happen when editing, but when rendering

That's way i mentioned (Viewer).
I'm not talking about CDN version of this editor. When we use react or nextjs, then this creates problem in server side rendering.

If we remove browser dependency,like window object, etc. Then this will automatically rendered on server in nextjs or reactjs, or any other js framework..

I don't understand what you mean, isn't js running in the browser? Unless using server-side js technology (such as nodejs)

[ats1999]

The server usually runs in php, not js. Generally speaking, the server is suitable for pre-rendering markdown (displaying the rendering result of the lowest result), and the browser front end is suitable for full-function rendering
The rendering of markdown should not happen when editing, but when rendering

That's way i mentioned (Viewer).
I'm not talking about CDN version of this editor. When we use react or nextjs, then this creates problem in server side rendering.
If we remove browser dependency,like window object, etc. Then this will automatically rendered on server in nextjs or reactjs, or any other js framework..

I don't understand what you mean, isn't js running in the browser? Unless using server-side js technology (such as nodejs)

Yeah, i am talking about NodeJs.

See, https://github.com/nhn/tui.editor/issues/1222 https://github.com/nhn/tui.editor/issues/875 https://github.com/nhn/tui.editor/issues/95 https://github.com/nhn/tui.editor/issues/1222

[jack9603301]

Oh thanks

[ats1999]

Oh thanks

Is there any plan to support SSR?

[bdevg]

Oh thanks
is SSR will be supported in next version?

[seonim-ryu]

@ats1999 @jack9603301 This article was not registered for discussion. If you have a feature you want in 3.0 and want to talk in detail or request a feature, please register a new issue and post the issue as a related link in the comments here.

[bdevg]

I hope, there will be any plan to support SSR https://github.com/nhn/tui.editor/issues/1323

[EgoistDeveloper]

My suggestions

• Popup backdrop or blur and then disable other buttons until to popup closing or focusout.
• Optional popup tabs. Sometimes there is no need file upload tab, I want show only other tab.
• Extendable editor. Like textarea grip. This option useful for user experience.

[likunyan]

Dark Mode?

[msegmx]

ES2015 standard?

[kimdj2]

I wish I could change the code block to dark mode.

[Tiberiusss]

Hello! I really like the editor, but it lacks some features and fixes that are expected with the release of version 3. Could you give an approximate date when the release is expected?

[js87zz]

@Tiberiusss
Although the schedule has been delayed a little, it aims to be released within the first half of the year!

[Tiberiusss]

Thx for answer!)

[stfenjobs]

hi there

now time is 2021-05-14

very hope v3

[gaoxinke88888888]

hi there

now time is 2021-05-17
very hope v3

[js87zz]

@stfenjobs @gaoxinke88888888
Alpha versions will be released before June. Please wait a little longer!

[stfenjobs]

@js87zz

thank you very much

[ats1999]

@js87zz Which feature are going to be released in the Alpha versions?

[shyr]

Is there any plan to support it on mobile?

[codingcn]

How to migrate V2 to v3.0.0-alpha.0?

I see that the V3 update has been pushed

https://www.npmjs.com/package/@toast-ui/editor

[stfenjobs]

good job , where is v3 document ?

[js87zz]

The new alpha version has finally been released. Simple information can be obtained from this issue. No documentation of migration guides or features has been made yet. However, it will be added by working on it sequentially.

[jack9603301]

When will v3 be released?