You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+16-3
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,9 @@
1
1
# LiteLoaderQQNT-Markdown
2
2
3
-
4
-
)
[](https://github.com/Ikaleio/LiteLoaderQQNT-Markdown/commits/v4/)
6
+
[)](https://github.com/Ikaleio/LiteLoaderQQNT-Markdown/issues)
5
7
6
8
7
9
## 简介
@@ -110,6 +112,17 @@ Normal test with HTML Entities & " ' < > .
Copy file name to clipboardexpand all lines: docs/dev/msg_rendering_process.md
+26-5
Original file line number
Diff line number
Diff line change
@@ -9,11 +9,32 @@
9
9
10
10
# Workflow
11
11
12
-
Currently the plugin does NOT rendering all content inside a message box. We only deal with contents that may need go through the markdown renderer. Also, since some element should NOT be considered as Markdown when rendering and should keep what it look like throughout the rendering, we introduced the concept of **Fragement Processor**(FragProcessor).
12
+
Currently the plugin does NOT rendering all content inside a message box. We only deal with contents that may need go through the markdown renderer. Also, since some element should NOT be considered as Markdown when rendering and should keep what it look like throughout the rendering, we introduced the concept of **Fragment Processor**_(FragProcessor)_.
13
13
14
14
## Fragments
15
15
16
-
As you see, we **consider the `childern` of the message box as a "fragment"**. Then we have **a list of `FragProcessor`, each takes in charge of render a certain type of fragments**.
16
+
When dealing with QQNT messages, we considered a message `span` as a basic rendering unit. A general QQNT message HTML element has the folloing structure:
17
+
18
+
```
19
+
- span.mix-message__inner
20
+
- span.text_element
21
+
- span / p / ...
22
+
- span.text_element_at
23
+
- span.other_element
24
+
```
25
+
26
+
In conclusion:
27
+
28
+
- A `span.mix-message__inner` is related to a single message box, we will use `msgBox` to refer to it below.
29
+
- A `msgBox` could have multiple `span.*_element_*` span, which's classname indictas the content type of this span, for example, a pure text, an emoji or a image etc.
30
+
31
+
Here, we **consider the `span` children of the msgBox as the "fragments" of this message**. Then we have **a list of `FragProcessor`, each takes in charge of catching and rendering a certain type of fragments**.
32
+
33
+
For example, we could have:
34
+
35
+
-`TextFragProcessor` who deal with `span.text-element` fragments.
36
+
-`EmojiFragProcessor` who deal with emoji info in fragments.
37
+
- ...
17
38
18
39
## Fragment Processor
19
40
@@ -27,7 +48,7 @@ type FragmentProcessFunc = (
27
48
) =>FragmentProcessFuncRetType|undefined;
28
49
```
29
50
30
-
When `render()` function is triggered, a provided list of Fragment Processor will be iterated from begin to end **respectively and preemptively**.
51
+
When `render()` function is triggered, for **each fragment** in each message, a **provided list of Fragment Processor** will be iterated from begin to end **respectively and preemptively**.
31
52
32
53
This means, for a single fragment, once a processor successfully returned a not `undefined` value *(actually it should be `FragmentProcessFuncRetType` obejct)*, the loop is end and the return value is used for this fragment.
As you see, it specified the `original` SPAN element, and a new `rendered` element. For now, we just replace the `original` child of `messageBox` with `rendered`.
48
69
49
-
> **Notice**
70
+
> [!note]
50
71
>
51
72
> Keep in mind that the `original` HTML element passed to Fragment Processor could be directly updated.
52
73
>
@@ -87,4 +108,4 @@ For more info about the process, check out source code file:
87
108
88
109
For outdated doc:
89
110
90
-
-[Message Rendering Process Doc 2.3.5](./msg_rendering_process_2.3.5.md)
111
+
-[Message Rendering Process Doc 2.3.5](./msg_rendering_process_2.3.5.md)
This document is used to record some Known Issue of this plugin.
2
2
3
-
# Compatability Issue With Other Plugin
4
-
5
-
Currently we found that sometimes it would cause incorrect rendering behaviour when using this plugin with `LiteTools`(another QQNT plugin). And user may experience:
6
-
7
-
- Incorrect LiteTools Slot rendering position. For example, the *Message Send Time* and *Withdrawed* slot may be rendered with incorrect position / alignment.
8
-
9
-
Currently the workaround for the LiteTool Time slot is to use JavaScript to observe the `offsetHeight` of each message box. If it over a specific value, we consider this message a multiple-line message and set the `flex-direction: column` to the root message box, otherwise set `flex-direction: row`.
10
-
11
-
This require change message box div into `flex` which may cause other rendering issue, and this workaround should be replaced by a better solution.
12
-
13
3
# Post Rendering Function Exec Order Issue
14
4
15
5
Currently, we call `renderSingleMsgBox()` function inside `render()`, then after we call some post-rendering functions, the whole process is like:
@@ -26,4 +16,4 @@ elementDebugLogger();
26
16
27
17
However the issue is the *MarkdownIt* render function returns Promise, so the `renderSingleMsgBox()` is an async function. And so, the post-rendering function below actually may run first while the message is not fully rendererd.
28
18
29
-
Currently we do NOT implement any workaround on this since the test show this issue don't affect the rendering result for now. However this is something that should be fixed in the future.
19
+
Currently we do NOT implement any workaround on this since the test show this issue don't affect the rendering result for now. However this is something that should be fixed in the future.
0 commit comments