Fix Inputs interactive area

[ariser]

Why

Horizontal space in Inputs appear interactive, and should be interactive, but is not.
Clicking anywhere within visible input area should activate the field.

inactive-input-padding.mov

What

To address the issue:

• Changed Inputs layout
• TextField: introduced props startContent and endContent, that accept any ReactNode and render extra content before or after input control
• SearchField: removed all code and remade the component on top of TextField, because they are exactly the same; SearchField now uses startContent to render its icon
• PasswordField: used the same utility component to render the eye button as TextField uses to render endContent
• Changed how icons/buttons placed inside Inputs behave:
  • before: hidden icons still occupy space
  • after: hidden icons are not rendered at all
  • why: hidden icons obscure interaction with the field in the same way; clicking any empty space should activate the field, but with hidden icons it's not the case

Also:

• Updated stories for TextField, SearchField, and PasswordField to be auto-generated; now they are more informative and up-to-date with the actual components API.
  • before: https://click-ui.vercel.app/?path=/docs/forms-input-textfield--docs
  • after: https://click-ui-git-textfield-active-area-clickhouse.vercel.app/?path=/docs/forms-input-textfield--docs

Remaining issues

• Because of how Inputs are built, there is still non-interactive areas in some cases. In particular, because we use gap to create space between elements inside InputWrapper, these gaps don't have proper cursor, and aren't interactive. To be fixed in next iterations.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
click-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 16, 2025 8:01pm

[ariser]

readOnly disappeared from the parameters list, because it's actually a part of the native input API, not of the click-ui component API.
And rightfully so, because we don't actually support this property. If you set readOnly together with clear, then it's possible to clear the field, despite it being read-only.

We need to

• stop accepting any native property in component API. Because:
  1. we can't guarantee they will work, considering we have custom component logic (readOnly is an example)
  2. they clog up component API, making it hard to use
  3. it is not clear, which HTML element these props will be assigned to
• properly support hand-picked properties like readOnly in the component
• optionally, accept prop controlProps/controlAttrs that would accept all native attributes and pass them directly to the control

[ariser]

We also have a resize in the params list now, that doesn't actually work! Even for TextArea!
But it's also correct, because components do accept this property. They don't process it in any way, but they do accept it.

[ariser]

is there any reason we were hiding icons using visibility rather than not rendering them?

[ariser]

mind accepted visual changes: https://www.chromatic.com/build?appId=6481a2f37ea081d3131e5219&number=3001