HTML serialization fixes #1633
HTML serialization fixes #1633
Conversation
# Conflicts: # yarn.lock
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
🦋 Changeset detectedLatest commit: 84c3285 The changes in this PR will be included in the next version bump. This PR includes changesets to release 61 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Awesome, thanks! I'll move that stuff into a new package as Would you mind tagging the fixed issues? |
|
I was unable to get proper line breaks with the new |
|
@igorsheg-wix – could you give an example of line breaks that are missing? The logic is only concerned about leaf nodes / actual content where line breaks should be inserted, not all whitespace or |
|
Considering this node stucture: [
{
"type": "h1",
"children": [
{
"text": "This is my title"
}
]
},
{
"type": "p",
"children": [
{
"text": "this is a paragprah\nand this line is a soft break "
}
],
"id": 1657096475851
}
]I would expect that the serialization will return: <div><h1>This is my title</h1></div>
<div><p>this is a paragprah<br />and this line is a soft break </p></div>Which happens with my patch. |
|
@igorsheg-wix I'm sorry, I re-read your earlier comment and I understand exactly what you mean now. Yes you're right – this is an oversight in my PR. The option should indeed be passed down to the lower-level call to |
Description
This PR fixes a handful of bugs with the HTML serialization logic, and also closes the following:
Remove URI encoding in favour of HTML encoding
The HTML serializer used
encodeURIComponent/decodeURIComponentwhich causes issues when users enter links with URI encoded query strings or code blocks. The content would not be preserved exactly as the user intended as it was mistakenly decoded. Rich text should be considered "what you see is what you get", so if a user chooses to enter "%20" in the editor, this should be serialized exactly as the user entered it.High-level changes:
I have adapted the HTML serializer to use HTML encode/decode (
html-entitiesnpm library) so that all user input can be respected properly and safely serialized/deserialized without any loss of content.I've added the option to
convertNewLinesToHtmlBrin the HTML serializer so that\nchars within paragraphs can be converted to<br />tags (this is optional, so retains backwards compatibility for existing users).Removed the
isEncodedutil as it's no longer usedBroken class names with stripClassNames util
The
stripClassNamesutil also had a bug where class names would be broken. Before, when serializing a paragraph, you would get a nested "class" string:Before (note broken class attribute):
After: