Skip to content

[sc-50634] Erumu: Make a Way to Set a Custom Type on TextInput - #28

Merged
robmagary merged 1 commit into
mainfrom
rob/sc-50634/erumu-text-input-custom-type
Jun 17, 2026
Merged

[sc-50634] Erumu: Make a Way to Set a Custom Type on TextInput#28
robmagary merged 1 commit into
mainfrom
rob/sc-50634/erumu-text-input-custom-type

Conversation

@robmagary

Copy link
Copy Markdown
Contributor

Adds an option to render a TextInput with a custom type. This will allow us to update the Breathmint TextField widget to render with an email type and display the correct keyboard on mobile devices in the login view.

@robmagary
robmagary merged commit db2b97e into main Jun 17, 2026
1 check passed
@robmagary
robmagary deleted the rob/sc-50634/erumu-text-input-custom-type branch June 17, 2026 11:30
, HTML.value m.currentValue
]
in
input (ourProps <> disabledProp m.disabled <> userProps) []

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This duplicates the rendering logic from render. An the very least render should call this function. It would be even better if the widget took the input type as part of init so that we don't even need separate render functions.

I also have some amount of discomfort with the fact that you can put any old input type in here (e.g. "checkbox") when the widgets are really designed around hiding that from you. It's tempting to define an enum, or at least a newtype around the the string and then some of the standard options provided as values exported from this widget.

@robmagary robmagary Jun 17, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could add a new DOM.Erumu.Widget.Input.Builder module and pattern it after the Button.Builder in Breathmint. Then I could use the Input Builder to replace the CheckboxInput, FileInput, and TextInput helper functions with calls to the builder. That would give me a central place to define the InputType enum and define a default input with the text type and matching message. That would preserve the current API and expose a smart underlying API for building these other input types.
The builder pattern is there, so it really isn't a large lift with so few options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants