What is Computed State?
Computed state refers to values that are derived from other reactive state. Instead of storing the computed value separately and manually updating it whenever its dependencies change, you can compute it on the fly. In GetX, you can use simple getters, Rx variables updated with workers, or the GetX widget to efficiently manage computed state.
Comparison of Approaches
| Approach | Best For | Performance | Complexity |
|---|---|---|---|
| Getter in Controller | Simple synchronous computations | Recomputed on every access | Low |
| Worker + Rx Variable | Side effects or memoization | Recomputed only when dependencies change | Medium |
| GetX Widget | Expensive computations / scoped rebuilds | Recomputed only when dependencies change | Low-Medium |
- Using Getters in Controllers
The simplest way to create a computed value is to use a getter in your controller. The getter will be re-evaluated every time it is accessed, and if you use it inside Obx, it will be re-evaluated whenever any of its dependencies change.
- Reactive Computed Variables with Workers
If you want the computed value to be reactive itself (so you can observe it as an Rx), you can use a worker to update a secondary reactive variable whenever its dependencies change.
- Using the GetX Widget for Efficient Computations
The GetX widget is ideal for computed state because it allows you to recompute only when its observed variables change, without storing an extra reactive variable. It also supports returning a widget directly.
- Computed Lists and Filtering
A common use case is filtering a reactive list based on a search query. You can compute the filtered list on the fly.
- Performance Considerations
When using getters for computed values, the computation runs every time the getter is accessed. If the computation is expensive, you may want to memoize the result. Using GetX widget with a builder ensures the computation only runs when dependencies change, not on every frame. For lists, consider using RxList and updating it only when needed (e.g., after filter changes) if the list is large.
- Computed State with StateMixin
You can combine computed state with StateMixin to handle loading/error states alongside derived data.
Best Practices
- Use getters for simple, cheap computations – They are easy to read and maintain.
- Use
GetXwidget for expensive computations – It recomputes only when dependencies change, avoiding unnecessary work. - Memoize expensive results – Cache computed values if they are reused and recomputed often.
- Keep computed logic in the controller – Not in the UI, to maintain separation of concerns.
- Avoid calling getters inside
buildwithoutObx– The value won't update when dependencies change. - Use
everAllordebouncefor complex derived state – Especially if you need to perform async work after a change.
Common Mistakes
- ❌ Using a getter inside
Obxbut the getter accesses non‑reactive variables – The UI won't update. ✅ Ensure all dependencies are reactive (.obs). - ❌ Re‑computing expensive values on every rebuild – Causes performance issues.
✅ Use
GetXwidget to limit recomputation. - ❌ Storing computed state in an
Rxvariable that is manually updated – Leads to duplicate state and potential bugs. ✅ Use getters or workers to derive it automatically. - ❌ Not handling null cases in computed values – If the source data can be null, handle it gracefully.
Conclusion
Computed state is a powerful pattern in reactive programming. GetX offers multiple ways to implement it, from simple getters to reactive workers and the GetX widget. By choosing the right approach based on complexity and performance needs, you can keep your controllers clean and your UI responsive.