Re-frame db organization

Viewed 252

We have our Re-frame app db organized like this (simplified for this post):

{:meta {:page/search {:page/component #'...} :page/details {:page/component #'...}}
 :widget/base {:cur-page-id :page/search}
 :page/search {:page/route {:query-params {:q "1"}, ...}, 
 :page/details {:page/route {:query-params {:q "2"}}, ...}

Consider everything under :meta immutable.

The base widget takes care of rendering the currently selected page by subscribing to [:widget/base :cur-page-id] and then selecting [:meta cur-page-id :page/component]. It also needs the :page/route of the current page, which the pages themselves also need. It gets this one by subscribing to (fn [db] (get-in db [cur-page-id :page/route])). This may be an anti-pattern because we now have a subscription to the entire db.

We could refactor this, but maybe it’s good to know first what this costs in performance. Is there a way to measure this properly?

We could e.g. store the routes under the :widget/base entry where pages would look up their own routes via a subscription that selects only :widget/base :routes, avoiding a subscription to the entire db.

1 Answers
Related