-
Notifications
You must be signed in to change notification settings - Fork 880
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
Give a clearer error message when rendering into null/undefined #2661
Conversation
🦋 Changeset detectedLatest commit: 6be911e 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
|
Is there an issue for this one? Was is coming up internally? |
@@ -637,6 +637,13 @@ export const render = ( | |||
container: HTMLElement | DocumentFragment, | |||
options?: RenderOptions | |||
): RootPart => { | |||
if (DEV_MODE && container == null) { |
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 feels like runtime type-checking here, which we don't do in most other places. What's an example of a problematic call? Would a check that the container is a HTMLElement or DocumentFragment be better for that case?
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 case that came up was:
render(html`...`, document.body);
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.
In particular, the error use case was
<html>
<head>
<script src="./bundle.js"></script>
</head>
<body>
<some-lit-element></some-lit-element>
</body>
</html>
Without this proposed patch, would generate the cryptic
Uncaught TypeError: Cannot read properties of null (reading '_$litPart$')
\
error (because ./bundle.js
launches before document.body
is set).
This patch aims at creating a more humane error message in these kind of situations.
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.
So because bundle.js
is a sync script and it contains some top-level render(html
..., document.body)
call and document.body
doesn't exist yet? The <some-lit-element>
has nothing to do with it right?
Just wondering here because there are probably a lot of places in our API you could incorrectly pass null
. This seems ok though.
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.
Yes <some-lit-element>
was there to justify the inclusion of lit in the bundle.js
. The correct code should be
<html>
<head></head>
<body>
<some-lit-element></some-lit-element>
<script src="./bundle.js"></script>
</body>
</html>
No description provided.