From 6effae5c701939897e9f507fafb87582d68bd020 Mon Sep 17 00:00:00 2001 From: Mike Thompson Date: Sun, 18 Feb 2018 08:44:02 +1100 Subject: [PATCH] Update ReplayButton.md --- docs/HyperlinkedInformation/ReplayButton.md | 25 +++++++++++---------- 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/docs/HyperlinkedInformation/ReplayButton.md b/docs/HyperlinkedInformation/ReplayButton.md index 045236b..f4d5f9f 100644 --- a/docs/HyperlinkedInformation/ReplayButton.md +++ b/docs/HyperlinkedInformation/ReplayButton.md @@ -15,12 +15,12 @@ an "Action Replay" of "The Observed Epoch", and this happens in two Steps: So, Step 1 is "reestablish initial conditions" and Step 2 is "do it all again". ### Further Notes: - - In Step 1, the reset of `app-db` will trigger dominoes 4,5,6, causing - subscriptions and views to run as the application returns to the "prior state", - but none of the trace for this is captured. It is all ignored. - - All trace arising in Step 2 forms a normal, new Epoch. The (original) Observed Epoch (which we are replaying) + - In Step 1, the reset of `app-db` will trigger computation and trace. + Subscriptions and views are run as the application returns to the "prior state", + but none of the associated trace is captured. It is all ignored. + - Trace arising from Step 2 forms a normal, new Epoch. The Observed Epoch (which we are replaying) is still there, untouched. - - The new Epoch (Step 2) is added to the end of the existing Epoch list. It becomes the most recent Epoch. + - New Epochs (Step 2) are always added to the end of the Epoch list (never inserted amongst old Epochs). - The user's experience is that they click the "Replay" button and immediately view the result. So, after Step 2, the user is auto-navigated to this new epoch. @@ -28,18 +28,19 @@ So, Step 1 is "reestablish initial conditions" and Step 2 is "do it all again". It facilitates "The HotPlay Workflow": - A. You `Observe` an Epoch (in `re-frame-trace`) to see if an event was correctly processed - - B. You notice a problem, and you `Edit` (correct) the event handler (or subs handler, view, etc) via Cursive, Emacs, etc. + - B. You notice a problem, and you `Edit` (fix) the event handler (or subs handler, view, etc) via Cursive, Emacs, etc. - C. Figwheel will re-compile and `Hotload` your correction - D: You click the `Replay` button - E: Back to A -Because of `Replay's` "Step 1", you effortlessly get identical "initial conditions" -each iteration of the workflow, which removes a lot of incidental cognative load -(struggling around trying to put the application back into the right state for each new iteration) -and keeps the iterations snappy. Flow. +Because of `Replay's` "Step 1", you effortlessly get identical "initial conditions" for +each iteration of the workflow, and this is true blessing. It removes the nagging +cognative load of "allowing for" slightly shifting state. Or the effort of manually +reestablishing identical application state before each iteration. -WARNING: obviously this works best when the state is contained in your SPA. When -there's remote state (a remote database?) it gets trickier to return to initial conditions. +WARNING: obviously this only works when the state is contained in your SPA. When +there's remote state (a remote database?) it is more effort to return to initial conditions +each iteration. ### The Workflow Name