-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Fix DomSlot debugging #3817
Fix DomSlot debugging #3817
Conversation
Size Comparison
✅ None of the examples has changed their size significantly. |
c39dc71
to
f657df0
Compare
Visit the preview URL for this PR (updated for commit f657df0): https://yew-rs-api--pr3817-domslot-debug-p3q90mow.web.app (expires Mon, 10 Mar 2025 16:03:05 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
Benchmark - coreYew Master
Pull Request
|
Benchmark - SSRYew Master
Pull Request
|
I'm not sure what the motivation behind the TRAP is. It seems to be used as next_sibling placeholders? Why can't we make next sibling optional? |
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.
Tried this in a large SSR project that previously panicked over the trap, with and without release mode. Both work fine!
It is a placeholder. Note that it's only used when |
Description
Formatting the internal
DomSlot
struct for debugging could cause a panic if this was done before hydration of an element finished (There are multiple ways to invoke this from user code, such as formatting aHandle
).This was only a problem in code with
debug_assertions
enabled.Checklist