feat(input): add min/max/step attr for inputs (LIBS-133)

[KaiVandivier]

Adds support for adding native min, max and step attributes to inputs in Input and InputField

Relates to this discussion: dhis2/notes#240

[cypress]

---

Test summary

501 • 0 • 0 • 0

---

Run details

Project	ui
Status	Passed
Commit	8e7e25f
Started	Feb 25, 2021 11:56 AM
Ended	Feb 25, 2021 12:00 PM
Duration	03:45 💡
OS	Linux Ubuntu - 20.04
Browser	Electron 87

View run in Cypress Dashboard ➡️

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[ghost]

Changes look good to me, only thing that I'm not sure about is the accepted type (see comment). Once that's resolved this should be good to merge 👍

[ghost]

Ah, and this: I think I'd personally classify this update as a feat update, unless I'm missing something it seems like we didn't support this before and it's a new feature. But if I'm misinterpreting that and fix is actually better that's fine with me as well.

One other thing: it's good to specify a scope for all commits. So instead of say fix: ..., do fix(input): .... That way the changelog changes will be grouped by topic and easier to read. Also, I'd get rid of the merge commit by rebasing on master, that way you'll have a cleaner history before merging (not sure if that'll have an effect for semantic release, but it seems cleaner to me).

[KaiVandivier]

Ah, and this: I think I'd personally classify this update as a feat update, unless I'm missing something it seems like we didn't support this before and it's a new feature. But if I'm misinterpreting that and fix is actually better that's fine with me as well.

'feat' is fine with me 👍

One other thing: it's good to specify a scope for all commits. So instead of say fix: ..., do fix(input): .... That way the changelog changes will be grouped by topic and easier to read.

Ah, that sounds good - I'll do that from now on. I didn't do it for that commit above because it includes Input and InputField, but maybe it would have been better to split them up for scoping purposes.

Also, I'd get rid of the merge commit by rebasing on master, that way you'll have a cleaner history before merging (not sure if that'll have an effect for semantic release, but it seems cleaner to me).

I'm planning to squash merge because I don't think the individual commits here are important to see on master, does that seem fine?

Thanks @ismay!

[KaiVandivier]

Cleaned up history to two commits with correct scopes ^

[ghost]

Looks good, nice work! I'd recommend a regular merge over a squash merge in this case, since you have two updates in the PR. Would be a shame to let the rebasing go to waste 😋

[dhis2-bot]

🎉 This PR is included in version 6.5.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