Commit Graph

15 Commits

Author SHA1 Message Date
Robin Malfait 958e3ea8c6 bug fixes (#261)
* apply re-focus bug fix to Popover

* force focus in Menu.Items from within Menu.Items component itself

* force focus in Listbox.Options from within Listbox.Options component itself

* fix undefined values in id's

We were setting the element in state, but updates to the id were not taken into account

* update the caniuse db

* ensure useInertOthers works in multiple places

Previously each hook call would take care of the whole tree. However
when multiple calls to this hook are happening we need to make sure that
you are not removing the aria-hidden when another hook is still used.

This will fix that by keeping track of a list of "interactable" items,
and updating the parents (root of the body) accordingly.

* add the concept of a Stack

When you are rendering a Dialog, we will make sure that this Dialog is
rendered inside a Portal. However, when you are also rendering a Menu,
there is a chance that your Menu doesn't fit within the Dialog,
therefore you will likely render the Menu.Items inside a Portal so that
you can style it as if it is rendered inside but overflows the Dialog
correctly.

This introduces an interesting/annoying problem. Your Menu.Items are now
rendered in a Portal, as a *sibling* to the Dialog. This means that
autoFocus, focusTrap, ... all these features don't work as expected.

Introducing this Stack will allow us to register DOM nodes into a list
of contains that we consider being part of the main container. In other
words, the sibling Menu.Items will now be considered part of the Dialog.
Even though it is rendered *outside* of the Dialog.

This concept also allows for some fun stuff, for example, nesting
Dialog's is no problem with this approach. Dialogs are technically
rendered as siblings in the Portal, but the FocusTrap, and all that just
works as expected.

* capture keyboard events in the capturing phase

This will allow us to use event.stopPropagation() in the code (which
will be required, probably) but still see the keystrokes in the
playground.

* stop propagating keyboard events

This looks a bit silly, and ideally we can solve this in a more elegant
way. However when you nest a Menu inside a Dialog, both of those
components have a `close on escape` functionality built in. However when
your Menu is open, and you press escape, you only want to close the
Menu, not the Dialog. Therefore if we `event.stopPropagation()` it
allows us to stop the `escape` keystroke in the Menu from reaching all
the way to the Dialog itself.

* update Dialog example that showcases nested Dialogs, and nested Menu

* update changelog
2021-04-02 15:55:15 +02:00
Robin Malfait 648a2843e6 Multiple new components (#220)
* add Disclosure component

* expose the Disclosure component

* add Disclosure example component page

* temporary fix selector because of JSDOM bug

* add useFocusTrap hook

* add FocusTrap component

* expose FocusTrap

* add Dialog component

* add Dialog example component page

* expose Dialog

* random cleanup

* make TypeScript a bit more happy

* add Switch.Description component for React

* add Switch.Description component for Vue

* ensure focus event is triggered on click when element is focusable

* remove Dialog.Button and Dialog.Panel from accessibility assertions

* add Portal component

* expose Portal

* always render Dialog in a Portal

* add useInertOthers hook

This will allow us to mark everything but the current ref as "inert".
This is important for screenreaders, to ensure that screenreaders and
assistive technology can't interact with other content but the current
ref.

This implementation is not ideal yet. It doesn't take into account that
you can use the hook in 2 different components. For now this is fine,
since we only use it in a Dialog and you should also probably only have
a single Dialog open at a time.

Will improve this in the future!

* use the useInertOthers hook

* add scroll lock to the dialog

* ensure we respect autoFocus on form elements within the Dialog

If we have an autoFocus on an input, that input will receive focus. Once
we try to focus the first focusable element in the Dialog this could be
lead to unwanted behaviour. Therefore we check if the focus already is
within the Dialog, if it is, keep it like that.

* only mark aria-modal when Dialog is open

* add initialFocus option to Dialog, FocusTrap & useFocusTrap

* add tests and a few fixes for the initialFocusRef functionality

* forward ref to underlying Dialog component

* close Dialog when it becomes hidden

Could happen when this is in md:hidden for example

* prevent infinite loop

When we `Tab` in a FocusTrap it will try and focus the Next element. If
we are in a state where none of the elements inside the FocusTrap can be
focused, then we keep trying to focus the next one in line. This results
in an infinite loop...

To mitigate this issue, we check if we looped around, if we did, it
means that we tried all the other focusable elements, therefore we can
stop.

* isIntersecting doesn't work in every scenario

When page is scrollable, when dialog is translated of the page. Now just checking for sizes, which should be enough for md:hiden cases

* render Portal contents in a div

Otherwise you can't use multiple Portal components if you render multiple children inside each Portal

* ensure the props bag is typed

* add getByText and assertContainsActiveElement helpers

* add Popover component

* expose Popover

* add Popover example component page

* add quick checks to prevent useless renders

* drop incorrect close function

* update Changelog

* make test error more readable when comparing DOM nodes

* actually call .focus() on the element

This ensures that the document.activeElement becomes the focused element.

* improve useSyncRefs, because ...refs is *always* different

* add dedicated focus management utilities

* refactor useFocusTrap, use focus management utilities

* fix regression while using outside click

There might be a chance that you didn't even notice this *bug*. The idea
is that when you click outside, that the Menu or Listbox closes. However
there is another step that happens:

1. When you click on a focusable item, keep the focus on that item.
2. When you click on a non-focusable item, move focus back to the
   Menu.Button or Listbox.Button

We broke part 2, we never returned to the Menu.Button or Listbox.Button.
This is (might) be important for screenreaders so that they don't "get lost",
because if you click on a non-focusable item, the document.body becomes
the active element. Confusing.

* add outside-click to Dialog itself

* update docs
2021-04-02 15:55:14 +02:00
Robin Malfait ef00732685 cleanup and consistency (#213)
- Made the use of `const` and `let` consistent
- import required functions and types from 'react' instead of using the
  `React.` namespace.
- Added `Expand` type, which can expand complex types to their "final"
  result.
- Ensured that we use `as const` for DEFAULT_XXX_TAG where we used a
  string. So that we have the type of `div` instead of `string` for
  example.
- Used `interface` over `type` where possible. I'm personally more of a
  `type` fan. But the TypeScript recommends `interfaces` where possible
  because they are faster, yield better error messages and so on.
2021-01-30 14:46:54 +01:00
Robin Malfait 24725216e4 fix: outside click refocus bug (#114)
* add watch script

* make interactions in Vue and React consistent

* re-work focus restoration

When we click outside of the Menu or Listbox, we want to
restore the focus to the Button, *unless* we clicked on/in an element
that is focusable in itself. For example, when the Menu is open and you
click in an input field, the input field should stay focused. We should
also close the Menu itself at this point.

* add examples with multiple elements

* bump dependencies
2020-10-20 15:38:12 +02:00
Robin Malfait aab23c9077 feat: add render features + render strategy (#106)
* add unmount strategy to README (React)

* add unmount strategy to README (Vue)

* add different render features (React)

* use render features in Menu and Listbox (React)

* add different render features (Vue)

* use render features in Menu and Listbox (Vue)

* bump dependencies

* add ability to change the ref property using `refName`

Example use case:

```tsx
// Some components have this API with an `innerRef`. The suggested approach is to use
// `React.forwardRef` so that you get the actual `ref` value. However if you already have this
// `innerRef` API than we can use the `refName="innerRef"` to give the `ref` prop a good name. It
// defaults to `ref` so that it still works everywhere else.

function MyButton({ innerRef, ...props }) {
  return <button ref={innerRef} {...props} />
}

<Menu.Button as={MyButton} refName="innerRef" />
```

* small cleanup, move refs to props we control

* add tests for the render abstraction (Render)

+ use the unique __ symbol as a default value in the Props type for the
  omitable props.

* use render features in Transition (React)

* add/update Transition examples to also showcase the `unmount={false}` render strategy

* bump dependencies

* add example with nested unmount/hide transitions

* add unmount to Transition documentation
2020-10-18 15:34:05 +02:00
Robin Malfait a5089d07b1 feat: Add Transition events (#57)
* fix wrong class in tests

* add Transition event callbacks

* add Transition Modal example with Event callbacks

* update props table of Transition component
2020-10-08 15:30:10 +02:00
Robin Malfait 6e3d496998 feat: add Switch component (#26)
* add Switch component

* add tests to verify that we can click the label to toggle the Switch

* use onKeyUp to prevent triggering the onClick in firefox
2020-10-05 16:47:31 +02:00
Arno Schutijzer ef25b08cb2 docs: fix typo (#29) 2020-10-02 22:59:07 +02:00
Robin Malfait 99ecdaefd4 update branding
Replace Tailwind UI with Headless UI
2020-10-02 13:56:47 +02:00
Robin Malfait 58ff88698b feat: add Listbox component (#3)
* make jest monorepo aware

* add @testing-library/jest-dom for custom matchers

This way we can use expect(element).toHaveAttribute(key, value?)

* abstract keys enum

* change type to unknown, because we don't know the return value

* update use-id hook, make it suspense aware

Thanks Reach UI!

* hoist the disposables collection

* add accessbility assertions for listbox

Also made it consistent for the Menu component and simplified some of the assertions

* add use-computed hook

This allows us re-render when hooks change, but also return a value. So this is a combination of useEffect and a useState value.

* add Listbox component

* bump dependencies

* add listbox example

* add lint-staged

This way we will only lint the files that have been staged and ready to be committed instead of the whole codebase

* add missing prevent defaults

* improve tests to verify that we can actually update the value of the listbox

* scroll the active listbox item into view

* small optimization, only focus "Nothing" on pointer leave when we are the active item

We used to always go to "Nothing" on pointer leave. And while this code
doesn't get called often, it *gets* called if you are using your arrow
keys and the mouse pointer is still over the list.

* bump dependencies

Also moved the tailwind dependencies to the root

* fix typo

* drop the default Transition inside the Menu and Listbox components

* update examples to reflect drop of default Transition wrapper

* rename Listbox.{Items,Item} to Listbox.{Options,Option}

Also rename all instances of `item` to `option` in tests and comments
and what have you...

* fix typo

* drop disabled prop, use aria-disabled only
2020-10-02 11:05:41 +02:00
Robin Malfait 4a6048ef6c make examples between Vue and React consistent 2020-09-21 23:25:09 +02:00
Robin Malfait 1f29594414 add Menu examples in React 2020-09-21 12:50:44 +02:00
Robin Malfait eed9f85b93 prerender 404 pages with a table of contents of all examples 2020-09-20 21:18:27 +02:00
Robin Malfait 6757fad6a4 use correct package reference 2020-09-17 11:01:51 +02:00
Robin Malfait 8b546f054b setup @headlessui/react package 2020-09-16 18:20:49 +02:00