Removes the view diff hover links (and strategy icons) in the new views
and removes trailing colons.
In removing the hover links, I have split up the content of their files
(`StrategyTooltipLink` and `SegmentTooltipLink`) into
`Change{Segment|Strategy}Name` and `{Segment|Strategy}Diff`. I have
reverted the existing tooltip files to their state before I began
changing this and added deprecation notices. These old tooltips are only
used by the old components, so we don't need to work on them after all.
In doing this work, I've also updated the strategy change diff to handle
the new functionality (tabs instead of hover)
The removal of the trailing colons (so that it's `adding strategy
gradual rollout` instead of `adding strategy: gradual rollout` is in
preparation for the remaining changes to the header that we're
introducing with this change. The removal of these is not behind a flag,
so I've also done it in the legacy components. This feels like a very
low risk change, so it felt like more work to have to check a flag for
each of the different instances where we use it.
<img width="839" alt="image"
src="https://github.com/user-attachments/assets/b29b8073-c282-4b4b-948f-9a545082ac31"
/>
We don't want deleted strategies to have the red background color
anymore with the new change/diff view. As such, we can remove it in the
new component and add a todo to delete the css for it after it's gone.
<img width="1050" alt="image"
src="https://github.com/user-attachments/assets/083cbcac-5df9-47cd-bd78-2501c3bbf64e"
/>
Updates the strategy change component used in change requests to have a
"tab"-like functionality, where you can switch between "Change" (the
rendered strategy) and "View diff" (the JSON diff). This is a tab
switcher, so you navigate it with arrow keys if on a keyboard, and I've
set selection to follow focus for now. This is my preference as it saves
you extra space/enter taps, but we can remove it later if we want.
Most of the changes in this PR is wrapping the existing strategy change
components/sections in tab panels and tab context providers.
Later changes in this project will remove the existing "view diff" hover
link in favor of this view.
There is some work to do on the design front (in terms of spacing,
borders, etc), but this covers the core functionality.
The pre-existing strategy change component has been moved into the
"LegacyStrategyChange" file with no changes beyond a deprecation
comment. The existing tests now test the new component instead with no
breakage. (I anticipate breaking when we remove the view diff link,
though)
Change with strategy variants:
<img width="991" alt="image"
src="https://github.com/user-attachments/assets/ac28912f-5b08-4a9c-96da-81bfd0b2e68e"
/>
<img width="1005" alt="image"
src="https://github.com/user-attachments/assets/4addaacc-101c-46cb-888f-95dc3b1cac25"
/>
## Edge case: deleted strat with no reference strategy
There is a case in the code where "reference strategy" can be undefined
for a deleted strategy. It is defined as follows:
```ts
const referenceStrategy =
changeRequestState === 'Applied'
? change.payload.snapshot
: currentStrategy;
```
I've decided to still show the "(no changes)" json diff in that setting,
so that the tabs actually affect something. I don't know how often this
happens, though: probably not anymore unless your CR is _ancient_, as we
introduced the snapshot quite a while ago, and `currentStrategy`
shouldn't really be undefined here, I should think.
Deleted strategy with no reference strategy:
Change:
<img width="1013" alt="image"
src="https://github.com/user-attachments/assets/352eaec9-c0ef-4d5a-b765-11304daf4474"
/>
Diff:
<img width="1029" alt="image"
src="https://github.com/user-attachments/assets/e69c81a6-1ef7-47ff-853a-9fb900b26303"
/>
Follow-up to: https://github.com/Unleash/unleash/pull/10213
This makes our `AddValuesPopover` backdrop click-through. This means you
can interact with any element in the "background" right away and it will
work, while closing the popover at the same time.
If this works well it may be worth extracting to a reusable
ClickThroughPopover or similar.
Adds a number of small corrections and fixes to (mainly) CR-related
component. Discovered as part of adding the new JSON diff view. Refer to
the various inline comments for explanations.
---------
Co-authored-by: Tymoteusz Czech <2625371+Tymek@users.noreply.github.com>
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.
