From what I've seen all of the interaction primitives (createHover, createFocus, etc.) have their props argument set as required instead of optional. Are props actually always required? Seams that you should be fine just doing this in some scenarios: (when you don't need to combine props)

const { focusProps } = createFocus()
<input {...forcusProps}/>

Hey, I work on React Aria. Very happy to see this project extending our work to another framework! It's something I've wanted to experiment with for a long time, but haven't had time.

React Aria uses the Apache 2.0 license, which is very permissive but requires that the copyright headers in source files, LICENSE, and NOTICE.txt files be included in any redistributions or modifications. Since many of the files in this project appear to be direct ports of code from React Aria, we would really appreciate if you could include the license here as well.

Also, please let us know if there is anything we can do to help. Like I said, extending React Aria to support other frameworks is something we've had on our long term wishlist for a while. As you build out the primitives here, it would be really great if you could share any learnings with us, or ideas about how some of the code could be shared. Would be great to potentially come up with an abstraction where this stuff could be more easily shared between frameworks rather than duplicating efforts, porting bug fixes back and forth, etc.

Was trying to install @solid-aria/interactions.

Are you sure you want to have ^workspace instead of ^0.1.0 for the dependency version? Changesets will update the versions automatically anyway.

I've refactored the createSlotId helper to work in a way I've described on discord.

Instead of tracking a fixed array of dependencies to preform document.getElementById check — It'll track the actual id usage via separate track() function.

This way displaying the element with e.g. descriptionId can to toggled depending on a signal separate from signals that would be tracked with the deps array from before, and update the value of descriptionId accordingly.

I've run the tests this time! :)

• Change dependency versions of packages from "workspace^" to "^0.1.0" (current version) — Fixes #29 0.1.0 instead of 0.1.1 because changesets should update those

• Move solid-primitives packages from peerDependencies to dependencies. Those are normal dependencies. This may cause missing peerdependency warnings during installs (in this repo), to do that we'd have to add "solid-js" as dev dependency everywhere, but I just didn't have the strength to do it. The warnings are harmless anyway...

Having automatic tests specifically for SSR should help ensure that solid-aria can be used with solid-start without trouble. Not that it's certain that it'll run, we've seen that there are a lot of random things, especially with jsx transform that could go wrong. But the API itself should benefit from this.

• moved some of the configs to new /configs dir — frees some space in the root
• Added jest config & setup files specifically for ssr
• Added ssr tests to label package (It's a only a start😄)
• Fixed createSlotId to prevent it from accessing DOM APIs on the server.

Should I add a changeset for all packages, or only the updated utils?

Refactors the filterDOMProps to do less work, and be easier to use

const domProps = mergeProps(createMemo(() => filterDOMProps(props, { labelable: true })));
const domProps = filterDOMProps(props, { labelable: true });

Besides the select package, all tests pass

I'm playing with gitpod to work on this repo. There are some issues with permission, this is why I'm using a fork. But in exchange, I might be able to bypass the mac vs windows differences.

• @solid-aria/i18n: added createNumberFormatter primitive.
• @solid-aria/primitives: added progress and separator packages.
• @solid-aria/utils: added number utilities.
• @solid-aria/progress: new package.
• @solid-aria/separator: new package.

This PR is dependent of https://github.com/solidjs-community/solid-aria/pull/73 since it has changes to createFocusable

This is the port of Tooltip.

TODO

• [ ] Tooltip
• [ ] Tests
• [ ] Update doc

This is my first contribution to the project. I am looking for feedback.

I have pretty much followed what @react-aria/tooltip is doing.

I'm having a Typescript error with the return of createTooltipTrigger. I'm getting this error:

Types of property 'onFocus' are incompatible. 
Type 'EventHandlerUnion<any, 
FocusEvent> 
| EventHandlerUnion<HTMLElement, FocusEvent>
| undefined' is not assignable to type '((e: FocusEvent) => void) | undefined'.

Looking at the signature of onFocus from FocusEvents => onFocus?: (e: FocusEvent) => void; in @solid-aria/types, this is exactly the same signature as we have in @react-aria/types. In their implementation of onFocus, they are not passing the event to onFocus and it is not complaining in @react-aria

Looking at createFocusable interface FocusableResult, focusableProps: JSX.HTMLAttributes<any>; and onFocus in HTMLAttributes is indeed onFocus?: EventHandlerUnion<T, FocusEvent>;

@fabien-ml I see you worked in createFocusable, do you think you could help me out?

See Stackblitz reproduction repo here: https://stackblitz.com/edit/solidjs-template-r95c6s?file=src/App.tsx

If I have an Item in the accordion that's wrapped in a fragment, the <Show when={}> component directly within the fragment does not react to state updates.

Here's the relevant code from the Stackblitz

import { Item } from '@solid-aria/collection';
import { createSignal, Show } from 'solid-js';
import { Accordion } from './Accordion';

/**
 * There are two accordion items in here, one wrapped in a
 * fragment, and one wrapped in a div. When pressing the
 * trigger button, the text to the right of it should
 * disappear/appear, because it's wrapped in a 
 * <Show when={visible()}></Show>. On the one wrapped in a 
 * div it does, but the one wrapped in a fragment you have to
 * collapse & expand the Item header once to trigger the 
 * state update.
 *
 * The accordion code is a straight copy/paste from https://github.com/solidjs-community/solid-aria/blob/main/packages/accordion/README.md
 */

export default function App() {
  const [visible, setVisible] = createSignal(true);

  return (
    <Accordion>
      <Item key="fragment" title="With fragment wrapper">
        <>
          <button
            style={{ color: visible() ? 'green' : 'red' }}
            onClick={() => setVisible((v) => !v)}
          >
            Trigger
          </button>

          <Show when={visible()}> - Should appear/disappear</Show>
        </>
      </Item>

      <Item key="div" title="With div wrapper">
        <div>
          <button
            style={{ color: visible() ? 'green' : 'red' }}
            onClick={() => setVisible((v) => !v)}
          >
            Trigger
          </button>

          <Show when={visible()}> - Should appear/disappear</Show>
        </div>
      </Item>
    </Accordion>
  );
}

Please check if the usage of Solid is correct, I am still learning it. I also found that you are using splitProps instead of restructuring. Not sure why?

I copied the ElementType from https://github.com/solidjs/solid/issues/701#issuecomment-1007706044

I'm trying to use solid-aria in Astro but I get :

require() of ES Module myproject/node_modules/@solid-aria/focus/dist/cjs/index.js from myproject/node_modules/@solid-
aria/selection/dist/index.cjs not supported. index.js is treated as an ES module file as it is a .js file whose nearest parent package.json 
contains "type": "module" which declares all .js files in that package scope as ES modules. error. 

Any idea why that happens?

I'm getting this error only when using solid-aria so I asked here instead of the Astro server, And it doesn't look like an Astro issue.

Here is a small stackblitz to reproduce. The error is slightly different here but I think it's the same thing.

https://stackblitz.com/edit/github-7cxbsf?on=stackblitz

Fixes #71

TODO:

• [x] createButton
• [x] createFocusable
• [ ] createToggleButton
• [ ] fix createRadio
• [ ] fix createTextField
• [ ] add changeset
• [ ] update docs