* placeholder for next release
* Ensure portal root exists in the DOM (#950)
* ensure that the portal root is always in the DOM
When using NextJS, it happens that between page transitions the portal
root gets removed form the DOM. We will check the DOM when the `target`
updates, and if it doesn't exist anymore, then we will re-insert it in
the DOM.
* update changelog
* Allow `Tabs` to be controllable (#970)
* feat(react): Allow Tab Component to be controlled
* fix falsy bug
`selectedIndex || defaultIndex` would result in the `defaultIndex` if
`selectedIndex` is set to 0. This means that if you have this code:
```js
<Tab.Group selectedIndex={0} defaultIndex={2} />
```
That you will never be able to see the very first tab, unless you
provided a negative value like `-1`.
`selectedIndex ?? defaultIndex` fixes this, since it purely checkes for
`undefined` and `null`.
* implemented controllable Tabs for Vue
* add dedicated test to ensure changing the defaultIndex has no effect
* update changelog
Co-authored-by: ChiefORZ <seb.schaffernak@gmail.com>
* Fix missing key binding in examples (#1036)
Co-authored-by: superDragon <xkloveme@gmail.com>
* Fix slice => splice typo in Vue Tabs component (#1037)
Co-authored-by: Ryan Gossiaux <ryan.gossiaux@gmail.com>
* update changelog
* Ensure correct DOM node order when performing focus actions (#1038)
* ensure that the order of DOM nodes is correct
When we are performing actions like `focusIn(list, Focus.First)` then we
have to ensrue that we are working with the correct list that is
properly sorted.
It can happen that the list of DOM nodes is out of sync. This can happen
if you have 3 Tabs, hide the second (which triggers an unmount and an
`unregister` of the Tab), then re-add the second item in the middle.
This will re-add the item to the end of the list instead of in the middle.
We can solve this by always sorting items when we are adding / removing
items, but this is a bit more error prone because it is easy to forget.
Instead we will sort it when performing the actual keyboard action.
If we didn't provide a list but an element, then we use a
getFocusableElements(element) function, but this already gives you a
correctly sorted list so we don't need to do that for this list.
* add tests to prove the correct order when performing actions
* cleanup code just for tests
It could still happen that this internal list is not ordered correctly
but that's not really a problem we just have the list to keep track of
things.
For our tests we now use the position from the DOM directly.
* update changelog
Co-authored-by: ChiefORZ <seb.schaffernak@gmail.com>
Co-authored-by: superDragon <xkloveme@gmail.com>
Co-authored-by: Ryan Gossiaux <ryan.gossiaux@gmail.com>
The `useId` hook causes a re-render in TransitionChild immediately after mount which triggers a transition by `initial` being false in the second re-render regardless of how `appear` was set.
This commit also contains new code introduced after the PR in #853 was
merged. I just squashed it all together to prevent noisy commits to try
and fix CI.
The funny thing is that now the final commit looks fairly stupid/simple
but it wasn't that easy as I would have liked.
1. Couldn't find a proper way to execute `npm version` using yarn
workspaces. `yarn workspaces foreach npm version` would have worked
if we were using Yarn 2 instead of Yarn 1.
2. Introducing `version` and `publish` scripts in both packages worked,
but then the default `version` and `publish` were also executed.
3. Once I made the scripts unique (`npm-version`, `npm-publish`) it
worked~ish. The registry was always set to a yarnpkg registry, even
if we set the registry in CI and in a local .npmrc file. My guess is
that we are executing in a nested directory and therefore it didn't
work.
4. Next, I found the `npm workspaces` option so that we can use that in
addition to `yarn workspaces` 🙃
5. In CI of course this didn't work, because I was not using the same
node version...
6. After everything worked, I did cleanup of the new scripts, and
removed the introduced .npmrc files.
* fix broken `escape` key behaviour
We've "fixed" an issue when we had nested Dialogs ([#430](https://github.com/tailwindlabs/headlessui/pull/430)).
The `escape` would not close the correct Dialog. The issue here was with
the logic to know whether we were the last Dialog or not. The issue was
_not_ how we implemented the `close` functionality.
To make things easier, we moved the global window event to a scoped div
(the Dialog itself). While that fixed the nested Dialog issue, it
introduced this bug where `escape` would not close if you click on a
non-focusable element like a span in the Dialog.
Since that PR we did a bunch of improvements on how the underlying
"stacking" system worked.
This PR reverts to the "global" window event listener so that we can
still catch all of the `escape` keydown events.
Fixes: #524Fixes: #693
* update changelog
* Add Vue emit types
* ensure value is a boolean
Even though we only use `false` for now
* add Vue emit types for Tabs component
* update changelog
Co-authored-by: henribru <6639509+henribru@users.noreply.github.com>
* 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
* expose a `close` function via the render prop for the `Popover` and `Popover.Panel` components (React)
* expose a `close` function via the render prop for the `Disclosure` and `Disclosure.Panel` components (React)
* expose a `close` function via the render prop for the `Popover` and `PopoverPanel` components (Vue)
* expose a `close` function via the render prop for the `Disclosure` and `DisclosurePanel` components (Vue)
* add `aria-orientation` to the Listbox component
By default the `Listbox` will have an orientation of `vertical`. When
you pass the `horizontal` prop to the `Listbox` component then the
`aria-orientation` will be set to `horizontal`.
Additionally, we swap the previous/next keys:
- Vertical: ArrowUp/ArrowDown
- Horizontal: ArrowLeft/ArrowRight
* update changelog
* add ability to use `Disclosure.Button` inside a `Disclosure.Panel`
If you do it this way, then the `Disclosure.Button` will function as a
`close` button.
This will make it consistent with the `Popover.Button` inside the
`Popover.Panel` funcitonality.
* update changelog
Robin Malfait