Thanks for the pointers Daniel, these should come in handy as I refactor!

Best,
Jakub

On Thursday, September 7, 2017 at 6:18:23 PM UTC-4, Daniel Compton wrote:
>
> Hi Jakub
>
> You might already know this, but rather than creating the subscriptions 
> manually, you can also use syntactic sugar to specify them as a dependency. 
> For example:
>
>
> https://github.com/Day8/re-frame/blob/8555c7c5a67e94e22c968eee545b6ff2f8db63dd/examples/todomvc/src/todomvc/subs.cljs#L135-L144
>
> (reg-sub
>   :visible-todos
>   :<- [:todos]
>   :<- [:showing]
>   (fn [[todos showing] _]
>     (let [filter-fn (case showing
>                       :active (complement :done)
>                       :done :done
>                       :all identity)]
>       (filter filter-fn todos))))
>
> I'm not sure if I totally understood your question, and answered something 
> you weren't asking?
>
> Also, if you need to get into the nitty gritty of subscriptions firing and 
> seeing how long they take to run, you can look at 
> https://github.com/Day8/re-frame-trace. We're still working on improving 
> the developer experience for general re-frame debugging/usage, but it's 
> perfect for your use case of trying to see exactly which subscriptions are 
> running, being created, and being destroyed.
>
> Hope that helps!
>
> Daniel.
>
>
> On Fri, Sep 8, 2017 at 6:53 AM Jakub Ner <[email protected] <javascript:>> 
> wrote:
>
>> I ended up just putting an empty...
>>
>>   (fn [_ _]
>>     [])
>>
>>  ... to force the code into "layer 3"/"materialized view" and that seems 
>> to work well: successfully decoupled recalculation of this function from 
>> every single unrelated *app-db* update and the nested *reactions*/
>> *subscriptions* seems to remain reactive.
>>
>> My new code with change in *green*:
>>
>> (rf/reg-sub
>>   :foo
>>  * (fn [_ _]*
>> *    [])*
>>
>>   (fn [_ [_ x y z] _]
>>     (let [A @(subs/subscribe [:l x y])
>>           B @(subs/subscribe [:m y z])
>>           C @(subs/subscribe [:n x y z])
>>           D @(subs/subscribe [:o])]
>>       (into #{}
>>             (apply concat
>>                    (for [a A
>>                          b B
>>                          :let [u (first C)]
>>                          :when @(subs/subscribe [:p a u)]
>>                      (for [c C
>>                            :when (< 0 @(subs/subscribe [:q a u c]))]
>>                        (list a u c))))))))
>>
>>
>>
>> On Thursday, September 7, 2017 at 4:47:41 AM UTC-4, Jakub Ner wrote:
>>>
>>> Hello,
>>>
>>> I'm not sure how to even search for the question I'm about to ask...  
>>> I'm fairly new to this and I hope I'm using the right terminology.
>>>
>>> I'm going through some reframe subscriptions and trying to refactor them 
>>> for performance.  My problem is that I have "layer 2"/"extraction" 
>>> subscriptions that loop through other subscriptions and do crazy things: 
>>>  slow?
>>>
>>> I'm not exactly sure what to do with these.  I thought I should make 
>>> "layer 3"/"materialized view" subscriptions out of them and have the crazy 
>>> loops "subscribe" in the first function (the one subscribing to other 
>>> reactions).  But maybe I'm out to lunch.
>>>
>>> Here is an example of the "layer 2"/"extraction" subscription I'm 
>>> dealing with:
>>>
>>> (rf/reg-sub
>>>   :foo
>>>   (fn [_ [_ x y z] _]
>>>     (let [A @(subs/subscribe [:l x y])
>>>           B @(subs/subscribe [:m y z])
>>>           C @(subs/subscribe [:n x y z])
>>>           D @(subs/subscribe [:o])]
>>>       (into #{}
>>>             (apply concat
>>>                    (for [a A
>>>                          b B
>>>                          :let [u (first C)]
>>>                          :when @(subs/subscribe [:p a u)]
>>>                      (for [c C
>>>                            :when (< 0 @(subs/subscribe [:q a u c]))]
>>>                        (list a u c))))))))
>>>
>>>
>>> Should I just make this a normal function (instead of registering a 
>>> subscription) and coerce it to be a reaction?  Would that be more efficient?
>>>  
>>>
>> -- 
>> 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] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> Visit this group at https://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 https://groups.google.com/group/clojurescript.

Reply via email to