[RFP] The Inputs Update

[caiotarifa]

Description

Discovering Nuxt UI and Nuxt UI Pro has been one of the highlights of 2024 for me. These libraries have saved me countless hours while delivering polished, tested, and consistent components that elevate the aesthetic and functional quality of my projects. I admire the exceptional work being done by @benjamincanac and the team, particularly with the ambitious mission of rewriting the library to embrace both TailwindCSS v4 and Reka UI within Nuxt UI v3.

One of the standout features in v3 has been the integration of TanStack Tables into the UTable component, adding to tables many new features and possibilities. However, after some usage in real-world scenarios, I’ve noticed a gap: a wider variety of input components.

I know that v3 is still in alpha, but I’d like to propose a new initiative for a future release, which I’m calling "The Inputs Update". This RFP could focus on identifying and implementing input components that would further enhance the library’s usability and versatility.

Additionally, this aligns with a prior suggestion to categorize form-related components separately within the documentation (#3019).

New Components

• UInputCurrency
  While UInputNumber provides basic formatting options, a dedicated UInputCurrency component would offer enhanced functionality for handling monetary inputs, especially in scenarios requiring localized formatting.
  
  Related: [UInput] Currency input #1704

• UInputColor
  Currently, there is an example in UColorPicker, but it feels verbose and lacks certain key features, such as a text input for users to paste HEX or RGB values.
  

• UInputEditor
  Since Reka UI lacks a native editor component, I recommend integrating a third-party solution like Quill or TipTap (which already offers Nuxt/Vue support). Although previously dismissed by the author, this feature remains highly requested by the community.
  
  Related: Proposal: Add a Built-in Rich Text Editor Component to Nuxt UI #2698, Add Markdown editor component #1889, Will volta.net's rich media editor be open source? #791

• UInputTime
  Implement the TimeField component from Reka UI, this component could support single and range-based time selection.
  Related: [InputTime] Implement component #3089, feat: time-field #3969
  

• UInputDate
  Implementation of Reka UI’s DatePicker and DateRangePicker.
  
  Related: [InputDate] Implement component #2524, Add a Date Picker Component with Manual Input Option from Reka-UI #2873

• UInputDateTime
  A hybrid component combining UInputDate and UInputTime for scenarios requiring both date and time inputs.
  

• UInputMonth
  Ideal for cases where users need to select a combination of month and year.
  

• UInputYear
  A simpler component for year-only selection.
  

• UInputMask
  Masked inputs are indispensable for formatting fields like postal codes or national IDs. I suggest leveraging Vue The Mask for implementation.
  
  Related: Custom input fields, format/parse  #1303, [Feature request] Input mask #510

• UInputPhone
  A phone input with internationalization support, much like LocaleSelect (which already displays flags and country names). The libphonenumber-js library could serve as the foundation.
  
  Related: Phone number input component #2815

Updates to Existing Components

• UPinInput → UInputPin
  Rename the existing UPinInput component to align with the naming convention used across other input components.

• UInput / UTextarea
  Add a native character counter via a counter property, configurable using the min and/or max attributes. Currently, there is an example for this functionality, but a native implementation would improve the developer experience.

Additional context

No response

[zAlweNy26]

This is awesome, nice idea!
I have just a doubt: wouldn't it be cleaner to have UInputTime, UInputDate and UInputDateTime in just one component? Something like UInputDateTime (same name, yes) but with a prop to switch between time, date and datetime (the default).
I'm saying that because they are pretty much the same component to me.
What do you think about this?

[caiotarifa]

This is awesome, nice idea! I have just a doubt: wouldn't it be cleaner to have UInputTime, UInputDate and UInputDateTime in just one component? Something like UInputDateTime (same name, yes) but with a prop to switch between time, date and datetime (the default). I'm saying that because they are pretty much the same component to me. What do you think about this?

@zAlweNy26 That’s definitely an option worth considering, and I see where you’re coming from. However, I personally believe it’s more organized and keeps responsibilities better divided—with less logical overhead—if we have separate components. This also allows the individual "pickers" to stay modular and focused.

A good example of this approach is the @mantine/dates library, which has been an inspiration for me. What are your thoughts on this perspective?

https://mantine.dev/dates/getting-started/

[benjamincanac]

Sorry for the delay on this! First of all thanks for the kind words and this proposal. We're kinda of reliant on Reka UI for those kind of components, we can only make UInputTime and UInputDate at the moment.

I don't want to go back to logic hell like in v2 where we have enough to maintain with "styling" if I can say.

Regarding UInputMask and UInputPhone, is it not doable already using those directives? 🤔 I'd rather keep the base components and give the flexibility to build whatever people wants.

(I only disagree with the PinInput rename, a InputPin would be okay if there was only one input but that's not the case)

[caiotarifa]

Hey, @benjamincanac.

Regarding the month and year selector, I agree with you and will open a new issue in the Reka UI repository to request components for these controls.

About UInputMask, UInputPhone and UInputCurrency, I really think they should be part of the core library. These are fundamental form controls that almost every web application needs, and making them available out of the box would prevent developers from reinventing the same functionality (like we have with LocaleSelect).

Finally, renaming UPinInput to UInputPin makes sense for me from a naming-convention perspective (but that's just an opinion and I don't think it's that relevant here).

---

UPDATE

I created the feature request on Reka UI, please help leaving your 👍.

unovue/reka-ui#1933