-
Notifications
You must be signed in to change notification settings - Fork 170
Open
Description
Summary
Several files in the codebase still use Flutter's native setState / StatefulBuilder for local UI state, and one instance of GetBuilder remains in the app. These are inconsistent with the project's GetX-first architecture already established in HomeController, DetailRouteController, etc.
Problem
| File | Issue |
|---|---|
tags_widget.dart |
TagsRoute is a StatefulWidget with 3 setState calls — no corresponding GetX controller exists |
date_picker_input.dart |
3 setState calls managing currentIndex and _selectedDates list |
profile_view.dart |
StatefulBuilder wrapping dialog content with 2 setState calls for selectedMode |
manage_task_server_page_body.dart |
1 setState inside modal + 1 GetBuilder<ManageTaskServerController> |
add_task_bottom_sheet_new.dart |
4 orphaned homeController.update() calls — NOPs since no GetBuilder listens |
tasks_builder.dart |
Calls private storageWidget._refreshTasks() — brittle and bypasses the public API |
Expected Behavior
All UI state should be managed via .obs reactive variables and Obx widgets, consistent with the existing GetX architecture. No setState, StatefulBuilder, or orphaned update() calls should remain in the app code.
Steps to Reproduce
Run grep -r "setState" lib/app/ — returns active hits in the files above.
Labels
refactor getx state-management good first issue
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels