Readme tweaks
This commit is contained in:
parent
57b1fbc160
commit
61e2964c6a
48
README.md
48
README.md
|
@ -1076,7 +1076,7 @@ If you have that data, then you can reproduce the exception.
|
|||
re-frame allows you to time travel. Install the "checkpoint" state into `app-db`
|
||||
and then "play forward" through the collection dispatched events.
|
||||
|
||||
The only way the system "moves forwards" is via events. "Replaying events" moves you
|
||||
The only way the app "moves forwards" is via events. "Replaying events" moves you
|
||||
step by step towards the exception causing problem.
|
||||
|
||||
This is utterly, utterly perfect for debugging assuming, of course, you are in a position to capture
|
||||
|
@ -1100,45 +1100,25 @@ modify `app-db` themselves. That is always done in a handler.
|
|||
to dispatch their outcome. All events are handled via dispatch. on-success should never ever change
|
||||
`app-db`.
|
||||
|
||||
## The CPU Hog Problem
|
||||
|
||||
### The CPU Hog
|
||||
Sometime a handler has a lot of CPU intensive work to do, and it takes a while to get through.
|
||||
|
||||
If a handler hogs the CPU, this will freeze the GUI - browsers
|
||||
only give us one thread of execution.
|
||||
When a handler hogs the CPU, nothing else can happen. Browsers only give us one thread of
|
||||
execution and that CPU-hogging handler owns it, and it isn't giving it up. The UI will be
|
||||
frozen and there will be
|
||||
no processing of any other handlers (eg: on-success of POSTs), etc, etc. Nothing.
|
||||
|
||||
Long running handlers must somehow hand control
|
||||
back to the GUI every so often, while still continuing on with the
|
||||
computation when the GUI update work has been done.
|
||||
And a frozen UI is a problem. GUI repaints are not happening. And user interactions are not being processed.
|
||||
|
||||
Luckily re-frame has a fairly easily solution.
|
||||
How are we to show progress updates like "Hey, X% completed"? Or how can we handle the
|
||||
user clicking on that "Cancel" button trying to stop this long running process?
|
||||
|
||||
First, you have to organise for your handler to break up the work into chunks.
|
||||
After each chunk is done, a handler should not go on to the next, and instead it should
|
||||
re-dispatch to itself an event which (1) says the work is not finished; and
|
||||
(2) supplies the work completed so far, along with info about the chunk to be
|
||||
undertaken next.
|
||||
We need a means by which long running handlers can hand control
|
||||
back for "other" processing every so often, while still continuing on with their
|
||||
computation.
|
||||
|
||||
The event handler will then do another chunk, before `dispatching` to itself again,
|
||||
and so on.
|
||||
|
||||
In between each `dispatch`, re-frame hands back
|
||||
control to the GUI thread, so it can render any pending updates,
|
||||
before then continuing on to handle
|
||||
the next dispatched event, which in our case would be the next chunk of work.
|
||||
|
||||
At a certain point, when all the work is done, the handler will likely put the
|
||||
fruits of its labour into `app-db` and clear any flags which might, for example,
|
||||
cause a modal dialog to be displayed explaining progress.
|
||||
|
||||
This arrangement is nice and flexible. For example,
|
||||
in some cases, your modal dialog explaining progress might have a "cancel" button. If clicked, this
|
||||
button will dispatch a cancel event and the handler for the event will tweak the `app-db`
|
||||
indicating that that computation should be abandoned. When a chunk-processing-handler
|
||||
next begins, it will check the cancel flag, and, if it is found, will
|
||||
stop the CPU intensive process.
|
||||
|
||||
Events arriving from a server might also cause the calculation to have to be restarted,
|
||||
or modified. This is all fairly easily handled within the chunked dispatch approach just described.
|
||||
Luckily, [re-frame has a solution](https://github.com/Day8/re-frame/wiki/The-CPU-Hog-Problem).
|
||||
|
||||
|
||||
### In Summary
|
||||
|
|
Loading…
Reference in New Issue