-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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: Respecting user-provided ids in ComboBox options #25867
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
7 changes: 7 additions & 0 deletions
7
change/@fluentui-react-a5c36bc6-3f4e-4de1-91a8-8d2407288c7c.json
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
{ | ||
"type": "patch", | ||
"comment": "fix: Respecting user-provided ids in ComboBox options.", | ||
"packageName": "@fluentui/react", | ||
"email": "makotom@microsoft.com", | ||
"dependentChangeType": "patch" | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
The list is probably never long enough for this difference to matter that much and I could see object spread getting transpiled to
Object.assign
anyway but usingObject.assign
is faster than spread.https://jsbench.me/q5lb5lumdv
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.
I'll make a separate PR to address this (it happens in more places within
ComboBox
).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.
Actually, I get hit with an eslint rule error if I do that, so maybe we prefer this approach in v8
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.
The docs for this plugin state that
which, along with readability, seem to be the arguments in favor of enforcing spread. In the benchmark I linked spread is ~80% slower in Edge and ~85% slower in Chrome, while
Object.assign
is ~6% slower in Firefox. May perform better indeed 😉. What I'm getting from this is that the performance is implementation-dependent so it could change tomorrow, but that even in the case where spread is faster it's not that much faster (and it's within the margin of error, +/- ~7%). Compared with the cases where spread is slower, it's much slower and well outside the margin of error. So where we think performance is critical we should prefer Object.assign.So is performance critical here? That's not so clear to me. I'm of the opinion that we should strive for Fluent to be as fast as (reasonably) possible, leaving as many resources to our users as possible so in that sense all performance is always critical. Yet, it's not clear to me that this measurably affects the perf of
ComboBox
?I think this change is simple enough that it's worth benchmarking spread vs object.assign in
ComboBox
itself to see what shakes out.What do you think about running a
ComboBox
bench for this case?ETA: I should note that in testing Firefox is in the neighborhood of 875 opts/s at the fastest while Chrome and Edge are around 1000 opts/s meaning Firefox is more consistent but slower overall.