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

Update InterEpoch.md

This commit is contained in:
Mike Thompson 2018-02-10 15:09:11 +11:00 committed by GitHub
parent 6109ec7f52
commit 3a4ddb3115
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/HyperlinkedInformation/InterEpoch.md
View File

@ -6,10 +6,10 @@
Intra-epoch traces are emitted under (at least) three circumstances:
* Views sometimes have local state in the form of local ratoms which control, for example, the appearance of popups or mouseover annimations. When the state of these ratoms change, dependent views will likely rerender, and the trace to do with this rerendering will flow from reagent to `re-frame`trace`. But there'll be no "current" epoch to put it in. Because there was no event (just a pseudo event caused by the ratom reset)
* Views sometimes have local state in the form of local ratoms which control, for example, the appearance of popups or mouseover annimations. When the state of these ratoms change, dependent views will likely rerender, and the trace to do with this rerendering will flow from reagent to `re-frame-trace`. But there'll be no "current" epoch to put it in. Because there was no event (just a pseudo event caused by the ratom reset)
* A Figwheel recompile and subsequent code reload will cause all existing subscriptions to be destroyed, andwill trigger a complete re-render of your application
* `re-frame-trace` itself resetting the value in `app-db`. Again there will be a flurry of subscription and view trace, but no epoch, because there was no event.
The first of these is essential to the functioning of your application, whidh makes their trace interesting and informative. The last two are incidental to the tooling and are probably best ignored. Probably.
The first of these is essential to the functioning of your application, which makes the trace interesting and informative. The last two are incidental to the tooling and are probably best ignored. Probably.
`re-frame-trace` collects any intra-epoch subscription traces and shows them in the subs panel with the next epoch. They are broken out into a separate section marked: "Intra-Epoch Subscriptions".