-
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
Proposal for an ordered attribute white list, and new property injection types #7428
Comments
I like the idea of improving this code, however generalizing too much seems like it's likely to introduce perf regressions for every other case ( I think it's good to explore but we'll probably be a bit more cautious around this code. cc @spicyj since he's probably done the most with this code recently. |
The performance angle of this is a bit of a bummer. I'm killing the cost of the index look up when sorting by storing the order of a property on insertion time, but I haven't figured out a way to get around the cost of building the array every time. Something for me to mull over. |
This problem should only extend to inputs and perhaps very few related elements, so it probably doesn't really make sense to do it globally. Had JS been lower-level it may have been negligible but I doubt it will be in JS. As for the O(nlogn) |
Implementing this for specific elements (I'm specifically looking at |
As for @syranide's comment about GCC optimization. Bummer... There's only 6 or so properties that need to be ordered. I'll revert my array-ification and just keep a list of those properties. Maybe then I can migrate that to the |
FWIW I actually don't think GCC is that important here. I think these shouldn't be getting crushed, even in advanced mode, since they are mostly DOM properties (might be a couple cases where that isn't true). |
Slowly chipping away at this. It's a fun problem. Keeping a tag specific priority list solves the performance problem. Basically: check to see if the tag name is defined within a map of priorities. If so, then enumerate over those properties first. Benchmarks report about what you'd expect: controlled inputs are faster because they do less work. Everything else appears to be roughly the same (or at least within the margin of error). |
I finally got this to a state that I feel good about. I thought it might be easier just to comment on the code directly: |
Closing this one out. I might revisit this after some progress is made on removing the attribute whitelist, but that might be a ways off. Thanks for the discussion! |
I've been working a lot with the
ReactDOMInput
wrapper to fix IE and Chrome bugs and I've noticed that a good portion of the code exists to prevent attributes from being assigned in the wrong order, and for inserting them in a specific way.So that got me curious about benefits centralized, ordered, property assignment might yield. I'm interested in:
type
andstep
beforevalue
.value
,defaultValue
,checked
, anddefaultChecked
assignment order code.I've been investigating that by reimplementing my Chrome backspace fix #7359 with more logic moved to
DOMProperty
. Code fromReactDOMInput
can be eliminated because of guarantees in property assignment order. I'm very curious if it could be eliminated from the other wrappers and other DOM utilities.This work is here: master...nhunzaker:nh-ordered-props. I sort of hesitate to share, but I'm curious if this the type of thing you would accept as a contribution, and is it safe to do this work in parallel with the React Fiber feature?
If so, I was going to start reproducing all of the edge cases fixed by the wrappers, and start working towards reducing the amount of "rule breaking" they require to get properties to assign as expected. Otherwise, I guess I have a much better understanding of how property assignment works :).
The text was updated successfully, but these errors were encountered: