* add tests to guarantee `FocusTrap` with a single element works as expected
* it should keep the focus in the Dialog
Even if there is only 1 element. We were skipping the current active
element so the container didn't have any elements anymore and just
continued to the next focusable element in line. This will prevent that
and ensure that we can only skip elements if there are multiple ones.
* update changelog
* do not add `disabled` prop to `MenuItem`
We use the `aria-disabled` instead so that you can still style it and
that assistive techonology can read the disabled state. If it has the
`disabled` prop itself, then often you can't interact with it at all.
We also default to `disabled = false`, which means that the default
behaviour was a `<element disabled="false">` in the DOM. If you then
have CSS like `[disabled] { opacity: 0.8; }` then this also applies to
the elements with `disabled="false"`.
Fixes: #2134
* ensure Vue playground still works
* ensure Vue overrides the `onXXX` correctly
* update changelog
* Allow clicks inside dialog panel when target is inside shadow root
* Introduce resettable “server” state
This will aid in testing
* Add SSR and hydration tests for react
* Fix server rendering of Tabs on React 17
* Fix CS
* Skip hydration tests
* Tweak SSR implementation in Vue
* Update changelog
* improve types for addEventListener inside disposables
* improve scroll locking
Instead of using the "simple" hack with the `position: fixed;` we now
went back to the `touchmove` implementation.
The `position: fixed;` causes some annoying issues. For starters, on iOS
you will now get a strange gap (due to safe areas). Some applications
also saw "blank" screens based on how the page was implemented.
We also saw some issues internally, where clicking changing the scroll
position on the main page from within the Dialog.
Think about something along the lines of:
```html
<a href="#interesting-link-on-the-current-page">Interesting link on the page</a>
```
This doesn't work becauase the page is now fixed, and there is nothing
to scroll...
Instead, we now use the `touchmove` again. The problem with this last
time was that this disabled _all_ touch move events. This is obviously
not good.
Luckily, we already have a concept of "safe containers". This is what we
use for the `outside click` behaviour as well. Basically in a Dialog,
your `Dialog.Panel` is the safe container. But also third party DOM
elements that are rendered inside that Panel (or as a sibling of the
Dialog, but not your main app).
We can re-use this knowledge of "safe containers", and only cancel the
`touchmove` behaviour if this didn't happen in any of the safe
containers.
* update changelog
* sort DOM nodes using tabIndex first
It will still keep the same DOM order if tabIndex matches, thanks to
stable sorts!
* refactor `focusIn` API
All the arguments resulted in usage like `focusIn(container,
Focus.First, true, null)`, and to make things worse, we need to add
something else to this list in the future.
Instead, let's keep the `container` and the type of `Focus` as known
params, all the other things can sit in an options object.
* fix FocusTrap escape due to strange tabindex values
This code will now ensure that we can't escape the FocusTrap if you use
`<tab>` and you happen to tab to an element outside of the FocusTrap
because the next item in line happens to be outside of the FocusTrap and
we never hit any of the focus guard elements.
How it works is as follows:
1. The `onBlur` is implemented on the `FocusTrap` itself, this will give
us some information in the event itself.
- `e.target` is the element that is being blurred (think of it as `from`)
- `e.currentTarget` is the element with the event listener (the dialog)
- `e.relatedTarget` is the element we are going to (think of it as `to`)
2. If the blur happened due to a `<tab>` or `<shift>+<tab>`, then we
will move focus back inside the FocusTrap, and go from the `e.target`
to the next or previous value.
3. If the blur happened programmatically (so no tab keys are involved,
aka no direction is known), then the focus is restored to the
`e.target` value.
Fixes: #1656
* update changelog
* Pass default slot instead of raw children to components
This is essentially how the internal implementation of `<component>` works. This works even for element VNodes.
* Update changelog
* only restore focus to the Menu Button if necessary
This will check whether the focus got moved to somewhere else or not
once we activate an item via click or pressing `enter`.
Pressing escape will still move focus to the Menu Button.
* update changelog
* improve event handler merging
This will ensure that an actual event is passed before checking the
`event.defaultPrevented`.
For React, we also have to make sure that we are not dealing with a
SyntehticEvent.
Thanks @Mookiepiece!
Co-authored-by: =?UTF-8?q?=E5=BD=BC=E8=A1=93=E5=90=91?= <48076971+Mookiepiece@users.noreply.github.com>
* update changelog
Co-authored-by: =?UTF-8?q?=E5=BD=BC=E8=A1=93=E5=90=91?= <48076971+Mookiepiece@users.noreply.github.com>
* 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>
* check typeof document in addition to typeof window
* remove unused import
* Extract SSR check to a central spot
* Fix CS
* Update changelog
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* sort props in error message
This will make the error message consistent regardless which props (and
in what order) they are applied.
* WIP
* `click()` on a disabled element should no-op
* incomingProps was already merged
* cleanup tests a bit and make it consistent with the React tests
* cleanup unused code
* 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
* 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
* 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>
* 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
* implement `objetToFormEntries` functionality
If we are working with more complex data structures then we have to
encode those data structures into a syntax that the HTML can understand.
This means that we have to use `<input type="hidden" name="..." value="...">` syntax.
To convert a simple array we can use the following syntax:
```js
// Assuming we have a `name` of `person`
let input = ['Alice', 'Bob', 'Charlie']
```
Results in:
```html
<input type="hidden" name="person[]" value="Alice" />
<input type="hidden" name="person[]" value="Bob" />
<input type="hidden" name="person[]" value="Charlie" />
```
Note: the additional `[]` in the name attribute.
---
A more complex object (even deeply nested) can be encoded like this:
```js
// Assuming we have a `name` of `person`
let input = {
id: 1,
name: {
first: 'Jane',
last: 'Doe'
}
}
```
Results in:
```html
<input type="hidden" name="person[id]" value="1" />
<input type="hidden" name="person[name][first]" value="Jane" />
<input type="hidden" name="person[name][last]" value="Doe" />
```
* implement VisuallyHidden component
* implement and export some extra helper utilities
* implement form element for Switch
* implement form element for Combobox
* implement form element for RadioGroup
* implement form element for Listbox
* add combined forms example to the playground
* update changelog
* enable support for iterators
* ensure to compile dom iterables
* remove unused imports
* 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
* Add combobox to Vue playground
* Update input props
* Wire up input event for changes
This fires changes whenever you type, not just on blur
* Fix playground
* Don't fire input event when pressing escape
The input event is only supposed to fire when the .value of the input changes. Pressing escape doesn't change the value of the input directly so it shouldn't fire.
* Add latest active option render prop
* Add missing active option props to Vue version
* cleanup
* Move test
* Fix error
* Add latest active option to Vue version
* Tweak active option to not re-render
* Remove refocusing on outside mousedown
* Update tests
* Forward refs on combobox to children
* Cleanup code a bit
* Fix lint problems on commit
* Fix typescript issues
* 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
* 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>
* 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>
* 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>
* only destructure from props inside render
* conditionally ensure that tabindex -1 exists
* reflect `disabled` prop in React as well
* 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>
* add redent function when verifying snapshots
This allows us not to care about the correct amount of spaces and always
produces a clean output.
* make the container the parent of the wrapper element
* drop the visible prop on the Portal component
* drop visible prop on Portal component
+ Also cleanup a little bit
* expose the RenderStrategy
* implement Transition component in Vue
* expose Transition component
* add Transitions to the Dialog example
We didn't take functional components into account, therefore we would
receive errors because a Transition component is a functional component
in production and we didn't take that into account.
* small improvement
* validate Vue vnode
Also change Fragment to "template", *oops*.
* improve error messages in tests for Menu (Vue)
Also actually making sure that we have valid MenuItem components... By
default it renders a template, therefore `<MenuItem>Abc</MenuItem>` is
technically incorrect.
* 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 small dom utility to resolve the dom node from a ref
* use dom() to resolve underlying DOM node
There is probably a better way to do this, the idea is that we apply a
ref to the component. However by default for html components
`yourRef.value` will be the underlying DOM node. However if you pass the
ref to another component, the actual DOM node will be located at
`yourRef.value.$el`.
Fixes: #21
* update changelog
Robin Malfait