status-im/re-frame
2
0
Fork 0
mirror of https://github.com/status-im/re-frame.git synced 2025-02-23 15:28:09 +00:00
Code Issues Projects Releases Wiki Activity

Readme WIP

Browse Source
This commit is contained in:
mike-thompson-day8 2014-12-13 01:20:41 +11:00
parent 1d9d15d598
commit d294e679d4
1 changed files with 17 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
README.md
View File

@ -1,3 +1,7 @@
## Status
Alpha. Incomplete.
## re-frame ## re-frame
re-frame is a tiny [reagent] framework for writing [SPAs] using ClojureScript. re-frame is a tiny [reagent] framework for writing [SPAs] using ClojureScript.
@ -56,7 +60,7 @@ Our re-frame diagram starts with the "well formed data at rest" bit:
app-db app-db
``` ```
So, re-frame recomends that you put your data into one place (probably one dirty great re-frame recomends that you put your data into one place (probably one dirty great
big atom) which we'll call `app-db`. Structure the data in that place, of course. big atom) which we'll call `app-db`. Structure the data in that place, of course.
Now, this advice is not the slightest bit controversial for 'real' databases, right? Now, this advice is not the slightest bit controversial for 'real' databases, right?
@ -185,7 +189,7 @@ Good, let's introduce a `reaction`:
(def n (reagent/atom "re-frame")) (def n (reagent/atom "re-frame"))
;; The computation '(greet n)' produces hiccup which is stored into 'hiccup-ratom' ;; The computation '(greet n)' produces hiccup which is stored into 'hiccup-ratom'
(def hiccup-ratom (reaction (greet n))) ;; notice the used of reaction (def hiccup-ratom (reaction (greet n))) ;; notice the use of reaction
;; what is the result of the initial computation ? ;; what is the result of the initial computation ?
(println @hiccup-ratom) (println @hiccup-ratom)
@ -237,7 +241,7 @@ app-db --> components --> hiccup --> Reagent --> VDOM --> ReactJS --> DOM
``` ```
The combined three-function pipeline should be seen as a pure The combined three-function pipeline should be seen as a pure
function `P` takes `app-db` as a parameter, and returns DOM. function `P` which takes `app-db` as a parameter, and returns DOM.
``` ```
app-db --> P --> DOM app-db --> P --> DOM
``` ```
@ -247,9 +251,9 @@ This arrangement is:
1. Easy to test. We put data into the ratom, allow the DOM to be rendered, and check that the right divs are in place. This would typically be done via phantomjs. 1. Easy to test. We put data into the ratom, allow the DOM to be rendered, and check that the right divs are in place. This would typically be done via phantomjs.
2. Easily understood. Generally, components can be understood in isolation. In almost all cases, a component is genuinely a pure fucntion, or is conceptually a pure function. 2. Easily understood. Generally, components can be understood in isolation. In almost all cases, a component is genuinely a pure fucntion, or is conceptually a pure function.
The whole thing might be a multistep process, but we only have to bother ourselves with the writing of the `components`. Reagent/ReactJS looks after the rest. The whole thing might be a multistep process, but we only have to bother ourselves with the writing of the `components`. Reagent/ReactJS looks after the rest of the pipeline.
If the `app-db` changes, the DOM changes. The DOM is a function of the ratom (state of the app). If the `app-db` changes, the DOM changes. The DOM is a function of app-db (the state of the app).
But wait ... we do have to do some work to kick off the flow correctly ... But wait ... we do have to do some work to kick off the flow correctly ...
@ -264,8 +268,10 @@ How does the flow begin. How does data flow from the `app-db` to the components?
We want our components to `subscribe` to changes in `app-db`. We want our components to `subscribe` to changes in `app-db`.
XXX Talk about (subscribe some-id) XXX A subscription is a `reaction` .... (reaction (get-in [:some :path] @app-db))
XXX needs `identical?` check for efficiency ... only propogate when value has changed
XXX Talk about registration of subscription handlers. XXX Talk about registration of subscription handlers.
XXX need to invoke (dispose XXXX)
components tend to be organised into a heirarchy and often data is flowing from parent to child compoentns. components tend to be organised into a heirarchy and often data is flowing from parent to child compoentns.
@ -382,16 +388,13 @@ XXXX handlers have to be registered
---------- The End ---------- The End
`dispatch` can be implemtned in There's a bunch of ways to implement "dispatch events". You could push the events into a core.asyc channel. Or you could call a `dispatch` multimethod, and find the right event handler by inspection of `first` on the event vectory. In our implementation `dispatch` and `router` are merged.
Remember, an event is just data. And it is flowing in the opposite direction `dispatch` is the conveyor belt, and it could be implemtned in many ways:
to the data which causes the DOm to be rendered in the first place. - it could push events into a core.asyc channel.
When an event reaches the end of the conveyor belt, it has to be routed to the right handler -- the one which handles this kind of event. `router` could be implemented as:
- a multimethod, and find the right event handler by inspection of `first` on the event vectory.
So something has to look at `first` in event vector cand know how to call the right handler.
The conveyor belt could easily be done via core.async, but we do it the simplest possible way.