-
-
Notifications
You must be signed in to change notification settings - Fork 878
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
Custom elements callbacks should untrack #2039
Comments
I'd have to argue this is a no-fix. There's no way to intercept this at all. If anything, the responsibility must be delegated to the user. |
Its untracking:
What makes you think there's no way? |
It"d definitely considerably increase size of codegen and put overhead on everything. There are a ton of touch points too because of all the micro optimizations we do. This seems pretty tricky. I doubt highly the vast majority of Solid users would want to take any sort of hit for WCs. To be fair it isn even WCs in general as Solid Element works fine doing the untrack itself. Its this specific pattern. |
Interesting, I only used this because I know there's an effect there. So if one were to create custom elements using solid it will be using Solid Element. I wonder if in that case it will still track, as there are so many ways to cause these callbacks. As every day there's more use of WE this should be keep in consideration in my opinion. |
Describe the bug
Custom elements have numerous callbacks and these should untrack to avoid recursion. This is a bit tricky because a lot of DOM methods for manipulation could cause the callbacks to fire.
Your Example Website or App
https://playground.solidjs.com/anonymous/b6031b3f-7ce9-4322-a06f-31823340af8d
Steps to Reproduce the Bug or Issue
Testing code is the following
The text was updated successfully, but these errors were encountered: