Skip to content
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

feat: Update Selected options if options changed #1098

Merged
merged 1 commit into from
Dec 17, 2024

Conversation

JonnCharpentier
Copy link
Contributor

No description provided.

Comment on lines -154 to -162
const selectedOptions = useMemo(() => {
// `selectedOptions` should only ever update if the `values` prop actually change.
// Assuming `values` is a state variable, then it should hold its identity until it _really_ changes.
// Though, it is possible that the `options` prop has changed, which is a dependency on this `useMemo`.
// That could trigger an unnecessary new reference for `selectedOptions`, and cause additional renders or unexpected state changes.
// We should avoid updating `selectedOptions` unless `values` has actually changed.
if (!equal([...values].sort(), selectedOptionsRef.current.map(getOptionValue).sort())) {
selectedOptionsRef.current = options.filter((o) => values.includes(getOptionValue(o)));
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

concern: I'm a little worried that this big comment was added for good reason, and that removing this code will regress the issue (especially since it is going back to the same implementation as before)

I believe due diligence here is required to figure out:

  1. What functionality does this fix, and is it still an issue in the system/regress when removed?
  2. If it is an issue, can we update this in a way that fixes your issue and keeps the other issue from reappearing?

Copy link
Contributor

@0ces 0ces Dec 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue this is meant to fix this: https://homeboundinc.slack.com/archives/G01QEA5CXL1/p1714491658184339, not sure if is still a problem

Copy link
Contributor

@stephenh stephenh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per slack discussion, this PR doesn't fully revert Brandon's fix, which also had a "if debounce search then early return" removed, that is staying removed.

I'm pretty willing to bet the "early return" was the core/biggest fix, and that this "set a useRef from within a useMemo" was ...probably... not necessary, given Jonn's retested that page and it seems to still be working fine.

That said, if not, we'll take another crack at this, and likely with a "something different than setting a ref from within a use memo" approach.

@JonnCharpentier JonnCharpentier merged commit d2d89b4 into main Dec 17, 2024
6 checks passed
@JonnCharpentier JonnCharpentier deleted the sc-63111/update-selected-options branch December 17, 2024 18:23
homebound-team-bot pushed a commit that referenced this pull request Dec 17, 2024
## [2.376.0](v2.375.0...v2.376.0) (2024-12-17)

### Features

* Update Selected options if options changed ([#1098](#1098)) ([d2d89b4](d2d89b4))
@homebound-team-bot
Copy link

🎉 This PR is included in version 2.376.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants