-
Notifications
You must be signed in to change notification settings - Fork 47k
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
Seal pooled events? #5853
Comments
But you can't unseal when the user does persist the object, right? You're suggesting that users are never allowed to add properties to synthetic events? |
@jimfb Yeah, that's obviously an issue. I would call it bad practice to modify events like that, so I personally wouldn't mind preventing it, but it might still be something we want to support. We could also clone instead of persisting events (same number of allocations), but it would obviously affect the API ( |
Would it be sufficient to just detect the problem and warn? We could check to verify that there are no extraneous properties on the event object after the event handler has completed, right? Or we could wrap the event in a proxy object (in dev mode and where supported - firefox, edge, chrome-canary, etc) and warn if someone mutates an event before persisting it. |
Yeah that should be fine too. Ultimately you're messing up the pooled events so it really should be an error. But then it couldn't be DEV-only and that's bad.
Tangentially, we could even use this to warn when accessing an event after it has been returned to the pool? |
There are lots of things that I believe should be errors, but the javascript community seems to like things that fail soft. That was one of my biggest culture shocks, coming from a java background where the community believes that things should always fail super hard. I've given up on that fight, need to choose my battles :P.
We could do that anyway, with Anyway, overall, I agree this seems like a useful feature to implement 👍 |
I agree, but this is more because we don't want the perf hit in production I would say.
Yeah I guess so... but it's probably a little involved and it technically changes the runtime behavior (they are now getters/setters instead of values), I doubt anyone would notice but still. IMHO it's fine if DEV-warnings for coding practices only work in modern browsers. PS. Hmm, didn't we have something like this? Perhaps we already do... I remember @spicyj working on something like it, but perhaps it never shipped. |
@jimfb Good first "bug"? |
Yep. |
I'll work on this after #5840. |
@jimfb Hi, I was trying to work on this issue. As you have mentioned:
I tried to figure out are there any "hooks" for finding when the event handler have been completed. While I navigated the React source I found that Any help? |
I made a PR for this #5947. |
Kind of related to the old #1612 and #5840, anyone trying to be smart and adding properties to a pooled non-persisted event will cause those to properties to remain in the pool, causing a memory leak of sorts. Could it make sense to
Object.seal(event)
the events, that way we ensure that users can't mess with the event object in bad or unsupported ways.Should probably do this instead: #5853 (comment)
The text was updated successfully, but these errors were encountered: