Previously since query params were changing by global search, and
menubar was also altering them, they were conflicting. Menubar does not
need query params as state. So using search hook directly.
Now searching works in command bar
1. Currently piggybacking on the search hook, but I think it is not fast
enough, and also it is using the query params as the global search. This
causes some weird behaviour in UI. This probably means we will create
separate endpoint for this.
![image](https://github.com/Unleash/unleash/assets/964450/a24f41ae-93d7-4ebe-a92b-c20dfe7cb666)
This PR disables the filtering capability in the front end for unknown
users.
Modifying the back end to support filtering for unknown users is not
something we want to do yet. It's possible, but it requires adding a lot
of special cases to the handling code (refer to [PR
#7359](https://github.com/Unleash/unleash/pull/7359)), which we'd like
to avoid if possible. To avoid annoying cases where the filtering
doesn't work as expected and breaks user expectations, we're disabling
the filtering capability for unknown users in the front end.
We can consider whether to enable back-end results for unknown in the future if we get
user feedback that it's important.
This PR works by changing the avatar cell component. When the user has
id 0 (and is therefore unknown), we:
- set aria-disabled to true. This alerts users with assistive tech that
the button is disabled, but it doesn't take it out of the tab order, so
it's not mysteriously missing.
- change the tooltip text, telling users that they can't filter by
unknown users.
- disable the avatar callback function, so clicking on the avatar
doesn't do anything.
The accompanying tests assert this functionality.
I considered also updating the screen reader text, but I think that
would add more confusion or be more information than the user needs.
According to MDN's article on the [aria-disabled
attribute](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled):
> [the aria-disabled] declaration will inform people using assistive
technologies, such as screen readers, that such elements are not meant
to be editable or otherwise operable.
**Upgrade to React v18 for Unleash v6. Here's why I think it's a good
time to do it:**
- Command Bar project: We've begun work on the command bar project, and
there's a fantastic library we want to use. However, it requires React
v18 support.
- Straightforward Upgrade: I took a look at the upgrade guide
https://react.dev/blog/2022/03/08/react-18-upgrade-guide and it seems
fairly straightforward. In fact, I was able to get React v18 running
with minimal changes in just 10 minutes!
- Dropping IE Support: React v18 no longer supports Internet Explorer
(IE), which is no longer supported by Microsoft as of June 15, 2022.
Upgrading to v18 in v6 would be a good way to align with this change.
TS updates:
* FC children has to be explicit:
https://stackoverflow.com/questions/71788254/react-18-typescript-children-fc
* forcing version 18 types in resolutions:
https://sentry.io/answers/type-is-not-assignable-to-type-reactnode/
Test updates:
* fixing SWR issue that we have always had but it manifests more in new
React (https://github.com/vercel/swr/issues/2373)
---------
Co-authored-by: kwasniew <kwasniewski.mateusz@gmail.com>
This PR lets you filter by flag creator by interacting with the user's
avatar.
Additionally, I've switched the custom popover for the standard tooltip
that we use elsewhere in the table. This gives the table a more cohesive
feel. As such, I have also deleted the component created in a previous
PR, because it's no longer in use anywhere.
It now looks like this (when tabbed to; notice the focus ring):
![image](https://github.com/Unleash/unleash/assets/17786332/d321d9df-0b17-49c3-bea7-89331df3f994)
What the title says. There are input values that are whitespace
sensitive, so this will trim clientId and entity field, preventing the
form from sending leading or trailing whitespace. Will make a PR on
enterprise as well to trim on the backend as well.
This PR fixes a bug where if you navigated to the projects page via the
menu, scrolled down, and hovered over a project's avatars, you'd be
scrolled to the top of the page when you moused off the avatar.
Turns out this issue was also in the group cards. It seems to be that
the popover attempts to restore focus back to where you where, which, if
you navigated via the menu, is at the top of the page. Because these
popovers don't have any focusable content, we can disable that
functionality.
Additionally, I've disabled the scroll lock when the popover is open.
The scroll lock made it impossible to scroll when one of the popovers is
open, which is confusing as a user.
This change adds information about the project modes to the new
project creation form, using the tooltip for project creation modes.
In doing so, it updates the config button tooltip to accept extra
elements and adds styling for them.
What it looks like:
![image](https://github.com/Unleash/unleash/assets/17786332/809fb48e-2404-416b-a867-6fa04978ccc1)
## a11y issues
This solution does present one problem: the popover doesn't get focus,
so it's impossible for you to scroll with only a keyboard. However, this
is something that's present in Unleash already, and not something that I
think would be easily solvable, so I don't think this is when we should
solve it.
1. Only suggest to create a tag value if the input is more than two
characters after trimming.
2. Ignore trailing and leading whitespace when considering which
autocomplete options to show
This PR changes the project screen by calling the main tab "flags"
instead of "overview". There isn't really an overview available on that
tab anymore, only a list of flags.