-
-
Notifications
You must be signed in to change notification settings - Fork 716
/
router.cljc
240 lines (205 loc) · 10.4 KB
/
router.cljc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
(ns re-frame.router
(:require [re-frame.events :refer [handle]]
[re-frame.interop :refer [after-render empty-queue next-tick]]
[re-frame.loggers :refer [console]]
[re-frame.trace :as trace :include-macros true]))
;; -- Router Loop ------------------------------------------------------------
;;
;; A call to "re-frame.core/dispatch" places an event on a queue for processing.
;; A short time later, the handler registered to handle this event will be run.
;; What follows is the implementation of this process.
;;
;; The task is to process queued events in a perpetual loop, one after
;; the other, FIFO, calling the registered event-handler for each, being idle when
;; there are no events, and firing up when one arrives.
;;
;; But browsers only have a single thread of control and we must be
;; careful to not hog the CPU. When processing events one after another, we
;; must regularly hand back control to the browser, so it can redraw, process
;; websockets, etc. But not too regularly! If we are in a de-focused browser
;; tab, our app will be CPU throttled. Each time we get back control, we have
;; to process all queued events, or else something like a bursty websocket
;; (producing events) might overwhelm the queue. So there's a balance.
;;
;; The processing/handling of an event happens "asynchronously" sometime after
;; that event was enqueued via "dispatch". The original implementation of this router loop
;; used `core.async`. As a result, it was fairly simple, and it mostly worked,
;; but it did not give enough control. So now we hand-roll our own,
;; finite-state-machine and all.
;;
;; In what follows, the strategy is this:
;; - maintain a FIFO queue of `dispatched` events.
;; - when a new event arrives, "schedule" processing of this queue using
;; goog.async.nextTick, which means it will happen "very soon".
;; - when processing events, one after the other, do ALL the currently
;; queued events. Don't stop. Don't yield to the browser. Hog that CPU.
;; - but if any new events are dispatched during this cycle of processing,
;; don't do them immediately. Leave them queued. Yield first to the browser,
;; and do these new events in the next processing cycle. That way we drain
;; the queue up to a point, but we never hog the CPU forever. In
;; particular, we handle the case where handling one event will beget
;; another event. The freshly begotten event will be handled next cycle,
;; with yielding in-between.
;; - In some cases, an event should not be handled until after the GUI has been
;; updated, i.e., after the next Reagent animation frame. In such a case,
;; the event should be dispatched with :flush-dom metadata like this:
;; (dispatch ^:flush-dom [:event-id other params])
;; Such an event will temporarily block all further processing because
;; events are processed sequentially: we handle one event completely
;; before we handle the ones behind it.
;;
;; Implementation notes:
;; - queue processing can be in a number of states: scheduled, running, paused
;; etc. So it is modeled as a Finite State Machine.
;; See "-fsm-trigger" (below) for the states and transitions.
;; - the scheduling is done via "goog.async.nextTick" which is pretty quick
;; - when the event has :flush-dom metadata we schedule via
;; "reagent.core.after-render"
;; which will run event processing after the next Reagent animation frame.
;;
;; Events can have metadata which says to pause event processing.
;; event metadata -> "run later" functions
(def later-fns
{:flush-dom (fn [f] (after-render #(next-tick f))) ;; one tick after the end of the next animation frame
:yield next-tick}) ;; almost immediately
;; Event Queue Abstraction
(defprotocol IEventQueue
;; -- API
(push [this event])
(add-post-event-callback [this id callback-fn])
(remove-post-event-callback [this id])
(purge [this])
;; -- Implementation via a Finite State Machine
(-fsm-trigger [this trigger arg])
;; -- Finite State Machine actions
(-add-event [this event])
(-process-1st-event-in-queue [this])
(-run-next-tick [this])
(-run-queue [this])
(-exception [this ex])
(-pause [this later-fn])
(-resume [this])
(-call-post-event-callbacks [this event]))
;; Concrete implementation of IEventQueue
(deftype EventQueue [#?(:cljs ^:mutable fsm-state :clj ^:volatile-mutable fsm-state)
#?(:cljs ^:mutable queue :clj ^:volatile-mutable queue)
#?(:cljs ^:mutable post-event-callback-fns :clj ^:volatile-mutable post-event-callback-fns)]
IEventQueue
;; -- API ------------------------------------------------------------------
(push [this event] ;; presumably called by dispatch
(-fsm-trigger this :add-event event))
;; register a callback function which will be called after each event is processed
(add-post-event-callback [_ id callback-fn]
(if (contains? post-event-callback-fns id)
(console :warn "re-frame: overwriting existing post event call back with id:" id))
(->> (assoc post-event-callback-fns id callback-fn)
(set! post-event-callback-fns)))
(remove-post-event-callback [_ id]
(if-not (contains? post-event-callback-fns id)
(console :warn "re-frame: could not remove post event call back with id:" id)
(->> (dissoc post-event-callback-fns id)
(set! post-event-callback-fns))))
(purge [_]
(set! queue empty-queue))
;; -- FSM Implementation ---------------------------------------------------
(-fsm-trigger
[this trigger arg]
;; The following "case" implements the Finite State Machine.
;; Given a "trigger", and the existing FSM state, it computes the
;; new FSM state and the transition action (function).
(locking this
(trace/with-trace {:op-type ::fsm-trigger}
(let [[new-fsm-state action-fn]
(case [fsm-state trigger]
;; You should read the following "case" as:
;; [current-FSM-state trigger] -> [new-FSM-state action-fn]
;;
;; So, for example, the next line should be interpreted as:
;; if you are in state ":idle" and a trigger ":add-event"
;; happens, then move the FSM to state ":scheduled" and execute
;; that two-part "do" function.
[:idle :add-event] [:scheduled #(do (-add-event this arg)
(-run-next-tick this))]
;; State: :scheduled (the queue is scheduled to run, soon)
[:scheduled :add-event] [:scheduled #(-add-event this arg)]
[:scheduled :run-queue] [:running #(-run-queue this)]
;; State: :running (the queue is being processed one event after another)
[:running :add-event] [:running #(-add-event this arg)]
[:running :pause] [:paused #(-pause this arg)]
[:running :exception] [:idle #(-exception this arg)]
[:running :finish-run] (if (empty? queue) ;; FSM guard
[:idle]
[:scheduled #(-run-next-tick this)])
;; State: :paused (:flush-dom metadata on an event has caused a temporary pause in processing)
[:paused :add-event] [:paused #(-add-event this arg)]
[:paused :resume] [:running #(-resume this)]
(throw (ex-info (str "re-frame: router state transition not found. " fsm-state " " trigger)
{:fsm-state fsm-state, :trigger trigger})))]
;; The "case" above computed both the new FSM state, and the action. Now, make it happen.
(trace/merge-trace! {:operation [fsm-state trigger]
:tags {:current-state fsm-state
:new-state new-fsm-state}})
(set! fsm-state new-fsm-state)
(when action-fn (action-fn))))))
(-add-event
[_ event]
(set! queue (conj queue event)))
(-process-1st-event-in-queue
[this]
(let [event-v (peek queue)]
(try
(handle event-v)
(set! queue (pop queue))
(-call-post-event-callbacks this event-v)
(catch #?(:cljs :default :clj Exception) ex
(-fsm-trigger this :exception ex)))))
(-run-next-tick
[this]
(next-tick #(-fsm-trigger this :run-queue nil)))
;; Process all the events currently in the queue, but not any new ones.
;; Be aware that events might have metadata which will pause processing.
(-run-queue
[this]
(loop [n (count queue)]
(if (zero? n)
(-fsm-trigger this :finish-run nil)
(if-let [later-fn (some later-fns (-> queue peek meta keys))] ;; any metadata which causes pausing?
(-fsm-trigger this :pause later-fn)
(do (-process-1st-event-in-queue this)
(recur (dec n)))))))
(-exception
[this ex]
(purge this) ;; purge the queue
(throw ex))
(-pause
[this later-fn]
(later-fn #(-fsm-trigger this :resume nil)))
(-call-post-event-callbacks
[_ event-v]
(doseq [callback (vals post-event-callback-fns)]
(callback event-v queue)))
(-resume
[this]
(-process-1st-event-in-queue this) ;; do the event which paused processing
(-run-queue this))) ;; do the rest of the queued events
;; ---------------------------------------------------------------------------
;; Event Queue
;; When "dispatch" is called, the event is added into this event queue. Later,
;; the queue will "run" and the event will be "handled" by the registered function.
;;
(def event-queue (->EventQueue :idle empty-queue {}))
;; ---------------------------------------------------------------------------
;; Dispatching
;;
(defn dispatch
[event]
(if (nil? event)
(throw (ex-info "re-frame: you called \"dispatch\" without an event vector." {}))
(push event-queue event))
nil) ;; Ensure nil return. See https://github.com/day8/re-frame/wiki/Beware-Returning-False
(defn dispatch-sync
[event-v]
(handle event-v)
(-call-post-event-callbacks event-queue event-v) ;; slightly ugly hack. Run the registered post event callbacks.
(trace/with-trace {:op-type :sync})
nil) ;; Ensure nil return. See https://github.com/day8/re-frame/wiki/Beware-Returning-False