@kauko: You can just do it manually. If you have recipe books that have a list of recipes, instead of storing the recipe information you would store [:recipe recipe-id]. Your :recipe/get subscription would just look like (get @db [:recipe recipe-id]), and your recipes would all go into your data structure as {:recipe {1 recipe-1, 2 recipe-2}}.

hello reframians. am I right that approach outlined here https://github.com/yatesco/re-frame-stiching-together is still linear in complexity w.r.t. number of records?

because if we subscribe as (subscribe [:foo some-id]) for each id in some map {id -> foo}, those subscriptions will be evaluated for each map update. granted, if we update only one entry in that map, only one subscription will produce new value (and will trigger component update), but nevertheless the overhead is linear in a number of subscriptions

I hope that the explanations is clear

@si14 your analysis reads correctly. There may be N identical? checks when you update a collection containing N items (and each is obtained via a subscription)

This sort of a tracing technique will give you insight into what subcriptions are running and what components are getting rerendered: https://github.com/Day8/re-frame/wiki/Debugging

@mikethompson: do you see this as a problem? As far as I can understand, in om.next it can be solved by om.next itself because of their queries (which can use reverse indexes) instead of general functions. Please don't take it as an offence, I like re-frame a lot and am generally curious.

on the second thought, it may be just an additional function like "subscribe-in"

@si14: I haven't found it to be a practical problem. Regarding om.next, I've not yet looked at it, so I can't give you a comparison, sorry. Others here may know more and chime in.