mirror of
https://github.com/status-im/re-frame.git
synced 2025-02-23 07:18:22 +00:00
Break apart A-Larger-App docs and restructure README
This commit is contained in:
parent
f63ae9364c
commit
e1d69fc7b5
@ -49,62 +49,4 @@ src
|
||||
└── panelN
|
||||
```
|
||||
|
||||
## What About Navigation?
|
||||
|
||||
How do I switch between different panels of a larger app?
|
||||
|
||||
Your `app-db` could have an `:active-panel` key containing an id for the panel being displayed.
|
||||
|
||||
|
||||
When the user does something navigation-ish (selects a tab, a dropdown or something which changes the active panel), then the associated event and dispatch look like this:
|
||||
|
||||
```clj
|
||||
(re-frame/reg-event-db
|
||||
:set-active-panel
|
||||
(fn [db [_ value]]
|
||||
(assoc db :active-panel value)))
|
||||
|
||||
(re-frame/dispatch
|
||||
[:set-active-panel :panel1])
|
||||
```
|
||||
|
||||
A high level reagent view has a subscription to :active-panel and will switch to the associated panel.
|
||||
```clj
|
||||
(re-frame/reg-sub
|
||||
:active-panel
|
||||
(fn [db _]
|
||||
(:active-panel db)))
|
||||
|
||||
(defn panel1
|
||||
[]
|
||||
[:div {:on-click #(re-frame/dispatch [:set-active-panel :panel2])}
|
||||
"Here" ])
|
||||
|
||||
(defn panel2
|
||||
[]
|
||||
[:div "There"])
|
||||
|
||||
(defn high-level-view
|
||||
[]
|
||||
(let [active (re-frame/subscribe [:active-panel])]
|
||||
(fn []
|
||||
[:div
|
||||
[:div.title "Heading"]
|
||||
(condp = @active ;; or you could look up in a map
|
||||
:panel1 [panel1]
|
||||
:panel2 [panel2])])))
|
||||
|
||||
```
|
||||
|
||||
## What About Event Ids?
|
||||
|
||||
As an app gets bigger, you'll tend to get clashes on event ids. One panel will need to `dispatch` an `:edit` event and so will another, but the two panels will have different handlers.
|
||||
So how then to not have a clash? How then to distinguish between one edit event and another?
|
||||
|
||||
Your goal should be to use event-ids which encode both the event itself (`:edit` ?) and the context (`:panel1` or `:panel2` ?).
|
||||
|
||||
Luckily, ClojureScript provides a nice easy solution: use keywords with a synthetic namespace. Perhaps something like `:panel1/edit` and `:panel2/edit`.
|
||||
|
||||
You see ClojureScript allows the namespace in a keyword to be a fiction. I can have the keyword `:panel1/edit` even though `panel1.cljs` doesn't exist.
|
||||
|
||||
Naturally, you'll take advantage of this by using keyword namespaces which are both unique and descriptive.
|
||||
Continue to [Navigation](Navigation.md) to learn how to switch between panels of a larger app.
|
||||
|
13
docs/Namespaced-Keywords.md
Normal file
13
docs/Namespaced-Keywords.md
Normal file
@ -0,0 +1,13 @@
|
||||
|
||||
## What About Event Ids?
|
||||
|
||||
As an app gets bigger, you'll tend to get clashes on event ids. One panel will need to `dispatch` an `:edit` event and so will another, but the two panels will have different handlers.
|
||||
So how then to not have a clash? How then to distinguish between one edit event and another?
|
||||
|
||||
Your goal should be to use event-ids which encode both the event itself (`:edit` ?) and the context (`:panel1` or `:panel2` ?).
|
||||
|
||||
Luckily, ClojureScript provides a nice easy solution: use keywords with a synthetic namespace. Perhaps something like `:panel1/edit` and `:panel2/edit`.
|
||||
|
||||
You see ClojureScript allows the namespace in a keyword to be a fiction. I can have the keyword `:panel1/edit` even though `panel1.cljs` doesn't exist.
|
||||
|
||||
Naturally, you'll take advantage of this by using keyword namespaces which are both unique and descriptive.
|
49
docs/Navigation.md
Normal file
49
docs/Navigation.md
Normal file
@ -0,0 +1,49 @@
|
||||
|
||||
## What About Navigation?
|
||||
|
||||
How do I switch between different panels of a larger app?
|
||||
|
||||
Your `app-db` could have an `:active-panel` key containing an id for the panel being displayed.
|
||||
|
||||
|
||||
When the user does something navigation-ish (selects a tab, a dropdown or something which changes the active panel), then the associated event and dispatch look like this:
|
||||
|
||||
```clj
|
||||
(re-frame/reg-event-db
|
||||
:set-active-panel
|
||||
(fn [db [_ value]]
|
||||
(assoc db :active-panel value)))
|
||||
|
||||
(re-frame/dispatch
|
||||
[:set-active-panel :panel1])
|
||||
```
|
||||
|
||||
A high level reagent view has a subscription to :active-panel and will switch to the associated panel.
|
||||
```clj
|
||||
(re-frame/reg-sub
|
||||
:active-panel
|
||||
(fn [db _]
|
||||
(:active-panel db)))
|
||||
|
||||
(defn panel1
|
||||
[]
|
||||
[:div {:on-click #(re-frame/dispatch [:set-active-panel :panel2])}
|
||||
"Here" ])
|
||||
|
||||
(defn panel2
|
||||
[]
|
||||
[:div "There"])
|
||||
|
||||
(defn high-level-view
|
||||
[]
|
||||
(let [active (re-frame/subscribe [:active-panel])]
|
||||
(fn []
|
||||
[:div
|
||||
[:div.title "Heading"]
|
||||
(condp = @active ;; or you could look up in a map
|
||||
:panel1 [panel1]
|
||||
:panel2 [panel2])])))
|
||||
|
||||
```
|
||||
|
||||
Continue to [Namespaced Keywords](Namespaced-Keywords.md) to reduce clashes on event ids.
|
@ -1,3 +1,8 @@
|
||||
Structuring Your Application
|
||||
1. [A Larger App](A-Larger-App.md)
|
||||
2. [Navigation](Navigation.md)
|
||||
3. [Namespaced Keywords](Namespaced-Keywords.md)
|
||||
|
||||
|
||||
Understanding Event Handlers:
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user