Persist state of changed files (with localstorage)

[JosManMx]

Feature Request

Why it is needed

When working through multiple diffs, it’s common to mark files as “done/ready” and then refresh the page (or come back later) to continue. Today, the Upgrade Helper loses that progress on reload, so users must re-scan and re-check files, which adds friction during upgrades—especially for larger jumps or when coordinating across a team.

Persisting the “checked as ready” state would make the tool more resilient to accidental reloads and allow users to pause and resume upgrades without losing their place. This also aligns with recent UX asks to improve the flow after marking items as done (e.g., collapsing or keeping context), see related: “When a file is marked as done, it should collapse too.” (issue #410).

Possible implementation

Persist the “checked” state per file in localStorage keyed by the selected RN version range:

• Key shape: uh:checked:<fromVersion>-><toVersion>
• Value: JSON array (or map) of file identifiers (e.g., relative paths) that are marked as done.
• Write: On toggle, update the local in-memory state and mirror to localStorage.
• Read/Hydrate: On initial load (and when changing versions), read the key and pre-populate the checked state.
• Reset controls: Provide a small “Reset progress” / “Clear checked” action that wipes the key for the current range.
• Forward compatibility: Namespace can be extended to include view mode (split/unified) or diff source if needed.
• No network/storage server needed: localStorage avoids any backend requirement and fits this GitHub Pages app model. (RN docs reference Upgrade Helper as a web tool, so client-side persistence is appropriate.)
  Edge considerations:
• If the file list changes for a given version pair (e.g., tool updates), unknown IDs should be ignored gracefully.
• Provide a visual hint that progress is remembered (e.g., a small “Saved locally” tooltip near the checkbox area).
• Optional: expose a URL param to disable persistence (e.g., ?persist=0) for ephemeral sessions.
• Optional: add a compact progress indicator (e.g., “12/31 files done”).

What do you think?

I’d love to hear what others think about this idea — whether it would be useful in your upgrade workflow, or if there’s a better way to approach persistence.
If maintainers or contributors think this makes sense, I could try developing and submitting a PR for it.