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.
|
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
|
@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
|
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>
|
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.
|
successful part of the framework. We thought we were happy.
|
||||||
|
|
||||||
But recently @steveb8n gave a cljsyd talk on
|
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
|
arcane to delightfully simple in 20 mins. Interceptors are
|
||||||
really "middleware via data" rather than "middleware via higher order functions".
|
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
|
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:
|
Breaking:
|
||||||
- removed middleware `log-ex`. It is no longer needed because browsers now correctly report the
|
- 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.
|
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,
|
- `debug` middleware now produces slightly different output (to console). So no code will need to change,
|
||||||
|
@ -197,8 +197,8 @@ Fixed:
|
||||||
|
|
||||||
New API:
|
New API:
|
||||||
- [#118](https://github.com/Day8/re-frame/pull/118) - Add `add-post-event-callback` to the 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.
|
@pupeno is developing [prerenderer](https://carouselapps.com/prerenderer) which looks pretty neat.
|
||||||
Support this effort by adding a way for preprender to hook event processing.
|
Support this effort by adding a way for prerenderer to hook event processing.
|
||||||
|
|
||||||
- `on-changes` middleware now official. No longer experimental.
|
- `on-changes` middleware now official. No longer experimental.
|
||||||
|
|
||||||
|
@ -250,7 +250,7 @@ Headline:
|
||||||
- mean apps, in production, stand a chance of reporting UHE
|
- mean apps, in production, stand a chance of reporting UHE
|
||||||
to the user, and can perhaps even recover to a sane state.
|
to the user, and can perhaps even recover to a sane state.
|
||||||
- #53 Fix Logging And Error Reporting
|
- #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).
|
Further explanation [here](https://github.com/Day8/re-frame/wiki/FAQ#3-can-re-frame-use-my-logging-functions).
|
||||||
|
|
||||||
Deprecated:
|
Deprecated:
|
||||||
|
|
|
@ -86,22 +86,22 @@ right value. Nice! But how do we make this magic happen?
|
||||||
### Abracadabra
|
### Abracadabra
|
||||||
|
|
||||||
Each time an event handler is executed, a brand new `context`
|
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.
|
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,
|
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
|
sitting on the end of a chain, itself wrapped up in an interceptor. We know
|
||||||
this story well from a previous tutorial.
|
this story well from a previous tutorial.
|
||||||
|
|
||||||
So, all members of the Interceptor chain have the opportunity to add to `:coeffects`
|
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
|
via their `:before` function. This is where `:coeffects` magic happens. This is how
|
||||||
new keys can be added to `:coeffect`, so that later our event handler magically finds the
|
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.
|
right data (like `:local-store`) in its `cofx` argument. It is the Interceptors.
|
||||||
|
|
||||||
### Which 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.
|
when we register our event handler.
|
||||||
|
|
||||||
Something like this (this handler is the same as before, except for one detail):
|
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.
|
`inject-cofx` is part of the re-frame API.
|
||||||
|
|
||||||
It is a function which returns an Interceptor whose `:before` function loads
|
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
|
`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.
|
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.
|
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
|
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!
|
nested vectors of interceptors!
|
||||||
|
|
||||||
No problem, re-frame uses `flatten` to take out all the nesting - the
|
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`
|
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`)
|
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`
|
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. 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
|
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.
|
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
|
Given an `id`, and an optional value, lookup the registered coeffect
|
||||||
handler (previously registered via `reg-cofx`) and it with two arguments:
|
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.
|
is expected to return a modified coeffect.
|
||||||
"
|
"
|
||||||
([id]
|
([id]
|
||||||
|
|
|
@ -45,7 +45,7 @@
|
||||||
|
|
||||||
;; -- subscriptions
|
;; -- subscriptions
|
||||||
(defn reg-sub-raw
|
(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
|
which is expected to take two arguments: app-db and query vector, and return
|
||||||
a `reaction`.
|
a `reaction`.
|
||||||
|
|
||||||
|
|
|
@ -84,9 +84,9 @@
|
||||||
Returns updated `context`. Ie. the `context` which has been threaded
|
Returns updated `context`. Ie. the `context` which has been threaded
|
||||||
through all interceptor functions.
|
through all interceptor functions.
|
||||||
|
|
||||||
Generally speaking, an interceptor's `:before` fucntion will (if present)
|
Generally speaking, an interceptor's `:before` function will (if present)
|
||||||
add to a `context's` `:coeffect`, while it's `:after` function
|
add to a `context's` `:coeffects`, while it's `:after` function
|
||||||
will modify the `context`'s `:effect`. Very approximately.
|
will modify the `context`'s `:effects`. Very approximately.
|
||||||
|
|
||||||
But because all interceptor functions are given `context`, and can
|
But because all interceptor functions are given `context`, and can
|
||||||
return a modified version of it, the way is clear for an interceptor
|
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`
|
The first few interceptors in a chain will likely have `:before`
|
||||||
functions which \"prime\" the `context` by adding the event, and
|
functions which \"prime\" the `context` by adding the event, and
|
||||||
the current state of app-db into `:coeffects`. But interceptors can
|
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
|
some information from localstore, or a random number, or access to
|
||||||
a DataScript connection.
|
a DataScript connection.
|
||||||
|
|
||||||
|
|
|
@ -131,7 +131,7 @@
|
||||||
;; So, for example, the next line should be interpreted as:
|
;; So, for example, the next line should be interpreted as:
|
||||||
;; if you are in state ":idle" and a trigger ":add-event"
|
;; if you are in state ":idle" and a trigger ":add-event"
|
||||||
;; happens, then move the FSM to state ":scheduled" and execute
|
;; 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)
|
[:idle :add-event] [:scheduled #(do (-add-event this arg)
|
||||||
(-run-next-tick this))]
|
(-run-next-tick this))]
|
||||||
|
|
||||||
|
|
|
@ -144,7 +144,7 @@
|
||||||
|
|
||||||
Notes:
|
Notes:
|
||||||
1. cater for `path` appearing more than once in an interceptor chain.
|
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.
|
`:db` should be made.
|
||||||
"
|
"
|
||||||
[& args]
|
[& args]
|
||||||
|
|
Loading…
Reference in New Issue