Event for submitting single-field (`onEnterKey`/`onSubmit` perhaps?)

[frnco]

I've been using Mint for a while, and in pretty much every project I ended up having to deal with the same problem. The most common scenario is when creating a Search Box. Seems pretty simple, create a <Ui.Input >, define a state to hold its value (Shouldn't be needed but let's roll with it), define an onChange event that updates the state, and now I have to submit it... onIconClick makes for half of the solution, but a reasonable search box will also trigger when the user hits the Enter key, and that's not so easy in mint.

Right now I'm using this slight aberration to make this work:

onChange={(newValue : String) : Promise(Never,Void) {
  next { fieldValue = newValue }
}}
onKeyDown={(e : Html.Event) : Promise(Never,Void) {
  if (e.key == "Enter") {
    "someUrl/#{`encodeURI(#{fieldValue})`}"
    |> Window.navigate
  } else {
    Promise.never()
    }
}}
onIconClick={(e : Html.Event) : Promise(Never,Void) {
  "someUrl/#{`encodeURI(#{fieldValue})`}"
  |> Window.navigate
}}

The else branch is irrelevant boilerplate, and the e.key == "Enter" doesn't check for modifiers like Ctrl or Shift or pretty much anything. It's be a lot easier to have something like:

onSubmit={(fieldValue : String) : Promise(Never,Void){
  "someUrl/#{`encodeURI(#{fieldValue})`}"
  |> Window.navigate
}}

which could actually replace all three handlers above, with the added benefit of doing away with having a state.

Am I the only one who thinks this is a good idea, or are there others who agree we could use something like this?

[gdotdesign]

I think it would be a good addition, although I would use the onEnterSubmit name for it to be more explicit.

Alternatively we could just add an onEnter property: property onEnter : Function(Html.Event, Promise(Never, Void) which could be used like:

onEnter={(event : Html.Event) : Promise(Never,Void) {
  "someUrl/#{`encodeURI(#{Dom.getValue(event.target)})`}"
  |> Window.navigate
}}

[frnco]

I think it would be a good addition, although I would use the onEnterSubmit name for it to be more explicit.

I tried to think about how it might be used, and the action of "Submitting" an input, search box or whatever, usually can be triggered by both hitting "Enter" or clicking a button. Considering that, I was thinking about having a way to trigger onSubmit from clicking the icon (i.e., onIconClick). Ideally we would be able to have onIconClick={Ui.Input::Submit} but I suppose that would mean whenever we want to use the function version on onIconClick that function would also have to be written as an enum, i.e. Ui.Input::Function((event : Html.Event) : Promise(Never,Void) { ... })...

[gdotdesign]

I don't think it's unusual to submit an input from an icon which is displayed in an input, so we shouldn't add that, but if anybody wants to do that they can, by using the onIconClick, it's only a little boilerplate since the value of the input always needs to be store anyway.

[frnco]

I don't think it's unusual to submit an input from an icon which is displayed in an input, so we shouldn't add that, but if anybody wants to do that they can, by using the onIconClick, it's only a little boilerplate since the value of the input always needs to be store anyway.

On that note, perhaps having a Ui.Form might be a good idea. This issue's main point is how hard it is to trigger some simple actions. In pure html you define a form which has some action that happens upon it being submitted, in vanilla Javascript you can use HTML's onsubmit="someArbitraryJs()" attribute to trigger some action, in Mint however you need to couple every field to something (Either some state or use a store or whatever), and then manually deal with all that. Something like '<Ui.Form onSubmit={(e:Html.Event):Promise.never(){ someAction }}/><Ui.Field /></Ui.Form>` could make sense.

The trouble is actually making something like that work. This is one of the big issues I see with Mint's current state, the developer needs to manually keep track of every value and cross-reference stuff to do anything, and this is actually a reasonable problem to have, as there's no easy and obvious way to solve that. Still, being reasonable doesn't mean it's not annoying. Don't get me wrong though, it's a lot better than Elm and everything else that came before, but I believe it could still be improved in many ways, from having the state automatically sync with the value (Thus making it unnecessary to define an onChange handler) to having easier ways to submit a field to even having simpler ways to work with forms containing multiple fields. Currently a form with multiple fields needs either states for every field or a single state containing a record that as a field to store the data for every form field/input; and then additionally it needs onChange attributes on every form field to update their respective states - or their field on the record state, in which case it also needs to deal with Maybe -, plus a button that has to remap each and every one of such states - or fields of the state record which in this case once again also need to check for Maybe::Nothing - to something, and only then you can use it... it's a lot of boilerplate for something that is fairly simple in terms of logic.