* fix `slot` state of `RadioGroup` component
The `useEvent` is 1 tick too late (due to the update of the callback
happening in useEffect). This isn't a problem for event listeners, but
it is for functions that need to run "now".
We can change the `useLatestValue` hook to do something like:
```diff
export function useLatestValue<T>(value: T) {
let cache = useRef(value)
- useIsoMorphicEffect(() => {
- cache.current = value
- }, [value])
+ cache.current = value
return cache
}
```
But then we are mutating our refs in render which isn't ideal.
* update changelog
* add test to verify that the correct slot data is exposed
We had an issue where an open Dialog got hidden by css didn't properly
unmount because the Transition never "finished". We fixed this by
checking if the node was hidden by using `getBoundingClientRect`.
Today I learned that just *reading* those values (aka call
`node.getBoundingClientRect()`) it for whatever reason completely stops
the transition. This causes the enter transitions to completely stop
working.
Instead, we move this code so that we only check the existence of the
Node when we try to transition out because this means that the Node is
definitely there, just have to check its bounding rect.
* splitup CHANGELOG.md file
Scope each changelog per package
* simplify CHANGELOG.md files
We don't need to scope them anymore, they are already scoped.
* remove leftover code
This code existed before we had the option to make the first option the
"active" one.
This also contains a bug in the React code where pressing "ArrowDown" in
a closed Combobox opens the combobox and goes to the second item instead
of the first option.
* 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
In the cleanup PR, we added the `Data` and `Actions` type, but we
already had a `Actions` type so had to rename it to something. Chose
`Command` but this is now inconsistent with the rest of the codebase.
Instead, let's revert that change and use these shorthands:
- `Data` -> `_Data`
- `Actions` -> `_Actions`
- `Commands` -> `Actions`
- `CommandTypes` -> `ActionTypes`
The `_` prefix is a little bit strange, but it is a private type and not
exposed so fine for now.
* 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
* make the ref optional in the `Popover` component
We "required" the prop to calculate the `ownerDocument`. But if you
don't provide a ref, then we will use the `Popover.Button` to calculate
it. If that's not defined, then we can fallback to the default
`document`.
* update changelog
* improve scroll lock, scrollbarWidth
The idea is as follow:
If you currently have a scrollbar, and you open a Dialog then we enable
a "Scroll lock" so that you can't scroll in the background behind the
modal. We can achieve this by adding a `overflow: hidden;` to the
`html`.
The issue is that by doing this, we lose the scrollbar and therefore the
page will jump to right because now there is a bit more room.
To account for this, we set a `padding-right` on the `html` of the
scrollbarWidth in pixels. This counteracts the visual jump you would
see.
The issue with this approach is that there could *still* be a scrollbar
once we add the `overflow: hidden`. This can happen if you use new css
features like the `scrollbar-gutter: stable;`.
To take this into account, we will measure the scrollbar again after we
set the `overflow: hidden`. Now we will only apply that counteracting
offset if there would actually be a jump by measuring the before and
after widths and applying the diff if there is one.
* update changelog
* improve `Popover` keyboard usage
Use `TabSentinel` instead of intercepting the `Tab` keydown events.
* use Buttons in Popover example
* update changelog
* refactor `VisuallyHidden` to `Hidden` component
This new component will also make sure that it is visually hidden to
sighted users. However, it contains a few more features that are going
to be useful in other places as well. These features include:
1. Make visually hidden to sighted users (default)
2. Hide from assistive technology via `features={Features.Hidden}`
(will add `display: none;`)
3. Hide from assistive technology but make the element focusable via
`features={Features.Focusable}` (will add `aria-hidden="true"`)
* add `useEvent` hook
This will behave the same (roughly) as the new to be released `useEvent`
hook in React 18.X
This hook allows you to have a stable function that can "see" the latest
data it is using. We already had this concept using:
```js
let handleX = useLatestValue(() => {
// ...
})
```
But this returned a stable ref so you had to call `handleX.current()`.
This new hook is a bit nicer to work with but doesn't change much in the
end.
* add `useTabDirection` hook
This keeps track of the direction people are tabbing in. This returns a
ref so no re-renders happen because of this hook.
* add `useWatch` hook
This is similar to the `useEffect` hook, but only executes if values are
_actually_ changing... 😒
* add `microTask` util
* refactor `useFocusTrap` hook to `FocusTrap` component
Using a component directly allows us to simplify the focus trap logic
itself. Instead of intercepting the <kbd>Tab</kbd> keydown event and
figuring out the correct element to focus, we will now add 2 "guard"
buttons (hence why we require a component now). These buttons will
receive focus and if they do, redirect the focus to the first/last
element inside the focus trap.
The sweet part is that all the tabs in between those buttons will now be
handled natively by the browser. No need to find the first non disabled,
non hidden with correct tabIndex element!
* refactor the `Dialog` component to use the `FocusTrap` component
Also added a hidden button so that we know the correct "main" tree of
the application. Before this we were assuming the previous active
element which will still be correct in most cases but we don't have
access to that anymore since the logic is encapsulated inside the
FocusTrap component.
* ensure `<Portal />` properly cleans up
We make sure that the Portal is cleaning up its `element` properly.
We also make sure to call the `target.appendChild(element)`
conditionally because I ran into a super annoying bug where a focused
element got blurred because I believe that this re-mounts the element
instead of 'moving' it or just ignoring it, if it already is in the
correct spot.
* refactor: use `useEvent` instead of `useLatestValue`
Not really necessary, just cleaner.
* update changelog
* ignore `Escape` when event got prevented
Some external libraries only use `event.preventDefault()` and not
`event.stopPropagation()`. This means that the Dialog can still receive
an `Escape` keydown event which closes the Dialog.
We can also think about the `Escape` behaviour inside the modal as the
"default behaviour" once the Dialog is open. Therefore, we can also
check the `event.defaultPrevented` and ignore this event when this is
the case.
* update changelog
* cleanup README files
* ignore flakey tests for now
There are a handful of tests that are pretty flakey and fail every once
in a while on CI, I don't want to remove them yet, but rather ignore
them for now.
I am going to experiment with using Playwright/Puppeteer to use a real
browser instead.
* add explicit `multiple` prop to the `Combobox`
This allows you to set the value to a **tuple** in `single-value` mode,
which was not possible before the `multiple` prop was introduced,
because then it resulted in `multi-value` mode instead of `single-value`
mode.
* add explicit `multiple` prop to the `Listbox`
This allows you to set the value to a **tuple** in `single-value` mode,
which was not possible before the `multiple` prop was introduced,
because then it resulted in `multi-value` mode instead of `single-value`
mode.
* update changelog
* update playground to use `multiple` prop
* 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>
* implement `backspace` behaviour in tests
* add `Delete` Key
* implement `nullable` mode on Combobox in single value mode
If you pass a `nullable` prop to the Combobox, then it's possible to
unset the Combobox value by setting it to `null`.
This is triggered by removing all text from the input which will reset
the value itself as well.
* update changelog
* improve rendering of hidden form fields
* add `attemptSubmit` helper
This will allow us to _try_ and submit a form based on any element you
pass it. It will try and lookup the current form and if it is
submittable it will attempt to submit it.
Instead of submitting the form directly, we try to follow the native
browser support where it looks for the first `input[type=submit]`,
`input[type=image]`, `button` or `button[type=submit]`, then it clicks
it.
This allows you to disable your submit button, or have an `onClick` that
does an `event.preventDefault()` just like the native form in a browser
would do.
* ensure we can submit a form from a closed Combobox
When the Combobox is closed, then the `Enter` keydown event will be
ignored and thus not use `event.preventDefault()`.
With recent changes where we always have an active option, it means that
you will always be able to select an option.
If we have no option at all (some edge case) or when the combobox is
closed, then the `Enter` keydown event will just bubble, allowing you to
submit a form.
Fixes: #1282
This is a continuation of a PR ([#1176](https://github.com/tailwindlabs/headlessui/pull/1176)) provided by Alexander, so wanted to include
them as a co-author because of their initial work.
Co-authored-by: Alexander Lyon <arlyon@me.com>
* ensure we can submit a form from a RadioGroup
* ensure we can submit a form from a Switch
* simplify / refactor form playground example
* update changelog
Co-authored-by: Alexander Lyon <arlyon@me.com>
* fix double arrow down requirement
If the `activeOptionIndex` is set to `null`, then we default to the very
first non-disabled option. This data is _not_ stored in state because if
you as the user go to a specific option, then start searching then we
will maintain the active option. This means that we have to **update**
the `activeOptionIndex` when options are moving around.
While making the first option the active one, we can't store that in
state directly otherwise the very first option becomes the active one.
If we then inject combobox options _before_ the current one then all of
a sudden your active option would jump around a bit.
We don't want this jumping to happen, we want the very first option to
be the one that's active no matter which option it is.
Since this is not stored in state, our keydown handler was a bit borked.
Internally it thinks we are still at `activeOptionIndex === null`
therefore pressing arrow down would move us to `activeOptionIndex ===
0`. To go to the second option, we can press down again which would move
us to `activeOptionIndex === 1`. The only issue is that visually we were
already at `0`.
This fixes that by making sure that if we have `activeOptionIndex ===
null` that we fallback to the very first non disabled option _before_ we
execute the `goToOption()` code.
### Before:
**Open combobox**, `activeOptionIndex === null`
| Combobox |
| ----------------------- |
| **Option A** _(active)_ |
| Option B |
| Option C |
**Arrow Down**, `activeOptionIndex === 0`
| Combobox |
| ----------------------- |
| **Option A** _(active)_ |
| Option B |
| Option C |
**Arrow Down**, `activeOptionIndex === 1`
| Combobox |
| ----------------------- |
| Option A |
| **Option B** _(active)_ |
| Option C |
### After:
**Open combobox**, `activeOptionIndex === null`
| Combobox |
| ----------------------- |
| **Option A** _(active)_ |
| Option B |
| Option C |
**Arrow Down**, `activeOptionIndex === 1`
| Combobox |
| ----------------------- |
| Option A |
| **Option B** _(active)_ |
| Option C |
* update changelog
* ensure that the first option is always active
This will ensure that the first non-disabled option is the active one if
no other active options exist. This means that any time you search for
something that the first result is the active one and you can just press
<kbd>Enter</kbd> to activate the option.
However, there are a few rules that we have to take into account:
- If you just open the Combobox, and there is a `selected`
Combobox.Option, then we can't make the first option the active one.
The first selected Combobox.Option has precedence over this one. This
is important and rather tricky because Combobox.Option's register
themselves at some point (later) in time.
- If you already have an active option, then that option should stay
active. If it changes position, then the activeOptionIndex is adjusted
to account for that.
- If you "mouse leave" an option, then no option should be active. It
will be re-enabled the moment you start typing OR if you re-open the
Combobox. Otherwise, it can happen that you are at the bottom of the
list, mouse leave, and we scroll all the way back up to make the first
item the active one which is not good for UX reasons.
* filter list based on query in the playground
* update changelog
* mimic browser select on focus
When calling focusIn if the next node is selectable select all the text.
* refactor browser `select` behaviour for React and Vue
* update changelog
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* 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
* update tests to expose bug in React implementation
* fix incorrect `active` state on mouseLeave
The React code had a bug in the Listbox and Combobox components where it
incorrectly made the first selected value the active value.
The first selected option should be the active option when you open the
listbox. However when you already had the component in an `open` state,
hovered over a non-selected item and them left the option by moving it
to the body then the first selected option became the active one again.
This made sense because we used a `useEffect` in each option to make it
the active one if it was also selected. Since every component
re-renders, code got called and the bug arises.
Now, instead we moved the logic to make it the active option to the
reducer logic. We will check it when we register an option and doesn't
have an active option index yet or when we open the Listbox/Combobox.
This should also solve the strange scrolling behaviour where the options
scroll up if you have more options than you display.
* update changelog
Robin Malfait