TOAST UI Editor 3.0 RoadMap

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.

[js87zz]

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