* 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.
* rename Transition to TransitionRoot
This will allow us to write it as:
- TransitionRoot
- TransitionChild
This has the added benefit that it doesn't collide with the internal
Transition component from Vue itself.
* alias Transition.Root to Transition
This allows us to write:
- Transition.Root
- Transition.Child
If you have a standalone Transition, then you can still use <Transition /> as is.
* drop unusued import
* update changelog
* 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
* 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>
I was on a walk, and I realised that in Vue you can just call
provide(Symbol, context), which means that a hook like `useLabels` can
just provide context...
This simplifies a lot!
* improve internal Label component
We will now add a name to improve error messages, we also introduced a
`clickable` prop on the label.
Not 100% happy with the implementation of these internal Label &
Description components, but they are internal so we can always change it
to something that makes more sense!
* improve internal Description component
We will now add a name to improve error messages.
* provide the name prop to Description & Label providers
* implement the useLabels and useDescriptions in the Switch components
* update documentation
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.
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 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
* 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
* 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
* 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
- 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
Browsers. Are. Crazy.
In JSDOM, when you fire an event, you only get that specific event. You
don't get all the magic that the browser gives you. For example, when
you are focused on a button and press to "Tab" then in JSDOM you would
only get a keydown event. However in the browser you get this chain of
events:
1. `keydown` on the current element
2. `blur` on the current element
3. `focus` on the new element
4. `keyup` on the new element
I implemented this "magic", for the `Tab`, `Enter` and `Space` key for
now. Those are the most important currently. `Enter` and `Space` also
trigger `click` events for example.
I also have a "generic" implementation, where a normal press results in:
1. `keydown`
2. `keypress` (in case it has a `charCode` and is "printable", so `alt`
is ignored)
3. `keyup`
I also ensured that the cancelation when you use an
`event.preventDefault()` happens correctly.
Here is a fun summary: https://twitter.com/malfaitrobin/status/1354472678128820234
Press "Enter" on a button
-> keydown, keypress, click, keyup
Press "Space" on a button
-> keydown, keypress, keyup, click
Press "Enter" or "Space" on a button, with event.preventDefault() in the keydown listener
-> keydown, keyup
Press "Enter" on a button, with event.preventDefault() in the keypress listener
-> keydown, keypress, keyup
Press "Space" on a button, with event.preventDefault() in the keypress listener
-> keydown, keypress, keyup, click
* 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)
* add Switch component
* add tests to verify that we can click the label to toggle the Switch
* use onKeyUp to prevent triggering the onClick in firefox
* 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
This will allow us to do 2 things:
- When we are in "type ahead" mode, aka search, we can use spaces to
search. E.g.: "Account Settings" (notice the space)
- When we are not in "type ahead" mode, we can use `Space` to invoke the
menu item. We used to only allow `Enter` and `Click`.
* add failing tests to prove the outside-click issue
* fix outside click when we have multiple menu's
- We removed the `toggleMenu` since we only used it in a single spot,
and had to do some side effect logic (focus & event.preventDefault).
Wanted to make this consistent between React and Vue.
- If, in the "outside click" logic we detect that we clicked on the
button, we also ignore it.
- If, we click on the button we will toggle the menu.
Fixes: #18
This is an issue in the Vue version (it just works in the React version)
but I added tests for them anyway.
While this solution "works" I am not 100% happy with it. Let me explain
what's happening here and why I am not that happy about it:
- For starters, the Vue `nextTick` is apparently too fast. So what we do
is when we get the pointer up event, we will close the menu and
re-focus the button. We ran this code in a `nextTick` so that we can
ensure that we close the menu *after* all the click events are
finished. However because this is too fast, the menu is already closed
and the anchor link is already unmounted and thus not clickable
anymore. So instead we use a double requestAnimationFrame (to mimick a
`nextFrame` as seen in the `disposables` from the React code). This
works, but a bit messy, oh well.
- The next reason why I am not that happy is because I can't reproduce
it in JSDOM (Jest tests). When you *click* a link in JSDOM it doesn't
update the `window.location.hash` or `window.location.href`. To mimick
that behaviour I put a `@click` event on the anchor to verify that we
actually clicked it. However this already works, even before the
"fix". So I left a TODO in there so that we can hopefully fix the
test, so that we _can_ reproduce this behaviour.
Fixes: #14
Robin Malfait