Reference:

Example 1 - 
<Select.Root>
	<Select.Trigger>
    <Select.Item>

Example 2:
<Select>
	<SelectTrigger>
   <SelectItem>

Example 3:
<Select>
   <Select_Trigger>
   <Select_Item>

Running in nx preview website throws errors related in to invalid JSX.

Might be related to changes in prop destructuring.

Reproduction

• Starting the website

cd packages/website
npm start

• The following warning is shown

Proposed solution

We might want to replace className with class.

Final thoughts

• I am willing preparing a PR for it.

Still missing:

• Keyboard navigation
• Verify ARIA is fully implemented by the spec
• Fix the flickering issue
• placeholder?
• Design a theme-daisy implementation
• Auto placements
• storybook stories
• component testing
• multi-selection
• disabled items (skip them)
• arrow
• hidden inputs for selected value / values (plus enabling selecting a complicated object and not just a primitive value with item[prop])
• mouse clicking outside the list should close
• transitions / animations
• Grouping items

@gioboa wanted to work on this

We already have Cypress set up, which has a great DX (but no tests yet)
I wonder if we need to add playwright or is Cypress enough

This problem surfaced in trying to re-create native Select behavior.

Native Tab behavior on a select element activates the currently focused option and moves to the next tabbable element, usually the next form input element. As we have re-implemented the Select component without using native elements in favor of better styling capability, additional keyboard event listeners have to be implemented for accessibility.

However, Qwik currently only works with preventDefault as an attribute to an element like so:

<button preventDefault:onKeyUp>
</button>

and the following does not work:

<button onKeyUp$={(e) => {
    if (e.key === 'Tab') {
        e.preventDefault()
    }
}}>
</button>

This means that in order for us to recreate native Tab behavior for a Select component, we would have to set preventDefault on the element, and then re-implement existing behavior like Enter or Space to activate the element. This is potentially extra tedium or would clash with what users may expect when using Qwik UI in the future to compose their own components.

Upgrade all of the packages (especially the Qwik ones) to latest versions so we could update the qwik-nx plugin

Hi there

Great idea and work on this UI lib 🙏
Wanted to have a look at your storybook impl. end found this error below while building a static version of storybook.

 *  Executing task: npx nx run core:build-storybook 


> nx run core:build-storybook


>  NX  ui framework: @storybook/html


>  NX  Storybook builder starting ...

info => Cleaning outputDir: /Users/zanettin/development/tests/qwik-ui/dist/storybook/core
info => Loading presets
info => Loading custom manager config
info => Compiling manager..
info => Loading custom manager config
vite v3.2.1 building for production...
transforming (616) ../../node_modules/@mdx-js/react/dist/esm.js
🌼 daisyUI components 2.38.0  https://github.com/saadeghi/daisyui
  ✔︎ Including:  base, components, themes[29], utilities
  
✓ 1052 modules transformed.
[vite]: Rollup failed to resolve import "@qwik-city-plan" from "packages/core/src/s_aaalzkh0klq.js".
This is most likely unintended because it can break your application at runtime.
If you do want to externalize this module explicitly add it to
`build.rollupOptions.external`
transforming (1258) ../../node_modules/lodash/_cacheHas.jsinfo => Manager built (21 s)

 >  NX   [vite]: Rollup failed to resolve import "@qwik-city-plan" from "packages/core/src/s_aaalzkh0klq.js".

   This is most likely unintended because it can break your application at runtime.
   If you do want to externalize this module explicitly add it to
   `build.rollupOptions.external`
   Pass --verbose to see the stacktrace.


 ———————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————

 >  NX   Ran target build-storybook for project core (23s)
 
    ✖    1/1 failed
    ✔    0/1 succeeded [0 read from cache]
 
   See Nx Cloud run details at https://nx.app/runs/4wHL3jkmOH


 *  The terminal process "/bin/zsh '-c', 'npx nx run core:build-storybook'" terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it. 

Currently the `...props` is overriding the inner `class` of the component

for example:

<Alert class="alert-success">Message</Alert>

Will not render correctly because it'll replace the built in alert class inside the component

We need to merge them so both alert and alert-success will be part of the inner component's css class

A style guide should be written to maintain consistency across contributions.

E.g. Including a Signal suffix at the end of variables that utilizes Qwik's useSignal

Motivation

A Dialog is an UX-concept that is often used in projects.
We can provide a Dialog having an API that guides developers through the most common use cases:

• Responsiveness
• Animations/Transitions
• Dragging
• Scrolling long Content

Inspiration

• MUI Dialog
• a11y-dialog
• radix-dialog-primitive

Next Steps

• Study implementation of a11y-dialog
• Study implementation of react-a11y-dialog
• Come up with API-Design (hook-API for headless UI vs. component-API)
• Write Tests
• Write documentation
• Research features of other libraries
  • Sticky Actions Bar for long scrolling content (comes with Dialog.Actions)
  • Display Dialog as FullScreen
  • Allow custom open/close Animations
  • Allow Dragging Dialog
• Decide which features make it into the BETA

Accessibility is super important in my environment, and DaisyUI has real issues when it comes to accessibility.

Have you considered using a UI set like Headless UI that puts accessibility first?

Setup storybook for docs