Skip to content

CoreSetup_Arch_V1.0.md

Latest commit

 

History

History
516 lines (295 loc) · 14.4 KB

CoreSetup_Arch_V1.0.md

File metadata and controls

516 lines (295 loc) · 14.4 KB
Raw

CoreSetup_Architecture_V1.0

Version: V1.0
Date: April 12, 2025
Author: [Pending Your Input, e.g., Your Name/Team]
Status: Draft

1. Purpose

The CoreSetup_Architecture_V1.0 document outlines the architecture of the CoreSetup module, the foundation of the HealthSync application. CoreSetup manages the health log table (health-log.html), data storage, and user interactions, supporting pages like calc.html, doctor-report.html, reference.html, and help.html. This document aims to:

  • Simplify maintenance by splitting setup.js (~1000 lines) into smaller modules (~200 lines).

  • Ensure modularity (8/10) with 5-6 file uploads per task, within a 25-file limit.

  • Use IndexedDB to eliminate DOM storage issues.

  • Document event/listener hierarchies and module dependencies for easy modifications.

  • Support future pages and features without CoreSetup rewrites.

2. Architecture Overview

CoreSetup centers on health-log.html, providing table management, data storage, and navigation for HealthSync. It integrates with other pages via shared data (state-manager.js) and events (event-bus.js).

2.1 Directory Structure

text

CollapseWrapCopy

healthsync-root/

├── scripts/

│ ├── core/

│ │ ├── table-manager.js

│ │ ├── event-handlers.js

│ │ ├── state-manager.js

│ │ ├── validators.js

│ │ ├── nav-manager.js

│ │ ├── event-bus.js

│ │ ├── config.js

│ ├── shared/

│ │ ├── format-utils.js

│ │ ├── export-utils.js

│ ├── calc/

│ │ ├── calc-manager.js

│ ├── report/

│ │ ├── report-generator.js

│ ├── reference/

│ │ ├── reference-data.js

│ ├── help/

│ │ ├── help-content.js

├── styles/

│ ├── core.css

│ ├── shared.css

│ ├── calc.css

│ ├── report.css

│ ├── reference.css

│ ├── help.css

├── pages/

│ ├── health-log.html

│ ├── calc.html

│ ├── doctor-report.html

│ ├── reference.html

│ ├── help.html

├── assets/

│ ├── favicon.png

  • Total Files: 25 (7 core scripts, 2 shared, 4 page-specific, 6 styles, 5 pages, 1 asset).

  • CoreSetup: /scripts/core/, core.css, health-log.html (9 files).

  • Purpose: Hierarchical structure separates logic (/scripts/), styles (/styles/), and UI (/pages/), with flat subdirectories for simplicity.

