-
-
Notifications
You must be signed in to change notification settings - Fork 674
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
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
/decodeURIComponent
which 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-entities
npm 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
convertNewLinesToHtmlBr
in the HTML serializer so that\n
chars within paragraphs can be converted to<br />
tags (this is optional, so retains backwards compatibility for existing users).Removed the
isEncoded
util as it's no longer usedBroken class names with stripClassNames util
The
stripClassNames
util 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: