ons-input onchange handler

[evan]

I know we can use regular <input type=text> elements, but with 2.0’s autostyling, it’s preferrable to use ons-input. The problem is that ons-input doesn’t seem to do anything to attached html event handlers to the <input> field it creates.

I’d like to be able to do:

<ons-input ... onChange=...></ons-input>

but instead if have to add more code that will locate the dynamically created <input> element and add my event handlers to it. Are there any plans in 2.0 to add support for onClick/onChange/onInput… handlers to ons-input as well as add a property to set and get the values via ons-input attributes rather than having to dig down to the input tag after it’s created?

[munsterlander]

@evan I can’t speak for the Onsen team, but based on the post here:

https://onsen.io/blog/auto-style-app-onsen/

And some other discussions, I would think that Onsen is moving to a more standards based platform. To quote @Fran-Diox from the above post:

We don’t want to mix our markup with our logic so we avoid to include onclick or onchange attributes in our elements. We will define some initialization function (controller) for every page and set up its functionality from there. This is called unobtrusive JavaScript.

So, based on that information, I would believe the lifespan of onBlank events is limited / nearing the end.

[Fran Diox]

@evan

I’m not sure what’s the problem here. This works thanks to event bubbling.
As for the get/set values, ons-input works as a normal input. Modify onsInputElement.value, onsInputElement.checked etc.

@munsterlander We prefer this approach for our sample apps because there are many new developers who can learn about it. But it’s not our goal to impose a specific code style to everyone. Anyone should be able to use onclick and those handlers if they want :sweat_smile:

[munsterlander]

@Fran-Diox Well, I retract said statements! :stuck_out_tongue_winking_eye: Good to know for future development as well.