mirror of
https://github.com/metosin/reitit.git
synced 2026-01-28 09:00:33 +00:00
Improved frontend docs
This commit is contained in:
parent
bc26eaed83
commit
5abdb74424
3 changed files with 40 additions and 19 deletions
|
|
@ -1,12 +1,31 @@
|
||||||
# Frontend basics
|
# Frontend basics
|
||||||
|
|
||||||
* https://github.com/metosin/reitit/tree/master/examples/frontend
|
Reitit frontend integration is built from multiple layers:
|
||||||
|
|
||||||
|
- Core functions which are enchanted with few browser specific
|
||||||
|
features
|
||||||
|
- [Browser integration](./browser.md) for attaching Reitit to hash-change or HTML5
|
||||||
|
history events
|
||||||
|
- Stateful wrapper for easy use of history integration
|
||||||
|
- Optional [controller extension](./controllers.md)
|
||||||
|
|
||||||
|
## Core functions
|
||||||
|
|
||||||
`reitit.frontend` provides few useful functions wrapping core functions:
|
`reitit.frontend` provides few useful functions wrapping core functions:
|
||||||
|
|
||||||
- `match-by-path` version which parses a URI using JavaScript, including
|
`match-by-path` version which parses a URI using JavaScript, including
|
||||||
query-string, and also coerces the parameters.
|
query-string, and also [coerces the parameters](../coercion/coercion.md).
|
||||||
- `router` which compiles coercers by default
|
Coerced parameters are stored in match `:parameters` property. If coercion
|
||||||
- `match-by-name` and `match-by-name!` with optional `path-paramers` and
|
is not enabled, the original parameters are stored in the same property,
|
||||||
logging errors to `console.warn` instead of throwing errors (to prevent
|
to allow the same code to read parameters regardless if coercion is
|
||||||
React breaking due to errors).
|
enabled.
|
||||||
|
|
||||||
|
`router` which compiles coercers by default.
|
||||||
|
|
||||||
|
`match-by-name` and `match-by-name!` with optional `path-paramers` and
|
||||||
|
logging errors to `console.warn` instead of throwing errors to prevent
|
||||||
|
React breaking due to errors.
|
||||||
|
|
||||||
|
## Next
|
||||||
|
|
||||||
|
[Browser integration](./browser.md)
|
||||||
|
|
|
||||||
|
|
@ -21,5 +21,7 @@ Check examples for simple Ring handler example.
|
||||||
## Easy
|
## Easy
|
||||||
|
|
||||||
Reitit frontend routers require storing the state somewhere and passing it to
|
Reitit frontend routers require storing the state somewhere and passing it to
|
||||||
all the calls. Wrapper (`reitit.frontend.easy`) is provided which manages
|
all the calls. Wrapper `reitit.frontend.easy` is provided which manages
|
||||||
router instance and passes the instance to all calls.
|
a router instance and passes the instance to all calls. This should
|
||||||
|
allow easy use in most applications, as browser anyway can only have single
|
||||||
|
event handler for page change events.
|
||||||
|
|
|
||||||
|
|
@ -26,7 +26,7 @@ and `start` get called again.
|
||||||
You can add controllers to a route by adding them to the route data in the
|
You can add controllers to a route by adding them to the route data in the
|
||||||
`:controllers` vector. For example:
|
`:controllers` vector. For example:
|
||||||
|
|
||||||
```clojure
|
```cljs
|
||||||
["/item/:id"
|
["/item/:id"
|
||||||
{:controllers [{:params (fn [match] (get-in match [:path-params :id]))
|
{:controllers [{:params (fn [match] (get-in match [:path-params :id]))
|
||||||
:start (fn [item-id] (js/console.log :start item-id))
|
:start (fn [item-id] (js/console.log :start item-id))
|
||||||
|
|
@ -44,8 +44,7 @@ call
|
||||||
the URL changes. You can call it from the `on-navigate` callback of
|
the URL changes. You can call it from the `on-navigate` callback of
|
||||||
`reitit.frontend.easy`:
|
`reitit.frontend.easy`:
|
||||||
|
|
||||||
```clojure
|
```cljs
|
||||||
|
|
||||||
(ns frontend.core
|
(ns frontend.core
|
||||||
(:require [reitit.frontend.easy :as rfe]
|
(:require [reitit.frontend.easy :as rfe]
|
||||||
[reitit.frontend.controllers :as rfc]))
|
[reitit.frontend.controllers :as rfc]))
|
||||||
|
|
@ -70,10 +69,10 @@ See also [the full example](https://github.com/metosin/reitit/tree/master/exampl
|
||||||
|
|
||||||
## Nested controllers
|
## Nested controllers
|
||||||
|
|
||||||
When you nest routes in the route tree, the controllers get nested as well.
|
When you nest routes in the route tree, the controllers get concatenated when
|
||||||
Consider this route tree:
|
route data is merged. Consider this route tree:
|
||||||
|
|
||||||
```clojure
|
```cljs
|
||||||
["/" {:controllers [{:start (fn [_] (js/console.log "root start"))}]}
|
["/" {:controllers [{:start (fn [_] (js/console.log "root start"))}]}
|
||||||
["/item/:id"
|
["/item/:id"
|
||||||
{:controllers [{:params (fn [match] (get-in match [:path-params :id]))
|
{:controllers [{:params (fn [match] (get-in match [:path-params :id]))
|
||||||
|
|
@ -90,20 +89,22 @@ Consider this route tree:
|
||||||
started with the parameter `something-else`. The root controller stays on the
|
started with the parameter `something-else`. The root controller stays on the
|
||||||
whole time since its parameters do not change.
|
whole time since its parameters do not change.
|
||||||
|
|
||||||
## Authentication
|
## Tips
|
||||||
|
|
||||||
|
### Authentication
|
||||||
|
|
||||||
Controllers can be used to load resources from a server. If and when your
|
Controllers can be used to load resources from a server. If and when your
|
||||||
API requires authentication you will need to implement logic to prevent controllers
|
API requires authentication you will need to implement logic to prevent controllers
|
||||||
trying to do requests if user isn't authenticated yet.
|
trying to do requests if user isn't authenticated yet.
|
||||||
|
|
||||||
### Run controllers and check authentication
|
#### Run controllers and check authentication
|
||||||
|
|
||||||
If you have both unauthenticated and authenticated resources, you can
|
If you have both unauthenticated and authenticated resources, you can
|
||||||
run the controllers always and then check the authentication status
|
run the controllers always and then check the authentication status
|
||||||
on controller code, or on the code called from controllers (e.g. re-frame event
|
on controller code, or on the code called from controllers (e.g. re-frame event
|
||||||
handler).
|
handler).
|
||||||
|
|
||||||
### Disable controllers until user is authenticated
|
#### Disable controllers until user is authenticated
|
||||||
|
|
||||||
If all your resources require authentication an easy way to prevent bad
|
If all your resources require authentication an easy way to prevent bad
|
||||||
requests is to enable controllers only after authentication is done.
|
requests is to enable controllers only after authentication is done.
|
||||||
|
|
@ -119,7 +120,6 @@ Similar solution could be used to describe required resources as data (maybe
|
||||||
even GraphQL query) per route, and then have code automatically load
|
even GraphQL query) per route, and then have code automatically load
|
||||||
missing resources.
|
missing resources.
|
||||||
|
|
||||||
|
|
||||||
## Controllers elsewhere
|
## Controllers elsewhere
|
||||||
|
|
||||||
* [Controllers in Keechma](https://keechma.com/guides/controllers/)
|
* [Controllers in Keechma](https://keechma.com/guides/controllers/)
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue