Fix: typos in documentation

doc/advanced/composing_routers.md

@@ -43,7 +43,7 @@ Let's add a helper function to create a new router with extra routes:
     (r/options router)))
 ```
 
-We can now create a new router with an extra routes:
+We can now create a new router with extra routes:
 
 ```clj
 (def router2
@@ -137,7 +137,7 @@ Matching by path:
 
 That didn't work as we wanted, as the nested routers don't have such a route. The core routing doesn't understand anything the `:router` key, so it only matched against the top-level router, which gave a match for the catch-all path.
 
-As the `Match` contains all the route data, we can create a new matching function that understands the `:router` key. Below is a function that does recursive matching using the subrouters. It returns either `nil` or a vector of mathces.
+As the `Match` contains all the route data, we can create a new matching function that understands the `:router` key. Below is a function that does recursive matching using the subrouters. It returns either `nil` or a vector of matches.
 
 ```clj
 (require '[clojure.string :as str])
@@ -196,7 +196,7 @@ So, we can nest routers, but why would we do that?
 
 ## Dynamic routing
 
-In all the examples above, the routers were created ahead of time, making the whole route tree effective static.  To have more dynamic routing, we can use router references allowing the router to be swapped over time. We can also create fully dynamic routers where the router is re-created for each request. Let's walk through both cases.
+In all the examples above, the routers were created ahead of time, making the whole route tree effectively static.  To have more dynamic routing, we can use router references allowing the router to be swapped over time. We can also create fully dynamic routers where the router is re-created for each request. Let's walk through both cases.
 
 First, we need to modify our matching function to support router references:
 

doc/advanced/shared_routes.md

@@ -2,14 +2,14 @@
 
 As `reitit-core` works with both Clojure & ClojureScript, one can have a shared routing table for both the frontend and the backend application, using the [Clojure Common Files](https://clojure.org/guides/reader_conditionals).
 
-For backend, you need to define a `:handler` for the request processing, for fronend, `:name` enables the use of [reverse routing](../basics/name_based_routing.md).
+For backend, you need to define a `:handler` for the request processing, for frontend, `:name` enables the use of [reverse routing](../basics/name_based_routing.md).
 
 There are multiple options to use shared routing table.
 
 ## Using reader conditionals
 
 ```clj
-;; define the handlers for for clojure
+;; define the handlers for clojure
 #?(:clj (declare get-kikka))
 #?(:clj (declare post-kikka))
 

doc/basics/name_based_routing.md

@@ -75,7 +75,7 @@ Path-parameters are automatically coerced into strings, with the help of (curren
 ;        :path-params {:id "1"}}
 ```
 
-There is also a exception throwing version:
+There is also an exception throwing version:
 
 ```clj
 (r/match-by-name! router ::user)

doc/basics/route_conflicts.md

@@ -2,7 +2,7 @@
 
 We should fast if a router contains conflicting paths or route names. 
 
-When a `Router` is created via `reitit.core/router`, both path and route name conflicts are checked automatically. By default, in case of conflict, an `ex-info` is thrown with a descriptive message. Is some (legacy api) cases, path conflicts are should be allowed and one can override the path conflict resolution via `:conflicts` router option.
+When a `Router` is created via `reitit.core/router`, both path and route name conflicts are checked automatically. By default, in case of conflict, an `ex-info` is thrown with a descriptive message. In some (legacy api) cases, path conflicts should be allowed and one can override the path conflict resolution via `:conflicts` router option.
 
 ## Path Conflicts
 

doc/basics/route_data.md

@@ -1,6 +1,6 @@
 # Route Data
 
-Route data is the core feature of reitit. Routes can have any map-like data attached to them. This data is interpreted either by the client application or the `Router` via its `:coerce` and `:compile` hooks. Route data format can be defined and validated with `clojure.spec` enabling a architecture of both [adaptive and principled](https://youtu.be/x9pxbnFC4aQ?t=1907) components.
+Route data is the core feature of reitit. Routes can have any map-like data attached to them. This data is interpreted either by the client application or the `Router` via its `:coerce` and `:compile` hooks. Route data format can be defined and validated with `clojure.spec` enabling an architecture of both [adaptive and principled](https://youtu.be/x9pxbnFC4aQ?t=1907) components.
 
 Raw routes can have a non-sequential route argument that is expanded (via router `:expand` hook) into route data at router creation time. By default, Keywords are expanded into `:name` and functions into `:handler` keys.
 
@@ -45,7 +45,7 @@ The expanded route data can be retrieved from a router with `routes` and is retu
 
 ## Nested route data
 
-For nested route trees, route data is accumulated recursively from root towards leafs using [meta-merge](https://github.com/weavejester/meta-merge). Default behavior for colections is `:append`, but this can be overridden to `:prepend`, `:replace` or `:displace` using the target meta-data.
+For nested route trees, route data is accumulated recursively from root towards leafs using [meta-merge](https://github.com/weavejester/meta-merge). Default behavior for collections is `:append`, but this can be overridden to `:prepend`, `:replace` or `:displace` using the target meta-data.
 
 An example router with nested data:
 
@@ -73,7 +73,6 @@ Resolved route tree:
 ;                    :roles #{:db-admin}}]]
 ```
 
-
 ## Expansion
 
 By default, router `:expand` hook maps to `reitit.core/expand` function, backed by a `reitit.core/Expand` protocol. One can provide either a totally different function or add new implementations to that protocol. Expand implementations can be recursive.

doc/coercion/coercion.md

@@ -138,7 +138,7 @@ We get the coerced paremeters back. If a coercion fails, a typed (`:reitit.coerc
 
 ## Full example
 
-Here's an full example for doing routing and coercion with Reitit and Schema:
+Here's a full example for doing routing and coercion with Reitit and Schema:
 
 ```clj
 (require '[reitit.coercion.schema])

doc/http/transforming_interceptor_chain.md

@@ -2,7 +2,7 @@
 
 There is an extra option in http-router (actually, in the underlying interceptor-router): `:reitit.interceptor/transform` to transform the interceptor chain per endpoint. Value should be a function or a vector of functions that get a vector of compiled interceptors and should return a new vector of interceptors.
 
-**Note:** the last interceptor in the chain is usually the handler, compiled into an Interceptor. Applying a tranfromation `clojure.core/reverse` would put this interceptor into first in the chain, making the rest of the interceptors effectively unreachable. There is a helper `reitit.interceptor/transform-butlast` to transform all but the last interceptor.
+**Note:** the last interceptor in the chain is usually the handler, compiled into an Interceptor. Applying a transformation `clojure.core/reverse` would put this interceptor into first in the chain, making the rest of the interceptors effectively unreachable. There is a helper `reitit.interceptor/transform-butlast` to transform all but the last interceptor.
 
 ## Example Application
 

doc/ring/default_middleware.md

@@ -53,7 +53,7 @@ A preconfigured middleware using `exception/default-handlers`. Catches:
 
 ### `exception/create-exception-middleware`
 
-Creates the exception-middleware with custom options. Takes a map of `identifier => exception request => response` that is used to select the exception handler for the thown/raised exception identifier. Exception idenfier is either a `Keyword` or a Exception Class.
+Creates the exception-middleware with custom options. Takes a map of `identifier => exception request => response` that is used to select the exception handler for the thrown/raised exception identifier. Exception idenfier is either a `Keyword` or a Exception Class.
 
 The following handlers are available by default:
 
@@ -63,7 +63,7 @@ The following handlers are available by default:
 | `:muuntaja/decode`                   | handle Muuntaja decoding exceptions
 | `:reitit.coercion/request-coercion`  | request coercion errors (http 400 response)
 | `:reitit.coercion/response-coercion` | response coercion errors (http 500 response)
-| `::exception/default`                | a default exception handler if nothing else mathced (default `exception/default-handler`).
+| `::exception/default`                | a default exception handler if nothing else matched (default `exception/default-handler`).
 | `::exception/wrap`                   | a 3-arity handler to wrap the actual handler `handler exception request => response` (no default).
 
 The handler is selected from the options map by exception idenfitifier in the following lookup order:

doc/ring/dynamic_extensions.md

@@ -16,7 +16,7 @@ Example middleware to guard routes based on user roles:
         (handler request)))))
 ```
 
-Mounted to an app via router data (effecting all routes):
+Mounted to an app via router data (affecting all routes):
 
 ```clj
 (def handler (constantly {:status 200, :body "ok"}))

doc/ring/route_data_validation.md

@@ -144,7 +144,7 @@ Adding the `:zone` to route data fixes the problem:
 
 ### Implicit specs
 
-By design, clojure.spec validates all fully-qualified keys with `s/keys` specs even if they are not defined in that keyset. Validation in implicit but powerful.
+By design, clojure.spec validates all fully-qualified keys with `s/keys` specs even if they are not defined in that keyset. Validation is implicit but powerful.
 
 Let's reuse the `wrap-enforce-roles` from [Dynamic extensions](dynamic_extensions.md) and define specs for the data:
 

doc/ring/swagger.md

@@ -8,7 +8,7 @@ Reitit supports [Swagger2](https://swagger.io/) documentation, thanks to [schema
 
 To enable swagger-documentation for a ring-router:
 
-1. annotate you routes with swagger-data
+1. annotate your routes with swagger-data
 2. mount a swagger-handler to serve the swagger-spec
 3. optionally mount a swagger-ui to visualize the swagger-spec