Refactored and simplified code around flag filters, in preparation for
UI improvements. It's split into 2 PRs in order to simplify what needs
to be behind a flag and what doesn't.
- `ExperimentalColumnsMenu` moved to `ColumnsMenu`, old unused
`ColumnsMenu` removed
- Parts of the code moved to `ProjectFeaturesColumnsMenu`
- Moved `FlagCreationButton` to a separate file
- Removed part behind archived flag (`projectOverviewRefactorFeedback`)
This PR cleans up the projectListViewToggle flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10526
## 🧹 AI Flag Cleanup Summary
This change removes the `projectListViewToggle` feature flag and
hardcodes its
behavior. The feature, which allows toggling between card and list views
for
projects, is now permanently enabled.
### 🚮 Removed
- **Flag Definitions**
- Removed `projectListViewToggle` from `src/server-dev.ts`,
`src/lib/types/experimental.ts`, and
`frontend/src/interfaces/uiConfig.ts`.
- **Hooks & Conditionals**
- Removed `useUiFlag('projectListViewToggle')` calls from
`ProjectGroup.tsx`
and `ProjectList.tsx`.
- Removed conditional rendering logic based on the flag in
`ProjectGroup.tsx`
and `ProjectList.tsx`.
### 🛠 Kept
- **Project List View**
- The project list view functionality is now always available for
non-OSS
versions of Unleash.
- The `ProjectsListViewToggle` component is now always rendered when not
in an
OSS environment.
### 📝 Why
The `projectListViewToggle` feature flag was marked as completed and its
intended outcome was to be kept. The code has been updated to reflect
this by
removing the flag and making the feature a permanent part of the
application.
This simplifies the codebase by removing dead code paths and feature
flag
checks.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
This PR cleans up the createFlagDialogCache flag. These changes were
automatically generated by AI and should be reviewed carefully.
Fixes#10504
## 🧹 AI Flag Cleanup Summary
This change removes the `createFlagDialogCache` feature flag, making its
functionality permanent. The create-feature-flag dialog will now always
cache
its state in local storage.
### 🚮 Removed
- **TypeScript Definitions**
- Removed `createFlagDialogCache` from `UiFlags` in
`frontend/src/interfaces/uiConfig.ts`.
- Removed `createFlagDialogCache` from `IFlagKey` in
`src/lib/types/experimental.ts`.
- **Flag Configuration**
- Removed the `createFlagDialogCache` flag definition from
`src/lib/types/experimental.ts`.
- **Conditional Logic**
- Removed the `useUiFlag` hook and conditional logic for caching in
`frontend/src/component/project/Project/PaginatedProjectFeatureToggles/ProjectFe
atureTogglesHeader/CreateFeatureDialog.tsx`.
### 🛠 Kept
- **Feature Functionality**
- The feature of caching the create-flag dialog's form state in local
storage
is now always enabled.
### 📝 Why
The `createFlagDialogCache` feature has been successfully rolled out and
is now
considered stable. This cleanup removes the obsolete feature flag and
hardcodes
the enabled behavior, simplifying the codebase.
Co-authored-by: unleash-bot <194219037+unleash-bot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Updates a few remaining places where we check constraint operators with
the new constraint operator checks. Additionally, because there was only
one remaining place where we used the `oneOf` function, I replaced it
with a normal `includes` check and deleted the `oneOf` util. From what I
can tell, there's no need to have that utility function; it doesn't
provide much benefit over using the language built-ins 🤷🏼
This PR addresses and removes the last comment related to the
addEditStrategy flag. In doing so, I have also removed the remaining
dangling files from the new constraint accordion directory. I believe
that everything that's left in there now is currently in use.
This PR removes more constraint inputs and validators that are not in
use anymore. Additionally, the old constraint components that are still
being used by the project action filter item, have been moved to that
directory. This also goes for ResolveInput which has been simplified to
only the inputs and operators used by actions filter item.
I've done a manual side-by-side comparison of the old and newly
refactored filter item, and it appears to be working the exact same.
This PR continues the cleanup after removing the addEditStrategy flag
(part 2 of ???). The primary purpose of this PR is to delete and remove
all references to the LegacyConstraintAccordion.
I've gone and updated all references to the legacy files in external
components and verified manually that they still work.
Most of the files in this PR are changing references. I've extracted two
bits into more general constants/utils:
1. Constraint IDs are a symbol. it was exported as a const from the
previous createEmptyConstraint file. I've moved it into constants.
2. formatOperatorDescription was similarly used all over the place, so
I've placed it in the shared utils directory.
In reviewing this, you can ignore any changes in the legacy constraint
accordion folder, because that's all been deleted. Instead, focus on the
changes in the other files. It's primarily just import updates, but
would be good to get a second set of eyes, anyway.
Adds caching via localstorage to the flag creation form, so that if you
(accidentally) close the form before submitting it, you'll retain (most)
of the same data when you reopen it.
Specifically, we'll store:
- name
- description
- type
- tags
- impression data
We can't store the project as it is now, because it gets overridden by
whatever is in the URL. However, this is probably a good thing. It means
that if you navigate to a different project and open the feature
creation form there, it'll retain everything from the last one, but
it'll use the current project.
The stored data is cleared when you successfully create a feature, so
that you don't get dangling data.
The data is also stored in a shared cache for all projects, so that you
don't have different caches per project.
The behavior of seeding the form is hidden behind a flag (that doesn't
exist yet). We'll still read and write to the cache if the flag is off,
but we won't use it to populate the feature form, so it has no
discernible impact on the user.
## Bug detected 🐛 ... and squashed
Working on this, I came to realize that there was a bug in how the
config button and use feature form hooks interacted. We (in this case
probably me) have assumed that it's fine to use a set for any option
checking in the config buttons. Also, we're using a set to store tags in
the feature form. But objects aren't compared by value in JS, so the set
will happily accept multiple instances of the same tag. Likewise, these
tags won't show up as selected in the dropdown because when the dropdown
checks if the set `has` the value, it's using reference equality.
To get around this, I have normalized the values of the Tags set to
strings (`<type>:<value>`), which are easily comparable.
We can iterate on this later if we need to.
## `useLocalStorageState`
In doing this, I have also made a change to the useLocalStorageState
hook:
the exposed "setState" function now writes to the localstorage
immediately. This is because the useEffect method might not have time to
save the data if the component unmounts (this was the case with the flag
dialog).
However, I have kept the useEffect because it gets run on component
mount and then only when it changes. This means that we will get double
saves to localstorage, but it'll be with the same data, so it's benign.
I've tried out two other uses of the hook (event timeline props and
environment columns in the project flags table) and see no discernible
difference in behavior.
## `useFeatureForm`
I have also made a change to the useFeatureForm hook and removed a
`useEffect` that would reset the name to whatever you passed in as the
initial name if you cleared it out. This essentially meant that you
couldn't clear the name completely, because it would just refill with
the initial name.
As far as I can tell, there is no need to have this sticking around
anymore. The hook is only used in two places: the flag creation dialog
and the flag edit page. The flag edit page doesn't allow you to change
the name anyway and it was causing issues in the dialog. It's likely a
holdover from the way something worked 3 years ago. Both the dialog and
the edit screen seem to work just fine with this change.
I have also changed the function parameters from ordered parameters to
an object. There's so many of them that even you don't think it's a good
idea to use objects when you have multiple params with the same type,
it's just nigh-impossible to remember the order by now.
## Minor changes
Additionally, I came across three issues that were causing react errors,
and have fixed them.
1. we'd forgotten to interpolate a variable and just used the variable
name in a string instead
2. an html attribute that doesn't exist (`aria-role` instead of `role`)
3. Providing a disabled button inside a tooltip. I've seen this one
around for ages and it prevented tooltips from working on disabled
buttons. The solution was wrapping it in a span.
On insights and project status, we would like to show "technica debt"
instead of "health". New value is that of `1/health`, or simplified:
`healthy flags / total flags`
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.
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>
