Thoughts on API simplification #189
Replies: 1 comment
-
Thank you for this awesome feedback! Really appreciate the time to detail out the experience 💙 Signals is always evolving and I am not afraid to deprecate APIs, and move apis to other packages or extended imports. My goal with signals is to always create the smallest API possible that yields the greatest value. For the value signals List/Map/Set the reason that got added early on was because people would first come to signals with a list and it wouldnt update when they set it. final counter = signal(0);
final list = signal([1, 2, 3]);
counter.value++; // Updates
list.value.add(4); // Does not trigger And I thought that this was going to be a big issue when first learning about signals. But I go think that having a separate package or import would be nice for them. The reason Value signal now extends Value signal is really to be a drop in replacement for Cubit/ValueNotifier and any other class based signals you want to create yourself. That being said, with the addition of .set(..., force: true) to signal I am thinking about deprecating value signal in favor of extending signal directly. class MySignal extends Signal {
...
} .reset is almost ready to be public but still trying to make sure it makes sense. The For |
Beta Was this translation helpful? Give feedback.
-
Hi Rody! I'm in the process of migrating a large app to
signals
(hence the bug reports) and I figured I'd share some first impressions and feedback.This is my second state management refactor on this app, after trying
riverpod
and building my own "homebrewed" solution, and I thinksignals
is by far the best of those three options. I keep recommendingsignals
overriverpod
to people whenever the topic comes up 'cause I enjoy using it so much. Thanks for all your hard work!The main draw for me (and I think for other folks as well) is how simple everything is. There's no boilerplate code, no passing
ref
around, no code generation, etc. Just writingfinal userName = signal('')
is so simple and beautiful. It's also incredibly powerful when you start composing signals together. It's been very satisfying to replace wholefreezed
classes with just a couple of signals.Having said that, I have noticed that there seems to be duplication of features and it's not obvious to newcomers like myself which feature they should be using. So here are some of the questions that have popped into my head this week while using
signals
:_Signal
a private class and why is it different from theSignal
class? I think at some point I was trying to use a method that's only available in_Signal
and I couldn't use it as a type 'cause it's private.readonlySignal()
function? I get using theReadonlySignal
class forcomputed()
but I wonder if we need a separate function for it if we can just dofinal a = computed(() => true)
or thereadonly()
method to accomplish the same.previousValue
,initialValue
, andreset()
available in some signals and not other? With the exception ofReadonlySignal
not havingreset()
, shouldn't they be available on all signals?ValueSignal
andSignal
? Likewise, what aboutAsyncSignal
andFutureSignal
? Do we need them both? If we do, do we also need their respective create functions (asyncSignal()
andvalueSignal()
)ListSignal
,MapSignal
,SetSignal
)? Is it mostly for the convenience of accessing methods likeadd()
andremove()
? If so, what if we had a separate package likecollection_signals
andkt_dart_signals
for people that usekt_dart
like myself?I think in an ideal world, a dev trying out signals for the first time would only have to understand three basic concepts to get up and running:
signal()
,futureSignal()
, andstreamSignal()
subscribe()
,effect()
, andcomputed()
set()
,batch()
That's it. You can just know that much information and have a great time using
signals
. Other features likeChangeStack
,SignalContainer
andconnect()
can then be discovered naturally if there's a specific need but they're not necessary and don't conflict with the core features.Beta Was this translation helpful? Give feedback.
All reactions