> How would you allow an event handler to register for all events? Right now
> each one is required to explicitly register for each event via keyword. I
> have modified re-frame to allow handlers to also register a function that
> does the test.
re-frame is quite a flexible base. You should be able to build layers on top
of it, rather than modifying it.
For example, you might do it this way: dispatch to the first handler … the
one that needs to see all events … and then have IT dispatch to the next, more
specific handler?
In effect do this: (dispatch [:see-everything :specific-handler-id other])
And, then, the handler for :sees-everything, can effectively (dispatch (rest
event-v)) and the second event handler is routed to.
Remember there is nothing to stop your handler doing its own routing. In fact,
you could register just one handler with re-frame, and have it implement
whatever routing scheme you needed (using a completely different registration
scheme if needs be)
>
> Why did you choose a vector to represent the events? In my case events are
> most naturally represented as maps.
I considered both vectors and maps. Pros and Cons. From memory, I finished up
with vectors because:
- that's the way the (very clever) "Pedestal App" designers did events.
- less syntax at dispatch time.
- it seemed easy enough to send a map in a vector, if ever that was required.
- remember that middleware can do whatever transformation you want on the
way through.
- vectors can get turned into maps fairly easily:
(let [[& {:as m}] [:a 45 :b 23]]
m)
;;=> {:a 45, :b 23}
I don’t see that choosing one or the other makes much difference. Easy enough
to dispatch a map inside the vector. Its all data.
>
> I'm creating a generic event handler that instead of using the FSM
> abstraction as the controller uses a rule engine. The engine and its query
> mechanism uses maps as the primary data element to perform pattern matching.
I’m very interested to see where this approach goes. Finding ways of
"declaratively" specifying the control layer of an app is a really interesting
area to me and re-frame has more promise in this area than I have ever seen
elsewhere. I love to hear how you go with it.
>
> Obviously this is a reference implementation and I have just modified the
> code to meet my needs but I wanted to know your thinking on the choices
> mentioned above.
>
> Thanks for writing re-frame. I was struggling trying to do the same thing
> with Om, freactive and other front end libraries but never got there... Btw -
> using a programmable controller might allow re-frame to become a library
> rather than a reference implementation. TBD.
Thanks! I’m enjoying taking it forward.
As indicated above, I think re-frame’s existing router is infinitely flexible
already, to the point that you can just register one handler (all events go
there) and then you do all your own routing yourself thought that one handler.
You could implement whatever routing system you wanted operating out of that
one handler.
--
Mike
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed to the Google Groups
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.
