Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: fix markdown-design.md #13

Merged
merged 1 commit into from
Jan 8, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 17 additions & 4 deletions docs/markdown-design.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,12 +44,25 @@ Based on the above tabular analysis,the following conclusions have been drawn:
1. The disadvantages of Blackfriday and gomarkdown are more obvious,it is difficult to meet the needs of community articles.
2. Compared with Goldmark, Lute has fewer users and starts late, so we chose **Goldmark**.

### result
### scheme

---
#### Go+JS Markdown Parser

After researching some existing blog systems, including [Feishu Online Documents](https://eq2pyit41ih.feishu.cn/drive/home/), [CSDN](https://www.csdn.net/), [Chaindrop](https://ld246.com/), etc., which are all parsed by the back-end markdown parser when displaying articles, then directly return to the front-end static page. When editing, they use the front-end markdown editor (except for Chaindrop, which does not have a real-time preview function). GitHub's markdown is also compiled by the back-end, so **we also plan to use the back-end markdown to parse**. There is a high probability that it will not be modified after the article is published, so the back-end analysis only needs to be parsed and stored, while the front-end markdown parser, everyone needs to parse it every time when it is opened.
After researching some existing blog systems, including [Feishu Online Documents](https://eq2pyit41ih.feishu.cn/drive/home/), [CSDN](https://www.csdn.net/), [Chaindrop](https://ld246.com/), etc., which are all return to the front-end static page. When editing, they use the front-end markdown editor (except for Chaindrop, which does not have a real-time preview function). GitHub's markdown is compiled by the back-end, so **we also plan to use the back-end markdown to parse**. There is a high probability that it will not be modified after the article is published, so the back-end analysis only needs to be parsed and stored, while the front-end markdown parser, everyone needs to parse it every time when it is opened.

Although the back-end parser is used when displaying the article, the real-time preview effect must be better when writing the article using front-end markdown parser, because the modification is particularly frequent at this time, and there is no need to send it to the back-end to parse and then return to the front-end, which is sure to be real-time is not good, so the **front-end parser is used when writing the article**.

Based on the above analysis, it has been decided to use **cherry(js markdown parser)** when writing the article for real-time compilation, while use **goldmark(go markdown parser)** when publishing and presenting articles for one-time compilation.
Based on the above analysis, it has been decided to use **cherry-markdown(js markdown parser)** when writing the article for real-time compilation, while using **goldmark(go markdown parser)** to publish articles for one-time compilation.

#### JS Markdown Parser

Another scheme is using the front-end markdown editor to parse and then transfer the parsed HTML results to the back-end for storage. In this way, it is possible to use only one markdown parser to parse the article once when we publish it, and we don't need to parse it again when viewing it.

Based on the above analysis, **We can implement both real-time preview and one-time compilation by using a front-end parser, named cherry-markdown.**

#### result

---

Although *Go+JS Markdown Parser* is more flexible, due to the different parsers of the two parsers, there may be a situation where the format of the article previewed and displayed in real time does not match, so we choose ***JS Markdown Parser Scheme(cherry-markdown)*** for markdown parsing.