Is extending signals endorsed? #48
Replies: 3 comments 4 replies
-
The code you provided is fine, the only downside I see is you can't extend an additional class (but you don't need to). final themeMode = createSignal(ThemeMode.system);
themeMode.observe((previousValue, value) {
sharedPreferences.setString('themeMode', value.toString());
}); But this is just a personal choice. In any case, yes you can extend signals without any problems. |
Beta Was this translation helpful? Give feedback.
-
That makes sense. Is |
Beta Was this translation helpful? Give feedback.
-
How would you handle cases where class ThemeModeSignal<ThemeMode> extends Signal<ThemeMode> {
ThemeModeSignal(super.initialValue);
@override
void set(ThemeMode newValue) {
if (newValue == ThemeMode.system) {
// ignore
return;
} else if (newValue == ThemeMode.dark) {
super.set(ThemeMode.light);
} else { // must be ThemeMode.light
super.set(newValue);
}
}
} |
Beta Was this translation helpful? Give feedback.
-
I am wondering what is the best way to manage complex signals, where a custom implementation to the
value
setter is wished. With Riverpod I would extendStateNotifierProvider
. When using this library, is the following endorsed, or if there is a better approach?Beta Was this translation helpful? Give feedback.
All reactions