Clojurescript One: distinguishing event sources / multiple widget instances

[kovas boguta]

Pretty basic question here.

Suppose I want to have 2 copies of the form in the same application.

How will the event handlers know which form the events are coming
from, and which form needs to be modified in response to those events?

More generally, what if I have N copies of some widget that all have
the same structure, but different instance data. For example, a list
of tweets, where each tweet has "favorite" button.

My current impression is that I'd have to architect the event routing
myself, making sure some distinguishing ID is carried around
throughout.

Is this accurate?

What is the recommended way to handle this situation?

Thanks,
Kovas

[David Nolen]

I think it's an open question on how to best solve this problem. There have been many, many approaches to binding the UI to the data layer. ClojureScript One's dispatch approach is very interesting, but it might need something like efficient predicate dispatch to scale.

It's worth looking at complex binding solutions like Cocoa Bindings and simple binding UI / data binding projects like Backbone.js or Ember.js to see how much progress there is to be made in this space.

If people have other suggestion of things to look at, speak up.

David 

[Michael Fogus]

> it might need something like efficient predicate dispatch to scale.

It definitely needs something like that. I was hoping you'd be done
by now. ;-)

[Brenton]

The event-id can be any Clojure value. When you fire an event, you
need to make sure that there is enough information in this value to
properly dispatch to a reactor.

react-to takes an event predicate function which is called with the
event-id. If the function returns true then the reactor will handle
the event.

So, as you say, you would need to have a distinguishing id so that
this event predicate function can determine if it should react.

As David and Fogus point out, this is very slow at the moment. The
interesting question is: can we have the flexibility of arbitrary
event-ids and event predicate functions and make it fast?

[kovas boguta]

Thanks for the responses. I was worried I was missing something.

My concern isn't on the "dispatch" side (invoking the right function,
or how fast the right function is determined), but on the actual
action performed by the reactor, and the prospect of incidental
complexity in getting the necessary information routed through the
system.

Since the event-id can be any value, we can embed distinguishing data
into it and take it from there in a DIY fashion.

The problem with this (beyond performance) is that there is no
standard way to do it yet. Given you need both an event type, and a
unique id, there are multiple representations. {:event-type :x
:originator :y}, or [:x :y] , and all sorts of permutations... you can
also imagine attaching the originator as meta data. Or in the event
data.

Having multiple instances of some widget is a pretty common thing, so
it would be nice to have an abstraction that eliminates the
opportunity for every developer to invent their own conventions. It's
also problematic for using creating & using libraries ("am I allowed
to have only 1 of these calendar widgets per app, or is it safe to
have more?")

The current Clojurescript One design has the characteristic that it
unifies DOM event handling with general-purpose event handling. In my
mind it is not yet clear if this is a case of "over-unification". But
it has the consequence of removing the events from the context of the
DOM tree, which in other systems is what provides the context for DOM
manipulation as the reaction to the event.

Since there seems to be a lot of CLJS activity going on right now I
thought I'd raise these points.

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

[kovas boguta]

Hi David,

Setting aside the "data binding" aspect of the problem for a minute..

jQuery, Dojo and other JS libs seem to be going all-in on the "event
delegation" paradigm.

The idea is: instead of binding event handlers to each individual
instance, you let the events bubble up to the top of the document, and
then have a single mechanism that matches the [event, eventsource]
tuple to the desired function. In effect it allows elements to
inherit the dom handlers appropriate to them.

The advantages of this are: 1) Performance (no need to attach copies
of the same handler everywhere; more opportunities for JITing
optimizations) and 2) Code simplification (since adding new elements
does not require also attaching their event handlers) .

The core matching part seems up the logic/predicate dispatch alley.
Extending this kind of event-handling to data binding (for for example
having the matched tuple be [event, eventsource,
corresponding-model-data] ) might be a way to get at the problem.

[David Nolen]

On Fri, Jan 20, 2012 at 6:06 PM, kovas boguta <kovas....@gmail.com> wrote:

Hi David,

Setting aside the "data binding" aspect of the problem for a minute..

jQuery, Dojo and other JS libs seem to be going all-in on the "event
delegation" paradigm.

Yup event delegation is definitely the way to go.

David