We were seeing strange errors when the feature component was rendered
before the feature data was returned from the backend. Now, we ensure
the component is not rendered until the feature is available.
## About the changes
Our health implementation always returns GOOD if the server is up:
beb29f5b5b/src/lib/routes/health-check.ts (L46-L51)
Currently our documentation of the endpoint is misleading saying that it
will return BAD if unable to connect to PostgreSQL
Closes#9965
Vitest Pros:
* Automated failing test comments on github PRs
* A nice local UI with incremental testing when changing files (`yarn
test:ui`)
* Also nicely supported in all major IDEs, click to run test works (so
we won't miss what we had with jest).
* Works well with ESM
Vitest Cons:
* The ESBuild transformer vitest uses takes a little longer to transform
than our current SWC/jest setup, however, it is possible to setup SWC as
the transformer for vitest as well (though it only does one transform,
so we're paying ~7-10 seconds instead of ~ 2-3 seconds in transform
phase).
* Exposes how slow our tests are (tongue in cheek here)
https://linear.app/unleash/issue/2-3564/remove-filterexistingflagnames-feature-flag
We're removing the `filterExistingFlagNames` feature flag since we've
decided we want this to be the default behavior.
We don't need to rush to merge it, just in case we need to disable this
for any reason. However it should also be pretty easy to just revert if
needed.
Changes in tests are a bit tricky since they assumed the previous
behavior where we always registered metrics, even for non existing flag
names. `cachedFeatureNames` is also memoized with a TTL of 10s, so the
easiest way to overcome this was to override `cachedFeatureNames` to
return what we expected. As long as they return the same flag names that
we expect, we're able to register their metrics.
Let me know if you can think of a better approach.
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
Add `getProjectLinkTemplates` method to ProjectStore and corresponding
test. Ideally this should be in a read-model, but let's finish link
templates end to end
