Spelling fixes
This commit is contained in:
parent
df8c1f41c8
commit
c14935dea6
12
CHANGES.md
12
CHANGES.md
|
@ -67,7 +67,7 @@ Joking aside, this is a substantial release which will change how you use re-fra
|
|||
Reagent available). But you can debug your event handler tests using full JVM tooling goodness.
|
||||
|
||||
@samroberton and @escherize have provided the thought leadership and drive here. They converted
|
||||
re-frame to `.cljc`, supplying plugable interop for both the `js` and `jvm` platforms.
|
||||
re-frame to `.cljc`, supplying pluggable interop for both the `js` and `jvm` platforms.
|
||||
|
||||
Further, they have worked with @danielcompton to create a library of testing utilities which
|
||||
will hopefully evolve into a nice step forward on both platforms: <br>
|
||||
|
@ -93,7 +93,7 @@ Joking aside, this is a substantial release which will change how you use re-fra
|
|||
successful part of the framework. We thought we were happy.
|
||||
|
||||
But recently @steveb8n gave a cljsyd talk on
|
||||
Pedistal's Interceptor pattern which suddenly transformed them from
|
||||
Pedestal's Interceptor pattern which suddenly transformed them from
|
||||
arcane to delightfully simple in 20 mins. Interceptors are
|
||||
really "middleware via data" rather than "middleware via higher order functions".
|
||||
So it is another way of doing the same thing, but thanks to @steveb8n
|
||||
|
@ -176,7 +176,7 @@ Joking aside, this is a substantial release which will change how you use re-fra
|
|||
|
||||
Breaking:
|
||||
- removed middleware `log-ex`. It is no longer needed because browsers now correctly report the
|
||||
throw site of re-thown exceptions. In the unlikely event that you absolutely still need it,
|
||||
throw site of re-thrown exceptions. In the unlikely event that you absolutely still need it,
|
||||
the source for `log-ex` is still in `middleware.cljs`, commented out. Just transfer it to your project.
|
||||
|
||||
- `debug` middleware now produces slightly different output (to console). So no code will need to change,
|
||||
|
@ -197,8 +197,8 @@ Fixed:
|
|||
|
||||
New API:
|
||||
- [#118](https://github.com/Day8/re-frame/pull/118) - Add `add-post-event-callback` to the API.
|
||||
@pupeno is developing [preprender](https://carouselapps.com/prerenderer) which looks pretty neat.
|
||||
Support this effort by adding a way for preprender to hook event processing.
|
||||
@pupeno is developing [prerenderer](https://carouselapps.com/prerenderer) which looks pretty neat.
|
||||
Support this effort by adding a way for prerenderer to hook event processing.
|
||||
|
||||
- `on-changes` middleware now official. No longer experimental.
|
||||
|
||||
|
@ -250,7 +250,7 @@ Headline:
|
|||
- mean apps, in production, stand a chance of reporting UHE
|
||||
to the user, and can perhaps even recover to a sane state.
|
||||
- #53 Fix Logging And Error Reporting
|
||||
You can now provide your own logging fucntions.
|
||||
You can now provide your own logging functions.
|
||||
Further explanation [here](https://github.com/Day8/re-frame/wiki/FAQ#3-can-re-frame-use-my-logging-functions).
|
||||
|
||||
Deprecated:
|
||||
|
|
|
@ -86,22 +86,22 @@ right value. Nice! But how do we make this magic happen?
|
|||
### Abracadabra
|
||||
|
||||
Each time an event handler is executed, a brand new `context`
|
||||
is created, and within that `context` is a brand new `:coeffect`
|
||||
is created, and within that `context` is a brand new `:coeffects`
|
||||
map, which is initially totally empty.
|
||||
|
||||
That pristine `context` value (containing a pristine `:coeffect` map) is threaded
|
||||
That pristine `context` value (containing a pristine `:coeffects` map) is threaded
|
||||
through a chain of Interceptors before it finally reaches our event handler,
|
||||
sitting on the end of a chain, itself wrapped up in an interceptor. We know
|
||||
this story well from a previous tutorial.
|
||||
|
||||
So, all members of the Interceptor chain have the opportunity to add to `:coeffects`
|
||||
via their `:before` function. This is where `:coeffect` magic happens. This is how
|
||||
new keys can be added to `:coeffect`, so that later our event handler magically finds the
|
||||
via their `:before` function. This is where `:coeffects` magic happens. This is how
|
||||
new keys can be added to `:coeffects`, so that later our event handler magically finds the
|
||||
right data (like `:local-store`) in its `cofx` argument. It is the Interceptors.
|
||||
|
||||
### Which Interceptors?
|
||||
|
||||
If Interceptors put data in `:coeffect`, then we'll need to add the right ones
|
||||
If Interceptors put data in `:coeffects`, then we'll need to add the right ones
|
||||
when we register our event handler.
|
||||
|
||||
Something like this (this handler is the same as before, except for one detail):
|
||||
|
@ -125,7 +125,7 @@ to our event handler (`cofx`).
|
|||
`inject-cofx` is part of the re-frame API.
|
||||
|
||||
It is a function which returns an Interceptor whose `:before` function loads
|
||||
a key/value pair into a `context's` `:coeffect` map.
|
||||
a key/value pair into a `context's` `:coeffects` map.
|
||||
|
||||
`inject-cofx` takes either one or two arguments. The first is always the `id` of the coeffect
|
||||
required (called a `cofx-id`). The 2nd is an optional addition value.
|
||||
|
|
|
@ -95,7 +95,7 @@ So that `specific-interceptor` could be something required for just this one
|
|||
event handler, and it can be combined the standard ones.
|
||||
|
||||
Wait on! "I see a problem", you say. `standard-interceptors` is a `vector`, and it
|
||||
is within another `vector` allong side `specific-interceptor` - so that's
|
||||
is within another `vector` along side `specific-interceptor` - so that's
|
||||
nested vectors of interceptors!
|
||||
|
||||
No problem, re-frame uses `flatten` to take out all the nesting - the
|
||||
|
|
|
@ -317,7 +317,7 @@ Notes:
|
|||
1. Notice how this wrapper extracts data from the `context's` `:coeffects`
|
||||
and then calls the handler with that data (a handler must be called with `db` and `event`)
|
||||
2. Equally notice how this wrapping takes the return value from the `-db`
|
||||
handler and puts it into `context's` `:effect`
|
||||
handler and puts it into `context's` `:effects`
|
||||
3. The modified `context` (it has a new `:effects`) is returned
|
||||
3. This is all done in `:before`. There is no `:after` (it is a noop). But this
|
||||
could have been reversed with the work happening in `:after` and `:before` a noop. Shrug.
|
||||
|
|
|
@ -33,7 +33,7 @@
|
|||
|
||||
Given an `id`, and an optional value, lookup the registered coeffect
|
||||
handler (previously registered via `reg-cofx`) and it with two arguments:
|
||||
the current value of `:coeffect` and, optionally, the value. The registered handler
|
||||
the current value of `:coeffects` and, optionally, the value. The registered handler
|
||||
is expected to return a modified coeffect.
|
||||
"
|
||||
([id]
|
||||
|
|
|
@ -45,7 +45,7 @@
|
|||
|
||||
;; -- subscriptions
|
||||
(defn reg-sub-raw
|
||||
"Associate a given `query id` with a given subscription handler fucntion `handler-fn`
|
||||
"Associate a given `query id` with a given subscription handler function `handler-fn`
|
||||
which is expected to take two arguments: app-db and query vector, and return
|
||||
a `reaction`.
|
||||
|
||||
|
|
|
@ -84,9 +84,9 @@
|
|||
Returns updated `context`. Ie. the `context` which has been threaded
|
||||
through all interceptor functions.
|
||||
|
||||
Generally speaking, an interceptor's `:before` fucntion will (if present)
|
||||
add to a `context's` `:coeffect`, while it's `:after` function
|
||||
will modify the `context`'s `:effect`. Very approximately.
|
||||
Generally speaking, an interceptor's `:before` function will (if present)
|
||||
add to a `context's` `:coeffects`, while it's `:after` function
|
||||
will modify the `context`'s `:effects`. Very approximately.
|
||||
|
||||
But because all interceptor functions are given `context`, and can
|
||||
return a modified version of it, the way is clear for an interceptor
|
||||
|
@ -179,7 +179,7 @@
|
|||
The first few interceptors in a chain will likely have `:before`
|
||||
functions which \"prime\" the `context` by adding the event, and
|
||||
the current state of app-db into `:coeffects`. But interceptors can
|
||||
add whatever they want to `:coeffect` - perhaps the event handler needs
|
||||
add whatever they want to `:coeffects` - perhaps the event handler needs
|
||||
some information from localstore, or a random number, or access to
|
||||
a DataScript connection.
|
||||
|
||||
|
|
|
@ -131,7 +131,7 @@
|
|||
;; So, for example, the next line should be interpreted as:
|
||||
;; if you are in state ":idle" and a trigger ":add-event"
|
||||
;; happens, then move the FSM to state ":scheduled" and execute
|
||||
;; that two-part "do" fucntion.
|
||||
;; that two-part "do" function.
|
||||
[:idle :add-event] [:scheduled #(do (-add-event this arg)
|
||||
(-run-next-tick this))]
|
||||
|
||||
|
|
|
@ -144,7 +144,7 @@
|
|||
|
||||
Notes:
|
||||
1. cater for `path` appearing more than once in an interceptor chain.
|
||||
2. `:effect` may not contain `:db` effect. Which means no change to
|
||||
2. `:effects` may not contain `:db` effect. Which means no change to
|
||||
`:db` should be made.
|
||||
"
|
||||
[& args]
|
||||
|
|
Loading…
Reference in New Issue