Fork me on GitHub
#re-frame
<
2017-05-15
>
ksmithbaylor17:05:34

I've got some subscriptions that take a lot of CPU time. Is there an easy way to memoize them within re-frame?

nrako19:05:05

@ksmithbaylor can you explain a bit more what you are trying to do? The subscription won't signal a change if the data in the app-db that it is pulling from is not updated by something. When it does change, you would need to re-run the function anyway and would lose the benefits of memoize.

ksmithbaylor19:05:11

I've got an app-db with (among other things), something like this:

{:page :home
 :raw-data { ... }} ; deeply-nested map deserialized from a large JSON file on disk

ksmithbaylor19:05:57

I have a :navigate event that is fired when the user switches which page they are viewing (`:home`, :preferences, etc)

ksmithbaylor19:05:43

Some of the raw data is "inactive" and should not be considered in my app, so I have a function called active-data that takes in the raw data and returns just the relevant set of data I care about.

bradleesand19:05:13

Maybe make a sub for :active-data and register all your subs with (reg-sub :foo :<- [:active-data] (fn [active-data] ....)

ksmithbaylor19:05:31

I set up the following subscriptions:

(rf/reg-sub :raw-data
  #(:raw-data %))

(rf/ref-sub :active-data
  :<- [:raw-data]
  (fn [data _]
    (active-data data)))

ksmithbaylor19:05:59

And whenever I :navigate between pages, it is re-calling my active-data function even though only the :page key has changed in app-db.

ksmithbaylor19:05:03

Does that make sense?

ksmithbaylor19:05:20

Yeah, I have other subs that depend on :<- [:active-data].

bradleesand19:05:04

It does seems strange that it's calling active-data when only :page changes

ksmithbaylor19:05:15

Yeah. My solution right now is to pre-compute :active-data and insert it in the app-db along with :raw-data, since that only happens once when the app boots. But it would certainly be cleaner to not need to store :active-data in the app-db and instead make it just a view of :raw-data.

ksmithbaylor19:05:54

I sort of see subscriptions as views on top of db tables, and what I'm doing is sort of like a materialized view.

ksmithbaylor19:05:05

(minus the tables, of course :))

bradleesand19:05:08

that makes sense

bradleesand19:05:25

what if you just compute active-data and discard raw-data?

bradleesand19:05:37

I agree that it seems like it would be good to have subscriptions as "views" of the "raw-data" and not store "active-data"

ksmithbaylor19:05:59

I could probably do that, my hoarding tendencies tell me I might need it at some point, but I think most of my app will be built upon :active-data.

ksmithbaylor19:05:15

That's probably the best solution.

ksmithbaylor19:05:44

Does it sound like I have something hooked up wrong, though? I thought subscriptions would only be re-calculated if their input data changed.

bradleesand19:05:01

that's my understanding as well

bradleesand19:05:21

I haven't dug into it much to really understand the inner workings (yet) though

ksmithbaylor19:05:21

Alright. If I get a chance to circle back and investigate this, I'll report here. But for now I'm going to do the calculation up-front and call it a day.

sandbags23:05:50

Is re-frame-datatable compatible with re-com? I'm not sure if tables are allowed in this new flexbox world or if everything is supposed to be v-box/h-box