Re-frame db organization

We have our re-frame db application organized in this way (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 :metaimmutable.

The widget basewill take care of rendering the currently selected page by subscribing to [:widget/base :cur-page-id]and then selecting [:meta cur-page-id :page/component]. He also needs the :page/routecurrent page, which the pages themselves also need. He gets it by subscribing to (fn [db] (get-in db [cur-page-id :page/route])). It can be an anti-template, because now we have a subscription for the entire db.

We could reorganize this, but it may be good to know first what it costs in performance. Is there a way to measure this correctly?

We could, for example, save the routes in the section :widget/basewhere the pages will search for their routes through a subscription that selects only :widget/base :routes, avoiding subscribing to the entire db.

+4
source share
1 answer

For measuring subscription performance, https://github.com/Day8/re-frame-trace is recommended.

0
source

Source: https://habr.com/ru/post/1689675/


All Articles