Skip to content
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

React-like efficient hydration #4975

Closed
benmccann opened this issue Jun 5, 2020 · 1 comment · Fixed by #6204
Closed

React-like efficient hydration #4975

benmccann opened this issue Jun 5, 2020 · 1 comment · Fixed by #6204

Comments

@benmccann
Copy link
Member

There are a number of open requests for more efficient hydration. Most notably #4308, but also #4297, #2152, #4444, and others. However, they all seem to still be doing far more work than I think is necessary.

The React hydrate docs say:

React will attempt to attach event listeners to the existing markup. React expects that the rendered content is identical between the server and the client. In development mode, React warns about mismatches during hydration. There are no guarantees that attribute differences will be patched up in case of mismatches. This is important for performance reasons because in most apps, mismatches are rare, and so validating all markup would be prohibitively expensive.

This is what I would intuitively think hydration should do. I.e. attach event listeners and nothing more. This would be much more efficient at runtime as well as resulting in smaller bundles.

I'm not sure if there's a reason why SvelteJS today does a diff operation that compares the initial DOM to expected DOM when hydrating. It seems unnecessary in the majority of cases. Though I could see it being useful in development and testing. This would be a breaking change, but maybe could be added with an option and the old hydration method could be deprecated and eventually removed.

@benmccann
Copy link
Member Author

There was another bug, so the performance improvement was reverted. I'm going to leave this closed as a duplicate of #4308 and we can track getting the performance improvement reimplemented in that issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants