Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to declare "methods" for event handlers (and other callbacks) #15

Open
dfrese opened this issue Nov 28, 2018 · 0 comments

Comments

@dfrese
Copy link
Member

dfrese commented Nov 28, 2018

DOM elements (and other native utilities) require simple real functions as event handlers, but handling the event usually requires accessing at least the component instance (this):

(dom/div {:onClick (fn [ev] (send-message! this (... ev)))})

But "binding" this in the closure like that, will recreate a new function in each rendering, and esp. if this is not a simple div but something bigger, this might have an impact on performance because functions are never =.

React solves this by implicitly binding custom "method" declarations of a class to 'this', so that a method of the class can serve as an event handler and this is bound to the component instance inside of the function body. Although the same could be done in Clojure and Reacl as well, it's not very idiomatic (this-as and so on).
Binding via a new Clojure type implementing IFn (like reactions) does not work for event-handler, as they must be real functions (at least React checks for typeof .. == "function")

Therefore I propose a new low-level class declaration like this:

(defclass foo this []
  methods [(my-handler [ev] (send-message! this ...ev))  ...]
)

Where the syntax is like that of letfn. Only this should be visible in the function bodies, because the methods should be created only once for an instance of the class.

There might be use-cases where the handling depends on the then current state and props (which could lead us on the ugly path of adding (get-local-state this) and alike), but maybe that can/should always be done in handle-message if needed anyway.

A higher level, more declarative way of defining event-handlers (resp. the translation of events into messages) could later be based on this primitive.

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

No branches or pull requests

1 participant