[feature] Hooks Style APIs

[medz]

This is a feature request

Background story

In Solidart v2-dev, it uses alien_signals to build high-performance Signals👍. But before Solidart took action, I built flutter_alien_signals; this was not my intention, because I have been desperately needing a good signal in flutter for a long time.

I built it temporarily, but recently solidart has completed the basic writing of v2, and I am using Solidart (previously using flutter_alien_signals) in the app I am building.

But flutter_alien_signals is not a long-term solution, because it only exists to solve my personal needs, and I am planning to point it to solidart from pub.

Why do you need a Hooks style API?

Maybe it's selfish, I have always tried to write less and clear logic code. I have successfully implemented such APIs design in Flutter several times and it works well.

##APIs

• StatelessWidget: class MyWidget extends StatelessWidget with Solidart
• StatefulWidget : class MyWidget extends StatefulWidget with StatefulSolidart

In build method:

  @override
  Widget build(BuildContext context) {
    final count = signal(0);
    void increment() => count.value++;

    return Scaffold(
      body: Center(
        child: Text('Count: ${count.get()}'),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: increment,
        child: const Icon(Icons.plus_one),
      ),
    );
  }

Convenient

class Counter extends SolidartWidget {
  const Counter({super.key});

  @override
  Widget build(BuildContext context) {
    final count = signal(0);
    void increment() => count.value++;

    return Scaffold(
      body: Center(
        child: Text('Count: ${count.get()}'),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: increment,
        child: const Icon(Icons.plus_one),
      ),
    );
  }
}

---

https://github.com/medz/alien-signals-dart/tree/main/pub/flutter_alien_signals Here you can see the prototype function I implemented. It currently uses a List to store the calling order and needs further optimization.

---

However, don't worry that you will need a lot of time to implement it. This is just a proposal, you can reject it, of course, if you want to accept it. I will submit a PR for this in the future when I have free time, you just need to review it❤️

[nank1ro]

I'm not against hooks, but they promote wrong separation of concerns. The build method should not contain any state logic, but should use it. The reason for that is that the build method is meant to be executed multiple times in the lifecycle of a widget. And hooks bypass this limitation caching the value, and returning the same instance.

I know you are thinking that writing less boilerplate is good (and in most cases it is), but in terms of separation of concerns it is not, because you end up placing everything in a single place.

In addition, you're increasing the user complexity, because now the user must know the new models SolidartWidget and StatefulSolidart and use them correctly. This is always a big red flag, because new models must be introduced only if they are indispensable.

Additionally this is good only for ephemeral state.

I'm not completely against this, and I'm open to make a separate package like solidart_hooks that uses flutter_hooks to provide this feature.

Let me know!

[medz]

@nank1ro https://github.com/medz/oref/blob/main/example/lib/main.dart I succeeded and it was easy to implement a hooks-like Flutter state management implementation.

Honestly, this is quite convenient. No extra widget writing burden for the user.