cyber-dojo
add auto-save file change between test events
When doing a review there is often a change to both a code file and a test file. It would be nice in this case (and others) to know which file was edited first. So, the idea is that when the current file is switched, all the files sent to saver, and (if there has been a change?), they are auto-saved. But only for katas that use most recent saver (which uses git). I think doing this on current-file being selected will also work for new-file, delete-file, rename-file.
- Whenever there is a file selection, send all files to saver. It can easily find if there has been an edit or not.
- In saver, if there has been a change, save a new event. Ensure this does not initially affect anything.
- In review mode only, show non-test file-edits. Show (E) icon for Edit, to live alongside rag traffic-lights.
- The UX does not update "live" with a new (E) icon when in edit mode. Those are only in review mode.
How to show non-test file-edits in review mode? If I select an (E) icon, how does the UX show this? I think it should be possible to arrange for differ to just work with the newly saved events.
Could make events from saver return only traffic-lights and add new method all_events() which also returned (E) events. Need to find out how review mode works when you select a traffic-light. How does it get the diff data, I presume it used the "index" in the light.json and optional +1 for the next traffic-light. How will this work when there are (E) icons with their own "sub-index"? Do I show all (E) icons, or only from most-recent test submission only? That would be nice UX polish.
CORE: The relationship between the index numbers seen in the review UX and the index numbers seen in events.json Answer, all entries in events.json have an index number, and all events are currently shown, including zero, which is the creation event.
Do I need a toggle in the UX to opt into showing the (E) icons in review mode? Does the rag index-number remain unchanged, and the underbar is the only UX clue? That is probably simplest.
Need to refresh knowledge of what saver stores, eg for config change. There is no git repo in earlier savers, but there is in the latest.
options.json
{
"theme": "light",
"colour": "on",
"predict": "off",
"revert_red": "off",
"revert_amber": "off",
"revert_green": "off"
}
There is a git commit for all events, and a git tag for test events. Eg $ git log
commit 3b5cc47633c62420605eeb5ff76b111f1128d908 (HEAD -> main)
Author: 2M6yBY <[email protected]>
Date: Sun Nov 30 07:14:43 2025 +0000
set option predict to on
commit 4f4e247dcef269940db1cdf2aa9fdd018000d79b (tag: 5)
Author: 2M6yBY <[email protected]>
Date: Sun Nov 30 07:13:28 2025 +0000
5 reverted to {"id":"2M6yBY","index":3}
commit 928d16dd78ee683b3dbfeca01e42941fada2774b (tag: 4)
Author: 2M6yBY <[email protected]>
Date: Sun Nov 30 07:13:28 2025 +0000
4 ran tests, predicted green, got amber
$ jq . events.json
[
{
"index": 0,
"event": "created",
"time": [
2025,
11,
30,
7,
9,
11,
338432
]
},
{
"duration": 0.841677,
"colour": "red",
"predicted": "none",
"revert_if_wrong": "off",
"index": 1,
"time": [
2025,
11,
30,
7,
9,
22,
867189
]
},
{
"duration": 0.536006,
"colour": "red",
"predicted": "none",
"revert_if_wrong": "off",
"index": 2,
"time": [
2025,
11,
30,
7,
9,
29,
850477
]
},
{
"duration": 0.555,
"colour": "green",
"predicted": "none",
"revert_if_wrong": "off",
"index": 3,
"time": [
2025,
11,
30,
7,
13,
9,
837311
]
},
{
"duration": 0.557254,
"colour": "amber",
"predicted": "green",
"revert_if_wrong": "on",
"index": 4,
"time": [
2025,
11,
30,
7,
13,
28,
200008
]
},
{
"colour": "green",
"revert": [
"2M6yBY",
3
],
"index": 5,
"time": [
2025,
11,
30,
7,
13,
28,
440817
]
}
]
This is returned, as is, without filtering.
source/app/views/kata/_filenames.html.erb has this
filenames.select = (filename) => {
// Can't do $('radio_' + filename) because filename
// could contain characters that aren't strictly legal
// characters in a dom node id so I do this instead...
const $filename = $(`[id="radio_${filename}"]`, $filenames);
filenames.unselectAll();
$filename.addClass('selected');
cd.kata.tabs.setFilename(filename);
const disabled = (filename === 'cyber-dojo.sh');
cd.deleteFileButton().attr('disabled', disabled);
cd.renameFileButton().attr('disabled', disabled);
};
which is called (setup) from source/app/views/kata/run_tests.js.erb
- refresh knowledge of how traffic-light indexes work in review mode.
- decide how saver saves new non-test events into events.json
- could the indexing be extended so 1 becomes 1.0 allowing 1.1, 1.2, 1.3 etc as non-test events?
- in web add events filter so prepare for (C)/(T) info in all events
- in web, make filenames.select() above do ajax call to web to send all files to saver
Design
Ideally differ will be unaffected.
Simply always auto-increment the index, even on file-edit events. In web edit-mode, there is always a display of the red/amber/green counts on the rhs. And in web edit-mode the current rag number is not displayed, only on the review page.
So add a new api method to get finer grained events. The current kata_events() will filter out the Edit events to remain the same.
The dashboard will be remain the same too, not showing Edit events. Clicking on a traffic-light in the dashboard opens a web-review page (without the [resume] buttom) This should be unaffected too.
In the review page, the current rag/event number can just be the incrementing index. The main issue will be UX filtering of the fine-grained events so that you only see the file-edits in the current light-light window. This should be possible with CSS class toggles.
In web-review mode there is already a toggle to see the diffs or not. Initially this should be unaffected.
I need to check if any code in web/dashboard assumes the next event index is just the previous one +1. This is the critical issue. It needs to come from the event data.
Maybe in the web-review mode the index number displayed could be decoupled from the underlying index. Eg 3.4 for the fourth file-edit after the 3rd traffic-light?
