Introduction
In GetX, you can make any class reactive by wrapping it with Rx<T> or using the .obs extension. This is essential when you need to react to changes in complex data structures. This guide covers how to create reactive custom models, update nested properties, and handle lists of custom objects effectively.
- Making a Custom Class Reactive
To make a custom class reactive, you have two options: use the .obs extension or the Rx<T> constructor. Both create an observable variable that notifies listeners when its value changes.
- Accessing and Modifying the Object
To read or update the entire object, use the .value property. Assigning a new object to .value triggers a UI update.
- Updating Nested Properties
If you modify a property of the object directly, the UI will not update because the object reference hasn't changed. To fix this, you have two options: use the update method or call refresh() after modification.
- The update Method Explained
The update method accepts a callback where you can modify the object. It automatically triggers a UI update after the callback finishes. This is the cleanest way to modify nested properties.
Comparison: update() vs refresh() vs replace
| Method | Syntax | When to Use | UI Update |
|---|---|---|---|
| `update()` | `rx.update((obj) => obj?.prop = val)` | Modifying nested properties | Automatic after callback |
| `refresh()` | `rx.refresh()` | After manual modifications or when object reference unchanged | Manual trigger |
| Replace object | `rx.value = newObject` | When you have a new instance (immutable models) | Automatic on assignment |
- Reactive Lists of Custom Objects
Use RxList<T> to create a reactive list of custom objects. You can add, remove, or modify items, and the UI will update automatically when the list structure changes. However, modifying a property of an item inside the list still requires a refresh.
- Using Workers with Custom Models
You can use workers to react to changes in the whole object or specific properties. Since workers only track the object reference, they will not fire when a nested property changes unless you call refresh() or update().
- Immutability vs Mutability
To avoid having to call refresh() on nested changes, you can make your model immutable and always replace the entire object when something changes. This is often easier and less error‑prone.
Best Practices
- Use immutable models when possible – Replace the whole object to avoid manual
refresh()calls. - Use
updatefor nested modifications – It’s concise and ensures the UI updates. - Avoid storing large objects as reactive – If the object is large and changes frequently, consider splitting it into smaller reactive parts.
- Use
refresh()sparingly – It forces a rebuild even if no change occurred; preferupdateor value assignment. - Keep your models simple – Business logic should stay in controllers, not in models.
Common Mistakes
- ❌ Modifying a property without
updateorrefresh– UI does not update. ✅ Useupdateorrefresh()after modification. - ❌ Using
.valuerepeatedly insideObx– Can cause unnecessary rebuilds if not needed. ✅ Use local variables or computed getters. - ❌ Forgetting that workers only react to reference changes – Nested changes won’t trigger workers.
✅ Call
refresh()or useupdate. - ❌ Not initializing
Rxvariables – Trying to usenullRx can cause errors. ✅ Always initialize with a value.
Conclusion
Making custom models reactive in GetX is straightforward. By understanding how to update nested properties, when to use update, and how to work with reactive lists, you can build reactive UIs that react to changes in complex data structures. Adopting immutable models can simplify the pattern further and reduce the risk of missing updates.