If you clear all of your local storage and reload the page, the 10x window should show up

If you’ve enabled it correctly

if i want to subscribe to a :filtered-list which depends on a :list and a :filter subscription, how would i stack all of that into a reg-sub?

Use :<- syntax for subs

Or make multiple subscribe calls in the first function and return them as a vector

@matthewdaniel

(rf/reg-sub
    :filtered-batch-items

    ;; signals function - define inputs 
    (fn [_ _]
        [(rf/subscribe [:batch-list])  (rf/subscribe [:filter])])      ;; <-- return a 2-vector of subscriptions 

   ;; computation function 
    (fn [[batch filter-kw] query-v]           ;; <--- destructure first arg as a 2-vector of values
        (filter filter-kw batch))

Be sure to read the docs. This is all covered

https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md (be sure to read the todomvc code recomended)

Is there a way to cache subscription values? I have an expensive subscription computation and I would like to get the result of the previous computation to optimize it. In more detail: I have an event sourced system where events are stored in the db. My subscriptions iterate over these events and compute different projections/read-models. Since I know, events are never deleted, I would like to get the result of my last computation and only apply the new events. Any ideas how to solve this?

@witek I read from a event source with re-graph and updated the state each time a message was received, is that something your looking for?

I guess, computing projections is not querying, so it belongs into the event handler and not into subscriptions...

@gklijs I thought, I could deffer the computation until a projection is really required by a subscription. But it seams this is not how re-frame is intended to work...

It would be really helpful inside of event handlers to know which view components are mounted. This way one could skip computing unnessesary stuff.

No, it's the other way around, data changes, and that might in some steps lead to changes to the dom.

Yes, I get this. What bugs me all the time, is that I always have to make changes in two places (event-handlers + view) to add a view component somewhere. I am missing independent components, which I just plug in in one place.

I would like to have some kind of "co-event-handlers" which are executet on every event, whenever the corresponding view component is mounted.

Well, if you have like one separate component, witch is not always shown, and needs data from a back-end. It takes some work in this case to update the state only when needed.

exactly

I did something like that though, where a made a subscription that would give back deferent things from the db depending on the active navbar element. Not sure if that really a good practice through.

Me too. But I have made an event handler for url changes, which put the params into the db. Then the subscription reads only from db