mirror of
https://github.com/status-im/re-frame.git
synced 2025-02-23 15:28:09 +00:00
Incorporate pull #49 from @ioRekz
This commit is contained in:
parent
f5ed759767
commit
47153fe7e1
46
README.md
46
README.md
@ -55,7 +55,44 @@ Features:
|
||||
and a hilarious, insiders-joke T-shirt, ideal for conferences (in design).
|
||||
What could possibly go wrong?
|
||||
|
||||
__Warning__: this is a long document. That was the summary.
|
||||
__Warning__: this is a long document. That was the summary. The rest is a tutorial.
|
||||
|
||||
*Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)*
|
||||
|
||||
- [What Problem Does It Solve?](#what-problem-does-it-solve)
|
||||
- [Correct Acronym?](#correct-acronym)
|
||||
- [Mostly A Mashup](#mostly-a-mashup)
|
||||
- [Client Side Bias](#client-side-bias)
|
||||
- [Guiding Philosophy](#guiding-philosophy)
|
||||
- [FRP Clarifications](#frp-clarifications)
|
||||
- [Explaining re-frame](#explaining-re-frame)
|
||||
- [On Data](#on-data)
|
||||
- [The Big Ratom](#the-big-ratom)
|
||||
- [The Benefits Of Data-In-The-One-Place](#the-benefits-of-data-in-the-one-place)
|
||||
- [Flow](#flow)
|
||||
- [How Flow Happens In Reagent](#how-flow-happens-in-reagent)
|
||||
- [Components](#components)
|
||||
- [Truth Interlude](#truth-interlude)
|
||||
- [Components Like Templates?](#components-like-templates)
|
||||
- [React etc.](#react-etc)
|
||||
- [Subscribe](#subscribe)
|
||||
- [Just A Read-Only Cursor?](#just-a-read-only-cursor)
|
||||
- [The Signal Graph](#the-signal-graph)
|
||||
- [A More Efficient Signal Graph](#a-more-efficient-signal-graph)
|
||||
- [The 2nd Flow](#the-2nd-flow)
|
||||
- [Event Flow](#event-flow)
|
||||
- [What are events?](#what-are-events)
|
||||
- [Dispatching Events](#dispatching-events)
|
||||
- [Event Handlers](#event-handlers)
|
||||
- [Routing](#routing)
|
||||
- [Control Via FSM](#control-via-fsm)
|
||||
- [As A Reduce](#as-a-reduce)
|
||||
- [Derived Data, Everywhere, flowing](#derived-data-everywhere-flowing)
|
||||
- [Logging And Debugging](#logging-and-debugging)
|
||||
- [Talking To A Server](#talking-to-a-server)
|
||||
- [The CPU Hog Problem](#the-cpu-hog-problem)
|
||||
- [In Summary](#in-summary)
|
||||
- [Licence](#licence)
|
||||
|
||||
## What Problem Does It Solve?
|
||||
|
||||
@ -916,6 +953,9 @@ and sometimes with async results.
|
||||
But the `app-db` mutation is ultimately handled by re-frame (it does the `reset!). That leaves your event
|
||||
handlers pure. As a result, they tend to be easy to test and understand. Many are almost trivial.
|
||||
|
||||
There's more to event handlers than can be covered here in this introductory tutorial. Read up on
|
||||
issues like Middleware [in the Wiki](https://github.com/Day8/re-frame/wiki#handler-middleware).
|
||||
|
||||
### Routing
|
||||
|
||||
When `dispatch` is passed an event vector, it just puts that event onto a conveyor belt.
|
||||
@ -1074,7 +1114,7 @@ a checkpoint, and the events since then.
|
||||
Some events handlers will need to initiate an async server connection (e.g. GET or POST something).
|
||||
|
||||
The initiating event handlers should organise that the `on-success` or `on-fail` handlers for
|
||||
these HTTP requests themselves simply dispatch an event. They should never attempt to
|
||||
these HTTP requests themselves simply dispatch a new event. They should never attempt to
|
||||
modify `app-db` themselves. That is always done in a handler.
|
||||
|
||||
**Notes**:
|
||||
@ -1086,6 +1126,8 @@ modify `app-db` themselves. That is always done in a handler.
|
||||
- if you kick off an HTTP request in a handler, then organise for the on-success or on-fail handlers
|
||||
to dispatch their outcome. All events are handled via dispatch. on-success should never ever change
|
||||
`app-db`.
|
||||
|
||||
The [wiki](https://github.com/Day8/re-frame/wiki/Talking-To-Servers) has more on the subject.
|
||||
|
||||
## The CPU Hog Problem
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user