How Stateful Widgets Are Used Best - Flutter Widgets 101 Ep. 2
Вставка
- Опубліковано 23 лип 2024
- What is a stateful widget? What is the difference between stateful and stateless widgets? How do state objects work? In episode 2 of Flutter Widgets 101, Andrew Brogdon answers these questions. Learn when to use a stateful widget and the inner workings of it by looking into the widget and element trees.
If you didn’t see the first episode on stateless widgets, click here to watch → bit.ly/FlutterWidgets101-1
Watch other episodes in the series → bit.ly/FlutterWidgets101
Resources:
Get started with Flutter → bit.ly/2qu9EP2
Try a Flutter codelab → bit.ly/Flutter-Codelab
Guide to creating a StatefulWidget → bit.ly/2Rz9em3
StatefulWidget API Docs. → bit.ly/2zELLJ1
Chapters:
0:00 - Intro
0:21 - Differences between stateful and stateless widgets
0:56 - StatefulWidget
6:08 - Why you won't make lots of stateful widgets
Subscribe to Google for Developers → goo.gle/developers
#Flutter - Наука та технологія
This is well explained Andrew, at a perfect speed, and helpful visuals. And I'm comparing to other Google Dev videos, so keep them coming!
Simple and effective formal documentation on Flutter. This really helps! Thank you dev team.
I just love how clear you guys explain everything.
This is so satisfying to watch. All the docs I ever read and tried to understand put into one video. Please make this series a really long one. :-p
Awesome tutorial !!! Simple, crisp and to the point !!!
Excellent Explanation, Thoroughly Enjoyed
Finally some information about why the overhead of a second class is even needed. Coming from React, it is quite confusing, especially because the "StatefulWidget" is actually immutable and stores all of the state within that subclass, that also acts as the element factory.
that's exactly what i needed to understand the true nature of stateful
widget
I still think it's a bit weird how it's the state that's creating the child widgets, not the Stateful Widget Class itself, like Stateless Widgets do.
I mean, It makes sense considering how the classes are organized, but it's pretty weird naming-wise.
I agree
Best explanation EVER and why I love the flutter more and more. Great job bro. Send me a Flutter t-shirt plzzzzzzzzzzz
Thank you for the video. btw, Could anybody tell me what theme and font did Andrew use to demonstrate the codes?
Hi!, i am wondering... how can i pass a parameter from the stateful widget' constructor to its state? eg: In the video example, pass a counter initial value from outside the itemCounter class.
Do i need to mantain all constructos parameters as final atributes in order to use them in the state?
I am just starting with Flutter. Very useful videos. Thanks in advance.
This is extremely helpful
Everyone: Developing apps is too hard for beginners
Flutter team : "Super Simple"
❤️❤️❤️
I just wish they'd use more than a single space for indentation. 😂
@@pleasejustletmebeanonymous6510 😂
Best explanation of Stateful Widgets still
Loving Flutter
Is such complexity of creating a notion of stateless and stateful necessary to create and manage such UI? Just wondering if it is necessary complication, since I'm still getting my head around this.
i want a life cycle for a single screen, like when i go to from A screen to B screen then a OnPasue() method of Screen A should be call like in Android Studio, and when i move back to Screen A then its OnResume() will be call,
Any Idea?
When we have StreamBuilders and the BLoC pattern, do we need stateful widgets?
Thanks a lot for this video. I am wondering about a third tree that Ian Hickson talks about: the render object tree. Why is it not in this video? Could one say, that the updated stateful widget (e.g. Tom: 1) is in reality a rendered object of the render tree? I am a little bit confused.
We left the render tree out of this video series in order to keep things simple. It's a lot easier for people to understand what we're covering if we start with just two trees rather than three. That said, it's definitely important to understand how rendering works, and we plan to have a series that covers it as well.
The question you asked ("Is StatefulWidget in reality a rendered object?") is a really interesting one. I was surprised to learn when I first started working with Flutter that StatefulWidget (and StatelessWidget) don't get rendered at all! There are no render objects created specifically for them. They don't get drawn, and don't listen for input events. All StatefulWidget ever does is create a state object, and all the state object ever does is track some fields and rebuild child widgets. Those *children* can have render objects, get laid out and painted, but the StatefulWidget itself doesn't.
If you check out the base class for StatefulElement, you can see some more info on this topic:
github.com/flutter/flutter/blob/71a15896d8f473331061f1e564bf7f3770d73e8d/packages/flutter/lib/src/widgets/framework.dart#L3681
I want a Flutter t-shirt
They sell them at amazon
This video is unlisted before you view the comments. I hope this series have daily uploads
hi, i am new to flutter, this whole thing is kinda causing me some headache and i would like some feedback
so i have this statefulwidget that gets a String name passed into it and then set the string to a card title
title: Text(
'${widget.name}',
),
like so, the issue its telling me
"Evaluation of this constant expression throws an exception.dart(const_eval_throws_exception)"
i know im missing something here, any help would be appreciated
Can someone help me out?
At 1:26, why is that final String name even needed?
Would be good to see a longer form video like this on animations.
Thanks for letting us know. While some good topics are obvious (like stateful widgets, for example), we try to take our cues from the audience as much as possible.
And gotchas of gestures.
if anyone watching reply i tired using stopwatch in flutter because i have to update value in order i need to use setstate function but whenever setstate function calls it's reset the stopwatch time looks like we can only use stopwatch in stateless widget how video games than work.
At 1:15, isn't there a definition loop between ItemCounter and _ItemCounterState? ItemCounter needs _ItemCounterState definition, and vice versa.
At 03:00, where does this magical "widget" object come from that allows you to access the properties of the widget that created the state (in this case widget.name)? How does the State object know which widget created it, since nothing is being passed to it in its constructor - when we create a new State using _ItemCounterSate() we are not passing any parameter or context or reference to the actual widget.
Agreed. There is too much magic here. If the full code was provided with this instruction, perhaps it would be more clear.
thanks 🧡
this is excatly what flutter has been lacking!!!
What is the best way to access properties of stateful widgets by the parents?
@muh2k4 Hey did you find a good answer, because i am wondering the same thing ?
Is it ok if I make all widgets StatefulWidget?
No, Stateful Widgets consume more resources.
Thank you. I am good.
Why do the previous page(s) are rebuilt when pushed to a new page?
Sorry, I don't quite follow. When you say "pages," what do you mean?
@@redbrogdon when I push from one stateful screen to another stateful screen, the previous screens in the stack are building everytime a new screen is pushed. Is this how it is supposed to work?
MaterialApp widget(WidgetsApp) has its own navigator, home property is the / route. They are stateful widgets when you push a new route, that widget calls setstate rebuilding all the children in the stack. You deduce the rest. If you're using inherited maybe you want to use the builder property along with home or routes. Sorry for my english
great
i'd wasted tons of times until i watched this video and realized that i'd been declaring state variables in the widget class. that was super horrible. thanks for this guy !
Glad we could help!
@@andrewbrogdon558 Hi Sir, you're the Man! Many thanks for you....!
When you say "When the widget is rebuilt, because the new widget has the same type as the old one, the element stays right where it is" - what is the meaning of "stays right where it is"? Since the element is what is actually seen on screen it needs to be re-rendered, right? In the video, changes in actual data are displayed in the widget, but the widget isn't visible; only the element is. So if a widget is rebuilt, does the element get re-rendered? And if so, what does "it stays right where it is" mean???
I imagine that you've already found the answer to your question, but the element itself is never actually "rendered" at all. Its job is to manage the connections between all the other pieces of the system (widget, state object, render object, etc.), know parent/child relationships, provide access to inherited widgets higher in the tree, and that kind of thing.
Its render objects that handle how the UI is laid out, rendered, and composited. I don't go into them in this video because I'm trying to keep things simple, but we have other videos that dive into all the details. This one by John Ryan is a favorite: ua-cam.com/video/zmbmrw07qBc/v-deo.html.
This guy is a f***ing genius
Why do people design stateless widgets for updating states? That's where I get confused. There are two things I heard/read stateless widgets remember their states, stateless widgets have to ability to mark changes within its widgets and re draw them. But I see people use stateless widgets and use them to get re-drawn and update themselves. For example I have made a clock app that updates its text widget and can also draw a clock face with the seconds, minutes and hour hand moving and its not using any statefull widgets. So then ultimately what is the defining advantage or use-case for statefull widgets?
Code is better than explanation
Thanks for these! Now to fix that UA-cam LIVE thumbnail upload JSON error... ;)
Why not just return a State object directly using the createState() method of the StatefulWidget instead of going through the convoluted process of making a whole new class just for this one State object? It presumably is only ever going to get created by the createState() function anyway - and only once ever - so it would be much easier to follow as a method rather than a whole new class.
I realise that it could then be re-used for other Stateful Widgets, like if they were list items, but usually this is not planned.
4:32 if Stateless Element updates itself to reference a new widget, that it is not so stateless after all
does nobody find this way of managing state is too complex? Compare it to react-native ru.reactjs.org/docs/state-and-lifecycle.html ru.reactjs.org/docs/hooks-state.html
I don't understand why should I create separate classes of creating state if all mutation would be done then in child class.
Who else come here from the Flutter code
I love flutter, but i want support google maps , PLEASE
Hi
I have the video next
I feel privileged
i couldnt understand
wait, wot?
Stop with these cliffhangers!
Over-engineered mess to say the least! Thinking back to other UI tools of the past, I'm reminded of Visual Basic, where Microsoft managed to get a beautiful RAD tool (with visual drag and drop surface and the best debugger) in the hands of developers that built far more complex applications and automated so many industries despite the underpowered hardware of that time and the language that VB was!