Simplify Toolbar Configuration: Modularization and Flexibility

[makhnatkin]

1. Introduction to the Concept of Modules

Why Are Modules Necessary?

During the development and use of MarkdownEditor, there is ambiguity in terminology. The term "extension" can refer to:

• Add-ons for the WYSIWYG editor (based on ProseMirror),
• Add-ons for the Markdown markup editor module (based on CodeMirror),
• Plugins for Markdown formatting (YFM),
• Elements of the MarkdownEditor interface,
• Or something else entirely.

This ambiguity complicates support and development, increases code coupling, and makes scalability more difficult.

To address these issues, I propose the concept of modules — components that belong to the program's interface and represent its shared elements. Modules will help differentiate between internal mechanisms (ProseMirror, CodeMirror) and interface elements, providing a clearer architecture and simplifying design, implementation, and maintenance.

Differentiating the Term "Editor":

• MarkdownEditor — the main program that integrates modules, extensions, and plugins. It is a unified platform for content editing.
• WYSIWYG editor module — handles visual text editing using ProseMirror.
• Markdown markup editor module — enables text editing with Markdown formatting based on CodeMirror.

Editor Modes and Modules:

MarkdownEditor provides two operating modes:

1. WYSIWYG mode:
   Utilizes the WYSIWYG editor module and associated toolbar modules.
2. Markdown markup mode:
   Utilizes the Markdown markup editor module and associated toolbar modules.

What Modules Are Present in the Current Interface?

Editor Modules:

1. WYSIWYG editor module:
   Provides visual text editing with real-time content updates. It is based on ProseMirror and supports functional extensions via the extensions folder.

   

2. Markdown markup editor module:
   Allows direct work with Markdown formatting. It is based on CodeMirror.

   

Toolbar Modules:

1. Main toolbar in WYSIWYG mode:
   Includes basic editing tools.

   

2. Additional toolbar in WYSIWYG mode:
   Found in the three-dot menu and provides access to advanced tools.

   

3. Main toolbar in Markdown markup mode:
   Contains tools for working with Markdown formatting.

   

4. Additional toolbar in Markdown markup mode:
   Found in the three-dot menu and offers additional Markdown-specific tools.

   

5. Selection toolbar in WYSIWYG mode:
   Appears when text is selected and offers contextual actions.

   

6. Slash toolbar in WYSIWYG mode:
   Activates upon entering the / character, allowing quick block selection.

   

2. Structure of Toolbar Buttons

A toolbar button in MarkdownEditor is a universal component combining an interface element with functionality for the WYSIWYG editor and Markdown markup editor modules. It should seamlessly integrate into the program's interface while executing actions tied to the ProseMirror or CodeMirror APIs.

A button can be used in any of the toolbar modules.

Given its universal nature, I propose dividing the button into three independent parts.

Key Parts of Toolbar Buttons:

1. Appearance:

• Defined within the common area of MarkdownEditor.
• Specifies the button's visual presentation: icon, text label, and tooltip.
• Ensures a consistent design across modes.

2. Actions for the WYSIWYG editor module:

• Defined in extensions for the WYSIWYG editor.
• Dictates the button's behavior in WYSIWYG mode.
• Utilizes the ProseMirror API.

3. Actions for the Markdown markup editor module:

• Defined in Markdown markup editor configuration files.
• Specifies the button's behavior in Markdown markup mode.
• Utilizes the CodeMirror API.

3. Presets for Toolbars

In the current version, toolbar button configurations for WYSIWYG and Markdown modes are defined separately. While this provides flexibility, it also lacks transparency.

I propose making presets the single point of entry for editor configuration.

Objectives of Presets:

1. Toolbar Formation:
   Presets define the structure of toolbars, including the buttons and their order.

2. Flexible Management:
   To reduce the core editor's complexity, presets should be passed as external props. This allows users to create their own configurations and decouple the editor's functionality. Additionally, users can import and reuse one of the five predefined presets if needed.

3. Support for Default Presets:
   The editor will include five predefined presets, with three of them aligned with MarkdownIt standards:

• zero — minimal button set,
• commonmark — aligned with the CommonMark standard,
• default — basic configuration.

How It Works:

1. If a user passes a reserved preset name (zero, commonmark, default), the editor automatically applies the corresponding configuration.
2. For all other cases, a user-provided configuration object is expected.