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.
On Wed, Jan 18, 2012 at 7:19 PM, Brenton <bashw...@gmail.com> wrote:
> 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?
>
> On Jan 17, 10:08 pm, kovas boguta <kovas.bog...@gmail.com> wrote:
>> 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
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
