You need an Examples page that is hosted on a wiki that anyone can edit with a few folks you delegate to as moderators (to remove spam etc)
Sent from my iPhone > On Mar 27, 2015, at 3:23 PM, Mike Thompson <[email protected]> wrote: > >> On Saturday, March 28, 2015 at 8:22:30 AM UTC+11, Colin Yates wrote: >> I see, so a subscription is more than just a projection of the db, it >> has a life-time where as an event handler is about a snapshot in time >> (guaranteed to be now?). >> >> I wasn't asking about the mechanical reasons why they weren't >> appropriate, more the concept, which you explained - thanks. >> >>> On 27 March 2015 at 21:15, Mike Thompson <[email protected]> wrote: >>>> On Saturday, March 28, 2015 at 7:52:13 AM UTC+11, Colin Yates wrote: >>>> Hi Mike, yep, that is what I meant by "> I can work around this - the >>>> subscription code typically delegates to a 'plain' defn so I can >>>> retrieve the data from the db and call the same defn, but sometimes >>>> that jars a bit." :). >>>> >>>> >>>>> On 27 March 2015 at 20:47, Mike Thompson <[email protected]> >>>>> wrote: >>>>>> On Saturday, March 28, 2015 at 7:36:26 AM UTC+11, Colin Yates wrote: >>>>>> I have various chunks of reference data, say a tree or a list of _all_ >>>>>> (i.e. active and historical) entities. I then have various subscriptions >>>>>> which refine that view, for example: >>>>>> - only active >>>>>> - only active but including a given id >>>>>> >>>>>> In the handler I sometimes need access to this data, but according to >>>>>> the re-frame doc: >>>>>> >>>>>> "Rules: >>>>>> >>>>>> components never source data directly from app-db, and instead, they use >>>>>> a subscription. >>>>>> subscriptions are only ever used by components (they are never used in, >>>>>> say, event handlers)." >>>>>> >>>>>> I can work around this - the subscription code typically delegates to a >>>>>> 'plain' defn so I can retrieve the data from the db and call the same >>>>>> defn, but sometimes that jars a bit. >>>>>> >>>>>> The fact it is useful for me to do something not only discouraged but >>>>>> actively against the rules makes me question my design somewhat; what is >>>>>> the rationale for not allowing an event handler to view a subscription? >>>>>> Am I wrong in viewing a subscription as merely a view on the data in >>>>>> which case I don't see the danger... >>>>>> >>>>>> I get that components should be divorced from the structure of the DB >>>>>> and event handlers necessarily need to know the structure but I see a >>>>>> subscriptions as more than just structure - it sometimes applies >>>>>> transformations that I would want to re-use. >>> >>> I'll expand ... >>> >>> Think about a subscription handler as: >>> 1. A query function (db) -> val ... >>> 2. some reaction wrapping around the outside >>> >>> The reaction wrapping is very useful for when you need "a stream" of >>> updates over time. Components need to get a told when "app-db" changes. >>> >>> But event handlers don't need a stream. They need a one-off value, based >>> off the db param they have been supplied. >>> >>> If you do try to use a subscription in an event handler, you'll get a >>> memory leak. The reaction won't get properly "disposed" (it is >>> automatically done for you when a Signal chain feeds through into a >>> component). >>> >>> So, repeating myself: event handlers don't need a constant stream of >>> updates. They don't need a subscription. All they need to do is call a >>> function on "db" to get a value, so factor that function out of the >>> subscription and make it available. > > > This strikes me as an FAQ, so I've started a page: > https://github.com/Day8/re-frame/wiki/FAQ > > Please feel free to edit for clarity. I wonder what else should be going in > the FAQ? > > -- > 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. -- 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.
