docs(predict): add PredictNext architecture and migration plan#28702
Draft
docs(predict): add PredictNext architecture and migration plan#28702
Conversation
Introduce comprehensive architecture documentation for the Predict feature redesign. The new PredictNext directory establishes the target architecture with deep modules, slim interfaces, and a canonical Event/Market/Outcome data model aligned with Polymarket and Kalshi. Documents cover: - 4-layer architecture (Components, Hooks, Controller/Services, Adapters) - 6 deep services with BaseDataService integration - 7 consolidated hooks (down from 37) - 3-tier component taxonomy with compound component patterns - Component view test strategy targeting 85-90% test code reduction - DDD ubiquitous language glossary - 8-phase strangler fig migration plan from Predict/ to PredictNext/
Contributor
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
matallui
changed the title
…lders Replace monolithic useEvents/usePortfolio hooks with granular per-query hooks organized in domain folders (hooks/events/, hooks/portfolio/). Each data hook triggers exactly one query so components only fetch what they need. Imperative hooks (trading, transactions, live-data) stay deep. Update architecture.md, hooks.md, and README.md to reflect the folder-based organization with barrel exports.
Add 'Hook Usage by Component Tier' section to hooks.md explaining that primitives are pure (no hooks), widgets wire data hooks to primitives, and views compose widgets with imperative/guard hooks. Update components.md widget descriptions with granular hook names (useEventList, useBalance, etc. instead of monolithic useEvents) and add code example for PredictHome view showing widget composition. Update hook composition rules to reflect the tier boundaries.
…lices Replace horizontal layer-by-layer migration (8 phases) with inside-out approach (7 phases). New strategy hollows out old provider and controller from the inside by delegating to new adapter and services, then migrates UI as vertical slices per screen. Key changes: - Add compat/ translation layer for bidirectional type mapping - Phase 2: Adapter replaces provider internals - Phases 3-4: Services replace controller internals (parallelizable) - Phase 5: New controller, old becomes pure shim - Phase 6: UI migrates one screen at a time (vertical slices) - Phase 7: Cleanup and rename (merged old phases 7+8)
Contributor
🔍 Smart E2E Test Selection⏭️ Smart E2E selection skipped - draft PR All E2E tests pre-selected. |
Contributor
|
✅ E2E Fixture Validation — Schema is up to date |
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Architecture documentation and migration plan for redesigning the Predict feature from the ground up. This establishes the target architecture in a new
PredictNext/directory with comprehensive docs covering every aspect of the redesign.Related issues
N/A — This is a documentation-only PR establishing the architecture plan.
Manual testing steps
N/A — Documentation only, no runtime changes.
Screenshots/Recordings
N/A
Pre-merge author checklist
Pre-merge reviewer checklist
What this PR contains
19 documentation files (5,597 lines) under
app/components/UI/PredictNext/:Foundational docs:
README.md— Feature overview, directory structure, public APIUBIQUITOUS_LANGUAGE.md— DDD glossary (Event/Market/Outcome canonical terms)Architecture docs (
docs/):architecture.md— Master architecture doc (4-layer, deep modules, data flow)services.md— 6 deep services + thin controller with TypeScript interfacesadapters.md— Protocol adapter pattern for Polymarket/Kalshicomponents.md— 3-tier component taxonomy with compound component patternshooks.md— 7 consolidated hooks (down from 37)testing.md— Component view test strategy (~85-90% test code reduction)state-management.md— BaseDataService integration, Redux, query keyserror-handling.md— PredictError class, 4 UI error categoriesMigration plan (
docs/migration/):README.md— Strangler fig strategy, motivation, 8-phase overviewphase-1-foundation.mdthroughphase-8-cleanup.md— Detailed per-phase plans with deliverables, acceptance criteria, and estimated PRsKey architectural decisions