Awesome
Derivatives
Subscriptions distilled.
usage | comparisons | change log | API docs
A note on terminology: There are a lot of things with similar meanings/use-cases around: subscriptions, reactions, derived atoms, view models.
I'll introduce another to make things even worse: derivative. A derivative implements IWatchable
and it's value is the result of applying a function to the value of other things (sources) implementing IWatchable
. Whenever any of the sources change the value of the derivative is updated.
Why this library
Let's assume you're hooked about the idea of storing all your application state in a single atom (db
). (Why this is a great idea is covered elsewhere.)
Most of your components don't need the entirety of this state and instead receive a small selection of it that is enough to allow the components to do their job. Now that data is not always a subtree (i.e. (get-in db ...)
) but might be a combination of various parts of your state. To transform the data in a way that it becomes useful for components you can use a function: (f @db)
.
Now you want to re-render your application whenever db
changes so the views are representing the data in db
. You end up calling f
a lot, and remember, f
has to do all the transformation for all components that could be rendered on the page, pretty inefficient!
To optimise we can create derivatives that contain data in shapes ideal to specific components and re-render those components when the derivative supplying the data changes.
These derivatives may depend on other derivatives, all ultimately leading up to your single db
atom. To keep things efficient we only recalculate the value of a derivative when any of it's sources changes.
The intention of this library is to make the creation and usage of these interdependent references (derivatives) simple and efficient.
A secondary objective is also to achieve the above without relying on global state being defined at the namespace level of this library. (See re-frame vs. pure-frame.)
What this library helps with
- transform
db
into shapes suited for rendering (a.k.a. view models) - managing a pool of derivatives so only needed derivatives are created and freed as soon as they become unused (currently Rum specific)
- server-side rendering (to some degree)
What this library doesn't help with
- Ensuring the required data is in
db
(server/client rendering) - Parameterized Subscriptions
Usage
[org.martinklepsch/derivatives "0.3.1-alpha"] ;; latest release
Derivatives of your application state can be defined via a kind of specification like the one below:
(def *db-atom (atom 0))
(def drv-spec
{;; a source with no dependencies
:db [[] *db-atom]
;; a derivative with a dependency
:inc [[:db] (fn [db] (inc db))]
;; a derivative with multiple dependencies
:as-map [[:db :inc] (fn [db inc] {:db db :inc inc})]}
A specification like the above can be easily turned into a map with the same keys where the values are derivatives (see org.martinklepsch.derivatives/build
).
Also it can be turned into a registry that can help with only creating needed derivatives and freeing them up when they become unused (see org.martinklepsch.derivatives/derivatives-pool
).
What follows is Rum specific and this library has a dependency on Rum but this pattern could be used with old Om apps, or even Reagent's reactions. I'm very open to changes in that direction.
In a Rum component tree you might use derivatives as follows (assuming *db-atom
and drv-spec
as above):
(rum/defcs derived-view < rum/reactive (d/drv :inc) (d/drv :as-map)
[s]
[:div
[:p ":inc " (-> (d/react s :inc) pr-str)]
[:p ":as-map " (-> (d/react s :as-map) pr-str)]])
(rum/defc app < (d/rum-derivatives drv-spec)
[spec]
[:div
[:button {:on-click #(swap! *db-atom inc)} "inc"]
(derived-view)])
The rum-derivatives
mixin adds two functions to the React context of all child components: one to get a derivative and one to release it. The drv
mixin adds hooks to your components that do exactly that and allow you to access the derivatives via component state.
Comparisons
Plain rum.core/derived-atom
Rum's derived-atoms serve as building block in this library but there are some things which are (rightfully) not solved by derived-atoms:
- Creation of interdependent derivative chains and
- a mechanism to only create actually needed derived-atoms.
A small code sample should illustrate this well:
(def *db (atom {:count 0})) ; base db
(def *increased
(rum/derived-atom [*db]
::increased
(fn [db]
(inc (:count db)))))
(def *as-map
(rum/derived-atom [*db *increased]
::as-map
(fn [db incd]
{:db db :increased incd})))
compared with the way this could be described using derivatives:
(def *db (atom {:count 0}))
(def spec
;; {name [depends-upon derive-fn]}
{:db [[] *db]
:increased [[:db] (fn [db] (inc (:count db)))]
:as-map [[:db :increased] (fn [db incd] {:db db :increased incd})]})
The benefit here is that we don't use vars to make sure the dependencies are met and that we provide this information in a way that can easily be turned into a dependency graph (data FTW) which will later help us only calculating required derivatives (done by derivatives-pool
). In comparison the first snippet will create derived-atoms and recalculate them whenever any of their dependencies change, no matter if you're using the derived-atom in any of your views.
Re-Frame Subscriptions
The way they work Re-Frame's dynamic subscriptions are not much different from the approach chosen here, they vary in two ways however:
- In Re-Frame you can do
(subscribe [:sub-id "a parameter"])
, with derivatives you can't. Instead these parameters need to be put intodb
and be used (potentially via another derivative) from there. - In Re-Frame subscriptions may have side-effects to listen to remote changes etc. This library does not intend to solve this kind of problem and thus side effects are discouraged.
Why no parameterized subscriptions?
In my personal experience a lot of non-idiomatic, non performance optimal re-frame use comes from having subscriptions in every corner of the code. Parameterized subscriptions enable this even more.
While a bandaid more than a solution the lack of parameterized subscriptions in Derivatives is meant to discourage ad-hoc, throwaway subscription use and instead encourage thoughtful reshaping of data from your DB into a form suitable for rendering.
Contributing
Feedback and PRs welcome.
Tests can be run with boot --source-paths test test
or boot -s test test
.
--
License: MPLv2, see LICENSE
.