-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
chore: Reduce hydration comment for {:else if} #15250
base: main
Are you sure you want to change the base?
Conversation
|
|
Some little change so I edited the first message. And a question : since -if_block(..., elseif: boolean)
+if_block(..., elseif: number[]) I'm not sure if this is OK, or if we have to deal with a compatibility layer. |
Compiler output is not subject to semver so it's fine |
|
||
if (!!condition === is_else) { | ||
if (!!condition === is_else || isNaN(hydrate_index)) { |
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.
We definitely don't want to be using isNaN
anywhere, it's a major codesmell
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.
I didn't known that.
What the alternative to detect bad hydration 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.
Validate it before doing parseInt
?
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.
What about hydrate_index !== hydrate_index
, which will be true only for NaN ?
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.
I mean you also have to facilitate mismatches, where the SSR content is intentionally different from the client side logic too, right? So in that case wouldn't the indexes also not match up?
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 in this case the indexes will not match.
Here it is rather the case where the comment is not from the Svelte hydration process...
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.
Also don't fully understand what the problem here is - isn't this more straightforward/less code to just go "this isn't a number, so something else went really wrong"?
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.
isNaN
has been condemned to hell all over, you can research its history. I'd just rather avoid it and it's caveats where possible.
It wasn't useless, it was done intentionally to clearly show what blocks belong to the if block. |
I didn't think the generated code had to be so explicit. I will restore it... |
Using
{#if} {:else if} {/if}
in template can produce lots of hydration code, since each{#if}
or{:else if}
will use a new block (with 2 possible hydration comments).Example in this issue : #15200
I modified
if_block()
in order to handle that differently, using a single block for allif/else if
.Take example of this dummy code :
Currently, this can produces :
<!--[--><div>one</div><!--]-->
<!--[!--><!--[--><div>two</div><!--]--><!--]-->
<!--[!--><!--[!--><!--[--><div>three</div><!--]--><!--]--><!--]-->
<!--[!--><!--[!--><!--[!--><!--[--><div>four</div><!--]--><!--]--><!--]--><!--]-->
<!--[!--><!--[!--><!--[!--><!--[!--><!--[--><div>five</div><!--]--><!--]--><!--]--><!--]--><!--]-->
<!--[!--><!--[!--><!--[!--><!--[!--><!--[!--><!--[!--><div>...</div><!--]--><!--]--><!--]--><!--]--><!--]--><!--]-->
With this change, it will produce only one hydration block in all case :
<!--[--><div>one</div><!--]-->
<!--[1--><div>two</div><!--]-->
<!--[2--><div>three</div><!--]-->
<!--[3--><div>four</div><!--]-->
<!--[4--><div>five</div><!--]-->
<!--[!--><div>...</div><!--]-->
The generated code is also reduced and simplified.
On client side the generated code is :
This will become :
Note : I also removed the JS scope block
{ ... }
. I think this is useless...Same thing on server side, where this code :
will become :
Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.packages/svelte/src
, add a changeset (npx changeset
).Tests and linting
pnpm test
and lint the project withpnpm lint