Markdown editor and operation method thereof, electronic equipment and storage medium
By configuring the Markdown editor for the modal window component and the file upload component, efficient batch image uploads were achieved, solving the problem of low efficiency in existing technologies and improving upload efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SUZHOU DIGITAL SOFT CLOUD TECH CO LTD
- Filing Date
- 2026-03-27
- Publication Date
- 2026-04-24
AI Technical Summary
Existing Markdown editors are inefficient when uploading images in batches, requiring users to perform a lot of repetitive operations.
This document provides a Markdown editor with a modal window component and a file upload component. It supports batch upload of images by dragging/selecting images, uploads images to the backend storage interface through a custom upload request, and integrates frontend form components and Markdown editor components, synchronously loading metadata and historical content returned from the backend.
It enables batch uploading of large numbers of image files, improving upload efficiency and eliminating the need for numerous repetitive operations.
Smart Images

Figure CN121920331A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of front-end development technology, and more specifically, to a Markdown editor and its operation method, an electronic device and a storage medium. Background Technology
[0002] Markdown is a lightweight markup language designed by John Gruber in 2004. Its core purpose is to quickly achieve basic text formatting using a concise, easy-to-read, and easy-to-write plain text syntax, eliminating the need for cumbersome mouse clicks required by rich text editors like Word. Furthermore, its plain text format is cross-platform, easy to store, and easy to convert, and can be easily rendered into various formats such as HTML, PDF, and ebooks. With the development of web technologies, web-based Markdown editors, due to their concise syntax and ease of reading and writing, are widely used in scenarios such as business case writing and technical document creation.
[0003] However, existing Markdown editors such as Editor.md and react-markdown-editor-lite only provide a basic image upload entry. Users need to manually complete the process of selecting an image, uploading it individually, copying the returned address, and pasting it into the editing area. This can meet the requirements when uploading a small number of images, but when batch uploading is required, a lot of repetitive operations are required, resulting in low upload efficiency. Summary of the Invention
[0004] In view of this, this application provides a Markdown editor and its operation method, an electronic device and a storage medium for improving the efficiency of batch uploading a large number of images.
[0005] To achieve the above objectives, the following solution is proposed:
[0006] A Markdown editor for use on electronic devices, the Markdown editor including an editing module and a display module, wherein:
[0007] The editing module is configured with a modal window component and a file upload component, providing a batch upload entry for dragging / selecting images. It is used to receive multiple image files selected by the user and upload the images to the backend storage interface through a custom upload request. It is also used to integrate the frontend form component and the Markdown editor component, and synchronously load the metadata and historical content returned by the backend.
[0008] The display module is used to listen for click events on directory items to trigger smooth scrolling of anchor points, obtain the scroll wheel offset, and render content that is from the same source as the editing module.
[0009] Optionally, the editing module includes a batch image upload unit, a metadata-content linkage unit, and an editing-end custom rendering unit, wherein:
[0010] The batch image upload unit is configured with a modal window component and a file upload component, which provides a drag-and-drop / selection dual-mode batch upload entry, responds to the user's custom upload request and asynchronously submits the image to the backend, updates the file status in real time and displays it visually, and automatically generates a preset style of Markdown image syntax after successful upload and inserts it into the editing area in batches;
[0011] The metadata-content linkage unit is used to integrate form components and Markdown editor components to achieve synchronous management of metadata and content;
[0012] The custom rendering unit in the editing end is used to bind the title text as a unique anchor point to the title element to ensure the uniqueness of the identifier.
[0013] Optionally, the batch image upload unit includes a file format verification subunit, wherein:
[0014] The file format verification subunit is used to verify the format of files uploaded by users, and only allows image files with preset formats to be uploaded.
[0015] Optionally, the metadata-content linkage unit includes a thumbnail upload subunit, wherein:
[0016] The thumbnail upload subunit is used to provide a separate thumbnail upload entry, and automatically updates the thumbnail path field of the form component after the thumbnail is successfully uploaded, thereby binding the thumbnail with metadata.
[0017] Optionally, the display module includes a directory-content linkage unit, a scroll wheel penetration unit, a precise highlighting unit, and a display-end custom rendering unit, wherein:
[0018] The directory-content linkage unit is used to generate directory components and listen for directory item click events to trigger smooth scrolling of anchor points. It distinguishes between program scrolling and manual scrolling by scrolling status indicators and clears the URL hash value after scrolling is completed to avoid routing conflicts.
[0019] The scroll wheel penetration unit is used to bind a scroll wheel event listener to the directory component, obtain the scroll wheel offset and pass it to the content rendering component to update the scroll distance, so as to prevent the directory component's own scrolling behavior from achieving scroll wheel penetration.
[0020] The precise highlighting unit is used to listen to the scrolling events of the content rendering component, calculate the distance between the title element and the top of the content area to filter out the target title, and update the highlighting status of the directory component accordingly.
[0021] The custom rendering unit on the display end is used to reuse the tag style customization rules and anchor point identification binding mechanism of the editing module to ensure the consistency of style between editing and display, and integrates syntax extension plugins to achieve content rendering with the same source as the editing end.
[0022] An operation method, applied to the Markdown editor as described above, optionally includes the following steps:
[0023] In response to the user's initialization request, the editing module performs initialization operations;
[0024] Responding to a user's editing request, the system receives the edited content uploaded by the user, which may include multiple image files;
[0025] In response to the user's save request, the edited content is saved.
[0026] In response to the user's request to display a case study, the program performs a display operation on the edited content.
[0027] Optionally, responding to the user's initialization request and performing initialization operations on the editing module includes the following steps:
[0028] Trigger the edit operation, pass in the case identifier, and send a data request to the backend;
[0029] Receive the full case data returned by the backend based on the data request;
[0030] Data filling is performed based on the full data of the case study to complete the initialization of the editing environment.
[0031] Optionally, responding to a user's case display request and performing a display operation on the edited content includes the following steps:
[0032] Perform the initialization of the display, request and retrieve all data from the backend;
[0033] Generate directory entries that correspond one-to-one with anchor points based on the acquired full data;
[0034] Execute the interactive linkage between the directory and its contents;
[0035] Perform a scroll wheel pass-through;
[0036] Implement class name highlighting when the content area scrolls.
[0037] An electronic device includes at least one processor and a memory connected to the processor, wherein:
[0038] The memory is used to store computer programs or instructions;
[0039] The processor is used to execute the computer program or instructions to enable the electronic device to perform the operation method described above.
[0040] A computer-readable storage medium is applied to an electronic device, the storage medium carrying one or more computer programs that can be executed by the electronic device to enable the electronic device to perform the operation method described above.
[0041] As can be seen from the above technical solution, this application discloses a Markdown editor and its operation method, an electronic device, and a storage medium. This editor is applied to an electronic device and includes an editing module and a display module. The editing module is configured with a modal window component and a file upload component, providing a batch upload entry for drag-and-drop / selection of images. It receives multiple image files selected by the user, uploads the images to the backend storage interface through a custom upload request, and integrates the frontend form component and the Markdown editor component, synchronously loading metadata and historical content returned by the backend. The display module listens for click events on directory items to trigger smooth scrolling of anchor points, obtains the scroll wheel offset, and renders content from the same source as the editing module. Compared to existing technologies, this technical solution enables batch uploading of a large number of image files without requiring numerous repetitive operations, thereby improving upload efficiency. Attached Figure Description
[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0043] Figure 1 This is a schematic diagram of a Markdown editor according to an embodiment of this application;
[0044] Figure 2 This is a schematic diagram of the interface of the editing module in an embodiment of this application;
[0045] Figure 3 This is a schematic diagram of the demonstration module according to an embodiment of this application;
[0046] Figure 4 This is a flowchart illustrating an operation method according to an embodiment of this application;
[0047] Figure 5 This is a block diagram of an electronic device according to an embodiment of this application. Detailed Implementation
[0048] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0049] To address the technical problems of existing solutions, this application proposes the following specific implementation scheme.
[0050] Figure 1 This is a schematic diagram of a Markdown editor according to an embodiment of this application.
[0051] like Figure 1 As shown, the Markdown editor provided in this embodiment is applied to an electronic device, which can be understood as a computer, server, or cloud platform with information processing and data computing capabilities. This Markdown editor is deployed on a web page and includes two core modules: an editing module 100 and a display module 200. Both modules are based on a unified Markdown content processing mechanism to achieve data and rule linkage, and ensure consistent content rendering and interaction logic between the editing and display ends through three unified rules: anchor point identifiers, style class names, and syntax parsing.
[0052] The editing module is used to edit and integrate Markdown business cases. It includes a batch image upload unit, a metadata-content linkage unit, and a custom rendering unit for the editing interface. Its interface is shown below. Figure 2 As shown.
[0053] The batch image upload unit is configured with a modal window component and a file upload component. It provides an entry point for batch image upload via drag-and-drop / selection, receiving multiple image files selected by the user. The images are asynchronously uploaded to the backend storage interface via a custom upload request. Upon successful upload, the backend-returned image storage address is recorded and the upload status is marked as "upload complete." If the upload fails, an error message is triggered. In response to user confirmation of insertion, the unit filters "upload complete" image files, automatically generates Markdown image syntax strings containing centered style tags, and inserts them in batches at the current cursor position in the Markdown editor. The batch image upload unit also includes a file format validation subunit, which only allows the upload of image files in formats such as JPG, PNG, and GIF, with a single file size not exceeding 10MB. Exceeding this limit triggers a format / size error message, effectively restricting the format and size of image files.
[0054] The batch image upload unit automates the entire process of "image selection - asynchronous upload - status management - styled insertion". The specific implementation steps are as follows:
[0055] 1. Interface and state initialization.
[0056] After the editing module loads, the "Insert Image" button is rendered in the editor toolbar, and the button is bound to a modal window trigger event. The modal window is initialized with a reasonable size (e.g., 600px wide, 400px high) to ensure ease of operation. Internally, it is divided into a "file list area" and an "operation button area." Simultaneously, a file status management dataset is initialized in the front-end memory. The dataset fields include a unique file identifier (UID), filename, file size, upload status (uploading / completed / failed), and image storage address; the initial state is empty.
[0057] 2. File selection and pre-verification.
[0058] After the user clicks the "Insert Image" button, a modal window pops up, allowing them to add multiple images by either dragging and dropping files to the file list area or selecting local files by clicking the file selection button. Once the files are added, the front-end immediately triggers a pre-validation process.
[0059] Format verification: Reads the MIME type of the file and only allows JPG, PNG, and GIF formats. If the format is not allowed, "Format error, do not proceed to the next step" will be displayed in the corresponding position in the file list area.
[0060] Size check: Read the file size in bytes and limit a single image to no more than 10MB. If the size exceeds this limit, display the message "Single image size does not exceed 10MB" and do not proceed to the next step.
[0061] Files that pass verification are automatically entered into the file status management dataset, the upload status is marked as "Uploading", and the file name, file size, and upload status (text + loading animation) are displayed in the file list area.
[0062] 3. Asynchronous upload and status update.
[0063] Files that pass pre-verification trigger an asynchronous upload process. The specific implementation logic is as follows:
[0064] Data encapsulation: Encapsulate the file into FormData format, with the file key fixed as "file", and add an identity verification token (assigned uniformly by the backend) to the request header;
[0065] Status monitoring: Update file status in real time by monitoring changes in the state of the XMLHttpRequest object.
[0066] Upload successful: Receive the image CDN storage address returned by the backend, update the status of the file in the dataset to "Completed", record the CDN address, and display the "Upload Complete" indicator in the file list area;
[0067] Upload failed: Update the status of the file in the dataset to "failed", display the "upload failed" sign and retry button in the file list area, and trigger the gradient interval retry mechanism at the same time - the first retry interval is 1 second, the second is 3 seconds, the third is 5 seconds, and the maximum number of retries is 3; if all 3 retries fail, retain the "failed" status and prompt the user "please check the network or select a new file".
[0068] 4. Styled batch insertion.
[0069] After the user confirms the upload status of all files and clicks the "Confirm Insertion" button, the front end performs the following operations:
[0070] Filter files in the dataset that are "completed", iterate through them to generate Markdown image syntax strings with a centered style, and keep the format fixed. <center> < / center> ;
[0071] The editor's built-in API is used to locate the current cursor position, and the generated syntax strings are then inserted in batches at the cursor position.
[0072] Trigger a refresh of the editor preview interface to display the inserted image in a centered style;
[0073] Close the modal window and clear the file status management dataset.
[0074] The Metadata-Content Linkage Unit integrates front-end form components and Markdown editor components. The form component binds to example metadata, including title, description, product type, and thumbnail path. The Markdown editor component binds to example content. During initialization, metadata and historical content returned from the backend are loaded synchronously and populated into the form and editor components respectively. Component change events are monitored, and metadata and content caches are updated in real time. Upon saving, metadata integrity is verified, and all data is integrated and submitted to the backend. The Metadata-Content Linkage Unit also includes a thumbnail upload sub-unit, providing a separate thumbnail upload entry. Upon successful upload, the thumbnail path field in the form component is automatically updated, thus binding the thumbnail to the metadata.
[0075] The metadata-content linkage unit enables synchronized management of case metadata (title, product type, thumbnail path, etc.) and Markdown content. The specific implementation steps are as follows:
[0076] 1. Component binding and global state container construction.
[0077] During the initialization of the editing module, the form component is logically bound to the Markdown editor component, and a global state container is built:
[0078] The form component is configured with metadata fields such as title and product information, and each field is bound to a change listener event;
[0079] Configure the editor component with basic editing functions (font, paragraph, list, etc.) and bind content change listener events;
[0080] The global state container is divided into a "metadata cache" and a "content cache" to store the latest values of the two types of data in real time, enabling data sharing between form components and editor components.
[0081] 2. Synchronous initialization loading.
[0082] When a user enters the editing page, the front-end performs initialization based on the page routing parameters:
[0083] If the routing parameters include a case identifier (edit historical cases): Submit the case identifier to the backend case details interface to obtain the full data including metadata and historical Markdown content; automatically populate the metadata into the corresponding fields of the form component, automatically populate the historical content into the editor component, and complete the initialization of the editing environment;
[0084] If the route parameters do not have a case identifier (create a new case): the form component is filled with default values (the product type defaults to "uncategorized", and the other fields are empty), the editor component displays empty content, and the global state container is initialized to empty.
[0085] 3. Real-time cache updates.
[0086] During the editing process, the front-end monitors component changes in real time and updates the cache accordingly:
[0087] When the value of any field in a form component is modified, the latest value is immediately synchronized to the metadata cache of the global state container;
[0088] When the content of the editor component is modified, the latest content is immediately synchronized to the content cache of the global state container, and the current cursor position is recorded (to facilitate positioning when inserting content later).
[0089] 4. Integrate verification and submission.
[0090] When the user clicks the "Save" button, the save process is triggered:
[0091] Integrity check: Call the form component's validation logic to check if the required fields have been filled. If the validation fails, a red error message (such as "Title cannot be empty") will be displayed below the corresponding field, and the submission process will be terminated.
[0092] Data integration: After verification, metadata cache and content cache are extracted from the global state container and integrated into a data packet with a unified format (containing the two core fields of metadata and content).
[0093] Submission and Feedback: Submit a data packet to the backend case saving interface and receive the backend response: If the response is successful, the user will be redirected to the case list page, and a "Save Successful" message will pop up on the page; if the response fails, the user will be shown specific error information (such as "Product type does not exist, please select again") for correction.
[0094] 5. Linked thumbnail upload functionality.
[0095] The "Thumbnail Path" field in the form component is bound to an independent image upload process (the process is the same as the "File Selection - Pre-verification - Asynchronous Upload" steps for batch image upload, but only single image upload is restricted). After successful upload, the front end automatically fills the "Thumbnail Path" field with the returned thumbnail CDN address, without requiring the user to manually enter or copy the address.
[0096] The custom rendering unit in the editor is used to extend Markdown rendering rules, customize business style class names for heading tags (h1-h4, etc.) and paragraph tags, bind heading text as a unique anchor point to the heading element, and integrate a syntax extension plugin to support GitHub's FlavoredMarkdown syntax and mathematical formula rendering. The custom rendering unit in the editor enables style customization and anchor point binding of Markdown content, ensuring consistency between the edit preview and the displayed result. The specific implementation steps are as follows:
[0097] 1. Customization of style rules.
[0098] When the editor component initializes, it loads a custom style rule file, which defines the unique business style class name and corresponding style for the core tags.
[0099] First-level heading (h1): such as the class name "case-title-h1", with the following style: font size of 24px, brand main color, 1px solid border at the bottom, and 16px top and bottom padding;
[0100] Second-level heading (h2): such as the class name "case-title-h2", with the following style: font size of 20px, brand secondary color, and top and bottom padding of 12px;
[0101] Level 3 / Level 4 headings (h3 / h4): Define class names such as “case-title-h3” and “case-title-h4” respectively, with font sizes of 18px and 16px respectively, and top and bottom padding of 8px;
[0102] Paragraph (p): Class name such as "case-paragraph", style such as line height 1.8, font size 16px, color #333333, top and bottom margins 8px;
[0103] The above style rules apply directly to the editor's preview area, ensuring that the final display style can be previewed in real time during editing.
[0104] 2. Anchor point marking.
[0105] The custom rendering logic for binding the title tag is implemented as follows:
[0106] Parse the Markdown content in the editor and extract all heading levels from level 1 to level 4, along with the heading text.
[0107] Generate composite anchor tags in the format of "heading text-level" (e.g., the anchor tag "Case Overview-h2" corresponds to the h2 heading "Case Overview").
[0108] Bind the anchor tag to the id attribute of the title element, and add the style class name defined in step 1 to the title element to complete the integrated binding of style and anchor tag.
[0109] 3. Complex syntax extension configuration.
[0110] Multiple syntax parsing plugins are integrated into the editor component to expand Markdown's syntax support capabilities:
[0111] It integrates a GitHub-style Markdown syntax plugin, supporting the editing and previewing of syntax for tables, task lists, code blocks, etc.
[0112] It integrates a set of mathematical formula parsing plugins, supporting the input, parsing, and preview of LaTeX format mathematical formulas;
[0113] Integrated native HTML tag parsing plugin, supports <center> 、
[0114] Figure 3
[0115]
[0116]
[0117]
[0118]
[0119]
[0120]
[0121]
[0122]
[0123]
[0124]
[0125]
[0126]
[0127]
[0128]
[0129]
[0130]
[0131]
[0132]
[0133]
[0134]
[0135]
[0136]
[0137]
[0138]
[0139]
[0140]
[0141]
[0142]
[0143]
[0144]
[0145]
[0146]
[0147]
[0148]
[0149]
[0150]
[0151]
[0152]
[0153]
[0154]
[0155]
[0156]
[0157]
[0158]
[0159]
[0160]
[0161]
[0162]
[0163]
[0164] Figure 4
[0165] Figure 4
[0166]
[0167]
[0168]
[0169]
[0170]
[0171]
[0172] <center> < / center>
[0173]
[0174]
[0175]
[0176]
[0177]
[0178]
[0179]
[0180]
[0181]
[0182]
[0183]
[0184]
[0185]
[0186]
[0187]
[0188]
[0189]
[0190]
[0191]
[0192]
[0193]
[0194]
[0195]
[0196]
[0197]
[0198]
[0199]
[0200]
[0201]
[0202]
[0203]
[0204]
[0205]
[0206]
[0207]
[0208] Figure 5
[0209] Figure 5
[0210]
[0211]
[0212]
[0213]
[0214]
[0215]
[0216]
[0217]
[0218]
[0219] The parsing and rendering of custom HTML tags ensures accurate previews of centered images and complex tables. The display module is used to visualize and interact with Markdown business cases. It includes a table of contents-content linkage unit, a scroll wheel penetration unit, a precise highlighting unit, and a custom rendering unit for the display end, as shown in the interface. The table of contents-content linkage unit generates a table of contents component based on the title hierarchy parsed from the Markdown source content. It listens for click events on table of contents items to trigger smooth scrolling of anchor points, distinguishes between program scrolling and manual scrolling through scrolling status indicators, and clears the URL hash value after scrolling to avoid routing conflicts. The table of contents-content linkage unit implements click-to-jump and scroll-linked functionality for table of contents items, avoiding URL hash conflicts. The implementation is divided into two sub-steps: "Table of contents generation" and "Table of contents click-to-jump": 1. Table of contents generation step. After the display module loads the example content to be displayed, it executes the table of contents generation logic: It calls the syntax parsing plugin consistent with the editing client to parse the Markdown content into an abstract syntax tree; it traverses the abstract syntax tree, filters out all level 1 to 4 heading nodes, and extracts the heading text, level, and anchor point identifier for each node (in the same "heading text-level" format as the editing client); it generates a nested table of contents structure according to the heading level: level 1 headings are the top-level table of contents items, level 2 headings are indented 16px relative to level 1 headings, level 3 / 4 headings are indented sequentially, and each table of contents item is bound to a corresponding anchor point identifier. 2. Steps for clicking to jump to the table of contents. The directory item is bound to a click event, and the following actions are performed upon clicking: Initialize the scroll state flag (a boolean variable) with an initial value of "false" (non-programmatic scrolling); when the directory item is clicked, switch the flag to "true" (programmatic scrolling); locate the corresponding title element on the page based on the anchor point associated with the directory item; call the page scroll API to trigger smooth scrolling: configure the scroll animation to "smooth" mode, with the scroll target aligned between the top of the title element and the top of the content area, and reserving an 80px top offset (to adapt to the height of the fixed navigation bar at the top of the page); after scrolling is complete, delay for 3 seconds to switch the scroll state flag back to "false", and call the History API to clear the hash value in the page address bar (window.location.hash = '') to avoid hash value conflicts with front-end routing rules. The scroll wheel penetration unit is used to bind a scroll wheel event listener to the directory component, obtain the scroll wheel offset and pass it to the content rendering component to update the scroll distance, preventing the directory component's own scrolling behavior from achieving scroll wheel penetration.The scroll wheel penetration unit implements "scroll wheel operation in the directory area driving content area scrolling," simplifying long document browsing. The specific implementation steps are as follows: 1. During the initialization of the display module, a scroll wheel event listener function is bound to the directory area container; 2. When the user scrolls the mouse wheel in the directory area, the listener function first calls the event prevention method (event.preventDefault()) to prevent the directory area from scrolling itself; 3. The offset parameter (deltaY) of the scroll wheel event is read. deltaY is positive when scrolling downwards and negative when scrolling upwards; 4. This offset is passed to the content area container, and the scrollBy() method is called to update the scroll distance of the content area (scroll distance = current scroll distance + deltaY), thus implementing scroll wheel operation in the directory area driving content area scrolling; 5. When the page is unloaded, the scroll wheel event listener in the directory area is released, freeing up memory resources. The precise highlight unit listens to the scroll events of the content rendering component, iterates through the title elements to calculate the distance to the top of the content area, filters target titles that are "≥0 from the top and have the smallest distance," and updates the highlight status of the directory component accordingly. The precise highlighting unit achieves real-time linkage between "content scrolling - directory highlighting" to ensure accurate highlighting. The specific implementation steps are as follows: 1. During the initialization of the display module, a scroll event listener function is bound to the content area container, and a debouncing strategy (debouncing delay of 50 milliseconds) is configured to avoid frequent event triggering during scrolling; 2. When the content area scrolls, the scrolling status flag is first checked: if it is "true" (program-triggered scrolling), the highlighting logic is skipped; if it is "false" (user manually scrolls), the following highlighting logic is executed: traverse all level 1 to 4 heading elements within the content area, obtain the DOM node of each element; calculate the relative distance between each heading element and the top of the content area, using the formula: relative distance = content area scrolling distance + Navigation bar height (80px) - offset of title element from the top of document (offsetTop); filter title elements with "relative distance ≥ 0 (title has entered the visible area) and the smallest relative distance" as the target title to be highlighted; remove all highlight styles (such as red font, left border) from the directory items, and add highlight styles to the directory items corresponding to the target title; if the directory item is not within the visible range of the directory area, trigger the scrolling operation of the directory area to center the directory item in the directory area. 3. When the page is unloaded, release the scrolling event listener of the content area to release memory resources. The custom rendering unit on the display side is used to reuse the tag style customization rules and anchor point identification binding mechanism of the editing side to ensure the consistency of style between editing and display, and integrates syntax extension plugins to achieve content rendering with the same source as the editing side.The display module reuses the unified rules of the editing module to ensure consistency between the display and editing preview effects. The specific implementation steps are as follows: 1. During the initialization of the display module, load the same style rule file, anchor point generation rules, and syntax parsing plugin combination as the editing module; 2. Obtain the Markdown content to be displayed from the backend and call the syntax parsing plugin combination to parse the content: During parsing, bind "heading text-level" composite anchor points and exclusive style class names to heading elements; bind corresponding style class names to paragraphs, tables, and other elements; parse complex content such as mathematical formulas and HTML tags to ensure consistent rendering effects with the editing module; render the parsed content to the content area container of the display page to complete the visualization of the displayed content. The unified content processing mechanism between the editing and display modules is the core of maintaining consistency between them, including anchor point rules, style class name rules, and syntax parsing rules. Anchor point identification rules refer to the unified use of a composite anchor point format of "title text + hierarchy" on both the editing and display ends. The specific rules are: Anchor point composition: title text (excluding leading and trailing spaces) + hyphen (-) + title hierarchy (h1 / h2 / h3 / h4); Conflict avoidance: If there are titles with the same title text and the same hierarchy (e.g., two "Case Overview-h2"), a numerical sequence number is appended to the end of the anchor point (e.g., "Case Overview-h2-1" "Case Overview-h2-2") to ensure the anchor point is globally unique. Style class name rules refer to the unified business style class names defined for core tags on both the editing and display ends. The specific rules are: Class name naming convention: "case-tag type-hierarchy" (e.g., h1 corresponds to case-title-h1, paragraph corresponds to case-paragraph); Style file reuse: Both ends share the same set of CSS style files, which are deployed on the front-end static resource server and loaded through the same path on both the editing and display ends to ensure consistent style rules. The syntax parsing rules refer to the integration of identical syntax parsing plugins between the editing and display ends. Specifically, the rules are as follows: Basic syntax: Integrate the GitHub FlavoredMarkdown plugin, supporting basic extended syntax such as tables, task lists, and code blocks; Special syntax: Integrate mathematical formula parsing plugins (remarkMath + rehypeKatex) and HTML native tag parsing plugins (rehypeRaw); Parsing process: Both ends use the same parsing order (parsing basic syntax first, then mathematical formulas, and finally HTML tags) to ensure consistent parsing results. As can be seen from the above technical solution, this embodiment provides a Markdown editor for use on electronic devices, including an editing module and a display module.The editing module is configured with a modal window component and a file upload component, providing a batch upload entry for drag-and-drop / selection of images. It receives multiple image files selected by the user and uploads them to the backend storage interface via a custom upload request. It also integrates the frontend form component and the Markdown editor component, synchronously loading metadata and historical content returned from the backend. The display module listens for click events on directory items to trigger smooth scrolling of anchor points, obtains the scroll wheel offset, and renders content from the same source as the editing module. Compared to existing technologies, this technical solution enables batch uploading of a large number of image files without requiring numerous repetitive operations, thereby improving upload efficiency. A flowchart of an operation method according to an embodiment of this application is shown. As shown, the operation method provided in this embodiment is applied to the Markdown editor of the above embodiment, used to realize file editing, uploading, and display. The method specifically includes the following steps: S1, responding to the user's initialization request, performing initialization operations on the editing module. The initialization of the editing module involves retrieving full case data from the backend based on the case identifier, including metadata and historical Markdown content. The metadata is then synchronously populated into the frontend form component, and the historical content is synchronously populated into the Markdown editor component, completing the editing environment initialization. The specific process is as follows: 1. The user triggers an editing operation and passes in a case identifier (or a newly created case if no identifier is provided). The editing module sends a data request to the backend. 2. The backend returns full case data (empty data is returned for newly created cases, and metadata and historical Markdown content are returned for editing historical cases). 3. The metadata-content linkage unit populates the metadata into the form component and the historical content into the Markdown editor component. The editor's custom rendering unit renders the content in real time, completing the editing environment initialization. S2. The module responds to user editing requests and receives the edited content uploaded by the user. The system responds to metadata editing operations and updates the metadata cache in real time; it also responds to Markdown content editing operations and updates the content cache in real time, recording the cursor position. When an image upload operation is triggered, a modal window containing a file upload component pops up, receiving multiple image files selected by the user, initializing the file list, and marking all files as "uploading". Image files are asynchronously uploaded to the backend storage interface via a custom upload request. Upon successful upload, the corresponding file status is updated to "upload complete" and the storage address is recorded; if upload fails, the status is marked as "upload failed" and an error message is triggered. In response to user confirmation of insertion, image files with a status of "upload complete" are filtered, and a formatted Markdown image syntax string is automatically generated, batch-inserted into the editor at the current cursor position, and the editor content is updated and rendered in real time. The specific process is as follows: 1. Metadata and Basic Content Editing: When the user edits form components (such as entering a title or selecting a product type), the metadata cache is updated in real time; when the user edits editor components (such as entering text or inserting a title), the content cache is updated in real time and the cursor position is recorded.2. Batch Image Upload and Insertion: When the user clicks the "Insert Image" button, the batch image upload unit pops up a modal window, displaying the file upload component. 3. Users add multiple images by dragging and dropping or selecting. The component initializes the file list and marks all files as "Uploading," visually displaying the filenames and sizes. 4. A custom upload request encapsulates the images in FormData format and asynchronously submits them to the backend storage interface. Upon successful upload, the backend returns a CDN redirect address (format:). The unit updates the corresponding file status to "Upload Complete" and records the address. If the upload fails, the status is marked as "Upload Failed," triggering an error message (e.g., "Image upload failed, please try again"). 5. When the user clicks "Confirm Insertion," the unit filters "Upload Completed" images, automatically generates a `` format syntax string, and batch inserts them at the current cursor position in the editor. The editor's custom rendering unit renders the images in real time and displays them centered. 6. Thumbnail Upload: When the user clicks the "Upload Thumbnail" entry in the form component, the thumbnail upload sub-unit triggers a separate upload process. Upon successful upload, the "Thumbnail Path" field in the form is automatically updated, eliminating the need for manual address input. S3. Respond to the user's save request and perform a save operation on the edited content. Respond to the user's save request, verify the integrity of the form component's metadata, and if the verification passes, integrate the metadata cache and Markdown content cache; asynchronously submit the integrated full data to the backend save interface, and upon successful save, provide feedback on the operation result, completing the editing process. The specific process is as follows: 1. When the user clicks the "Save" button, the metadata-content linkage unit verifies the required fields of the form component (such as title, thumbnail). If the verification fails, the user is prompted to complete the fields; 2. If the verification passes, the unit integrates the metadata cache and content cache, generating full data containing "metadata + Markdown content"; 3. The full data is asynchronously submitted to the backend save interface. The backend stores the data and returns a success response. The frontend displays "Operation successful," the editing module closes, and a callback is triggered (such as refreshing the case list). S4. Respond to the user's case display request and perform a display operation on the edited content. The initialization module retrieves the full case data, including metadata and Markdown content, from the backend based on the case identifier. It then renders the Markdown content using a custom rendering unit on the display side, binding style class names and anchor points (heading text) to heading tags such as h1-h4, and binding uniform style class names to paragraph tags. Based on the Markdown content, it parses the heading levels and generates a directory component that corresponds one-to-one with the anchor points.When a directory item is clicked, perform the following operations: A. Set the scroll status indicator to "Program Scrolling"; B. Locate the target title element based on the anchor point associated with the directory item, perform a smooth scrolling operation, and set the top offset to 80px; C. After scrolling is complete, delay for 3000ms, set the scroll status indicator to "Non-Program Scrolling", and clear the URL hash value; When the directory area scroll wheel event is triggered, obtain the scroll wheel offset deltaY, pass the offset to the content rendering component, and update the scroll distance (scrollTop += deltaY), preventing the directory component from scrolling itself; Listen for the scroll event of the content rendering component. If the scroll status indicator is "Program Scrolling", skip the processing; otherwise, execute the following highlighting logic: A. Traverse all title elements and calculate the distance between each element and the top of the content area (contentScrollTop - title element offsetTop); B. Filter out the target title elements with "distance ≥ 0 and minimum distance" and determine their corresponding directory item index; C. Remove the highlight style of all directory items, add the highlight style to the target directory item, and complete the directory-content linkage highlighting. The interaction optimization is implemented through the following steps: 1. Display Initialization: The user triggers the display operation and passes in the case identifier. The display module requests all data from the backend. After the backend returns the data, the display client uses a custom rendering unit to render the Markdown content, binding style class names and anchor tags to heading tags, and binding uniform styles to paragraph tags. 2. Table of Contents Generation: The table of contents-content linkage unit parses the heading levels (h1-h4, etc.) in the Markdown content, generates table of contents items that correspond one-to-one with the anchor tags, and displays them on the side of the page. 3. Table of Contents-Content Linkage Interaction: Table of Contents Item Click: When the user clicks a table of contents item, the unit sets the scroll status indicator to "Scrolling in progress," locates the target heading element based on the anchor tag, and executes `element.scrollIntoView({ behavior: 'smooth', block:'start'})` to achieve smooth scrolling (with an 80px offset at the top to adapt to the navigation bar); after scrolling is complete, the status indicator is reset after a 3000ms delay, and the URL hash value is cleared. 4. Scroll Wheel Penetration: When the user scrolls the mouse in the directory area, the scroll wheel penetration unit obtains the scroll wheel offset deltaY, updates the scroll distance of the content area using `contentRef.current.scrollTop+=deltaY`, and calls `e.preventDefault()` to prevent the directory area from scrolling itself. 5. Precise Highlighting: When the content area scrolls, if the status is marked as "non-program scrolling," the precise highlighting unit iterates through the title elements, calculates the distance (contentScrollTop+190-title offsetTop), filters for target titles with a distance ≥ 0 and the smallest, adds the "active" class name to the corresponding directory item to achieve highlighting, and removes the highlighting style for other directory items.As can be seen from the above technical solutions, this application provides an operation method applied to the aforementioned Markdown editor. Specifically, in response to a user's initialization request, the method performs an initialization operation on the editing module; in response to a user's editing request, it receives the edited content uploaded by the user, which may include multiple image files; in response to a user's save request, it performs a save operation on the edited content; and in response to a user's example display request, it performs a display operation on the edited content. Through the above operations, this application enables batch uploading of a large number of image files without requiring numerous repetitive operations, thereby improving upload efficiency. The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functions, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in the flowchart or block diagram may represent a module, program segment, or part of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the accompanying drawings. For example, two consecutively represented blocks can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified functions or operations, or using a combination of dedicated hardware and computer instructions. Although the operations are depicted in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in sequential order. Multitasking and parallel processing may be advantageous in certain environments. It should be understood that the steps described in the method embodiments of this disclosure can be executed in different orders and / or in parallel. Furthermore, method embodiments may include additional steps and / or omit the execution of the shown steps. The scope of this disclosure is not limited in this respect. Computer program code for performing the operations of this disclosure can be written in one or more programming languages or combinations thereof, including but not limited to object-oriented programming languages—such as Java, Smalltalk, C++—and also conventional procedural programming languages—such as C or similar programming languages. The program code can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or it can be connected to an external computer. The diagram below illustrates a block diagram of an electronic device according to an embodiment of this application.The following reference illustrates a structural schematic diagram suitable for implementing an electronic device according to embodiments of the present disclosure. The terminal device in embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. This electronic device is merely an example and should not impose any limitations on the functionality and scope of use of embodiments of the present disclosure. The electronic device may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory ROM 502 or a program loaded from an input device 506 into a random access memory RAM 503. Various programs and data required for the operation of the electronic device are also stored in the RAM. The processing device, ROM, and RAM are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504. Typically, the following devices can be connected to the I / O interface: input devices including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although electronic devices with various devices are shown in the figures, it should be understood that it is not required to implement or possess all of the shown devices. More or fewer devices may be implemented or possessed alternatively. This application also provides an embodiment of a computer-readable storage medium. The aforementioned computer-readable storage medium is applied to an electronic device and carries one or more computer programs. When the one or more computer programs are executed by the electronic device, the electronic device responds to a user's initialization request by performing an initialization operation on the editing module; responds to a user's editing request by receiving edited content uploaded by the user, the edited content may include multiple image files; responds to a user's save request by performing a save operation on the edited content; and responds to a user's example display request by performing a display operation on the edited content. This application, through the above-described operations, enables batch uploading of a large number of image files without requiring numerous repetitive operations, thereby improving upload efficiency. It should be noted that the computer-readable medium described above can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. The computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof.More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof. The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention. Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.The technical solution provided by the present invention has been described in detail above. Specific examples have been used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core idea of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation and application scope based on the idea of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention. < / center>
Claims
1. A Markdown editor for use on electronic devices, characterized in that, The Markdown editor includes an editing module and a display module, wherein: The editing module is configured with a modal window component and a file upload component, providing a batch upload entry for dragging / selecting images. It is used to receive multiple image files selected by the user and upload the images to the backend storage interface through a custom upload request. It is also used to integrate the frontend form component and the Markdown editor component, and synchronously load the metadata and historical content returned by the backend. The display module is used to listen for click events on directory items to trigger smooth scrolling of anchor points, obtain the scroll wheel offset, and render content that is from the same source as the editing module.
2. The Markdown editor as described in claim 1, characterized in that, The editing module includes a batch image upload unit, a metadata-content linkage unit, and a custom rendering unit for the editing client, wherein: The batch image upload unit is configured with a modal window component and a file upload component, which provides a drag-and-drop / selection dual-mode batch upload entry, responds to the user's custom upload request and asynchronously submits the images to the backend, updates the file status in real time and displays it visually, and automatically generates a preset style of Markdown image syntax after successful upload and inserts it into the editing area in batches; The metadata-content linkage unit is used to integrate form components and Markdown editor components to achieve synchronous management of metadata and content; The custom rendering unit in the editing end is used to bind the title text as a unique anchor point to the title element to ensure the uniqueness of the identifier.
3. The Markdown editor as described in claim 2, characterized in that, The batch image upload unit includes a file format verification subunit, wherein: The file format verification subunit is used to verify the format of files uploaded by users, and only allows image files with preset formats to be uploaded.
4. The Markdown editor as described in claim 1, characterized in that, The metadata-content linkage unit includes a thumbnail upload subunit, wherein: The thumbnail upload subunit is used to provide a separate thumbnail upload entry, and automatically updates the thumbnail path field of the form component after the thumbnail is successfully uploaded, thereby binding the thumbnail with metadata.
5. The Markdown editor as described in claim 1, characterized in that, The display module includes a directory-content linkage unit, a scroll wheel penetration unit, a precise highlighting unit, and a display-end custom rendering unit, wherein: The directory-content linkage unit is used to generate directory components and listen for directory item click events to trigger smooth scrolling of anchor points. It distinguishes between program scrolling and manual scrolling by scrolling status indicators and clears the URL hash value after scrolling is completed to avoid routing conflicts. The scroll wheel penetration unit is used to bind a scroll wheel event listener to the directory component, obtain the scroll wheel offset and pass it to the content rendering component to update the scroll distance, so as to prevent the directory component's own scrolling behavior from achieving scroll wheel penetration. The precise highlighting unit is used to listen to the scrolling events of the content rendering component, calculate the distance between the title element and the top of the content area to filter out the target title, and update the highlighting status of the directory component accordingly. The custom rendering unit on the display end is used to reuse the tag style customization rules and anchor point identification binding mechanism of the editing module to ensure the consistency of style between editing and display, and integrates syntax extension plugins to achieve content rendering with the same source as the editing end.
6. An operating method, applied to the Markdown editor as described in any one of claims 1 to 5, characterized in that, The operation method includes the following steps: In response to the user's initialization request, the editing module performs initialization operations; Responding to a user's editing request, the system receives the edited content uploaded by the user, which may include multiple image files; In response to the user's save request, the edited content is saved. In response to the user's request to display a case study, the program performs a display operation on the edited content.
7. The operating method as described in claim 6, characterized in that, The initialization operation performed on the editing module in response to the user's initialization request includes the following steps: Trigger the edit operation, pass in the case identifier, and send a data request to the backend; Receive the full case data returned by the backend based on the data request; Data filling is performed based on the full data of the case study to complete the initialization of the editing environment.
8. The operating method as described in claim 6, characterized in that, The step of responding to a user's case display request and performing a display operation on the edited content includes the following steps: Perform the initialization of the display, request and retrieve all data from the backend; Generate directory entries that correspond one-to-one with anchor points based on the acquired full data; Execute the interactive linkage between the directory and its contents; Perform a scroll wheel pass-through; Implement class name highlighting when the content area scrolls.
9. An electronic device, characterized in that, The electronic device includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs or instructions; The processor is used to execute the computer program or instructions to enable the electronic device to perform the operating method as described in any one of claims 6 to 8.
10. A computer-readable storage medium for use in electronic devices, characterized in that, The storage medium carries one or more computer programs that can be executed by the electronic device, thereby enabling the electronic device to perform the operating method as described in any one of claims 6 to 8.
Citation Information
Patent Citations
Document processing method, device and equipment and computer readable storage medium
CN118796764A
OER paper automatic extraction agent system and working method thereof
CN121215105A