fdd26297953080d5ec905dda0bf5ec9607897d86
10 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Robin Malfait
|
fdd2629795 |
Improve overal codebase, use modern tech like esbuild and TypeScript 4! (#1055)
* 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 |
||
|
Robin Malfait
|
3bc7545169 |
Next release (#916)
* 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> |
||
|
Robin Malfait
|
084a2497d8 |
Fix incorrect nested Dialogs behaviour (#489)
* add tests to verify the nested Dialog behaviour * set mounted to true once rendered once * cache useWindowEvent listener We only care about the very last version of the listener function. This allows us to only change the event listener if the event name (string) and options (boolean | object) change. * add/delete messages when mounting/unmounting We don't require a dedicated hook anymore, so this is a bit of cleanup! * add comments to the FocusResult enum * splitup functionality and make it a bit more clear using feature flags * add getDialogOverlays helper * simplify the Portal component We don't need to add the current element to the Stack. We only want to take care of that in the Dialog component itself. * drop dom-containers Currently it is only used in a single spot, so I inlined it into that file. * simplify the FocusTrap component, use new API * improve Dialog component * update CHANGELOG |
||
|
Robin Malfait
|
c13e6b7752 |
Improve dialog and SSR (#477)
* delay initialization of Dialog We were using a useLayoutEffect, now let's use a useEffect instead. It still moves focus to the correct element, but that process is now a bit delayed. This means that users will less-likely be urged to "hack" around the issue by using fake focusable elements which will result in worse accessibility. * add hook to deal with server handoff This will allow us to delay certain features. For example we can delay the focus trapping until it is fully hydrated. We can also delay rendering the Portal to ensure hydration works correctly. * use server handoff complete hook * update changelog |
||
|
Robin Malfait
|
3855d664ea |
Link to docs (#333)
* 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. |
||
|
Robin Malfait
|
6f8225c437 |
Next batch of Vue components (#282)
* 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) |
||
|
Robin Malfait
|
00cc8c50e3 |
Add Alert & RadioGroup components (#274)
* 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 |
||
|
Robin Malfait
|
e3cbcc43f9 |
fix Portal cleanup issue (#266)
When the last portal is unmounted we will document.body.removeChild(target), but this crashes when something tampered with it. This is reproduceable in the tests. Instead we now ensure that the portal root always exists when mounting. We will also ensure to target.parentElement.removeChild which will ensure that we can reference the parent correctly. |
||
|
Robin Malfait
|
958e3ea8c6 |
bug fixes (#261)
* 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 |
||
|
Robin Malfait
|
648a2843e6 |
Multiple new components (#220)
* 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 |