Inputs roadmap

[tleperou]

Summary

Lay down here the vision and progression of implementing inputs.

It's an open discussion; please provide your insights!

Expected

Per component,

• headless implementation
• storybook
• documentation – inputs, outputs, parts, CSS custom props
• real world examples – ltr & rt, english, Chinese / Vietnamese (composable keyboard inputs)
• Axe report

Components

Inputs are any elements which let users provide one or multiple values. Inputs aren't necessarily part of a form.

Inputs shall follow WIA/ARIA specifications when relevant – include the naming.

• [ ] combobox – in progress
• [ ] select
• [ ] email
• [ ] password – in progress
• [x] phone – implemented
• [ ] credit card
• [ ] address
• [ ] date
• [ ] date range

combobox #

Provide an autocomplete textfield to update the options of a listbox.

Shall support any kind of HTML content.

Expected

Additionally to the WIC/ARIA specifications,

• sync list of options
• async list of options
• text based options
• html based options

Not expected

• state management

References

• https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/combobox_role
• https://www.w3.org/WAI/ARIA/apg/patterns/combobox/
• https://react-spectrum.adobe.com/react-aria/useComboBox.html

select #

Lots of in common with the combobox.

Expected

Additionally to the WIA/ARIA specifications,

• sync list of options
• async list of options
• text based options

Not expected

• state management

email #

Basic input text for email

Expected

Additionally to the WIA/ARIA specifications,

• regex based email validation

Ideas

• use server$ functions to support MX validation

password #

An input field password, with a confirmation input

Expected

Additionally to the WIA/ARIA specifications,

• regex strength based validation
• visible / not visible string
• confirmation input

phone #

International support phone number

Expected

Additionally to the WIA/ARIA specifications,

• format number (mask)
• provide list of country and country code
• basic validation

credit card #

A (up to) three fields to let users give their payment card info

Expected

• inputs number, ccv and date
• format number (mask)
• basic validation
• regex based card type identification

Not expected

• state management
• interface with payment systems

address #

The address field consist on two different components: an auto complete textfield and a detailed set of fields (cf. line 1, line 2, city, state, zip and country). But this component make sense mostly when we consider to provide a server$ function run against services like Google Maps APIs in order to provide a great users experience:

1. first, use the autocomplete field the address to automatically find the addresses based on suggestion that a remote service provide.
2. if no match suit with the users or no address is found then the user fill manually the detail of the address

date #

tbd

date range #

tbd

[gioboa]

Can we split this issue into multiple issues? Small tasks are easy to manage and less scary to deal with. A first implementation as a reference will be awesome

[tleperou]

Sure; +1 having small tasks.

Could this be set into a markdown file inside the repo, somewhere ?

[gioboa]

I think GitHub issue is the best place to have easy and public visibility

[GrandSchtroumpf]

Do you have expectation on how these component are supposed to be composed ? Compact composition

<Combobox label="Select a movie" onSearch$={search} display$={(movie) => movie.title}>
  <Option value={movie1}>{movie1.title}</Option>
  <Option value={movie2}>{movie2.title}</Option>
</Combobox>

Or complete composition

<Combobox>
  <Searchbox onSearch$={search} display$={(movie) => movie.title}>
    <Label></Label>
  </Searchbox>
  <Popover>
    <Listbox>
      <Option value={movie1}>{movie1.title}</Option>
      <Option value={movie2}>{movie2.title}</Option>
    </Listbox>
  </Popover>
</Combobox>

Or use props:

<Combobox
  onSearch$={search}
  display$={(movie) => movie.title}
  options={filterMovies}
  ...
/>

Other ?

[tleperou]

That a good question.

The Headless is made to provide the complete composition.

The props is really interested – particularly for the reason that passing params up and down the tree is made quiet easy. But in general, for my understanding (@shairez @gioboa and other maintainers could correct me), using the content projection <Slot /> that Qwik provides is preferable.

The compact: if I've not think about it until now, I like the idea. A compact could go along Daisy and Material by reusing in a more concise way the Headless (just my thoughts here).

---

Regarding the props strategy, I open this thread on Discord – that we're happy to get your insights. Let me know if you don't have Discord, I'll DM you.

👌

[fmgono]

Hi @tleperou , I already join the Builder IO discord server, but when I click the thread, it is nothing to show. Is it on the different server? Can you also invite me?

Thanks

[tleperou]

Have you joined the Qwik-ui server ?

[fmgon0]

Yes I have, just joined a couple of days ago