Widgets vs helper methods | Decoding Flutter
Vložit
- čas přidán 9. 12. 2021
- Flutter developers are well-acquainted with widget build methods that grow, and grow… and grow. In this video, Craig Labenz compares two different ways to break up those unwieldy build methods; and how the best option may be different than what you originally suspected.
See the differences in action in these DartPads:
Managing rebuilds with nested const widgets → goo.gle/3yallg1
Managing rebuilds with nested non-const widgets → goo.gle/3IyafpM
Preventing errors with separate widgets → goo.gle/3dDrR5o
Helper methods can create a requirement for Keys → goo.gle/31HlnQB
Get started with Flutter → goo.gle/Flutter
Learn more about the Dart Language → goo.gle/2YF9OCi
Watch more Decoding Flutter episodes → goo.gle/DecodingFlutter
Don’t miss an episode, subscribe to Flutter → goo.gle/FlutterYT
#DecodingFlutter #Flutter #Developer
product: Flutter - Development - User interface; - Věda a technologie
thanks, that was so important to me i used helper methods, but from now i will use classes
At least in VSC, the "refactor selected code to separate widget class" will notice variables defined out of scope, and automatically add them as parameters to the new class, providing the proper linkage at the original site. It stunned me the first time I tried that and it just worked. :)
know your tooling first
Ya , Intellij supports that too, would be better to have the class created in a new file though. Dont hv that yet
I didn't know this existed! Thanks for mentioning this great tool!
This is so underrated, I felt like I could have saved so much of my time when I got to know about this.
Greeeat video, it helped me a lot!
As a novice in flutter I've started to use different classes for widgets right from the beginning as it felt logical for me. But watching more and more tutorials I've found out that people in them use helper method extensively and switched to that approach as it seemed easier to transfer data that way.
Now, this video put thing in correct perspective and explains why it's not the best way
That was just soo helpful! As a new flutter developer, I just can't underestimate the value of such and advice!
Key takeaway
1. Use classes instead of helper functions
2. Use const constructor wherever possible
anymore ?
Thankyou so much !
maybe make use of lint for the const constructor best practice
this is not true sometimes helper functions more useful. you should watch this tutorial.
@@nielfollero5 why head to not go to?
@@longkhanh8544 It basically means the same
I was editing the widgets today and I was confused about the difference and this video helped me, thanks!
i like your explanation style and pace... slow and clear with simple examples , makes it really easy to absord
I've been looking for this video for a while. Now I got it clear. Thanks👏
I was using the the helper method approach... But from now, I will use another class to wrap my Child widget build methods....
Thanks for the insight... Much appreciated...
Thank you so much for this video. Was really eye opening and taught me something new!!
One of the most useful Decode to date... Kudos
Been curious about this issue for a while now, you hit the nail on the head as always, thank you Google
Thanks! I’ve been approaching the limits of readability in my current project and the „refactor widgets“ todo has been getting more and more priority recently. Now I know what to look out for :)
Very articulate and concise delivery!
Great video! I want to add that naming your helpers or classes well is very important!
Great teaching style! Question I always wondered answered.
I just start to do it recently and my app performance got much better 🙂
Thanks! Although I knew it already I needed to hear it from the flutter team again 😅!
Solved the biggest confusion I was having. Thanks
Very nice explanation
Great video! So many good things coming from Flutter
Thanks Craig. Very important video indeed.
Finally i got some arguments to use widgets 😍 love it 🥳
Thank you. That was very important information
You are awesome. Always thankful for your explanation.
I always used to use class constructors, because it makes code looks more readable and clearer for me. It's happy to hear that there are more valuable advantages too 😊.
K..
I also had thoughts about this topic. I started using separate classes for widgets but main problem I face with that is passing variables and callbacks are a bit challenging.
Great Video! I have one minor addition. We can actually convert helper methods to generated widgets via functional_widget package.
This way we get rid of both new class boilerplate and side effects of helper methods.
Why use yet another package when you can just right click and refactor to a class automatically. Not sure what IDE you use but android studio does this out of the box
@@thefamousdjx you have a very good point on this but adding new params or debugging properties makes classes longer and I have a feeling of writing boilerplate code unnecessarily. Therefore, I use this package :)
There are some annoyances that come with that package:
- you have to run build_runner every time you open a project
- files get generated next to classes and start to clutter your project
- there is a way to tell build_runner to generate files in special folder 'generated',
but moving files around project can break imports and you have to restart whole build_runner
- doing 'extract widget' from context menu will still create class widget and you'll have to spend some time
deleting code and replacing it with functional widget syntax
- similarly, if you press F12 to see implementation of functional widget, you'll end up in generated file instead of
actual function
After summing all this things up I realized it's unfortunately not worth doing it to save couple of lines. It's a great idea though, and I hope there will be better solutions in the future.
@@avalanche2073 And other devs need to know the package in order to understand your code
This is a extrenely valuable information. Thanks
We appreciate your positive feedback, Heshan 🙌
Very precious information 🤯
super cool advice. i love it!
excellent exhibition, and I will not tire of asking for it. In Spanish, please. Thank you
Very good content, for everyone involved you are awesome. 👨🏻💻 🚀
So relieved I have had developed a habit of separating widgets
Great explanation!
Super video. Great good practice.
thanks, i understand more something from your video!!!!
Ah crap, I need to rewrite a few things. Thanks! Backlog item added
Great video. Thanks
Good recommendations.
Thank you for yet another great video! I knew about it, but it's always good to refresh in memory.
The only thing I don't like is `const` keywords everywhere.
Okay, we don't have that annoying `new` keyword, but we have to print `const` again and again. Is it really that difficult to make the compiler smarter, so it would automatically add consts in front of widgets? If it already has a lint, suggesting const, why not to get rid of `const` in front of constructor and make a compiler to add it when app is building?
This couldn't agree more with you.
Having to wrote `const` constantly is pretty annoying.
Fully agree. If a constructor is already marked ‘const’, I don’t see why the compiler can’t quietly infer const wherever that constructor is invoked.
Yo me había preguntado eso. Gracias amigo
I never thought about performance and testability but I always preferred NewWidgets instead of helper methods as it looked more natural to do in platform like flutter.
I needed this
We're happy to hear that this was so helpful! Be sure to check out the links in the description for more tips and tutorials 🙂
I liked the video just for 3:49
Very well said.
What about if you use a global state management package like GetX or state rebuilder? Doesn't that mean that only the reactive part of the widget tree is rebuilt on state change?
In some scenarios, a widget class can significantly out perform its corresponding helper function. In the scenarios where helper methods out performs widget classes, the performance advantage brought by helper functions over widget classes tends to be marginal. Plus other benefits of using widget class, if you want a no-brainer decision, using widget class seems a better bet.
This is the case only for Stateful widgets or does it apply to completely Stateless widgets as well?
Thank you for korean subtitle!!
Nice tutorial
Nice video ❤️❤️
Hi! Thanks for this video. What theme and font u use?)
I use methods to format code. So should I use classes for formatting also? I like it being seperated bcoz it makes me reading it easier.
Thank you for tehe video!
Tried to apply this principle to create a countdown function but for some reason setting state in the countdown widget (which should only redraw the text every second) triggers a rebuild of its parent widget. Can't figure out why,
Thank you!
Interesting that this video mentions Remi but doesn't mention his library `functional_widget` which basically turns a Widget function into a class via code generation. This is basically what I use. You get all the benefits of a class as mentioned in the video with the terseness of a Widget function.
Because there's no need for a library when android studio already has this feature by simple right clicking and converting to class
Is there any scenario where helper methods would be a better choice than use a class?
great video
but what if we didnt have any setState inside the helper method ? is it still okay to use helper method ?
Geez wish someone told me this 3 years ago! I started with dozens of helper functions, slowly started using seperate widgets so the dart file wasn’t 2000 lines long. Still have a lot of refactoring to do 😅
Classes are always great since you can isolate them to a separate file. As your app grows bigger and complex, it becomes easier to fix bugs when things are isolated. The logic is also easier to follow when code is broken down instead of having over 2000 lines in a single file
top level functions are no different in this aspect
I couldn't disagree more. Lots of tiny source files makes the code a major pain to navigate through.
@@pianoman16 it's not painful if you give classes understandable names and use IDE's functions to navigate to type definition for example :)
Thanks @Remi
So I feel there is one catch, what if we are not using setstate inside that sub widget ? than I guess there should not be any problem in performace and we can use function there instead of new widget. everyone do share your views if I missunderstood anything here.
I never really liked too many lines of code in a single file. I believe that’s my unintentional love for class based widgets
Nice!
I really love the intro music!
can I have the full version? Hahaha
That's really nice
I perfer using helper method when I am using bloc for state management but when using stateful widget and when using setstate seprate class is better.
What is the connection between the bloc and the methods that the widgets return? The essence of the video is different
@@alexfokin4182 let me clear you. When we use bloc builder only the parts that need to change state is updated and that time we can use helper method as re render of whole ui is not done with the help of bloc builder as setstate is not used.
@@KingLeoMessi Of course, everything returned by the BlocBuilder is re-rendered, so it's important to remember that helper methods embedded within that block of your code will incur all of these trade-offs :)
I agree with you. We can specify which widget need to be rebuilt by wrapping it with BlocBuilder, BlocSelector. Helper methods now make our code is easy to read and maintenance.
Yay! I choose the right option then 🙃
is there a possibility that flutter will have a drag and drop method to create app in the future?
Amazing!
Thanks! These videos is really helpful!
I was in doubt about to separate the widgets (like Text('Hello');) in local variables, if it is also a bad idea... Another doubt is if for example I have a Widget with a lot of params, can I pass these params to another Widget using its instance? Like: WidgetWithALotParams(SomeChildWidget(parent: this)); (then the SomeChildWidget will have access to all WidgetWithALotParams params)
create models for passing a lot of parameters
Gracias ♥️
Thanks
thanks ☺️☺️☺️
Well this is helpful and I started doing this but hit some limitations (Either in my understanding or with Flutter)
So I have a form that has a complex dropdown that I would rather seperate it.
I still want to have access to values inside that dropdown for when I submit.
With a helper function I have access to that variable and can read it when I'm ready to submit
With a seperate class I don't have that link.
Is there a way I can share this data?
You can use name parameters to pass the values. Example: TextFiledWidget(value: value) something like this very easy..
Amazing
Where can I buy those dashes?
how about if we use getx?
I love the way he made us follow along 🤣.... I was just saying Yes, True, Ohhh That's true 😅
So, using classes is better than using helper methods.
Ok, but is this a big difference?
If it is not, I would prefer to use helper methods in general for smaller sub pieces of UI.
Because using classes for these small things means you will have a huge amount of classes (all of which you have to try to name correctly), and a larger percentage of your codebase will be boiler plate.
Thanks so much.
Help me from the end of death on boilerplate coding.
😁👍
is extracting widget in a variable is a good choice,??? Please reply .
No it isn't. It goes against Flutter's philosophy of fast rebuilds.
I think the good benefit from classes is respectability in different widgets. But it look like more than that. anyway I always use that way.
So making a new class that extends stateless/full widget for your widget is better than making a separate method in the same class to return a widget(helper)?
It only helps in the example, as the favorite icon is a stateful widget than can uodate itself
@@adamyong6766 so if my widget is stateful. Better to make a separate class for it. But if stateless, its ok to use method(helper)?
@@bluesilhouette6748 It doesn't matter if the widget is stateless or stateful. It's always better to use widgets than helper methods from the performance point of view.
@@mivoligo "always" is a very strong argument. Any supporting data?
@@guangyuchen7275 sorry, I'm sure I've used the word "always" incorrectly. There must be a way to worsen performance using widgets. :) I just wanted to emphasize that it doesn't matter is the widget is stateful or stateless. Flutter is optimized to use widgets and not functions returning widgets.
Though this is not the right platform to ask...I am struggling in building an android app with flutter.. apk is not building.. There is an error in build.gradle file.. It says
could not resolve properties..even stack overflow could not resolve my query
Why not use stateful builder with the helper widget?
the link is Error: Page not found, Please update.
this is the first time i heard about helper method.
Great!
I've always used separate widgets. If I need to use a callback, I declare a property for that
Its also bad to debug because the helper method is not visible in the debug widget tree
Rémi 🥖 🇫🇷 rocks 🥇💪😁
Minimizing dropped frames is nice but the real benefit is the power consumption. The vast majority of devices can run resource intensive apps effortlessly, but the power consumption is greatly affected. Making efficient apps is more for the battery life than for performance nowadays (although it's always good having faster apps as well)
It is sad that const won't work with any localisation approach and most of the endpoint widgets in the widget tree brunches are Text.
what about StatefulBuilder?
I've always used separate widgets without knowing all these advantages.
Same here 🤣
i wish there was some way around this. helper methods make things so much easier
if i have to create classes i have to pass in parameters and all code is more verbose
But usually helper methods require parameters too. Like context etc...