re-frame-10x/docs/HyperlinkedInformation/UnchangedLayer2.md

60 lines
2.9 KiB
Markdown
Raw Normal View History

This document briefly explains why `re-frame-trace` gives you an option to
ignore unchanged layer 2 subscriptions.
2018-01-18 00:50:18 +00:00
### Background
The `re-frame` docs
2018-01-18 00:50:18 +00:00
[make a distinction](https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md)
between `layer 2` and `layer 3` subscriptions:
- `layer 2` subscriptions extract data directly from `app-db` and should be
trivial in nature. There should be no computation in them beyond
what is necessary to extract a value from `app-db`
- `layer 3` subscriptions take values from `layer 2` nodes as inputs, and
compute a materialised view of those values. Just to repeat: they never directly
2018-01-18 00:50:18 +00:00
extract values from `app-db`. They create new values where necessary, and because of it
2018-01-18 01:31:14 +00:00
they to do more serious CPU work. So we never want to run a
`layer 3` subscriptions unless it is necessary.
This structure delivers efficiency. You see, **all** (currently instantiated) `layer 2` subscriptions
2018-01-18 00:50:18 +00:00
will run **every** time `app-db` changes in any way. All of them. Every time.
And `app-db` changes on almost every event, so we want them to be computationally
trivial.
2018-01-18 00:50:18 +00:00
2018-01-18 01:31:14 +00:00
If the value of a `layer 2` subscription tests `=` to its previous value, then the further
2018-01-18 00:50:18 +00:00
propagation of values through the signal graph will be pruned.
2018-01-18 01:31:14 +00:00
The more computationally intensive `layer 3` subscriptions, and ultimately
the views, will only recompute if and when there has been a change in their data inputs.
2018-01-18 00:50:18 +00:00
We don't want your app recomputing views only to find that nothing has changed. Inefficient.
2018-01-18 00:50:18 +00:00
### Back To Tracing
Because `layer 2` subs run on every single modification of `app-db`, and because
very often nothing has changed, their trace can be a bit noisy. Yes, it happened,
2018-01-18 01:31:14 +00:00
but it just isn't that interesting.
2018-01-18 00:50:18 +00:00
So `re-frame-trace` gives you the option of filtering out trace for
the `layer 2` subscriptions where the value "this time" is the same as the
2018-01-18 01:31:14 +00:00
value "last time".
2018-01-18 00:50:18 +00:00
On the other hand, if a `layer 2` subscription runs and its value is
different to last time, that's potentially fascinating and you'll want to
be told all about it. :-)
### Why do I sometimes see "Layer ?" when viewing a subscription?
To determine whether a subscription is a layer 2 or layer 3, re-frame-trace
looks at the input signals to a subscription. If one of the input signals is
app-db then the subscription is a layer 2 sub, otherwise it is a layer 3. If
a subscription hasn't run yet, then we can't know if it is a layer 2 or 3.
In almost all cases, a subscription will be created (by `(subscribe [:my-sub])`)
and run (by dereferencing the subscription) within the same epoch, providing
the layer level. If you see "Layer ?" this means that a subscription was created
but not used. This may indicate a bug in your application, although there are
cases where this is ok.
In most cases, after a few more epochs, that subscription will have run, and we
know it's layer level, and can use it for any subscriptions shown on any future
(and past) epochs.