This PR refactors the color picker so we stick to one set of colors
instead of changing available colors when theme changes. Colors picked
also work in dark theme and is aligned with UX.
This is exposing information we already have about permissions in a UI
that should help users have an overview of the permissions of a user
with regards to projects and environments
Adds focus styles to the env accordion header only when the focus is on
the header itself (not on the env toggle inside the header). The focus
style is consistent with what we do for other accordions (dashboard,
milestones).
Middle one is focused:
Focus is on the toggle inside the top one (yeh, we should have better
focus styles for toggles; but that's not for now):
Open and focused:
Getting the consistent background for the header when it's open is a
little tricky because the accordion container and summary are split into
different files. ~~This first iteration used a class name for the
specific header (because envs can have multiple accordion headers inside
them, e.g. release plans) and setting a CSS variable in the summary, so
that the background matches.~~ I found out that I only need to set it in
the parent anyway 😄
Without it, you get this (notice that there is a little white outside
the lower corners):
Makes two small changes to the release template UI based on walkthrough
feedback with UX
1) The how-to descriptions for creating release plans won't get hidden
when the user has created release plans. We think too much is better
than too little. At a later point we'll push users to documentation more
aggressively
2) The warning for when the user taps the "Use template" button now has
a line break to give it some breathing room and will render anchored to
the bottom left of the originating button rather than covering it
Implements the drag-n-drop tooltip the first time the user sees a
strategy drag handle on the feature env overview. It uses React Joyride,
which is the same system we use for the demo.
The design is a little different from the sketches because I couldn't
find a quick way to move the content (and the arrow) to be shifted
correctly.
If the demo is also active the first time a user visits a strategy page,
it'll render both the demo steps and this, but this tooltip doesn't
prevent the user from finishing the tour. It might be possible to avoid
that through checking state in localstorage, but I'd like to get this
approved first.
The tooltip uses the auth splash system to decide whether to show the
tooltip, meaning it's stored per user in the DB. To avoid it
re-rendering before you refetch from the back end, we also use a
temporary variable to check whether the user has closed it.
Rendered:
If the tour is also active:
Adds a new dialog option for whats in new in Unleash items. This can be
tiggerred by setting `popout` to true when configuring the items.
To do this without setting fire to the code, I've also needed to
refactor the NewInUnleash components:
- NewInUnleashItem becomes a dumb item that decides if a dialog or
tooltip should be rendered and controls that render state
- The child item in NewInUnleashItem has been moved out into
NewInUnleashSideBarItem, which feels a bit better since that is a
distinct UI element from the popup
- NewInUnleashDialog now exists, which is a dialog version of the popup.
Meaningfully different to ask for a new component
## Screenshots
Fixes janky drag and drop behavior and updates the styling of the drag
handle focus.
The solution uses the same method to prevent oscillation as we do for
strategies. To get access to the same context, I've added some extra
parameters to the OnMoveItem function and passed along the extra data
from the `useDragItem` hook. No new information, just making more of it
available, and turning it into an object so that you can declare the
properties you need (and get rid of potential wrong ordering of
drag/drop indices).
For the drag and drop behavior: If the dragged element is the same size
or smaller than the element you're dragging over, they will swap places
as soon as you enter that space. If the target element is larger,
however, they won't swap until you reach the drag/drop handle, even if
they could theoretically switch somewhere in the middle. This appears to
be a limitation of how the drag/drop event system works. New drag events
are only fired when you "dragenter" a new element, so it never fires
anywhere in the middle. Technically, we could insert more empty spans
inside the drag handle to trigger more events, but I wanna hold off on
that because it doesn't sound great.
When dragging, only the handle is visible; the rest of the card stays in
place. For strategies, we show a "ghost" version of the config you're
dragging. However, if you apply the drag handle to the card itself, all
of it becomes draggable, but you can no longer select the text inside
it, which is unfortunate. Strategies do solev this, though, but I
haven't been able to figure out why. If you know, please share!
Before:
After:
