-
Notifications
You must be signed in to change notification settings - Fork 1k
[ssr] Replace escape-html dependency with our own version #2346
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
Conversation
🦋 Changeset detectedLatest commit: 9dc4372 The changes in this PR will be included in the next version bump. 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 |
📊 Tachometer Benchmark ResultsSummarynop-update
render
update
update-reflect
Resultslit-element-list
render
update
update-reflect
lit-html-kitchen-sink
render
update
nop-update
lit-html-repeat
render
update
lit-html-template-heavy
render
update
reactive-element-list
render
update
update-reflect
|
| * Replaces characters which have special meaning in HTML (&<>"') with escaped | ||
| * HTML entities ("&", "<", etc.). | ||
| */ | ||
| export const escapeHtml = (str: string) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we use this in quoted attribute value position can we double-check that this is the right escape algorithm for that? I seem to recall there are difference escape requirements in different contexts, but don't know exactly off the top of my head.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing locally and some stack overflow posts seem to support this scheme. I do wonder why we need to quote anything except for & and ", though, since it seems that [<>'] should be safe inside an " attribute string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec isn't super precise about this, it seems
https://html.spec.whatwg.org/multipage/syntax.html#attributes-2
Attribute values are a mixture of text and character references, except with the additional restriction that the text cannot contain an ambiguous ampersand.
The definition of text:
Text is allowed inside elements, attribute values, and comments. Extra constraints are placed on what is and what is not allowed in text based on where the text is to be put, as described in the other sections.
But maybe there's another part of the spec I should be looking at.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's ok. This keeps the current behavior. Just something that crossed my mind with your fallback renderer PR.
AndrewJakubowicz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing domain knowledge, but syntactically this LGTM!
Is this code in a tested path?
| /[&<>"']/g, | ||
| (char) => replacements[char as keyof typeof replacements] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really elegant.
Yep, it's in the code path of most rendering, so it's covered by most tests. Confirmed that breaking the implementation fails some tests. |
The
escape-htmlpackage is not an ES module, and it's a pretty trivial function to just write ourselves. See https://unpkg.com/browse/[email protected]/index.js for reference. This new implementation should have the exact same output.Advantages: getting rid of the only non-esm dependency helps with running SSR in deno and service-workers, and drops our dependency surface area and package size.
Fixes #1998