VersionControl:PRs/rabbithole/15: Difference between revisions

From PickiPedia: A knowledge base of bluegrass, old time psychedelic jams, and other public domain music
Jump to navigationJump to search
DrivingThatTrain (talk | contribs)
cryptograss/rabbithole#15, as GitHub has it
 
DrivingThatTrain (talk | contribs)
cryptograss/rabbithole#15, as GitHub has it
 
(2 intermediate revisions by the same user not shown)
Line 5: Line 5:
|url=https://github.com/cryptograss/rabbithole/pull/15
|url=https://github.com/cryptograss/rabbithole/pull/15
|author=magent-cryptograss
|author=magent-cryptograss
|state=open
|state=merged
|base=main
|base=main
|branch=fix/saved-means-saved
|branch=fix/saved-means-saved
|opened=2026-11-06 07:16:05
|opened=2026-11-06 07:16:05
|pushed=2026-11-06 07:15:44
|pushed=2026-11-06 07:31:02
|merged=
|merged=2026-11-06 17:09:21
|closed=
|closed=
|worked_on_by=magent, skyler, justin
|worked_on_by=magent, skyler, justin
Line 16: Line 16:
|deploy=
|deploy=
}}
}}
<pre class="pr-body">Twice tonight an edit that never reached the wiki looked saved (Swords' G at 21:47, Cicada's caps at 05:58). Two causes, one rule.
**The rule:** "Saved" is said only when PickiPedia made a revision. Everything else says what it is.
**What was wrong**
- The footer and the Save button read "Saved" whenever the working data matched the original, which is also what a freshly opened editor looks like.
- The save path called any non-error answer "Saved!" without reading it. MediaWiki answers `result: Success` with `nochange` when the page already had the text.
- In the raw view: text typed but not applied left the data clean, so Save was *disabled* and read "Saved" over an edit going nowhere.
**What changes**
- `EditableTrackData` holds what the last save came back with (`null`, `{ revisionId }`, `{ unchanged }`) and whether raw text is pending. One method, `saveStateText()`, gives the words: *No changes* / *Edited, not yet applied* / *Unsaved changes* / *Saved, revision N* / *PickiPedia already had this*. Footer and button both read it; the footer follows the data, not only a render.
- Pending raw text counts as unsaved, so Save stays live. Save applies the textarea first; a YAML error is shown and nothing is sent.
- The save reads the wiki's answer: result must be Success, `nochange` is reported as such, a new revision is named.
- Editor imports get a new version string so browsers fetch this.
**Second commit, at Skyler's ask:** a save with no login offers a "Log in to PickiPedia" link that opens in a new tab, so the editor and its edits stay put; the edits are also written to the browser backup at once. The backup now carries the ensemble with the timeline, and restores both (before, an instrument edit was lost on reload while a marker edit survived).
**Checked** on pickipedia.xyz with the branch routed in and the edit API faked: open → "No changes", Save disabled; type in raw view → "Edited, not yet applied", Save live; wiki says nochange → "PickiPedia already had this" in footer, button and status; wiki makes a revision → "Saved, revision 14702" in all three; bad YAML → parser's error, nothing sent. Logged out: Save shows the login link, the backup holds the edit and ensemble, and a reload restores the edit as unsaved changes. Seven new tests, 99 pass.
Redeploy: pickipedia
Worked on by: magent, Skyler, Justin, in #rabbithole</pre>

Latest revision as of 18:06, 9 November 2026

rabbithole#15: Editor: "Saved" means PickiPedia made a revision
State 🟣 merged 2026-11-06 17:09:21
Worked on by magent, skyler, justin
Moods #rabbithole
Deploy not said
Branch fix/saved-means-saved → main, by magent-cryptograss
Opened · last pushed 2026-11-06 07:16:05 · 2026-11-06 07:31:02
Twice tonight an edit that never reached the wiki looked saved (Swords' G at 21:47, Cicada's caps at 05:58). Two causes, one rule.

**The rule:** "Saved" is said only when PickiPedia made a revision. Everything else says what it is.

**What was wrong**
- The footer and the Save button read "Saved" whenever the working data matched the original, which is also what a freshly opened editor looks like.
- The save path called any non-error answer "Saved!" without reading it. MediaWiki answers `result: Success` with `nochange` when the page already had the text.
- In the raw view: text typed but not applied left the data clean, so Save was *disabled* and read "Saved" over an edit going nowhere.

**What changes**
- `EditableTrackData` holds what the last save came back with (`null`, `{ revisionId }`, `{ unchanged }`) and whether raw text is pending. One method, `saveStateText()`, gives the words: *No changes* / *Edited, not yet applied* / *Unsaved changes* / *Saved, revision N* / *PickiPedia already had this*. Footer and button both read it; the footer follows the data, not only a render.
- Pending raw text counts as unsaved, so Save stays live. Save applies the textarea first; a YAML error is shown and nothing is sent.
- The save reads the wiki's answer: result must be Success, `nochange` is reported as such, a new revision is named.
- Editor imports get a new version string so browsers fetch this.

**Second commit, at Skyler's ask:** a save with no login offers a "Log in to PickiPedia" link that opens in a new tab, so the editor and its edits stay put; the edits are also written to the browser backup at once. The backup now carries the ensemble with the timeline, and restores both (before, an instrument edit was lost on reload while a marker edit survived).

**Checked** on pickipedia.xyz with the branch routed in and the edit API faked: open → "No changes", Save disabled; type in raw view → "Edited, not yet applied", Save live; wiki says nochange → "PickiPedia already had this" in footer, button and status; wiki makes a revision → "Saved, revision 14702" in all three; bad YAML → parser's error, nothing sent. Logged out: Save shows the login link, the backup holds the edit and ensemble, and a reload restores the edit as unsaved changes. Seven new tests, 99 pass.

Redeploy: pickipedia
Worked on by: magent, Skyler, Justin, in #rabbithole