46 lines
3.9 KiB
Markdown
46 lines
3.9 KiB
Markdown
|
# 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
|