Adds skeleton loading indicators for the lifecycle trend tile numbers:
- total flag count
- median stats
In doing so, I have added the `data-loading` attribute to the
PrettifyLargeNumber component (to avoid having to wrap it in a separate
element for that alone), and have added refs to the InsightsSection
component.
The loading indicators look better in dark mode than in light mode,
because they use the same background color as the text box in light
mode, so only the big number is visible. There is a task in Linear to
look into fixing this.
<img width="1548" alt="image"
src="https://github.com/user-attachments/assets/9e58d681-724e-45cb-baa1-b824dda48008"
/>
<img width="1554" alt="image"
src="https://github.com/user-attachments/assets/7738fac0-5660-464f-8d10-1bf2eacc9ca0"
/>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Switches the "flags per user" box with a "total number of flags" label
for the number in the box and an additional description available via
the help icon.
To accurately label the help text and link it to the figure, I've added
a tooltipId prop to the HelpIcon component.
<img width="551" alt="image"
src="https://github.com/user-attachments/assets/f3227e74-5976-454e-9b7d-db0d05927261"
/>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Update the title of the insights / analytics page when the menu item
changes
While the side menu item has already changed, this change also updates
the page header and title.
Also fixes an error with a prop that shouldn't have been forwarded.
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.
**BREAKING CHANGE**: DEFAULT_ENV changed from `default` (should not be
used anymore) to `development`
## About the changes
- Only delete default env if the install is fresh new.
- Consider development the new default. The main consequence of this
change is that the default is no longer considered `type=production`
environment but also for frontend tokens due to this assumption:
724c4b78a2/src/lib/schema/api-token-schema.test.ts (L54-L59)
(I believe this is mostly due to the [support for admin
tokens](https://github.com/Unleash/unleash/pull/10080#discussion_r2126871567))
- `feature_toggle_update_total` metric reports `n/a` in environment and
environment type as it's not environment specific
This is the first pass at the full lifecycle tiles. It adds the tile
header and current and historical median data.
I have also added large number handling to all the number instances in
the tile: in the header, the graph, and the median data. In doing so, I
exposed the algorithm we use in the PrettifyLargeNumber component.
Returning a react component isn't always a valid option (such as in the
chart). This does mean that you don't get a tooltip when you use the
function directly, but in things like the chart and the median
measurement that makes sense to me.
I've decided to return "No data" if the median days value is 0 or lower.
There's no data for historical medians yet, so I'm using the same number
for now.
<img width="1538" alt="image"
src="https://github.com/user-attachments/assets/72e6a90a-6b84-47ce-af02-59596a7ff91f"
/>
Adds aria label and description to the lifecycle trend charts
The label explains that it's a bar chart, which stage it's describing,
and
the number of flags in each category.
The description provides more information about the split between new
flags this week and older flags.
Adds lifecycle trend graphs to the insights page.
The graphs are each placed within their own boxes. The boxes do not have
any more information in them yet.
Also, because the data returned from the API is still all zeroes, I've
used mock data that matches the sketches.
Finally, the chart configuration and how it's split into a
LifecycleChart that lazy loads a LifecycleChartComponent is based on the
LineChart and LineChartComponent that we use elsewhere on the insights
page.
Light mode:
<img width="1562" alt="image"
src="https://github.com/user-attachments/assets/6dd11168-be24-42d4-aa97-a7a55651fa0e"
/>
We might want to tweak some colors in dark mode, but maybe not? 🤷🏼
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`
BREAKING CHANGE: As part of the preparation for a new major (7.0) this
removes /api/admin/projects/{projectId} endpoint. It has been deprecated
since 5.8, and we don't use it anymore in our frontend.
This removes a strategy that was already deprecated, but only for new
installations.
I tested starting with an installation with this strategy being used and
then updating, and I was still able to edit the strategy, so this should
not impact current users.
On a fresh install the strategy is no longer available.
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
BREAKING CHANGE: This removes the
GET /api/admin/projects/{project}/features/{featureName}/variants
PATCH /api/admin/projects/{project}/features/{featureName}/variants
PUT /api/admin/projects/{project}/features/{featureName}/variants
endpoints
Users should move to environment or strategy specific variant methods
rather than feature level variant methods.
The docker image was trying to load as CJS module:
```
unleash-1 | node:internal/modules/cjs/loader:1404
unleash-1 | throw err;
unleash-1 | ^
unleash-1 |
unleash-1 | Error: Cannot find module './build'
unleash-1 | Require stack:
unleash-1 | - /unleash/index.js
unleash-1 | at Function._resolveFilename (node:internal/modules/cjs/loader:1401:15)
unleash-1 | at defaultResolveImpl (node:internal/modules/cjs/loader:1057:19)
unleash-1 | at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1062:22)
unleash-1 | at Function._load (node:internal/modules/cjs/loader:1211:37)
unleash-1 | at TracingChannel.traceSync (node:diagnostics_channel:322:14)
unleash-1 | at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
unleash-1 | at Module.require (node:internal/modules/cjs/loader:1487:12)
unleash-1 | at require (node:internal/modules/helpers:135:16)
unleash-1 | at Object.<anonymous> (/unleash/index.js:3:17)
unleash-1 | at Module._compile (node:internal/modules/cjs/loader:1730:14) {
unleash-1 | code: 'MODULE_NOT_FOUND',
unleash-1 | requireStack: [ '/unleash/index.js' ]
unleash-1 | }
unleash-1 |
unleash-1 | Node.js v22.15.1
```
This PR makes use of the existing server.ts file instead of having a
specific index.js inside the docker folder, because they both do the
same thing
Splits the insights page into separate sections with their own separate
filters. Each filter is sticky to the top of the page, similar to how
the previous filters worked.
In doing this, I have also moved around a lot of code. Refer to the
inline comments for more specific examples, but on a high level, this
PR:
- Moves the flag check from InsightsCharts into Insights itself. Because
the old Insights had filters and state, and the new one does not, it
made sense to fork off higher up in the tree. Because the new version
doesn't have state, I have also simplified it and removed an
intermediate component (InsightsCharts) that doesn't feel necessary
anymore.
- Because InsightsCharts isn't used anymore, I've moved the
LegacyInsightsCharts file back into InsightsCharts. However, I'm happy
to move it back if we think that's useful.
- Instead of all charts living in InsightsCharts, I've split each
section into its own file in the new sections directory. Because the
sections have separate filters, they don't share any state anymore, so
there's nothing they share.
- I'm reusing the existing hook and endpoint. As it stands, the
performance insights use **most** of the data from that payload (but not
all of it). The user insights use some of it. Flag lifecycle insights
doesn't use anything, but I've wired it up to make the filters work. I
expect that we'll iterate on the API endpoints etc later.
Adding a single table to capture all lifecycle trends data.
One field presents a challenge: `median_time_in_stage_days`. This value
is calculated per `stage`, not per `flag_type`. As a result, we would
need to duplicate the total median time across each flag type. This
isn’t a major issue.
An alternative would be to create a separate table solely for the median
values, but that seems like overkill.
If there are two concurrent requests to create or edit change requests,
two separate ones may be created in parallel. The UI does not currently
handle this scenario, and if additional changes are made, they might be
added to a random existing change request—resulting in a messy and
unpredictable state.
This PR adds a unique index to the `change_requests` table
```
on (created_by, project, environment)
WHERE state NOT IN ('Applied', 'Cancelled', 'Rejected', 'Scheduled').
```
In the extremely rare case where such conflicting data already exists in
a database, the migration will automatically cancel one of the
conflicting change requests.
