Interceptor factory which runs the given function
f in the
f is called with two arguments:
v, and is expected to
return a modified
after interceptor which is only about side effects,
f to process and alter the given
db coeffect in some useful way,
contributing to the derived data, flowing vibe.
Imagine that todomvc needed to do duplicate detection - if any two todos had
the same text, then highlight their background, and report them via a warning
at the bottom of the panel.
Almost any user action (edit text, add new todo, remove a todo) requires a
complete reassessment of duplication errors and warnings. Eg: that edit
just made might have introduced a new duplicate, or removed one. Same with
any todo removal. So we need to re-calculate warnings after any CRUD events
associated with the todos list.
Unless we are careful, we might end up coding subtly different checks
for each kind of CRUD operation. The duplicates check made after
'delete todo' event might be subtly different to that done after an
editing operation. Nice and efficient, but fiddly. A bug generator
So, instead, we create an
f which recalculates ALL warnings from scratch
every time there is ANY change. It will inspect all the todos, and
reset ALL FLAGS every time (overwriting what was there previously)
and fully recalculate the list of duplicates (displayed at the bottom?).
f in an
:enrich interceptor, after every CRUD event,
we keep the handlers simple and yet we ensure this important step
(of getting warnings right) is not missed on any change.
We can test
f easily - it is a pure function - independently of
any CRUD operation.
This brings huge simplicity at the expense of some re-computation
each time. This may be a very satisfactory trade-off in many cases.