Added conflict count to CR metrics and CR id.
Something to think about:
There was idea that we can aggregate this data based on CR id, but CR id
is just a number from 0 to x. So it will not be unique across instances.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This changes the two interfaces IChangeRequest and
IChangeRequestSchedule to be union types instead of interfaces. It also
extracts the constituents of those union types into proper types
themselves (so that they can be used in function type signatures etc).
It also updates the type names.
This turned out to be more work than I had imagined, but I think the end
result pays off, giving us more type safety and control.
I wanted to use just `ChangeRequest` for the IChangeRequest type, but
that caused issues due to naming collisions with the `ChangeRequest`
component that we have, causing tests to fail. I've named it
`ChangeRequestType` as a potential solution, but suggestions are
welcome.
The relevant changes are in
`frontend/src/component/changeRequest/changeRequest.types.ts`.
Everything else is updated references and some necessary refactoring to
respect the new types.
This PR removes warning on the project settings by always making sure we
have the project before rendering the settings and do a conditional
check on the featureLimit number field.
We get a flash of the Unleash scaffold when we first load the page. For
a brief moment, we display version 3 and then overwrite it with the
correct version. Looks kinda silly, we know we're in version 5.x so
let's just do that
This PR refactores the StrategyVariants component to be passed in from
the outside to the new form component. This allows us to pass in the
StrategyVariants with an "editable" property in the create form which we
use to determine the editable state of the name input field. If the
editable field is not passed in we keep the old behavior.
Notable changes:
* StrategyVariants is now passed in from the outside, allowing us to
define different props at call time
* Added tests for the new behavior, and for keeping the old behavior
(such as in edit strategy)
* Added tracking
## Problem
The ConstraintAccordionList component was used in multiple places:
* Playground
* Segment form
* StrategyExecution
* Change requests
* Create strategy
* Edit strategy
This is problematic because some of the views are just pure visual
representations, and other views allow you to interact with and edit the
constraints. This causes a situation where the visual representation
needs to be aware of the implementation details of editing and mutating
constraints. In addition the ConstraintAccordionList is not just a pure
rendering of the list, it also keeps internal state on when to show the
create button and optional headers. This is makes it hard to make
changes when stylings need to be subtly different across components.
## Solution
Taking on the full refactor for this is out of scope, but it's
unfortunate that the ConstraintAccordionList needs all this internal
state. For now I split out the list into it's own component called
ConstraintList. I gathered the functions needed for editing and mutating
the constraints in a reusable hook and isolated the version of the list
used in the new feature strategy edit / create components into it's own
component so that the changes in layout will not affect anything else.
Ideally we should try to move towards a future where the components
don't keep internal state like this but clear boundaries and purposes
for the use.
Show a warning about how deleting a strategy might mess up scheduled
change requests.
If there are change requests, list them. If there are no conflicts, show
nothing. If we don't know (because of no successful response from the
API), say that it might cause issues.
