* menu should not trap focus for tab key
* introduce `focusFrom` focus management utility
This is internal API, and the actual API is not 100% ideal. I started
refactoring this in a separate branch but it got out of hand and touches
a bit more pieces of the codebase that aren't related to this PR at all.
The idea of this function is just so that we can go Next/Previous but
from the given element not from the document.activeElement. This is
important for this feature. We also bolted this ontop of the existing
code which now means that we have this API:
```js
focusIn([], Focus.Previouw, true, DOMNode)
```
Luckily it's internal API only!
* ensure closing via Tab works as expected
Just closing the Menu isn't 100% enough. If we do this, it means that
when the Menu is open, we press shift+tab, then we go to the
Menu.Button because the Menu.Items were the active element.
The other way is also incorrect because it can happen if you have an
`<a>` element as one of the Menu.Item elements then that `<a>` will
receive focus, then the `Menu` will close unmounting the focused `<a>`
and now that element is gone resulting in `document.body` being the
active element.
To fix this, we will make sure that we consider the `Menu` as 1 coherent
component. This means that using `<Tab>` will now go to the next element
after the `<Menu.Button>` once the Menu is closed.
Shift+Tab will go to the element before the `<Menu.Button>` even though
you are currently focused on the `Menu.Items` so depending on the timing
you go to the `Menu.Button` or not.
Considering the Menu as a single component it makes more sense use the
elements before / after the `Menu`
* update changelog
Co-authored-by: Enoch Riese <enoch.riese@gmail.com>
* convert dialog in playground to use Dialog.Panel
* convert `tabs-in-dialog` example to use `Dialog.Panel`
* add scrollable dialog example to the playground
* simplify `outside click` behaviour
Here is a little story. We used to use the `click` event listener on the
window to try and detect whether we clicked outside of the main area we
are working in.
This all worked fine, until we got a bug report that it didn't work
properly on Mobile, especially iOS. After a bit of debugging we switched
this behaviour to use `pointerdown` instead of the `click` event
listener. Worked great! Maybe...
The reason the `click` didn't work was because of another bug fix. In
React if you render a `<form><Dialog></form>` and your `Dialog` contains
a button without a type, (or an input where you press enter) then the
form would submit... even though we portalled the `Dialog` to a
different location, but it bubbled the event up via the SyntethicEvent
System. To fix this, we've added a "simple" `onClick(e) { e.stopPropagation() }`
to make sure that click events didn't leak out.
Alright no worries, but, now that we switched to `pointerdown` we got
another bug report that it didn't work on older iOS devices. Fine, let's
add a `mousedown` next to the `pointerdown` event. Now this works all
great! Maybe...
This doesn't work quite as we expected because it could happen that both
events fire and then the `onClose` of the Dialog component would fire
twice. In fact, there is an open issue about this: #1490 at the time of
writing this commit message.
We tried to only call the close function once by checking if those
events happen within the same "tick", which is not always the case...
Alright, let's ignore that issue for a second, there is another issue
that popped up... If you have a Dialog that is scrollable (because it is
greater than the current viewport) then a wild scrollbar appears (what a
weird Pokémon). The moment you try to click the scrollbar or drag it the
Dialog closes. What in the world...?
Well... turns out that `pointerdown` gets fired if you happen to "click"
(or touch) on the scrollbar. A click event does not get fired. No
worries we can fix this! Maybe...
(Narrator: ... nope ...)
One thing we can try is to measure the scrollbar width, and if you
happen to click near the edge then we ignore this click. You can think
of it like `let safeArea = viewportWidth - scrollBarWidth`. Everything
works great now! Maybe...
Well, let me tell you about macOS and "floating" scrollbars... you can't
measure those... AAAAAAAARGHHHH
Alright, scratch that, let's add an invisible 20px gap all around the
viewport without measuring as a safe area. Nobody will click in the 20px
gap, right, right?! Everything works great now! Maybe...
Mobile devices, yep, Dialogs are used there as well and usually there is
not a lot of room around those Dialogs so you almost always hit the
"safe area". Should we now try and detect the device people are
using...?
/me takes a deep breath...
Inhales... Exhales...
Alright, time to start thinking again... The outside click with a
"simple" click worked on Menu and Listbox not on the Dialog so this
should be enough right?
WAIT A MINUTE
Remember this piece of code from earlier:
```js
onClick(event) {
event.stopPropagation()
}
```
The click event never ever reaches the `window` so we can't detect the
click outside...
Let's move that code to the `Dialog.Panel` instead of on the `Dialog`
itself, this will make sure that we stop the click event from leaking
if you happen to nest a Dialog in a form and have a submitable
button/input in the `Dialog.Panel`. But if you click outside of the
`Dialog.Panel` the "click" event will bubble to the `window` so that we
can detect a click and check whether it was outside or not.
Time to start cleaning:
- ☑️ Remove all the scrollbar measuring code...
- Closing works on mobile now, no more safe area hack
- ☑️ Remove the pointerdown & mousedown event
- Outside click doesn't fire twice anymore
- ☑️ Use a "simple" click event listener
- We can click the scrollbar and the browser ignores it for us
All issues have been fixed! (Until the next one of course...)
* ensure a `Dialog.Panel` exists
* cleanup unnecessary code
* use capture phase for outside click behaviour
* further improve outside click
We added event.preventDefault() & event.defaultPrevented checks to make
sure that we only handle 1 layer at a time.
E.g.:
```js
<Dialog>
<Menu>
<Menu.Button>Button</Menu.Button>
<Menu.Items>...</Menu.Items>
</Menu>
</Dialog>
```
If you open the Dialog, then open the Menu, pressing `Escape` will close
the Menu but not the Dialog, pressing `Escape` again will close the
Dialog.
Now this is also applied to the outside click behaviour.
If you open the Dialog, then open the Menu, clicking outside will close
the Menu but not the Dialog, outside again will close the Dialog.
* add explicit `enabled` value to the `useOutsideClick` hook
* ensure outside click properly works with Poratl components
Usually this works out of the box, however our Portal components will
render inside the Dialog component "root" to ensure that it is inside
the non-inert tree and is inside the Dialog visually.
This means that the Portal is not in a separate container and
technically outside of the `Dialog.Panel` which means that it will close
when you click on a non-interactive item inside that Portal...
This fixes that and allows all Portal components.
* update changelog
* sort React imports
* improve type signature of the `useEvent` hook
* use more correct `useIsoMorphicEffect` check in `useEvent`
* refactor `useCallback` to cleaner `useEvent`
* convert `const` to `let`
Just for consistency..
* cleanup `Tabs` code
Created explicit functions that can be called from child components
instead of calling `dispatch` directly. Introduced a `useData` and
`useActions` hook to make child components easier.
The seperation of `useData` allows us to pass down props directly
instead of going via the `useReducer` hook and dispatching actions to
make values up to date.
* cleanup `Combobox` code
* cleanup `RadioGroup` code
* bump dev dependencies to React 18
* setup Jest to include `IS_REACT_ACT_ENVIRONMENT`
* prefer `useId` from React 18 if it exists
In React 16 & 17, where `useId` doesn't exist, we will fallback to our
implementation we have been using up until now.
The `useId` exposed by React 18, ensures stable references even in SSR
environments.
* update expected events
React 18 now uses the proper events:
- `blur` -> `focusout`
- `focus` -> `focusin`
* ensure to wait a bit longer
This is a bit unfortunate, but since React 18 now does an extra
unmount/remount in `StrictMode` to ensure that your code is
ConcurrentMode ready, it takes a bit longer to settle what the DOM sees.
That said, this is a temporary "hack". We are going to experiment with
using tools like Puppeteer/Playwright to run our tests in an actual
browser instead to eliminate all the weird details that we have to keep
in mind.
* prefer `.focus()` over `fireEvent.focus(el)`
* abstract `microTask` polyfill code
* prefer our `focus(el)` function over `el.focus()`
Internally we would still use `el.focus()`, but this allows us to have
more control over that `focus` function.
* add React 18 to the React Playground
* improve hooks for React 18
- Improving the cleanup of useEffect hooks
- useIsoMorphicEffect instead of normal useEffect, so that we can use
useLayoutEffect to be a bit quicker.
* improve disposables
- This allows us to add event listeners on a node, and get automatic
cleanup once `dispose` gets called.
- We also return all the `d.add` calls, so that we can cleanup specific
parts only instead of everything or nothing.
* reimplement the Transition component to be React 18 ready
* wait an additional frame for everything to settle
* update playground examples
* suppressConsoleLogs for RadioGroup components
* update changelog
* keep the `to` classes for a smoother transition
In the next transition we will remove _all_ classes provided and re-add
the once we need.
---
Some extra special thanks:
- Thanks @silvenon for your initial work on the `transition` events in #926
- Thanks @thecrypticace for doing late-night debugging sessions
Co-authored-by: =?UTF-8?q?Matija=20Marohni=C4=87?= <matija.marohnic@gmail.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* rename inconsistent `passThroughProps` and `passthroughProps` to more
concise `incomingProps`
This is going to make a bit more sense in the next commits of this
branch, hold on!
* split props into `propsWeControl` and `propsTheyControl`
This will allow us to merge the props with a bit more control. Instead
of overriding every prop from the user' props with our props, we can now
merge event listeners.
* update `render` API to accept `propsWeControl` and `propsTheyControl`
* improve the merge logic
This will essentially do the exact same thing we were doing before:
```js
let props = { ...propsTheyControl, ...propsWeControl }
```
But instead of overriding everything, we will merge the event listener
related props like `onClick`, `onKeyDown`, ...
* fix typo in tests
* simplify naming
- Rename `propsWeControl` to `ourProps`
- Rename `propsTheyControl` to `theirProps`
* update changelog
* remove raw `document.getElementById` calls
When we introduced the `forwardRef` for all components, we also made
sure that internal `ref`s were used to keep track of the actual DOM
node.
This code prefers the `internalXXRef` refs in favor of the
`document.getElementById` calls. This is way more React-ish, and also
fixes a few issues:
- Potential performance improvements (no need to re-query the DOM, since
we already have a reference to the DOM node). Note: this is a *guess*,
I didn't measure this.
- It could be that the element is rendered in another `document`, the
correct would involve something like
`someDOMNode.ownerDocument.getElementById(...)` but that should not be
necessary anymore now.
* make Disclosure implementation between React & Vue consistent
* use a similar convention for DOM refs to other components
* update changelog
* adjust active {item,option} index
We had various ordering issues, and now we properly sort all the notes
which is awesome. However, there is this case where we still use the
`activeOptionIndex` / `activeItemIndex` from _before_ the sort happens.
Now we will ensure that this is properly adjusted when performing the
sort of the items.
In addition, we will also properly adjust these values when
`registering` and `unregistering` items, not only when performing
actions.
* update changelog
* improve outside click support
We used to use `pointerdown`, but some older devices with iOS 12 didn't
have support for that. Instead we used `mousedown`. But now it turns out
that some devices only properly use `pointerdown` and not the `mousedown` event.
Instead, we will listen to both, but make sure to only handle the event
once.
* update changelog
* ensure proper sort order
We already fixed a bug in the past where the order of DOM nodes wasn't
stored in the correct order when performing operations (e.g.: using your
keyboard to go to the next option).
We fixed this by ensuring that when we register/unregister an
option/item, that we sorted the list properly. This worked fine, until
we introduced the Combobox components. This is because items in a
Combobox are continuously filtered and because of that moved around.
Moving a DOM node to a new position _doesn't_ require a full
unmount/remount. This means that the sort gets messed up and the order
is wrong when moving around again.
To fix this, we will always perform a sort when performing actions. This
could have performance drawbacks, but the alternative is to re-sort when
the component gets updated. The bad part is that you can update a
component via many ways (like changes on the parent), in those
scenario's you probably don't care to properly re-order the internal
list. Instead we do it while performing an action (`goToOption` / `goToItem`).
To make things a bit more efficient, instead of querying the DOM all the
time using `document.querySelectorAll`, we will keep track of the
underlying DOM node instead. This does increase memory usage a bit but I
think that this is a fine trade-off.
Performance wise this could also be a bottleneck to perform the sorting
if you have a lot of data. But this problem already exists today,
therefore I consider this a complete new problem instead to solve. Maybe
we don't solve it in Headless UI itself, but figure out a way to make it
composable with existing virtualization libraries.
* update changelog
* disable scroll when hover list item
* change API a bit
* fix scroll into view
For keyboard only for Combobox, Listbox and Menu for both React and Vue.
* update changelog
Co-authored-by: yuta-ike <38308823+yuta-ike@users.noreply.github.com>
* forward ref to all components
* fix playground pages
This isn't a perfect fix of course. But the TypeScript changes required
to do it properly are a bit bigger and require more work.
Having this ready is a good step forward.
* update changelog
* trigger scrollIntoView effect when position changes
This is important otherwise it could happen that the current active item
is still the active item even if we inserted X items before the current
one. This will result in the active item being out of the current
viewport. To fix this, we will also make sure to trigger the effect if
the position of the active item changes.
* update changelog
* use esbuild for React instead of tsdx
* remove tsdx from Vue
* use consistent names
* add jest and prettier
* update scripts
* ignore some folders for prettier
* run lint script instead of tsdx lint
* run prettier en-masse
This has a few changes because of the new prettier version.
* bump typescript to latest version
* make typescript happy
* cleanup playground package.json
* make esbuild a dev dependency
* make scripts consistent
* fix husky hooks
* add dedicated watch script
* add `yarn playground-react` and `yarn react-playground` (alias)
This will make sure to run a watcher for the actual @headlessui/react
package, and start a development server in the playground-react package.
* ignore formatting in the .next folder
* run prettier on playground-react package
* setup playground-vue
Still not 100% working, but getting there!
* add playground aliases in @headlessui/vue and @headlessui/react
This allows you to run `yarn react playground` or `yarn vue playground`
from the root.
* add `clean` script
* move examples folder in playground-vue to root
* ensure new lines for consistency in scripts
* fix typescript issue
* fix typescript issues in playgrounds
* make sure to run prettier on everything it can
* run prettier on all files
* improve error output
If you minify the code, then it could happen that the errors are a bit
obscure. This will hardcode the component name to improve errors.
* add the `prettier-plugin-tailwindcss` plugin, party!
* update changelog
* improve typeahead search logic
This ensures that if you have 4 items:
- Alice
- Bob
- Charlie
- Bob
And you search for `b`, then you jump to the first `Bob`, but if yuo
search again for `b` then we used to go to the very first `Bob` because
we always searched from the top. Now we will search from the active item
and onwards. Which means that we will now jump to the second `Bob`.
* update changelog
* ensure correct order in `Menu.Item`
* Update Vue version of menu component ordering issue
* ensure correct order of `Listbox.Option`s
* add test to verify that RadioGroup.Option order is correct
* ensure correct order of `ListboxOption`s
* cleanup
* add test to verify that `RadioGroupOption` order is correct
* update changelog
* use similar a,z signature compared to other places
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* add `{type:'button'}` only for buttons
We will try and infer the type based on the passed in `props.as` prop or
the default tag. However, when somebody uses `as={CustomComponent}` then
we don't know what it will render. Therefore we have to pass it a ref
and check if the final result is a button or not. If it is, and it
doesn't have a `type` yet, then we can set the `type` correctly.
* update changelog
* encode expected `aria-expanded` behaviour
* ensure `aria-expanded` has the correct value
`aria-expanded` can be in 3 different states:
| Value | Description |
| ------------------- | -------------------------------------------------------------------------- |
| false | The grouping element this element owns or controls is collapsed. |
| true | The grouping element this element owns or controls is expanded. |
| undefined (default) | The element does not own or control a grouping element that is expandable. |
Ref: https://www.w3.org/TR/wai-aria-1.2/#aria-expandedFixes: #580
* ensure `disabled` prop in Vue is not rendered when `false`
* update changelog
* only destructure from props inside render
* conditionally ensure that tabindex -1 exists
* reflect `disabled` prop in React as well
* update changelog
* ensure that you can use Transition Child components
When you are using the implicit variants of the components, for example
when you are using a Transition component inside a Menu component then
it might look weird in Vue.
The Vue code could look like this:
```
<Menu>
<TransitionRoot>
<MenuItems>...</MenuItems>
</TransitionRoot>
<Menu>
```
However, `TransitionRoot` doesn't make much sense here because it sits
in the middle of 2 components, and it is also not controlled by an
explicit `show` prop.
This commit will allows you to use a `TransitionChild` instead (in fact,
both work).
We basically now do a few things, when you are using a TransitionChild:
- Do we have a parent `TransitionRoot`? Yes -> Use it
- Do we have an open closed state? Yes -> Render a TransitionRoot in
between behind the scenes.
- Throw the error we were throwing before!
* update changelog
* simplify examples by using the implicit open/closed state
* introduce Open/Closed context (React)
* use Open/Closed context in Dialog component (React)
* use Open/Closed context in Disclosure component (React)
* use Open/Closed context in Listbox component (React)
* use Open/Closed context in Menu component (React)
* use Open/Closed context in Popover component (React)
* use Open/Closed context in Transition component (React)
* introduce Open/Closed context (Vue)
* use Open/Closed context in Dialog component (Vue)
* use Open/Closed context in Disclosure component (Vue)
* use Open/Closed context in Listbox component (Vue)
* use Open/Closed context in Menu component (Vue)
* use Open/Closed context in Popover component (Vue)
* use Open/Closed context in Transition component (Vue)
* use a ref in the Description comopnent
This allows us to update the ref and everything should work after that.
Currently we only saw the "current" state.
* add more Vue examples
* update changelog
* Fixed typos (#350)
* chore: Fix typo in render.ts (#347)
* Better vue link (#353)
* Better vue link
* add better React link
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Enable NoScroll feature for the initial useFocusTrap hook (#356)
* enable NoScroll feature for the initial useFocusTrap hook
Once you are using Tab and Shift+Tab it does the scrolling.
Fixes: #345
* update changelog
* Revert "Enable NoScroll feature for the initial useFocusTrap hook (#356)"
This reverts commit 19590b07624d7e3d751cbf11de869dfb0ea432ba.
Solution is not 100% correct, so will revert for now!
* Improve search (#385)
* make search case insensitive for the listbox
* make search case insensitive for the menu
* update changelog
* add `disabled` prop to RadioGroup and RadioGroup Option (#401)
* add `disabled` prop to RadioGroup and RadioGroup Option
Also did some general cleanup which in turn fixed an issue where the
RadioGroup is unreachable when a value is used that doesn't exist in the
list of options.
Fixes: #378
* update changelog
* Fix type of `RadioGroupOption` (#400)
Match RadioGroupOption value types to match modelValue allowed types for RadioGroup
* update changelog
* fix typo's
* chore(CI): update main workflow (#395)
* chore(CI): update main workflow
* Update main.yml
* fix dialog event propagation (#422)
* re-export the `screen` utility for quick debugging purposes
* stop event propagation when clicking inside a Dialog
Fixes: #414
* improve dialog escape (#430)
* Make sure that `Escape` only closes the top most Dialog
* update changelog
* add defaultOpen prop to Disclosure component (#447)
* add defaultOpen prop to Disclosure component
* update changelog
Co-authored-by: Shuvro Roy <shuvro.roy@northsouth.edu>
Co-authored-by: Alex Nault <nault.alex@gmail.com>
Co-authored-by: Eugene Kopich <github@web2033.com>
Co-authored-by: Nathan Shoemark <n.shoemark@gmail.com>
Co-authored-by: Michaël De Boey <info@michaeldeboey.be>
* increase maximum error offset for CI tests
We try to detect how long durations took. However there is no nice way
to time this in JSDOM. Instead we take snapshots every
requestAnimationFrame and when things change we also write down the
time.
This solution is not ideal and results in false positives (especially on
CI environments).
However, it is good enough to ensure that the duration is not 0 and not
500.
* cleanup README's and link to docs site
* remove readme's in favor of doc site
This will be easier, so that we don't have to maintain multiple repo's.
* add useTreeWalker hooks
We got a PR to fix the createTreeWalker so that it also works in IE11.
We don't actively support IE11, so if things work (with polyfills) then
it's good but I don't want to maintain IE11 specific code.
That said, I wanted to abstract the createTreeWalker code to a nice
little hook. The fix for IE is also pretty small, it uses a function
instead of an object and it has a last argument that is deprecated, but
has no obvious effect for our use cases.
Since the incoming PR was based on the `main` branch (where we only had
1 reference to createTreeWalker), I wanted to make sure that we got all
the references on the latest `develop` branch.
Closes: #295
Co-authored-by: Simon VDB <simonvdbroeck@gmail.com>
* use useTreeWalker hook
Co-authored-by: Simon VDB <simonvdbroeck@gmail.com>
When we are listening to a keydown event, and when a `space` event
enters. If you then event.preventDefault(), then we still trigger the
click event in firefox. To get around this, we have to make sure that we
cancel the `space` event in the keyup event.
* add little editor hack
By adding a html`..` to the template strings editors can get syntax
highlighting for these template strings. Even better, prettier can even
format the contents inside those because now it is "aware" of what kind
of content is inside of these template strings.
You might notice that for the Menu component I have a jsx`..`, this is
another little hack, this only provides us with syntax highlighting and
not with prettier support.
The reason why we have this is that for some reason, when you have:
html`
<MenuItem>
`
It will be formatted as:
html`
<menuitem>
`
There might exist a better name we can use instead of jsx, but for now,
this will do. Having syntax highlighting is already 10x better than what
we had before!
* add Alert component
* update changelog
* update REACT readme for Alert component
* expose Alert component
* add Disclosure component
* expose Disclosure component
* add FocusTrap component
* add FocusTrap example
* expose FocusTrap
* update test utils
We've been making some changes in the React utils, so we have to update
them here as well!
* add Popover component
* expose Popover
* drop unused state
* type Disclosure's API object
* add Portal component
* add Portal example
* expose Portal component
* use correct containElement assertion
* add useInertOthers hook
* add Dialog component
* fix various typo's
* expose Dialog
* add Popover example
* force focus on the Popover button on click
* drop own id when using labels
We are nesting the Label and Description components, if we also add the
id of ourselves we get strange results when using Voice Over.
First you would hear the contents (which includes the labels and
descriptions) then you would hear the labels and descriptions again.
We don't want to hear things twice!
* add Dialog example
* ensure to stop propagation
Otherwise if you nest a Menu inside a Dialog and you press `Escape` the
Dialog will close as well, which is not the expected behaviour.
* improve focus management
When you trigger a Popover using a `click` event, then start using `Tab`
the next `a`-tags do not contain the default focus styles. These only
happen when you trigger it using the keyboard first.
Using a tabindex="0" does make it "focusable" and the default browser
styles will be visible. If we remove the tabindex in a
requestAnimationFrame or a setTimeout then the focus styles will be
removed as well.
This should not cause to many issues (fingers crossed) because the
document.activeElement was already referring to the correct element!
* remove Alert component
There are a lot of unknowns and context dependendant questions to
implement Alerts in a good way. The current Alert component just had a
role set, and it had no JS attached.
We will revisit this, once we start working on Alert Dialogs,
Notification center notifications (dismissable, hide after x time, ...)
* ensure Popover.Overlay auto shows/hides based on Popover state
* enable focus trapping based on `open` prop
Only enable focus trapping in the Dialog when `open` is true, regardless
of the `static` prop.
* handle attrs on Dialog manually
* add low level Description component
* add low level Label component
* add RadioGroup component
* expose RadioGroup
* update README with links to new components
* update changelog with all the changes
* add RadioGroup example
* improve type in test
* cleanup internal Dialog Description
We have a low level Description component abstraction that can be used
instead of the Dialog specifiction Description.
* refactor raw window events to a shared useWindowEvent
* passthrough prop bag via context for abstract Description
The Description component is a generic low level component that is
re-used. This causes an issue that the render prop "bag"/"slot" doesn't
contain the data from let's say a Dialog component.
This commit will ensure that you can specify a bag (React) and slot
(Vue) on the DescriptionProvider, so that the Description component can
read it from the context.
* improve render function in React
These contain a few changes that are purely internal changes. Nothing
changes / breaks in the public API of the components.
- Instead of using multiple arguments in your `render()` functions, we now
use an object.
- `propsBag` / `bag` is renamed to `slot`.
- We also provide a `name` to the render function, so that we can use
that to improve error messages.
* use the new internal render api (React)
* improve render function in Vue
* use the new internal render api (Vue)
* add Alert component
* expose Alert
* rename forgotten FLYOUT to POPOVER
* use PopoverRenderPropArg
* organize imports in a consistent way
* ensure Portals behave as expected
Portals can be nested from a React perspective, however in the DOM they
are rendered as siblings, this is mostly fine.
However, when they are rendered inside a Dialog, the Dialog itself is
marked with `role="modal"` which makes all the other content inert. This
means that rendering Menu.Items in a Portal or an Alert in a portal
makes it non-interactable. Alerts are not even announced.
To fix this, we ensure that we make the `root` of the Portal the actual
dialog. This allows you to still interact with it, because an open modal
is the "root" for the assistive technology.
But there is a catch, a Dialog in a Dialog *can* render as a sibling,
because you force the focus into the new Dialog. So we also ensured that
Dialogs are always rendered in the portal root, and not inside another
Dialog.
* add dialog with alert example
* add internal Description component
* add internal Label component
* add RadioGroup component
* expose RadioGroup
* add RadioGroup example
* ensure to include tha RadioGroup.Option own id
* update changelog
* split documentation
* 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
* allow className to be a function
Every component that accepts a className should be able to pass in a
function. This function will retrieve the render prop arg for this
component. The function should resolve to a string in the end.
This makes the API a bit nicer if you just need to change the classNames
based on some internal state.
E.g.:
```js
// Before
<Menu.Button as={Fragment}>
{({ open }) => (
<button className={open ? 'font-bold' : 'font-normal'}>
Hello
</button>
)}
</Menu.Button>
// After
<Menu.Button className={({ open }) => open ? 'font-bold' : 'font-normal'}>
Hello
</Menu.Button>
```
* cleanup types
* merge React imports
* update changelog
* fix outside click on span inside button works as expected
We have `outside click` behaviour implemented. Whenever the target
element is focusable we make sure that the newly clicked/focused element
stays focused. If it is not a focusable element we will make sure that
the Menu/Listbox button is re-focused so that screenreader users don't
get confused.
This is all fine, but it turns out that when you have a button with a
span, and you click on the span, then the event.target will be that
span. The span itself is not focusable of course, but the button will
get the focus. This results in the Menu/Listbox button being re-focused
which is incorrect.
For this we will introduce a FocusableMode on the `isFocusableElement`,
we will have a `Strict` mode, which means the actual element should be
focusable. And a `Loose` mode, which means that the actual element can
be inside a focusable element. E.g.: A span within a button.
* rename menu to listbox
Copy paste can be fun sometimes
* update changelog
* 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
- 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.
* add right click option to the interactions
* add tests to ensure right click behaves as expected
Fixes: #142Fixes: #167
* fallback to mouse events if pointer events are not supported
When the pointer events are not supported, then this is essentially a
no-op. When they *are* supported, then both the pointer *and* mouse
events will fire.
To mitigate potential issues, we make sure that state changes (and
potential re-renders) are idempotent (we bail out on potential state
updates when we are already ina certain state).
Fixes: #173Fixes: #167
And if we are in a disabled fieldset, double check that we are not in
the first legend. Because in that case we are visually outside of the
fieldset and according to the spec those elements should **not** be
considered disabled.
Fixes: #194
* 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
* 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
* make sure the Menu.Button can be disabled (React)
* make sure the MenuButton can be disabled (Vue)
* make sure the Listbox.Button can be disabled (React)
* make sure the ListboxButton can be disabled (Vue)
* make sure the Button is focused when the Menu closes (React)
* make sure the Button is focused when the Menu closes (Vue)
* make sure the Button is focused when the Listbox closes (React)
* make sure the Button is focused when the Listbox closes (Vue)
Robin Malfait