From c14935dea6f139297203aa679337efeacd4a7d43 Mon Sep 17 00:00:00 2001 From: Daniel Compton Date: Thu, 13 Oct 2016 17:44:29 +1300 Subject: [PATCH] Spelling fixes --- CHANGES.md | 12 ++++++------ docs/Coeffects.md | 12 ++++++------ docs/Debugging-Event-Handlers.md | 2 +- docs/Interceptors.md | 2 +- src/re_frame/cofx.cljc | 2 +- src/re_frame/core.cljc | 2 +- src/re_frame/interceptor.cljc | 8 ++++---- src/re_frame/router.cljc | 2 +- src/re_frame/std_interceptors.cljc | 2 +- 9 files changed, 22 insertions(+), 22 deletions(-) diff --git a/CHANGES.md b/CHANGES.md index c297918..a88944b 100644 --- a/CHANGES.md +++ b/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:
@@ -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: diff --git a/docs/Coeffects.md b/docs/Coeffects.md index 7b0bd04..0a7242c 100644 --- a/docs/Coeffects.md +++ b/docs/Coeffects.md @@ -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. diff --git a/docs/Debugging-Event-Handlers.md b/docs/Debugging-Event-Handlers.md index 3280a85..b50fb69 100644 --- a/docs/Debugging-Event-Handlers.md +++ b/docs/Debugging-Event-Handlers.md @@ -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 diff --git a/docs/Interceptors.md b/docs/Interceptors.md index 020bf8c..363d32b 100644 --- a/docs/Interceptors.md +++ b/docs/Interceptors.md @@ -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. diff --git a/src/re_frame/cofx.cljc b/src/re_frame/cofx.cljc index fad0520..819f5ed 100644 --- a/src/re_frame/cofx.cljc +++ b/src/re_frame/cofx.cljc @@ -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] diff --git a/src/re_frame/core.cljc b/src/re_frame/core.cljc index 22ae19f..719a42c 100644 --- a/src/re_frame/core.cljc +++ b/src/re_frame/core.cljc @@ -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`. diff --git a/src/re_frame/interceptor.cljc b/src/re_frame/interceptor.cljc index 1ae09eb..99e65bb 100644 --- a/src/re_frame/interceptor.cljc +++ b/src/re_frame/interceptor.cljc @@ -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. diff --git a/src/re_frame/router.cljc b/src/re_frame/router.cljc index 898a776..b9a691e 100644 --- a/src/re_frame/router.cljc +++ b/src/re_frame/router.cljc @@ -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))] diff --git a/src/re_frame/std_interceptors.cljc b/src/re_frame/std_interceptors.cljc index ec17b70..ceb96bd 100644 --- a/src/re_frame/std_interceptors.cljc +++ b/src/re_frame/std_interceptors.cljc @@ -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]