Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Decouple shared editor history from SPX-specific state

Open
  • Is something wrong?
#3,607 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
frontend

Research direction

This is design work, not a starter task. Begin with the existing shared-history implementation from PR #3494 and the SPX EditorState that owns the SPX-specific History, then the Tutorial v2 design docs on the issue-3403-tutorial-v2 branch. Done means a documented, SPX-independent history contract that a unified Course Editor timeline can use, with standalone SPX undo/redo unchanged and tests covering cross-domain undo/redo.

Written by the indexing model from the issue text.

Description

Parent

Part of #3403.

Long-term follow-up to the shared Course Editor history work discussed in PR #3494.

Background

The Course Editor contains both Course-owned files and an embedded SPX project. A single undo/redo timeline across both would make editing more coherent. The current SPX EditorState owns an SPX-specific History, so sharing one history with the Course Editor requires injecting it into the SPX Editor and coordinating state restoration.

The PR discussion identifies a longer-term direction: make History or EditorState independent of SPX so different editor domains can participate in shared editing history without making the generic history abstraction depend on the SPX project model. This is an architectural follow-up to the immediate shared-history implementation.

Scope

  • Evaluate and define an SPX-independent editing-history or editor-state abstraction that can be shared by the Course Editor and embedded SPX Editor.
  • Support a unified Course Editor undo/redo timeline spanning Course-owned files and embedded SPX project edits.
  • Define how undo and redo restore each domain's state and how they interact with SPX Editor state updates.
  • Preserve existing standalone SPX Editor history behavior and avoid introducing Course-specific concepts into the generic abstraction.

Plan

  • Review the shared-history implementation and identify the remaining coupling to SPX EditorState, project reloads, and mutation recording.
  • Design a generic history/state contract and document how independent editor domains register and restore changes.
  • Refactor the history or editor-state ownership to use the SPX-independent contract.
  • Integrate the Course Editor and embedded SPX Editor with one timeline and add focused coverage for cross-domain undo/redo and existing standalone behavior.

Acceptance criteria

  • The shared history abstraction does not require SPX project or Course-specific types.
  • Course Editor provides one chronological undo/redo timeline across Course-owned files and embedded SPX project edits.
  • Undo and redo consistently restore the affected Course or project state without stale editor/runtime state.
  • Standalone SPX Editor retains its existing undo/redo behavior.
  • The abstraction and its integration contract are documented.

Design references

Development coordination

Follow the coordination requirements in #3403:

  • Create the implementation branch from the latest goplus/issue-3403-tutorial-v2 and target that integration branch in the pull request until the initiative is integrated into dev.
  • Follow the User Tutorial v2 product design and the relevant contracts in the Tutorial v2 tech design.
  • If this work changes a shared decision or module contract, update the corresponding design document in the same child PR rather than silently diverging from it.
Dominant language
TypeScript
Stars
70
Forks
59
Avg merge
2d 3h
Merged PRs (30d)
50

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from goplus/builder

All issues in goplus/builder

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.