CCExtractor / CCExtractor/taskwarrior-flutter

[Refactor] Complete GetX Migration — Remove All Remaining `setState` and `GetBuilder` Usage

Open
#615 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Dart
Stars
244
Forks
179
Avg merge
12h 42m
Merged PRs (30d)
2

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` |
| `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`

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.