status-im
/
re-frame
mirror of https://github.com/status-im/re-frame.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

A bit of docs gardening on `CPU-hog`

This commit is contained in:
Mike Thompson 2016-08-31 00:20:50 +10:00
parent 48de6d4a81
commit 8a07f49c64
1 changed files with 7 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/Solve-the-CPU-hog-problem.md
View File

@ -20,13 +20,11 @@ We need a means by which long running handlers can hand control
back for "other" processing every so often, while still continuing back for "other" processing every so often, while still continuing
on with their computation. on with their computation.
Luckily, re-frame has a solution. ## The re-frame Solution
## The Solution __First__, all long running, CPU-hogging processes are put in event handlers.
Not in subscriptions. Not in components. Not hard to do,
__First__, all long running, CPU-hogging processes are put in handlers. but worth establishing as a rule, right up front.
Not in subscriptions. Not in components. This is not hard to do,
but worth highlighting.
__Second__, you must be able to break up that CPU __Second__, you must be able to break up that CPU
work into chunks. You need a way to do part of the work, pause, work into chunks. You need a way to do part of the work, pause,
@ -77,8 +75,8 @@ Here's an `-fx` handler which counts up to some number in chunks:
### Why Does A Redispatch Work? ### Why Does A Redispatch Work?
A `dispatched` event is handled asynchronously. It is put on the conveyor A `dispatched` event is handled asynchronously. It is queued
belt, and not actioned straight away. and not actioned straight away.
And here's the key: **After handling current events, re-frame yields control And here's the key: **After handling current events, re-frame yields control
to the browser**, allowing it to render any pending DOM changes, etc. After to the browser**, allowing it to render any pending DOM changes, etc. After
@ -92,7 +90,7 @@ When the next dispatch is handled, a next chunk of work will be done, and then a
after chunk. In 16ms increments if we are very careful (or some small amount after chunk. In 16ms increments if we are very careful (or some small amount
of time less than, say, 100ms). But with the browser getting a look-in after each iteration. of time less than, say, 100ms). But with the browser getting a look-in after each iteration.
### Variation ### Variations
As we go, the handler could be updating some value in `app-db` which indicates As we go, the handler could be updating some value in `app-db` which indicates
progress, and this state would then be rendered into the UI. progress, and this state would then be rendered into the UI.