1
0
mirror of https://github.com/Unleash/unleash.git synced 2025-10-22 11:18:20 +02:00
unleash.unleash/frontend/src/component/feature/FeatureStrategy/FeatureStrategyConstraints
Thomas Heartman 4ea2499ce7
Chore(1-3688): improve performance for large lists of legal values (#9978)
This PR implements a number of strategies to make the app perform better
when you have large lists. For instance, we have a constraint field that
has ~600 legal values. Currently in main, it is pretty slow and sloggy
to use (about on par with what we see in hosted).

With this PR, it becomes pretty snappy, as shown in this video (should
hopefully be even better in production mode?):


https://www.loom.com/share/2e882bee25a3454a85bec7752e8252dc?sid=7786b22d-6c60-47e8-bd71-cc5f347c4e0f

The steps taken are:
1. Change the `useState` hook to instead use `useReducer`. The reason is
that its dispatch function is guaranteed to have a stable identity. This
lets us use it in memoized functions and components.

2. Because useReducer doesn't update the state variable until the next
render, we need to use `useEffect` to update the constraint when it has
actually updated instead of just calling it after the reducer.

3. Add a `toggle value` action and use that instead of checking whether
the value is equal or not inside an onChange function. If we were to
check the state of the value outside the reducer, the memoized function
would be re-evaluated every time value or values change, which would
result in more renders than necessary. By instead doing this kind of
checking inside the reducer, we can cache more aggressively.

4. Because the onChange function can now be memoized, we can memoize all
the legal value selector labels too. This is the real goal here, because
we don't need to re-render 600 components, because one of them was
checked.

One side effect of using useEffect to call `onUpdate` is that it will
also be called immediately when the hook is invoked the first time, but
it will be called with the same value as the constraint that was passed
in, so I don't think that's an issue.

Second: the `useEffect` call uses `localConstraint` directly as a dep
instead of stringifying it. I'm not sure why, but stringifying it makes
it not update correctly for legal values.

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-05-14 08:04:39 +02:00
..
FeatureStrategyConstraintAccordionList chore: fix setConstraints being undefined/null (#9972) 2025-05-13 12:20:15 +03:00
RecentlyUsedConstraints chore: align recently used constraints to designs (#9904) 2025-05-06 15:42:38 +03:00
useEditableConstraint Chore(1-3688): improve performance for large lists of legal values (#9978) 2025-05-14 08:04:39 +02:00
AddSingleValueWidget.tsx chore(1-3639): constraint validation (#9909) 2025-05-06 15:21:33 +02:00
AddValuesPopover.tsx chore(1-3679): use numeric input mode for numbers. (#9875) 2025-05-05 11:30:52 +02:00
AddValuesWidget.tsx chore(1-3639): constraint validation (#9909) 2025-05-06 15:21:33 +02:00
ConstraintDateInput.tsx chore(1-3639): constraint validation (#9909) 2025-05-06 15:21:33 +02:00
ConstraintOperatorSelect.tsx chore: second design pass for editable constraints (#9843) 2025-04-25 10:37:04 +00:00
ConstraintValueSearch.tsx feat: 1-3652/legal value selector visual update (#9829) 2025-04-24 12:17:05 +02:00
EditableConstraint.tsx Chore(1-3688): improve performance for large lists of legal values (#9978) 2025-05-14 08:04:39 +02:00
FeatureStrategyConstraints.tsx fix: strategy targeting numeric also check value field (#6774) 2024-04-04 11:48:51 +02:00
LegalValuesSelector.tsx Chore(1-3688): improve performance for large lists of legal values (#9978) 2025-05-14 08:04:39 +02:00
resolve-legal-values.ts 1-3687/input mode separation (#9882) 2025-05-02 12:30:38 +02:00
ValueList.tsx Refactor: get rid of editable constraint wrapper (#9921) 2025-05-09 11:47:22 +02:00