This PR takes two steps towards better constraint handling:
## New type: `IConstraintWithId`
Introduces a new type, `IConstraintWithId`. This is the same as an
`IConstraint`, except the constraint id property is required. The idea
is that the list of editable constraints should move towards using this
instead of just `IConstraint`. That should prevent us (on a type-level)
from seeing more of the same kind of errors we saw with the segment
constraints yesterday.
I don't want to go ahead and update all the upstream uses of this to
IConstraintWithId in this PR, so I'll look at that separately.
## API payload constraint replacer
Introduces an api payload constraint "replacer", which we can use for
[JSON.stringify's `replacer`
parameter](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#the_replacer_parameter).
The current implementation works both for strategies and for segments
and has been added to edit + create forms for both of these resources.
This has a couple benefits:
1. We can clearly state exactly how we want them to be rendered,
including property order. I've decided to go with context -> operator ->
value(s) as the main one (check the screenie), as I believe this is the
most logical reading order.
2. We can exclude value/values (whichever one doesn't work with the
operator)
3. It doesn't matter how we treat constraints internally, we can still
present the payload how we want
4. Importantly: this only affects the stringification for the
user-facing API payload, so it's very low risk. It does not affect
anything that we actually send to the api.
Here's what it can look like with ordered properties:
<img width="392" alt="image"
src="https://github.com/user-attachments/assets/f46f77c8-0b5a-4ded-b13a-bb567df60bd3"
/>
Prevents the property order from changing when constraints are set from
the editable constraint component. When we render out the API command,
we don't specify the order of properties in the objects, which means
that it can change dramatically, which can be a little jarring.
As it is right now, it first renders in one order when you open the
strategy form:
<img width="299" alt="image"
src="https://github.com/user-attachments/assets/52cf2445-d9eb-402c-b5bc-0fece5fbe822"
/>
And when you navigate to the targeting section of the strategy form, it
changes to:
<img width="299" alt="image"
src="https://github.com/user-attachments/assets/e4cb7006-dcf4-4e88-befb-ccba5b647ddd"
/>
This also applies to constraints in segments.
With this change, the order will remain the same before and after.
Additionally, there's some extra tests around constraint ids being kept
the same and being set if it doesn't exist.
## Further work
This came about as part of the issue we had with constraint editing in
segments being broken as of now. As part of that, I would like to make
some further improvements (such as making the ID required when you use a
list of editable constraints), but that will be in a follow-up. There
are some complications that might not make it a viable option, sadly.
We could also try to stabilize the property order in the API rendering
methods (which I think might be a good idea), but because there's
multiple different ones, this seems to be a faster solution.
This adds constraint ids to segment constraints used in editing
segments. Without them, there was a bug where when you went to edit the
segment, all constraints would be invisibly set to the same constraint.
Addresses and removes all leftover comments related to the flag overview
redesign flag.
There's four changes here:
1. Remove release plan milestone strategy and environment footer.
Dangling files, no references.
2. Delete old code without references in theme.ts
3. Delete legacy playground result chip. Replace all references to it
with references to the new chip. The API is the exact same and the
legacy chip was just passing through everything to the new chip anyway,
so nothing should change.
4. Remove a now-redundant way to supply a default
Deletes the legacy strategy separator and removes all references to it.
Luckily, all references to the separator were in dangling files that
could themselves be deleted directly.
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 offers a little QoL upgrade in cases where you have only a
single available filter: Instead of having to first click "filters" and
then select the only option, we'll now always show the available filter,
whether it's marked as persistent or not.
The filter still gets a 'delete filter' button that clears the filter
(which is more convenient than having to deselect every one of the
options one by one), but the filter won't disappear when you clear it.
Additionally, because the `state` of the filter item will be undefined
if it has no value, I've added a `preventAutoOpen` prop to the
underlying Filter component.
~~I don't understand why we want to auto-open the filter, but it was
added by @kwasniew in https://github.com/Unleash/unleash/pull/5611, so
it appears to be deliberate.~~ The fact that we auto-open the filter
when state is undefined makes this a little tricky. I realized during
this that the reason we do it is that we want the filter to auto-open
when you select it from the dropdown. Maybe there's a better way to do
that than useEffect, but maybe not 🤷🏼
Further, the filter handling logic is quite complex (what filters to
show, ordering, etc), so I've moved as much of that into the multifilter
component, leaving the singlefilter as simple as possible.
I'm ... not particularly proud of the code here, so I'm happy to take
any suggestions for improvements. Happy to throw it all away if you have
a better way to achieve this goal.
## Rendered
The lifecycle insights use the persistent, single filter, the
performance insights do not:
<img width="1629" alt="image"
src="https://github.com/user-attachments/assets/b8599883-97dc-428e-a98f-ad59ad1c74ab"
/>
<img width="1556" alt="image"
src="https://github.com/user-attachments/assets/eacdc4bf-bc60-4e26-a88c-8be7dc5e31be"
/>
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.
Fixes a console log about invalid dom nesting:
<img width="1256" alt="image"
src="https://github.com/user-attachments/assets/0849103c-6901-4b64-a124-00eaf8cc7dde"
/>
I've changed the offending div to a span. We set `display: flex` on it,
anyway, so it shouldn't make a difference.
I've also removed some redundant functions and braces that we don't
need.
Removes all usages of flag addEditStrategy and refactors code where
necessary.
This is only the first step of the cleanup. After this, there's still
lots of code to be removed. I've got a different PR that removes ~5k
lines of code (https://github.com/Unleash/unleash/pull/10105) that I
want to reach in pieces to make sure that everythnig works on the way
there.
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.
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`
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.
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.
- added `sideMenuCleanup` flag
- extracted `SecondaryNavigation`, `SecondaryNavigationList` and
`MobileNavigationSidebar` into separate files
- hidden recent projects and flags
- renamed 'Insights' to 'Analytics'
Creates sections for the insights dashboard and moves charts around into
the same order as the sketches and into the right sections. There's no
charts for the top section (lifecycle currently) yet, and the sections
also don't have their own filters.
To make this re-ordering easier, I've also moved the previous insights
chart into a legacy file and set up a proxy component that handles
switching based on the flag.
Next step is separating the filters.
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.
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 💁🏼
This is a helper PR for a refactor I'm working on for the new constraint
inputs. In the refactoring, it's useful to have individual subtypes for
the various subgroups of operators and to be able to easily assert
whether something is X operator or not.
The only change required in the code base is a single check for
operators, which is now handled by using the new `isXOperator` functions
instead.
Yes, the operator file in constants now includes functions, but it
seemed useful to put the identification functions there instead of
somewhere unrelated. The tests are primarily to ensure that the
identifier function works, and I'd be happy to remove them if we think
it's necessary. That said, they're pretty simple unit tests, so I think
it's fine to leave them.
The main bulk of the change is: removing the explicit `: Operator[]`
typing to the various sub-sets of operators and instead adding explicit
types. Additionally, there's the new identifier functions.
Did two things:
1. Use basePath to prefix the Unleash repo used with the Unleash
Frontend SDK.
2. Use JSON.stringify as key for useEffect to avoid potential render
loop
Implements client-side validation of constraint values before you can
add them to a constraint.
I've removed the extra server-side validation that used to happen for
each specific constraint, because the surrounding form itself uses
server side validation to check every constraint every time there's a
change. This is what controls disabling the submit button etc.
I wanna make the next PR a bit of a followup cleanup now that it's
clearer what properties we do and don't need.
<img width="371" alt="image"
src="https://github.com/user-attachments/assets/7c98708f-fcbe-40ca-8590-bb0f5b2ad167"
/>
<img width="361" alt="image"
src="https://github.com/user-attachments/assets/503d4841-d910-4e8e-b0ef-a3d725739534"
/>
Initial PR that adds logic for displaying a link to stripe to view
consumption based pricing in the billing overview
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
Adds inputmode='decimal' to input fields with number input. As discussed
on the [GOV.UK
blog](https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/),
this finds a balance between giving numeric input options to mobile
devices and improving validation / user experience.
They mention this bit in their [design system
guideline](https://design-system.service.gov.uk/components/text-input/#numbers)
> Do not use `<input type="number">` unless your user research shows
that there’s a need for it. With `<input type="number">` there’s a risk
of users accidentally incrementing a number when they’re trying to do
something else - for example, scroll up or down the page. And if the
user tries to enter something that’s not a number, there’s no explicit
feedback about what they’re doing wrong.
I've purposefully not included the `pattern="[0-9]*"` attribute here,
because the browser error messages conflict with our own and have
several drawbacks in terms of accessibility according to Adrian
Roselli's ["Avoid default field
validation"](https://adrianroselli.com/2019/02/avoid-default-field-validation.html).
Instead, the validation here will be part of the validation handling
later.
Also, I've opted for using `decimal` instead of `numeric`, because we
allow you to store decimal values and that inputmode also adds the
decimal separator to the keyboard. As always, however, there's
complications: several languages (including Norwegian) use a comma as a
decimal separator instead of a period, so the keyboard will likely
contain numbers and a comma instead of a period. This is a problem
because JS doesn't recognize "45,6" as a valid number. I've added a
follow-up task to look into this. I thought at first it would just be
expanding the validation, but because it's stored as a string on the
back end and the SDKs presumably parse it, we can't just suddenly allow
commas as decimal separators.
