This PR adds:
* Generated types for useProjectDoraMetrics
* Mobile enhancements
* Tooltips
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
This PR updates the UI to reflect the changes to the implicit ^ and $
that we now add. The changes are:
1. Show input adornments for ^ and $ when you create a pattern.
2. Mention that ^ and $ are added implicitly in description.
3. Checks the example you provide against the pattern with added ^ and $
+ adds a test for that.
Points 1 and 2:
## Discussion point:
I have not touched the information about the pattern yet as the PR that
updates that is still in review (#4656), but it would be prudent to also
update that info to make it clearer. I can address that in a follow-up
PR.
Adds `number` as possible payload type for variant.
Adds a flag to enable the feature
Updates all relevant models and schemas
Adds the option to the UI
Closes: #
[1-1357](https://linear.app/unleash/issue/1-1357/support-number-in-variant-payload)
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
## About the changes
Instead of this:
```ts
const { uiConfig } = useUiConfig();
const myFlag = Boolean(uiConfig?.flags?.myFlag)
```
we can have this:
```ts
const myFlag = useUiFlag("myFlag")
```
With the same type safety, less verbose and more purposeful code.
### Important files
- `frontend/src/hooks/useUiFlag.ts`
## Discussion points
Can we in the future share flags between frontend and backend? Right now
adding a new flag has to be done in 4 different places (backend flag
keys list, backend flags defaults config, backend experimental server
options, frontend type).
Most ergonomic option is to pull config directly from Unleash.
Issue, based on previous user feedback:
https://github.com/Unleash/unleash/issues/4565
Internal feature request document:
[docs.google.com/document/d/1Sx0q...](https://docs.google.com/document/d/1Sx0qKZXUVUCjuY5F4MOh1ieOM1A2_jE58zEA7jaM_1g/edit?usp=sharing)
Because you need to match the pattern when copying toggles, it's
important that we show the required information to the user.
This change adds information about the pattern to the page. This isn't
its final design, but it's more important that the information is
there (to avoid user frustration) than that it is pretty.
This change makes it so that the flag name is revalidated against the
new
project pattern whenever you change the target project for a flag.
The validation is not run if the name is empty, if there is no
pattern, or if there is no validation method.
This solves the case where you input a name, then change the project,
and where the name isn't valid for the new project. Previously, it
wouldn't revalidate, but now it does.
While having a pattern when you have no example doesn't make a lot of
sense, it's a problem that you can't delete the example after deleting
the pattern: you previously had to remove the example before the
pattern.
This PR fixes that by always allowing you to update the example, even if
there is no pattern. Our server doesn't currently accept submitting an
example with no pattern, but we could allow that if we want to (and
probably just discard it on the back-end).
This PR also updates the validation of the example and the regex. There
were more unhandled edge cases previously where the validation would
disappear or be wrong. This should be fixed now. The new logic is that,
whenever you update the either the pattern or the example, we check:
- if you have an error in your pattern, no pattern, or no example, then
delete the example error if it exists
- have a well-formed pattern and an example then check if the example
matches the pattern and add/delete an error accordingly
This does have some consequences: editing the pattern can render your
example invalid. You'll also get immediate feedback instead of when you
switch focus. I think this is often a bad pattern (giving the user too
much negative feedback), but in terms of working with regexes, I think
it might be a good thing. We also give immediate feedback today, so I
don't think this is a regression.
Any thoughts are welcome.
Since `auth/{auth_type}/settings` is an Enterprise route, this prevents
404s when we try to use the hook to fetch auth settings in
non-Enterprise instances by using the conditional `useEnterpriseSWR`
hook.
This PR adds a feature naming pattern description to the project form.
It's rendered as a multi-line input field. The description is also
stored in the db.
This adapts most of @andreas-unleash's PR #4599 with some minor changes
(using description instead of prompt). Actually displaying this data to
the users will come in a later PR.
Does what it says on the tin, should help with cleaning up
https://github.com/Unleash/unleash/pull/4512 and respective schema
changes.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
When archiving or reviving feature toggles, when toggles disappear from
table, actions bar should also disappear.
<!-- Does it close an issue? Multiple? -->
Closes
https://linear.app/unleash/issue/1-1293/bulk-revive-modal-doesnt-go-away
Adds a first iteration of feature flag naming patterns. Currently behind a flag.
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Co-authored-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
