Work on explaining the importance if derive

This commit is contained in:
mike-thompson-day8 2015-03-05 10:39:09 +11:00
parent 44ad078cbb
commit e028034f48

View File

@ -94,26 +94,30 @@
(assoc-in db p (handler val v))))))) (assoc-in db p (handler val v)))))))
(defn validate (defn derive
"Middleware factory which runs a given function \"f\" in the after position. "Middleware factory which runs a given function \"f\" in the after position.
\"f\" is given the new db value and is expected to perform certain kinds of \"f\" is (db) -> db
\"overall\" checks on this new state, adding to it (or removing) necessary Different from \"after\" because f is expecteed to produce new derived data.
errors and warnings. re-frame is about derived data flowing,and this middleware allows you to
This need is such a common pattern!! There are invariably a category of derive new data each time a handler is called.
checks that require \"overall knowledge\". A usecase: f can perform certain kinds of \"overall\" validation checks
on the newly minted state, adding or removing error and warning flags.
This is such a common pattern!!
There are invariably a category of checks that require \"overall knowledge\".
For example, imagine that todomvc had to do duplicate detection - if any For example, imagine that todomvc had to do duplicate detection - if any
two todos had the same text, highlight them, and put a warning down the two todos had the same text, highlight them, and put a warning down the
bottom. bottom.
That requires access to all todos, plus the ability to assoc in one or Almost any action (edit text, add new todo, remove a todo) requires that
more duplicate reports. Perhaps make the background of these todos pink that new error/warning data be derived from the new state.
as a sign of the problem. And to perform this derivation, requires access to all todos, plus the ability to:
And that's just one kind of check, there may be a few that need to run - set (or remove) duplicate flags on individual todos (so they are
rendered with a pink background?)
- add (or remove) warnings at a more global level
And that's just one kind of check, there may be a few that are need to run
on every change. on every change.
\"f\" would need to be both adding and removing the duplicate warnings. \"f\" would need to be both adding and removing the duplicate warnings.
We don't want to pollute each handler with calls to \"f\", so we We could add a call to f in each handler but it is convienient to use
simply add it to the middleware for each handler, and presto the checks are middleware instead. "
always run.
This is a genuine part of the Derived Data, flowing thing."
[f] [f]
(fn middleware (fn middleware
[handler] [handler]
@ -127,7 +131,8 @@
"Middleware factory which runs a function \"f\" in the \"after handler\" "Middleware factory which runs a function \"f\" in the \"after handler\"
position presumably for side effects. position presumably for side effects.
\"f\" is given the value of \"db\". It's return value is ignored. \"f\" is given the value of \"db\". It's return value is ignored.
Examples: \"f\" can run schema validation. Or write current state to localstorage. etc." Examples: \"f\" can run schema validation. Or write current state to localstorage. etc.
In effect, \"f\" is meant to sideeffect. It gets no chance to change db. See \"derive\" (if you need that.)"
[f] [f]
(fn middleware (fn middleware
[handler] [handler]