Cutting the stateful boilerplate

[goderbauer]

Document Link

https://flutter.dev/go/stateful-macro

What problem are you solving?

Implementing a stateful widget in Flutter requires developers to write two classes: the StatefulWidget subclass and the State subclass. Could we use macros to reduce the number of classes and the lines a developer has to write to accomplish the same thing?

[miyoyo]

I'm going to be the "old man yells at cloud" here, but I feel like I have to.

I picked up flutter early on because both Dart and Flutter were built with simple structures, all of it was straightforward, easy to understand, and you didn't have to delve too deep into complex things to grok the entirety of the functionality of the framework.

Now, don't get me wrong, I don't disagree with simple macros that generate toJson/fromJson/copyWith/equality/hashcode/etc, these do fairly simple things, and explaining them is basically as simple as just putting an example of what the generated code looks like.

But this proposal? To me, this is too far. This doesn't look, feel, or sound like what Flutter is.

Widgets are no longer simple classes with that proposal. Instead, they become magic structures that perform obscure piping logic à la Angular, or even SwiftUI.
It feels like this is akin to trying to trade everything about the experience of writing flutter to end up looking basically like the other frameworks.

(Ignoring the proposal if it releases is not an option, peer pressure from the majority won't let me ignore such a feature change or it's semantics.)

[kroolzone]

I like flutter and dart for how explicit they are. Sane type safe language with very low magic like dart is a breath of fresh air in the world of metaprogramming and reflection magic madness. But like above poster mentioned, boilerplate reduction will likely go through because of the wider pressure. People would rather waste several hours and days debugging than write 5 more lines of code. I'm not against macros since they obviously provide major benefits and allow to do things that aren't possible otherwise. Macros are gonna be abused by the community no matter what but I hope dart and flutter team members themselves don't go overboard.

[benthillerkus]

I think that verbosity is definitely a big problem when writing UI code with Flutter and it regularly stops me from breaking up big build methods further.

And I also absolutely don't have an issue with macros or compiler extensions helping here. If I didn't want any ""magic""", I shouldn't choose a declarative framework, where -by definition- I submit some description of what I want and the framework figures out how to make that happen.
Macros are from my POV just another transformation the compiler does before spitting out optimized bytecode (which absolutely is magic to me :)

With that preface away: If all those paper cuts like @Input(), not being able to customize the constructor, those @Assert... are being required it's just not worth it. I don't think it's getting much simpler, succincter or faster to write that way.

In general I don't think Stateful Widget is a great API (for all the issues already discussed at length when React adopted hooks more than half a decade ago). And while the framework uses them a bunch (though often in ways that would prevent usage of the macro), I think for end users in non-library code (where some neutrality and agnosticism is often preserved), I don't think StatefulWidgets are that common. Certainly not at work where I've introduced hooks and we've been using just that.
I think it's fair to say that most state management packages for Flutter try to keep you away from writing Stateful Widgets, so I wonder for how many people this macro is actually something they'd use.

The need for a StatefulWidget macro stems from the need for StatefulWidgets, and I think it'd make more sense to actually go back to the hooks proposal, have a look and Compose and SwiftUI and look how we can use Macros to aid with that directly.

That being said, I think if you can get something like functional_widget for StatelessWidgets to work using macros, that'd still be worth shipping. If it's just an annotated function, it should be very easy to use and the reduction in LOC would be maximized.

[xu-baolin]

Sometimes the use of macros makes the code less readable, especially when the current Flutter programming paradigm is very mature. Secondly, macros make it difficult to link and jump to code in the IDE. Now that the IDE's AI code generation function is very powerful, writing one more stateful class will not cost much ：） Let us retain a little sense of ritual that belongs to Flutter.

[markusrubey]

I’d go even further and suggest macros similar to SwiftUI property wrappers such as @State, @Observable, and @Binding. Flutter’s offerings for sharing and mutating state across the widget tree are quite verbose and prone to bugs. Specifically, when both ancestor and descendant widgets subscribe to the same state, it can lead to complex and unintended behaviours.

A more opinionated and robust solution that encourages the composition of UI components, rather than relying on state management tied to individual screens, would be highly valuable. Such an approach would allow better scalability and could significantly increase adoption and support within the developer community.