How to access target element in event handler?

[pveber]

Event handler for change or input events on input elements provide the value property of these elements. However this is not enough in all situations, for instance, for input elements on files. In that case, you'd need to access the target element and call Element.files on it. Is there some way to achieve this?

At first I thought event handlers should be of the form:

val onchange: (Element.t -> 'msg) -> 'msg attribute

but that would require to introduce the type Element.t in Vdom... Thanks for any hint!

[alainfrisch]

The "callbacks" in the vdom should really remain pure.

If you can attach a (unique) id to the input element, you can generate a message in the onchange callback and in the update function raise a command (Cmd.t) whose handler retrieves the Dom element through the id.

Another direction is to create a "Custom" element that manage interactions with file input elements.

It might also be possible to create a new pseudo-attribute that encapsulates the required behavior, if it is general enough. What do need to do with the Element.files?

[pveber]

Thanks for the feedback!

If you can attach a (unique) id to the input element, you can generate a message in the onchange callback and in the update function raise a command (Cmd.t) whose handler retrieves the Dom element through the id.

Yes, this is doable. Let me try this.

Another direction is to create a "Custom" element that manage interactions with file input elements.

Not clear to me how to use that, sorry. Is there an example available somewhere?

What do need to do with the Element.files?

I need to access the contents of the selected files, and the only way I know to do this is to obtain a File object, through the files method of input elements. Maybe the handler for onchange or oninput could receive a richer (read-only) representation of the event target?

[pveber]

Attaching an id to input elements, passing this id in a message and getting the corresponding element was indeed very easy and the resulting code is quite pleasant to read. Thanks a lot for the advice! I'm closing the issue since I feel there is no need to make the API more complex for that need. Thanks again.

[copy]

If you can attach a (unique) id to the input element, you can generate a message in the onchange callback and in the update function raise a command (Cmd.t) whose handler retrieves the Dom element through the id.

I'm trying to access the .checked property of inputs of type checkbox and find this solution a bit unsatisfying. It exposes the user to the ugliness of the dom and require thinking of a unique name (naming things is hard), that can then collide with the rest of the world.

The "callbacks" in the vdom should really remain pure.

Can you elaborate on this? Wouldn't a (Element.t -> 'msg) be pure as long as it doesn't modify the element? Providing this would at least give the user a method of adding their own event attributes.

[alainfrisch]

I'm trying to access the .checked property of inputs of type checkbox and find this solution a bit unsatisfying.

It would be more in line with the support for text input field to maintain the state of the checkbox in the model, generate a "onclick" message and update the internal state when processing the message.

I've added some better support for checkbox in #16, together with an example showing both bound and unbound checkboxes (bound = the "checked" property is explicitly defined and must always be synchronized between the vdom and the dom). Can you check if this suits your needs?

Wouldn't a (Element.t -> 'msg) be pure as long as it doesn't modify the element?

Indeed, but there is no way to ensure that. Currently, the Vdom module is completely independent of the DOM or any Javascript feature, and could even be compiled natively and run on the server side (for instance for running tests).

[copy]

I've added some better support for checkbox in #16, together with an example showing both bound and unbound checkboxes (bound = the "checked" property is explicitly defined and must always be synchronized between the vdom and the dom). Can you check if this suits your needs?

Yes, this works nicely. Thanks!

Currently, the Vdom module is completely independent of the DOM or any Javascript feature, and could even be compiled natively and run on the server side (for instance for running tests).

I see, that makes sense.