Skip to content

Extract shared InterfaceNavigationData helper for Nav_Solvers/Verifiers/Visualizations - #511

Open
Trosper3 wants to merge 1 commit into
CSharpAPIfrom
refactor/navigation-data-shared-helper
Open

Extract shared InterfaceNavigationData helper for Nav_Solvers/Verifiers/Visualizations#511
Trosper3 wants to merge 1 commit into
CSharpAPIfrom
refactor/navigation-data-shared-helper

Conversation

@Trosper3

Copy link
Copy Markdown
Contributor

Summary

  • SolverNavigationData, VerifierNavigationData, and VisualizationNavigationData (in Nav_Solvers.cs/Nav_Verifiers.cs/Nav_Visualizations.cs) each independently defined their own {className, problemName} entry type and duplicated the same ~40 lines of Build()/Find() logic, differing only in which open generic marker interface (ISolver<>, IVerifier<>, IVisualization<>) and ProblemProvider dictionary they scanned.
  • New AdditionalControllers/Navigation/InterfaceNavigationData.cs adds a shared NavigationEntry type and InterfaceNavigationData.Build/Find/FindWithoutExtension, parameterized on the source dictionary and the open generic interface type. Each per-kind class is now a thin 6-line wrapper.
  • Per the issue's explicit direction: each controller's own not-found response shape (string sentinel for solvers/verifiers vs. empty array for visualizations — confirmed intentional, not a bug, per an existing comment in Nav_Visualizations.cs) stays controller-specific and untouched.
  • VerifierNavigationData.TryParseProblemKey (not duplicated in the other two files) is preserved as-is.
  • redux-tests/Metadata/ComplexityClass_Tests.cs and Nav_Batch.cs both consume *NavigationData.Entries externally via .className/.problemName — those property names and the static class names are unchanged, only the shared entry type and build logic moved.

Closes #462

Test plan

  • dotnet build --configuration Release (gates on dotnet format --verify-no-changes) — clean, 0 warnings/errors, no reformatting needed
  • dotnet test (full suite) — 898/898 passed, including the external consumers of *NavigationData.Entries

…rs/Verifiers/Visualizations

SolverNavigationData, VerifierNavigationData, and VisualizationNavigationData
each defined their own {className, problemName} entry type and duplicated
the same ~40 lines of Build/Find logic, differing only in which open generic
marker interface (ISolver<>, IVerifier<>, IVisualization<>) and
ProblemProvider dictionary they scanned. Extracts a shared NavigationEntry
type and InterfaceNavigationData.Build/Find/FindWithoutExtension helper
parameterized on the source dictionary and open generic interface type;
each per-kind class is now a thin wrapper. Controller-specific not-found
response shapes (string sentinel vs. empty array) are untouched, per the
issue's explicit direction -- that difference is intentional, not
duplication to fold away.

Closes #462
@github-actions

Copy link
Copy Markdown

Redux Build System — CI Report

dotnet · commit 3b15d50

Operation Status Summary Time
audit no known vulnerabilities 4.3s
format-check all files formatted 24.0s
lint 0 issues 35.3s
typecheck ⏭️ covered by lint (dotnet build)
unit-test 898 passed · coverage 69% (min 80%) 43.1s
build built local/redux:ci · 234MB 38.8s
integration-test ⏭️ no [integration] command
push ⏭️ not implemented

Overall: ❌ 4 passed · 1 failed · 3 skipped

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Nav_Solvers/Nav_Verifiers/Nav_Visualizations duplicate the same Build/Find boilerplate

1 participant