A few questions regarding your library

[jacob-emery]

1. In the docs it is stated that "You may incur the need to pass a Signal deep into the tree, this is discouraged. You should never pass a signal as a parameter.". Is this recommended only to prevent having a huge number of params as the app grows? Or does it have something to do with functionality too.

2. I have used Riverpod, but I want to move away from it because of many reasons (global nature of providers, ref is needed everywhere, ...). Some questions on how to move from Riverpod (I never used solidJS, so some questions might sound a bit silly 😂).

• 2.1. What do you use internally? ChangeNotifier (and/or ValueNotifiers)? Or some custom class extending ChangeNotifier? Or StateNotifier?
• 2.2. Riverpod providers are only lazy. What about solidart signals, resources, and so on? Are they strict by default, lazy by default, only strict or only lazy?
• 2.3. What is the analogous of Effect, in Riverpod?
• 2.4. In Riverpod I usually create my own notifiers to manage custom logic (something more advance than just changing state of a signal). What is the equivalent in your lib? It is my understanding, that when working with signals readers don't have direct access to the notifiers. How would you achieve functionality that is similar to the TodoNotifier in this example https://riverpod.dev/docs/providers/state_notifier_provider?

3. Are memos supported (yet)? Or are there just the same as derived signals in your lib?

4. If I were to only use Soliddart throughout my app, is reactivity really like in SolidJS (i.e. rebuilds only when really needed)?

5. Is the Solid widget needed only for inheriting a value, e.g.:

   final themeMode = context.observe<ThemeMode>(SignalId.themeMode);
   

   Or is a root Solid widget necessary when using this library in general, i.e., also before calling e.g.:

   SignalBuilder(
     signal: counter,
     builder: (_, value, __) {
       return Text('$value');
     },
   )
   

Maybe it would make sense to create a Discussion section and move this issue there.

[nank1ro]

1. It's recommended to prevent having a huge number of params and because you should use the Solid widget to pass signals down to the tree
2. Changing from riverpod
   2.1. Internally it's very similar to a ValueNotifier but with more extra built-in features (like previousValue, select, customizable comparator and so on)
   2.2. When using the Solid widget, every signal or provider you declare is lazy by default (but you can customise the behaviour for providers). They will be created only when read. The Resource is always lazy, it runs only when used inside a ResourceBuilder or when you call resolve() yourself. If you use createSignal outside of the Solid widget it gets created immediately.
   2.3. I would say ref.listen, but you shouldn't create an effect inside the build method (put it inside the initState instead). With the effect you can open a dialog, navigate to another page like what the ref.listen is meant for.
   2.4. You should use a SolidProvider in this case. See the todos example. You simply create a Dart class (no extends are needed) where you place all the business logic, signals, effects and so on and you provide it to descendants with the Solid widget.
3. Derived signals are enough, because they only emit a value when it changes. Right now this doesn't mean that the computation is cached, the function evaluates any time the parent signal changes to check if the derived signal has changed.
4. Yes, the reactivity is fine-grained. When you use SignalBuilder only the builder method is called when the signal changes. It's just your responsibility to put SignalBuilder down in the tree (only where really needed). The same applies to context.observe.
5. The Solid widget is not just for inheriting values. You can pass signals down into the tree and you can also pass providers to easily separate the business logic from the UI. In addition the Solid widget manages the lifecycle of signals and providers. When the Solid widget is removed from the tree, all signals and providers are automatically disposed.
   You're not forced to use the Solid widget, but I suggest you try it. This has nothing to do with SignalBuilder, because it works anyway even without a Solid widget.
   You're supposed to have many Solid widgets around your app like Provider (the library) works. In this way you never use "global" variables and the state is visible only to descendants and others cannot see nothing.

Feel free to ask any other question if you still have doubts

[jacob-emery]

Thanks for thoroughly answering each single point!

One of the things that bugged me in Riverpod was not being able to immediately invoke the function inside a provider, but having to create a ConsumerWidget just to use ref.read(provider). I really appreciate your lazy param.

I really like this signals concept and the fact your library — by not using global state — leverages the Flutter widget tree. Also, the examples and the documentation are immensely helpful. Really appreciate your effort! Well done! 🎊

[nank1ro]

Thank you so much! I really appreciate it 😊 One of the thing that is really important to me is that this library is meant to be easy for beginners. You already have to learn Flutter, and I wanted to leverage its power, respecting its rules and not introducing complex solutions or relying on code generation.