Icon instance vs class in Input component.

[ImogenF]

At the moment, there are 2 Input props concerning icons: statusIcon and placeholderIcon.

statusIcon is passed in as an icon instance, so that the user has more control over styling. placeholderIcon is currently the same, for consistency within the component, but it would make more sense for its size, colour etc. to be fixed.

The proposal is to remove statusIcon entirely from Input (Input already has too many options, and the user could just position an icon next to the input) and change placeholderIcon to a React component (type: IconComponentType).

[stereobooster]

As well I would throw ID fields into the discussion. Do we really need them in library? Can't they be crafted in user land instead?

[micha-f]

We're using it across the product in quite a few places. Might be nice to have it in the library then.

[ImogenF]

In that case maybe we could have ID fields as a separate component that extends Input, rather than having an isUniqueId prop on the Input component.

[TejasQ]

As well I would throw ID fields into the discussion. Do we really need them in library? Can't they be crafted in user land instead?

AFAIK, ID fields are optional props that are crafted in userland, but filled in for a11y if users omit them.

operational-ui/src/Input/Input.tsx

Line 95 in 04839de

const uniqueId = useUniqueId(id)

Passing an argument to useUniqueId just uses whatever it's given (from userland) instead of generating one. I don't see your point, @stereobooster.

In that case maybe we could have ID fields as a separate component that extends Input, rather than having an isUniqueId prop on the Input component.

I like this. A new UniqueInput component or similar that's a thin wrapper around Input. 👌

[stereobooster]

I mean those