On Sunday, March 8, 2015 at 10:11:43 PM UTC+11, Mike Thompson wrote:
> > 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
I just wrote this quickly (probably contains a lot of typos):
https://github.com/Day8/re-frame/wiki/Alternative-dispatch,-routing-&-handling
I was attempting to show that the existing "re-frame base" is reasonably
flexible and pluggable (up to a point).
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.
