Let the user settings hook just use the first defined value

[rafpaf]

This pull request adds a new option to to the useUserSetting hook: just use the first defined value. This helps avoid unnecessary re-renders, which avoids race conditions.

In the useUserSetting function, an additional parameter shouldUseFirstDefinedValue was added in this branch. If this parameter is true, only the first value retrieved from the API is used. This parameter is optional and set to false by default.

[rafpaf]

• Avoid race condition in Browse models filter #42574
• Let the user settings hook just use the first defined value #42605 👈
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rafpaf and the rest of your teammates on Graphite

[graphite-app]

Graphite Automations

"Notify author when CI fails" took an action on this PR • (05/17/24)

1 teammate was notified to this PR based on Raphael Krut-Landau's automation.

"Don't backport" took an action on this PR • (05/17/24)

1 label was added and 1 reviewer was added to this PR based on Raphael Krut-Landau's automation.

[replay-io]

Status	Complete ↗︎
Commit	6628f19
Results	⚠️ 1 Flaky ✅ 2526 Passed

[iethree]

1. This really needs tests. This is essentially a caching problem which is really hard, and tests will help make sure it works as we expect, and clearly document those expectations.
2. I'm not sure memoization like this is the right approach:

Here, we say, for the purposes of this hook, ignore all API values other than the first one. I think this is confusing to reason about, especially when multiple components are subscribing to the same setting.

I think what we really want here is aggressively optimistic updates - where we immediately update the value in the redux store and then don't update the redux store when the API request completes. That way we get completely synchronous behavior client side for these user settings, and hopefully save them server side, but it's no big deal if they don't. This also lets us avoid the weird back/forth race condition possibilities. I also think this should be the default behavior, maybe with the option to turn it off. WDYT?

[sloansparger]

I'd like to understand a bit more why this was needed. If useSetting is slow, we should fix it for everyone instead of opting in. If you have a singular use case for this, I'd opt for a more composable solution like:

const CheapToRerender = () => {
  const [setting] = useSetting('my-setting')
  const staleSetting = useFirstDefinedValue(setting);

  return (
     <ExpensiveToRerender thing={setting.attr} />
   )
}

[sloansparger]

I'm not sure this is what memoization is. If you provide a new key input (line 16) you'll get the previous key's output still. To me this is something like shouldUseFirstValue or shouldUseStaleValue.

[sloansparger]

If this were going to go through with this, I think there should be a setter that does something. You should be able to at the very least have your value update to the setter's value.

[rafpaf]

Not sure I follow

[sloansparger]

const [value, set] = useSetting('thing', { shouldMemoize: true });
console.log(value) // 'a'

// somewhere else
set('b');

// next render
const [value, set] = useSetting('thing', { shouldMemoize: true });
console.log(value) // 'a' <-- still a even though we set it to b

[rafpaf]

@sloansparger

I'd like to understand a bit more why this was needed. If useSetting is slow, we should fix it for everyone instead of opting in. If you have a singular use case for this, I'd opt for a more composable solution like:

const CheapToRerender = () => {
  const [setting] = useSetting('my-setting')
  const staleSetting = useFirstDefinedValue(setting);

  return (
     <ExpensiveToRerender thing={setting.attr} />
   )
}

I've changed the prop to shouldUseFirstDefinedValue and it defaults to true.

[rafpaf]

@sloansparger

I'd like to understand a bit more why this was needed.

The prop makes it possible to remove a race condition in the Browse models filter: Avoid race condition in Browse models filter. The race condition could arise for any similar UI that tracks a value in the API, so a general solution seemed useful

[rafpaf]

1. This really needs tests. This is essentially a caching problem which is really hard, and tests will help make sure it works as we expect, and clearly document those expectations.

Agreed. Will write some tests.

2. I'm not sure memoization like this is the right approach:

Here, we say, for the purposes of this hook, ignore all API values other than the first one. I think this is confusing to reason about, especially when multiple components are subscribing to the same setting.

I think what we really want here is aggressively optimistic updates - where we immediately update the value in the redux store and then don't update the redux store when the API request completes. That way we get completely synchronous behavior client side for these user settings, and hopefully save them server side, but it's no big deal if they don't. This also lets us avoid the weird back/forth race condition possibilities. I also think this should be the default behavior, maybe with the option to turn it off. WDYT?

I like this idea!