InputField: Support step?

[martinkrulltott]

Does InputField support the step prop for type: number?

[KaiVandivier]

It looks like it does not yet - that would be a good thing to add. I'll make a ticket

[martinkrulltott]

While at it, min and max would be very useful too.
Unless these should be added explicitly it would be enough to just pass through ...rest to the underlying input.

[janhenrikoverland]

Same answer as (almost) always: It's not a blocker, it works without it, but the user experience gets a bit weird.

[KaiVandivier]

Ticket: https://jira.dhis2.org/browse/LIBS-133

[Birkbjo]

Isn't this something we could add under a inputProps-object that is spread into the input-element? There's quite a lot of attributes for inputs that we should support, and since we are not spreading rest-props anywhere, I think that adding all these manually on a on-request basis is just annoying for both users and maintainers.

[KaiVandivier]

I think forwarding props from InputField-type components to their children Input components would probably make sense too

[KaiVandivier]

There is some discussion about a more generalized solution (which I support), but in the mean time this PR is open: dhis2/ui#520

[KaiVandivier]

Added in UI v6.5.0 🎉

[ismay]

@KaiVandivier mentioned that it'd be good to copy my comments from slack on this topic to a thread here as well.

I think that for the base components that basically resemble html elements with a bit of additional styling, I'd be in favor of just forwarding all props to the html element the component wraps. So like the button, the table components, etc. I was kind of against that initially, but I think for basic components that just add styling it simplifies things a lot. Base components are used in such a wide variety of usecase that it's not doable for us to manually cover all of them (well).

I personally think we currently have too much logic for our base components, where I think the user should be responsible for implementing that logic (or we could do it higher up in the lib for common usecases). That seems more flexible and simpler to me.

As to how we'd deal with props that have special styling purposes. Say, like the primary, secondary flags on a button, etc. We could just pick those out of the props, use them internally for setting conditional styles and not forward them. That's what you'd do with styled-components and what I love about how that lib works. It forces you to only use props for styling, and does not allow you to implement any other type of logic.

That way you're automatically separating "styled" components, from components that do something. Which seems like a good distinction to me between core components (only implement styles), and components that live higher up the hierarchy (can have behaviour).

I think I remember Viktor also saying that he was thinking about just forwarding all props for core components, and making them simpler. Though I don't know if he'd agree with the above.

To me the above seems like a practical solution that doesn't require us to vet each and every prop addition for basic components.

copied from: #238 (reply in thread)