Skip to content

Conversation

@Atry
Copy link
Contributor

@Atry Atry commented May 20, 2016

This will avoid unnecessary type cast like event.currentTarget.asInstanceOf[Input].value

@Atry
Copy link
Contributor Author

Atry commented Jun 30, 2016

@sjrd Could you review this PR, please?

@sjrd
Copy link
Member

sjrd commented Jul 7, 2016

I'm very uneasy about shadowing the names of event classes within the definitions of Element classes. This seems to invite a lot of confusion, and does not look like a sane design.

I'm sympathetic to the idea of making scalajs-dom more tightly typed, but IMO this should be done across the board by careful, integrated design. For example, ideally something like x.addEventListener("mouseup", (e: MouseEvent) => ...) should typecheck.

Wrt your use case, it seems to me that there is a much easier (and more readable) solution, which is simply to use the val of whatever element your attaching the event to. For example:

val b = document.createElement("input").asInstanceOf[html.Input] b.addEventListener("keyup", { (e: dom.Event) => val s = b.value // instead of `e.currentTarget.asInstanceOf[html.Input].value` }
@Atry
Copy link
Contributor Author

Atry commented Aug 3, 2016

I heavily used currentTarget in Binding.scala's TodoMVC DEMO:

https://github.com/ThoughtWorksInc/todo/blob/8fb28392ba73567cee8fbb37504615323e1d1fa2/js/src/main/scala/com/thoughtworks/todo/Main.scala#L109

I think assigning elements to a vals (like what I did here) will make these HTML templates too complicated to understand.

@sjrd
Copy link
Member

sjrd commented Mar 14, 2018

Closing this as part of an effort to close old PRs and be back on a sane basis. Something that deep would require careful analysis, and maybe a larger impact on all sides of the API.

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

Labels

None yet

2 participants