https://linear.app/unleash/issue/2-3569/fix-hide-project-archive-in-oss
Hides "project archive" in OSS.
I believe this is a bug. OSS only has one project and the project
archive was acting unexpectedly anyways since it was showing the same
default project as being archived. This is because in OSS we use the OSS
project-controller, not the Enterprise version (override) of it.
Updates how we handle deleted legal values for the constraint reducer.
The previous iteration used useState and took the deleted legal values
as a third argument. This isn't possible anymore because a reducer can
take only two args. The simplest way forward for this was to move the
deleted legal values into the state itself, so that it's available in
the reducer. Because deleted legal values can be updated whenever (when
we get a response for that specific context field), we'll update it via
`useEffect`.
I'm not crazy about this approach, so if you have better suggestions,
I'm listening.
I've changed the signature of the reducer, so I've also updated the
tests. In doing so, I thought it now makes more sense to have the base
objects be objects instead of functions, so the changes there are
primarily updating that.
Improves handling of constraints in use that have been deleted.
This change implments a few small changes on both the front and the back
end on how we deal with constraints that have been deleted.
The most important change is on the back end, in the
`/constraints/validate` endpoint. We used to throw here if the
constraint couldn't be found, but the only reason we wanted to look for
the constraint in the db was to check for legal values. Now, instead,
we'll allow you to pass a constraint field that doesn't exist in the
database. We'll still check the values against the operator for
validity, we just don't control legal values anymore (because there
aren't any).
On the front end, we improve the handling by showing the deleted context
filed in the dropdown, both when the selector dropdown is closed and
when it is open. However, if you change the context field, we remove the
deleted field from the list. This seems like a sensible tradeoff. Means
you can't select it if you've deselected it.
- Deletes an unused file
- Fixes a console.error due to a prop being passed on to the HTML
component
- Puts all editable constraint files within a separate directory.
The issue was that processing constraints after the API call in
updateStrategyOnFeature caused React's state updates to be interrupted
before they could be persisted to localStorage, but by moving that
processing before the API call, we ensure constraints are saved
immediately, regardless of API timing.
We're migrating to ESM, which will allow us to import the latest
versions of our dependencies.
Co-Authored-By: Christopher Kolstad <chriswk@getunleash.io>
Uses a purple color for the hover underline. Also, sets it to be
transparent when not-hovered, so that you get a nice fade in effect.
Focus (top) and hover (bottom) now have the same visual style, but
different ways to get to that state (expansion vs fade-in):
<img width="979" alt="image"
src="https://github.com/user-attachments/assets/e342ea4e-4821-4e4c-bb5d-6b9d3a672e26"
/>
There can be any number of these on a page, so setting autofocus here is
a Bad Idea (TM). It's probably a holdover from when the input was an
accordion and we wanted to give you focus when you opened it (we do a
similar thing for the popover, for instance).
This property will cause you to focus (and potentially scroll) to the
last constraint on the page.
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>
The current implementation states that if you do not have
access—typically as a viewer user—it renders the old component.
Rendering an empty view is acceptable, as this is part of the segment
creation flow, and if you do not have permissions, you do not need to
see it.
Adds a test suite for the useEditableConstraint hook, attempting to test
all the parts of it that we can't test in isolation.
Plus: a few, small refactorings:
- Renames `onAutoSave` on `onUpdate` to better match `onDelete` (and
because autosave doesn't really mean anything anymore).
- Simplifies and collapses some types
Adds a fairly comprehensive test suite for the constraint reducer. I put
in all cases I thought were relevant.
As part of this, I discovered one bug, and changed two actions.
The bug was toggling on the wrong property when you tried to invert case
sensitivity.
The action changes are:
- rename "remove value from list" to "remove value"
- remove "set value" in favor of instead letting "add value(s)" work in
single-value constraints too.
Extracts and tests the implementation of the functions to get deleted
and invalid legal values.
This is pretty straightforward stuff and arguably not crucial, but it
was an easy place to start and I don't think it hurts to have these in
place anyway.
This will stop displaying the semver version for our hosted (i.e.
managed) customers, as it has become less relevant over time. It remains
valuable for self-hosted users.
Adds an input form for single legal values (i.e. for number and semver
operators).
- Uses the `validator` for the constraint to check the list of legal
values and provides a list of "invalid legal values" for values that
don't pass validation.
- Values in the "invalid legal values" set are "disabled" when rendered
in the UI. Additionally, there's an extra bit of text that tells you
that values that aren't valid are disabled.
- Makes the legal values selector more generic and makes it adapt to
multi- or single-value selection based on input props. The external
interface is two separate components (to make it clearer that they are
different things and because their props don't line up perfectly).
Rendered:
<img width="957" alt="image"
src="https://github.com/user-attachments/assets/cd8d2f32-057d-4e31-8fd3-174676eeb65e"
/>
Still todo: testing deleted/invalid legal value detection. I'll do that
as part of the big testathon in a followup.
Fixes an issue where you would lose keyboard focus when interacting with
one of the input fields in the new editable constraint.
The fix was spinning out the inputs into their own separate component.
This prevents them from being re-rendered every time (or something idk)
which allows us to keep focus.
It also stops the popover for multi-value constraint operators from
closing after you've entered a value; allowing for faster entry of more
values (as was intended and as was how it functioned previously).
This (admittedly pretty big) PR removes a component layer, moves all
logic for updating constraint values into a single module, and dumbs
down other components.
The main changes are:
- EditableConstraintWrapper is gone. All the logic in there has been
moved into the new `useEditableConstraint` hook. Previously it was split
between the wrapper, editableConstraint itself, the legalValues
component.
- the `useEditableConstraint` hook accepts a constraint and a save
function and returns an editable version of that constraint, the
validator for input values, a function that accepts update commands,
and, when relevant, existing and deleted legal values.
- All the logic for updating a constraint now exists in the
`constraint-reducer` file. As a pure function, it'll be easy to unit
test pretty thoroughly to make sure all commands work as they should
(tests will come later)
- The legal values selector has been dumbed down consiberably as it no
longer needs to create its own internal weak map. The internal
representation of selected values is now a set, so any kind of lookup is
now constant time, which should remove the need for the extra layer of
abstraction.
## Discussion points
I know the reducer pattern isn't one we use a *lot* in Unleash, but I
found a couple examples of it in the front end and it's also quite
similar to how we handle state updates to change request states. I'd be
happy to find a different way to represent it if we can keep it in a
single, testable interface.
Semi-relatedly: I've exposed the actions to submit for the updates at
the moment, but we could map these to functions instead. It'd make
invocations a little easier (you wouldn't need to specify the action
yourself; only use the payload as a function arg if there is one), but
we'd end up doing more mapping to create them. I'm not sure it's worth
it, but I also don't mind if we do 💁🏼
