How do re-frame subscriptions work under the hood?

How does a subscription know that a part of the app-state it is concerned with has changed?

Does it just run all subscriptions and see if the value changed? If so, it's up to me to properly combine extractors and computations to improve the efficiency..

Found my answer: https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/subs.cljs#L12-L13 Ouch

computers are fast. worry about it when it becomes a problem.

it's still, quite literally, orders of magnitude more efficient than AngularJS, which re-runs every binding every time, and does so repeatedly until nothing changes anymore.

@danielstockton i work around this problem by just using reg-sub-raw and cursors when appropriate

that default behavior has always seemed crazy to me, though i'm sure it works fine for most people

I'm coming from om.next where the re-reads are more explicit, or are inferred from component queries.

I'm sure it isn't a problem if you design your app-db right, and use more layer3 subs.

that seems to be the broad advice. have simple, fast L2 subs to pull out slices of the app-db you care about, and then put everything else into L3. components at the bottom should depend directly on L3 subscriptions without further editing or filtering, so that they only run when they need to.

manipulating the DOM is many times more expensive than running a few pure CLJS functions.

Yes, i just had the realization why this is best practice. I was using far too many layer2 subscriptions probably.

I can imagine it's a common newbie mistake

I've been playing with different kinds of subscription generators -- the next direction I'm hoping to explore is specing out a nested map and generating a tree of subscriptions from that spec.