2.2 Module Roles

  • CoreSetup (/scripts/core/):

    • table-manager.js: Table rendering, row creation (addRow, initializeTable).

    • event-handlers.js: DOM events (click, keydown, input).

    • state-manager.js: IndexedDB storage (getState, saveTableData).

    • validators.js: Input validation (validateDate, formatTime).

    • nav-manager.js: Navigation (#year-select, #nav-toggle).

    • event-bus.js: Event coordination (publish, subscribe).

    • config.js: Constants (COLUMN_CONFIG, event options).

  • Shared (/scripts/shared/):

    • format-utils.js: Date/time formatting.

    • export-utils.js: CSV export logic.

  • Pages:

    • calc-manager.js: Calculations for calc.html.

    • report-generator.js: Reports for doctor-report.html.

    • reference-data.js: Content for reference.html.

    • help-content.js: Help for help.html.

  • Styles:

    • core.css: CoreSetup UI.

    • shared.css: Nav/buttons across pages.

    • calc.css, etc.: Page-specific styles.

2.3 Setup.js Reduction

  • Current: setup.js (~1000 lines) handles table, events, storage, modals, navigation.

  • Proposed: Eliminated, split into:

    • table-manager.js: ~250 lines.

    • event-handlers.js: ~300 lines.

    • state-manager.js: ~200 lines.

    • validators.js: ~150 lines.

    • nav-manager.js: ~100 lines.

    • event-bus.js: ~50 lines.

    • config.js: ~50 lines.

  • Why Smaller: Modular roles, IndexedDB removes DOM scraping, centralized listeners.

  • Impact: Easier edits (e.g., F/W in event-handlers.js, ~300 lines vs. ~1000).

3. Storage (IndexedDB)

3.1 Overview

  • Problem: Current DOM storage (e.g., <input> values, saveTableDataToLog) is slow, fragile, and complex.

  • Solution: IndexedDB in state-manager.js, eliminating DOM reliance.

3.2 Schema

  • Database: healthsyncDB

  • Stores:

    • logs: { year, startDate, endDate, rowsPerDay, doctorName, patientName, tableData }, key: year.

    • settings: { id, currentYear, rowsPerDay }, key: id (e.g., "config").

  • Indexes: logs.byYear for fast lookup.

3.3 Functions

  • initializeDB(): Sets up stores.

  • getState(year): Fetches log/settings.

  • saveTableData(year, tableData): Updates logs.

  • setCurrentYear(year): Updates settings.

  • exportLog(year): Generates CSV.

  • deleteLog(year): Removes log.

3.4 Impact

  • Performance: Async IndexedDB vs. DOM loops.

  • Reliability: Data persists without DOM sync.

  • Pages: calc.html, doctor-report.html use state-manager.js, not DOM.

4. Event Hierarchy

Events are organized by scope, with CoreSetup driving most interactions.

4.1 CoreSetup Events

  • Table:

    • click: Starts with user click, ends with selection (cell-selected) or context menu.

      • Children: contextmenu, cell-selected.

    • mousedown → mousemove → mouseup: Drag selection, ends with cell-selected.

    • keydown: Ctrl+C → copy, Ctrl+V → paste, Enter in F/W → newline-added, ends with row-updated.

    • input: Typing, ends with row-updated.

  • Modal:

    • click: Modal buttons, ends with log-created, log-updated.

  • Navigation:

    • change: #year-select, #log-actions, ends with state-updated, log-exported, log-deleted.

    • click: #nav-toggle, ends with nav-changed.

  • Event Selection:

    • change: Column E <select>, ends with intensity-popup, row-updated.

4.2 Other Pages

  • Calc: state-updated for data refresh, local click for controls.

  • Report: state-updated, click for report generation.

  • Reference/Help: nav-changed, local click for UI.

5. Listener Hierarchy

Listeners are centralized for modularity.

5.1 CoreSetup Listeners

  • event-handlers.js:

    • click (#health-log): Selects cells, skips F/W.

    • keydown (#health-log): Ctrl+C, Ctrl+V, Enter.

    • input (#health-log): Validates, saves to IndexedDB.

    • change (E <select>): Updates units, intensity.

    • click (modals): Saves/closes modals.

    • Custom: row-updated, state-updated for UI sync.

  • nav-manager.js:

    • change (#year-select, #log-actions): Updates state.

    • click (#nav-toggle): Toggles menu.

    • Custom: state-updated for UI.

  • table-manager.js:

    • Custom: row-updated, log-created for UI updates.

  • state-manager.js:

    • Custom: row-updated, log-created for IndexedDB saves.

5.2 Other Pages

  • calc-manager.js: state-updated, local click.

  • report-generator.js: state-updated, click.

  • reference-data.js, help-content.js: nav-changed, click.

6. Modularity

  • Score: 8/10.

  • Details:

    • Single-purpose modules (e.g., validators.js for checks).

    • 4-6 dependencies (e.g., table-manager.js: 5 files).

    • Loose coupling via event-bus.js.

    • Clear interfaces (e.g., state-manager.getState()).

  • Impact:

    • Fix bugs in one module (e.g., event-handlers.js).

    • Develop calc.html without CoreSetup UI.

    • Teams work independently (e.g., /calc/ vs. /core/).

7. Module Dependency Guide

To develop a module, upload 5-6 files to the assistant, testing all 25 locally.

Module Files to Upload (5-6 Max) Why Local Testing (Additional)
table-manager.js table-manager.js, state-manager.js, config.js, event-bus.js, core.css, health-log.html Table logic, data, constants, events, styles, DOM. event-handlers.js, validators.js, nav-manager.js, shared.css
event-handlers.js event-handlers.js, state-manager.js, validators.js, event-bus.js, core.css, health-log.html Event logic, data, validation, events, styles, DOM. table-manager.js, config.js, nav-manager.js
state-manager.js state-manager.js, event-bus.js Storage logic, events. All core modules, pages
validators.js validators.js, config.js Validation logic, optional constants. event-handlers.js, state-manager.js, health-log.html
nav-manager.js nav-manager.js, state-manager.js, event-bus.js, shared.css, health-log.html Nav logic, data, events, styles, DOM. core.css, other core modules
event-bus.js event-bus.js Event logic, standalone. All modules
config.js config.js Constants, standalone. table-manager.js, event-handlers.js
format-utils.js format-utils.js, config.js Formatting, optional constants. Page-specific scripts (e.g., calc-manager.js)
export-utils.js export-utils.js, config.js Export logic, optional constants. state-manager.js, report-generator.js
calc-manager.js calc-manager.js, state-manager.js, event-bus.js, format-utils.js, calc.css, calc.html Calc logic, data, events, formatting, styles, DOM. shared.css, config.js
report-generator.js report-generator.js, state-manager.js, event-bus.js, export-utils.js, report.css, doctor-report.html Report logic, data, events, export, styles, DOM. shared.css, format-utils.js
reference-data.js reference-data.js, reference.css, reference.html Content logic, styles, DOM. shared.css, format-utils.js
help-content.js help-content.js, help.css, help.html Help logic, styles, DOM. shared.css, nav-manager.js

  • Max Upload: 6 files, most 4-5, within 5-8 preference.

  • Local Testing: All 25 files, ensuring full verification.

  • Use Case: Developing calc-manager.js needs 6 files; upload these, test all locally.

8. Transition Strategy

  1. Phase 1: Document (Now):

    • Finalize this document with dependencies.

    • Outcome: Clear plan, 5-6 files per task.

  2. Phase 2: Split setup.js (1-2 Sessions):

    • Create /scripts/core/, upload 5-6 files (e.g., table-manager.js, state-manager.js).

    • Outcome: setup.js gone, modular core.

  3. Phase 3: Pages/Shared (1 Session):

    • Stub calc.html, etc., 4-5 files each.

    • Outcome: Full structure.

  4. Phase 4: Enhance (1-2 Sessions):

    • Develop calc-manager.js, 5-6 files.

    • Outcome: Functional HealthSync.

  5. Phase 5: Maintain (Ongoing):

    • Update modules, 1-6 files.

    • Outcome: Easy edits.

9. Benefits

  • Small Files: setup.js (~1000 lines) split into ~200-line modules.

  • Modular: 8/10, 4-6 dependencies, isolated tasks.

  • Efficient: 5-6 file uploads, 25 testable locally.

  • Support: Add features in 5 files (e.g., column).

  • Edits: Fix bugs in 4-5 files (e.g., paste).

  • Separation: Teams use distinct 5-file sets.

10. Risks and Mitigations

  • Risk: Missing uploads.

    • Mitigation: Dependency guide caps at 6 files.

  • Risk: Large modules.

    • Mitigation: Keep ~200-300 lines.

  • Risk: Testing complexity.

    • Mitigation: Standard page setup, clear documentation.

Delivery Options for .docx

Since I can’t attach files directly, here are ways to get CoreSetup_Architecture_V1.0.docx:

  1. Text Above: The text version (Section 3) mirrors the .docx content, formatted with headings/lists. You can copy it into a .docx file locally using a word processor (e.g., Microsoft Word, Google Docs).

  2. Split Text: If the full text is too long, I can break it into ~2-3 messages (e.g., Sections 1-5, 6-10), formatted for easy copying into a .docx.

  3. External Sharing: If you have a preferred method (e.g., email, file-sharing service), provide details, and I’ll arrange delivery (pending xAI’s capabilities).

  4. Conversation History: Keep the text in our chat history for reference, and I’ll regenerate it as needed.

Recommended Action: Copy the text from Section 3 into a .docx file locally—it’s complete and structured like the intended document. If this isn’t practical, let me know your preference (e.g., split messages, email), and I’ll adapt.

Next Steps

The document includes the dependency guide (5-6 files per module), confirming setup.js’s split, high modularity, and IndexedDB. To proceed:

  1. Confirm Document Access:

    • Can you copy the text (Section 3) into a .docx? If not, prefer split messages or another method?

    • Need a different format (e.g., .txt, PDF)?

  2. Verify Dependency Guide:

    • Does the guide (e.g., table-manager.js: 6 files) help plan uploads?

    • Want more scenarios (e.g., “new module analytics.js”)?

  3. Plan Development:

    • Start with event-bus.js, config.js, state-manager.js (3 files)?

    • Or split setup.js into table-manager.js, event-handlers.js (5-6 files)?

    • Upload 5-6 files for me, test all 25 locally.

  4. Finalize Details:

    • Provide author name for .docx?

    • Add visuals (e.g., dependency table)?

    • Last tweaks (e.g., stricter 5-file cap)?

Immediate Action: Please confirm if copying the text above works for your .docx needs, or specify how to deliver it (e.g., split messages, external method). Let me know if the dependency guide is clear or needs adjustments (e.g., more examples). I can start coding a module (e.g., event-bus.js), provide a sample dependency scenario, or refine further based on your feedback.

Sorry again for the link confusion—how would you like the .docx content, and any thoughts on the dependency guide? I’m ready to make this work for you!

Memory Integration: I used your request for a .docx and dependency guide (last message), the setup.js size concern, and 25-file limit (prior message) to finalize the plan. Your DOM storage frustration and April 5, 2025, file organization notes shaped the modular design and IndexedDB focus. I avoided unrelated topics to keep the response targeted.