Improve comment on enrich

This commit is contained in:
Mike Thompson 2017-01-04 07:00:34 +11:00
parent 43de26fb14
commit 1a6066348c
2 changed files with 13 additions and 10 deletions

View File

@ -206,10 +206,10 @@ On with the rest of my lies and distortions...
### reg-sub-raw
This low level part of the API, provides a way to register a subscription handler - so
This low level part of the API provides a way to register a subscription handler - so
the intent is similar to `reg-sub`.
You use it like you do other registration functions:
You use it like other registration functions:
```clj
(re-frame.core/reg-sub-raw ;; it is part of the API
:query-id ;; later use (subscribe [:query-id])
@ -231,7 +231,7 @@ As a result of point 3, each time `app-db` changes, the wrapped `reaction` will
`app-db` is an input signal to that `reaction`.
Unlike `reg-sub`, there is no 3-arity version of `reg-sub-raw`, so there's no way for you to provide an input signals function.
Instead, even simpler, you can use `subscribe` within the `reaction` itself. For example:
Instead, even simpler, you can just use `subscribe` within the `reaction` itself. For example:
```clj
(defn some-fn
[app-db event]

View File

@ -200,16 +200,19 @@
Almost any action (edit text, add new todo, remove a todo) requires a
complete reassesment of duplication errors and warnings. Eg: that edit
update might have introduced a new duplicate or removed one. Same with a
todo removal.
just made might have introduced a new duplicate, or removed one. Same with
any todo removal.
And to perform this enrichment, a function has to inspect all the todos,
possibly set flags on each, and set some overall list of duplicates.
And this duplication check might just be one check among many.
And, to perform this enrichment, a function has to inspect all the todos,
possibly set flags on each, and calculate some overall list of duplicates
(displayed at the bottom?). And this duplication check might just be one
check among many.
`f` would need to be both adding and removing the duplicate warnings.
By applying `f` in an `:after` interceptor, we keep the handlers
simple and yet we ensure this important step is not missed."
It would need to completely recompute all warnings, from scratch every time.
By applying `f` in an `:enrich` interceptor, we keep the handlers
simple and yet we ensure this important step (of getting warnings right)
is not missed on any change."
[f]
(->interceptor
:id :enrich