* update playground examples to use a shared `Button`
* expose a `ui-focus-visible` variant
* keep track of a `data-headlessui-focus-visible` attribute
* do not set the `tabindex`
The focus was always set, but the ring wasn't showing up. This was also
focusing a ring when the browser decided not the add one.
Let's make the browser decide when to show this or not.
* update changelog
* add `client-only` to mark everything as client components
This should improve the error messages when using Headless UI in a
Next.js 13+ repo instead of getting a cryptic error message that
`createContext` doesn't exist.
* update changelog
* prevent scrolling the page when using arrow keys in
* update changelog
* bump prettier
Does GitHub Actions have an incorrect cache somehow?
* use Active LTS in CI
* 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
* add `@headlessui/tailwindcss` plugin
* expose `data-headlessui-state="..."` data attribute
All components that expose boolean props in their render prop / v-slot
will receive a `data-headlessui-state="..."` attribute.
If it exposes boolean values but all are false, then there will be an
empty `data-headlessui-state=""`. If the current component is rendering
a `Fragment` then we don't expose those attributes.
* use tailwindcss in `playground-react` and `playground-vue`
We were using the CDN, but now that we have the
`@headlessui/tailwindcss` plugin, it's a bit easier to configure it
natively and import the plugin.
* ensure to build the `@headlessui/tailwindcss` package before starting the playground
* refactor `listbox` example to use the @headlessui/tailwindcss plugin
* update changelog
* bump Tailwind CSS to latest insiders version
* correctly generate types
* type `tailwind.config.js` files for playgrounds
* add todo for when `:has()` is available
* 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>
* improve Tree Shaking in ESM
Instead of bundling everything into a single ESM file, we generate every
single file as ESM. This is what we did in 1.4.x as well.
I would expect if your library had a single ESM file and you only used 1
function that the application you use it in correctly does the
tree-shakign for you. Apparantly a lot of applications are not properly
setup for this, so let's create multiple files instead.
* update changelog
* First attempt at a multi-listbox
* implement `multiple` mode on Listbox
* add multiple Listbox example to playground
* implement `multiple` mode on Combobox
* make sure groupContext is not undefined or null
On vercel, getting a strange issue like `TypeError: undefined is not an
object (evaluating 'r.resolveTarget')` which doesn't happen locally or
once published. Would expect it to be `null` since we default to `null`.
Hopefully this fixes things.
* bump all the dependencies
* make sure that `@types/react` use set to the correct version
`@types/react-dom` hardcoded the `@types/react` to version `16.14.21`
instead of using the latest `16.14.24` resulting in type mismatches.
*cries in inconsistency*
* update changelog
* add multiple Combobox example to playground
* refactor Combobox, use actions
* use combobox data
This is a first step in refactoring everything where we use dedicated
actions and data instead of accessing the reducer state directly.
It also allows us to get rid of mutations in render where we updated
some values in render directly which is not ideal.
Co-authored-by: pvanliefland <pierre.vanliefland@gmail.com>
* Remove vercel json file
* Don't use provide/inject outside of setup
* Upgrade minimum vue version
* Mark vue as an external
* Update lockfile
* WIP move render functions into setup
* WIP
* WIP
* Use setup returning render fns for tests
* 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
* start of combobox
* start with a copy of the Listbox
* WIP
* Add Vue Combobox
* Update Vue version of combobox
* Update tests
* Fix typescript errors in combobox test
* Fix input label
The spec says that the combobox itself is labelled directly by the associated label. The button can however be labelled by the label or itself.
* Add active descendant to combobox/input
* Add listbox role to comobox options
Right now the option list *is* just a listbox. If we were to allow other types in the future this will need to be changable
* Update tests
* move React playground to dedicated package
* add react playground script to root
* ensure we only open/close the combobox when necessary
* ensure export order is correct
* remove leftover pages directory from React package
* Only add aria controls when combobox is open
* add missing next commands
* make typescript happy
* build @headlessui/react before building playground-react
* add empty public folder
This makes vercel happy
* wip
* Add todo
* Update tests
Still more updates to do but some are blocked on implementation
* change default combobox example slightly
* ensure that we sync the input with new state
When the <Combobox value={...} /> changes, then the input should change
as well.
* only sync the value with the input in a single spot
* WIP: object value to string
* WIP
* WIP
* WIP groups
* Add static search filtering to combobox
* Move mouse leave event to combobox
* Fix use in fragments
* Update
* WIP
* make all tests pass for the combobox in React
* remove unnecessary playground item
* remove listbox wip
* only fire change event on inputs
Potentially we also have to do this for all kinds of form inputs. But
this will do for now.
* disable combobox vue tests
* Fix vue typescript errors
* Vue tests WIP
* improve combobox playgrounds a tiny bit
* ensure to lookup the correct value
* make sure that we are using a div instead of a Fragment
* expose `activeItem`
This will be similar to `yourData[activeIndex]`, but in this case the
active option's data. Can probably rename this if necessary!
* Update comments
* Port react tests to Vue
* Vue tests WIP
* WIP
* Rename activeItem to activeOption
* Move display value to input
* Update playgrounds
* Remove static filtering
* Add tests for display value
* WIP Vue Tests
* WIP
* unfocus suite
* Cleanup react accessibility assertions code
* Vue WIP
* Cleanup errors in react interactions test utils
* Update vue implementation
closer :D
* Fix searching
* Update
* Add display value stubs
* Update tests
* move `<Combobox onSearch={} />` to `<Combobox.Input onChange={} />`
* use `useLatestValue` hook
* make `onChange` explicitly required
* remove unused variables
* move `<Combobox @search="" />` to `<ComboboxInput @change="" />`
* use correct event
* use `let` for consistency
* remove unnecessary hidden check
* implement displayValue for Vue
* update playground to reflect changes
* make sure that the activeOptionIndex stays correct
* update changelog
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* 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
* fix unique symbol error (#248)
* Vue breaking change (#279)
* bump Vue
* ensure we reference the vite.config.js
* fix event name casing
Vue broke this in a 3.0.5 release, it still worked in 3.0.4.
Fixes: #267
* handle throwing while rendering a better in tests
* 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 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
Robin Malfait