Skip to content

Proposal: Add a complete interactive Practice section #474

Description

@AbsoluteZero000

Context

This is a discussion-first follow-up to #464, which was closed so the feature's scope, UX, data model, and localization approach could be agreed before implementation.

The README currently lists Practice as "Coming soon." The site already provides guided lessons and a free-form playground, but there is room for a focused experience where learners solve standalone exercises and receive feedback based on the behavior of their regex.

Goal

Add a complete Practice section where learners can reinforce concepts from Learn by solving interactive regex challenges without needing an account.

The main goals would be:

  • practice concepts through short, focused exercises
  • provide a clear beginner-to-advanced learning path
  • accept equivalent correct regexes rather than only one authored pattern
  • give useful feedback, progressive hints, and reference solutions
  • let learners see, retain, and reset their progress locally
  • fit the site's existing navigation, responsive UI, and localized routes

Proposed scope

The feature would launch as a complete experience containing:

  • a Practice catalog at /[lang]/practice
  • three tracks: Beginner, Intermediate, and Advanced
  • 36 challenges in total, with 12 challenges per track
  • localized titles, descriptions, instructions, hints, and feedback
  • sample text, expected matching behavior, and additional validation cases
  • regex and flags inputs with instant behavior-based validation
  • progressive hints and an explicitly revealed reference solution
  • previous/next navigation and keyboard shortcuts
  • per-track completion progress stored locally
  • completion states and level-complete feedback
  • reset controls with confirmation
  • responsive layouts consistent with the existing Learn and Playground experiences
  • integration with the header, landing page, localized routes, metadata, sitemap, and README
  • validator, challenge-data, and progress tests

The implementation should cover the complete feature in its initial release.

UX proposal

  1. The learner opens Practice and sees all three tracks with their challenge counts and completion progress.
  2. The learner selects a track and enters its ordered challenge path.
  3. Each challenge explains the matching goal and shows sample text.
  4. The learner enters a regex and flags.
  5. The UI reports an invalid expression, an incorrect result, or success.
  6. Optional hints are revealed progressively.
  7. A reference solution is available behind an explicit action.
  8. On success, progress is saved locally and the learner can continue by button or keyboard.
  9. Completing all challenges produces a level-complete state.
  10. Learners can return to the catalog or reset a track's progress with confirmation.

The screenshots in #464 show one possible direction, but they are references for discussion and can be reshaped before implementation.

Screenshots

These screenshots from #464 illustrate the current concept and are included as references for the UX discussion.

Practice levels

Practice levels

Practice challenge and learning path

Practice challenge and learning path

Data model proposal

Keep challenge mechanics separate from translated copy. Each challenge would contain:

  • a stable ID and ordering
  • track/difficulty
  • localization keys for title, instructions, and hints
  • initial regex/flags, when useful
  • visible examples plus additional validation cases
  • expected matches for each case
  • a reference solution

This keeps executable test data locale-neutral while allowing learner-facing text to live in the existing localization system.

Validation proposal

Validate behavior instead of comparing the submitted regex string with one exact solution:

  1. compile the expression using the site's JavaScript regex engine
  2. execute it against each authored case
  3. compare the resulting matches with the expected matches
  4. accept any expression that produces the required behavior across all cases

Tests should cover invalid regexes, flags, zero-length matches, ordering, duplicate matches, equivalent solutions, and the complete challenge dataset. We should also agree on safeguards for patterns that are too expensive to execute in the browser.

Localization

All learner-facing Practice copy should use localization keys and support the existing localized route structure. The challenge data itself should not duplicate translated content.

The complete Practice experience should include localized copy for every currently supported language at launch rather than relying on temporary English fallback text. Keeping mechanics separate from copy should allow translators to work from a consistent set of keys without duplicating validation data.

Suggested delivery

Once the scope and approach are approved, the feature would be implemented as one coordinated, complete change covering:

  1. challenge schema, all 36 challenges, validator, progress storage, and tests
  2. the catalog and all three challenge tracks
  3. hints, solutions, keyboard navigation, completion states, and reset controls
  4. navigation, landing-page integration, metadata, sitemap, and README
  5. localized copy for every supported language

The work can still be organized into clear internal commits for review, but the intended release is the entire Practice experience.

Questions for alignment

  1. Is a standalone Practice section with Beginner, Intermediate, and Advanced tracks the desired direction?
  2. Is 36 challenges, split evenly across the three tracks, the right amount for the initial release?
  3. Does the proposed behavior-based validation match the expected experience?
  4. Should progress remain local-only?
  5. Is complete localization for every supported language required before merging?
  6. Are progressive hints, reference solutions, keyboard navigation, and reset controls appropriate?
  7. Are there preferred UX patterns from the existing Learn or Playground pages that Practice should reuse?
  8. Are there any additional requirements for the data model or browser execution safeguards?

I would like to agree on these points before implementing the complete feature.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions