vasily/TCPDashboard
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
TCPDashboard/docs/decisions/ADR-005-Data-Driven-Indicators.md
Vasily.onl 3e0e89b826 Refactor indicator management to a data-driven approach 
- Introduced dynamic generation of parameter fields and callback handling for indicators, enhancing modularity and maintainability.
- Updated `config_utils.py` with new utility functions to load indicator templates and generate dynamic outputs and states for parameter fields.
- Refactored `indicators.py` to utilize these utilities, streamlining the callback logic and improving user experience by reducing hardcoded elements.
- Modified `indicator_modal.py` to create parameter fields dynamically based on JSON templates, eliminating the need for manual updates when adding new indicators.
- Added documentation outlining the new data-driven architecture for indicators, improving clarity and guidance for future development.

These changes significantly enhance the flexibility and scalability of the indicator system, aligning with project goals for maintainability and performance.
2025-06-11 19:09:52 +08:00

3.9 KiB
Raw Permalink Blame History

ADR-005: Data-Driven Indicator System

Status

Accepted

Context

Previously, the technical indicator configurations, including their parameters and UI generation logic, were partially hardcoded within Python files (e.g., dashboard/components/indicator_modal.py, dashboard/callbacks/indicators.py). This approach made adding new indicators, modifying existing ones, or updating their parameter schemas a cumbersome process, requiring direct code modifications in multiple files.

The need arose for a more flexible, scalable, and maintainable system that allows for easier management and extension of technical indicators without requiring constant code deployments.

Decision

We will refactor the technical indicator system to be fully data-driven. This involves:

  1. Centralizing Indicator Definitions: Moving indicator metadata, default parameters, and parameter schemas into JSON template files located in config/indicators/templates/.
  2. Dynamic UI Generation: The dashboard/components/indicator_modal.py component will dynamically read these JSON templates to generate parameter input fields for the indicator modal, eliminating hardcoded UI elements.
  3. Dynamic Callback Handling: The dashboard/callbacks/indicators.py callbacks will be refactored to dynamically collect, set, and reset indicator parameters based on the schema defined in the JSON templates, removing hardcoded logic for each indicator type.
  4. Runtime Loading: A new utility (config/indicators/config_utils.py) will be responsible for loading and parsing these JSON templates at runtime.

Consequences

Positive

  • Increased Extensibility: Adding new indicators or modifying existing ones now primarily involves creating or updating a JSON file, significantly reducing the development overhead and time to market for new indicator support.
  • Improved Maintainability: Centralized, data-driven configurations reduce code duplication and simplify updates, as changes are made in one place (the JSON template) rather than across multiple Python files.
  • Reduced Code Complexity: The indicator_modal.py and indicators.py files are now more concise and generic, focusing on dynamic generation rather than specific indicator logic.
  • Enhanced Scalability: The system can easily scale to support a large number of indicators without a proportional increase in Python code complexity.
  • Better Separation of Concerns: UI presentation logic is decoupled from indicator definition and business logic.

Negative

  • Initial Refactoring Effort: Requires a significant refactoring effort to migrate existing indicators and update dependent components.
  • New File Type Introduction: Introduces JSON files as a new configuration format, requiring developers to understand its structure.
  • Runtime Overhead (Minor): Small overhead for loading and parsing JSON files at application startup, though this is negligible for typical application sizes.
  • Debugging Configuration Issues: Issues with JSON formatting or schema mismatches may require checking JSON files in addition to Python code.

Alternatives Considered

  • Keeping Hardcoded Logic: Rejected due to the high maintenance burden and lack of scalability.
  • Database-Driven Configuration: Considered storing indicator configurations in a database. Rejected for initial implementation due to added complexity of database schema management, migration, and the overhead of a full CRUD API for configurations, which was deemed unnecessary for the current scope. JSON files provide a simpler, file-based persistence model that meets the immediate needs.
  • YAML/TOML Configuration: Considered other configuration formats like YAML or TOML. JSON was chosen due to its widespread use in web contexts (Dash/Plotly integration) and native Python support.

Decision Makers

[Your Name/Team Lead]

Date

2024-06-12