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.
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.
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.
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 !
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: ruclips.net/video/zmbmrw07qBc/видео.html.
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.
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.
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.
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?
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.
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 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?
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.
@@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
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.
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!
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.
I just love how clear you guys explain everything.
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
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 😂
Simple and effective formal documentation on Flutter. This really helps! Thank you dev team.
that's exactly what i needed to understand the true nature of stateful
widget
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!
I want a Flutter t-shirt
They sell them at amazon
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
This video is unlisted before you view the comments. I hope this series have daily uploads
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.
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: ruclips.net/video/zmbmrw07qBc/видео.html.
Best explanation EVER and why I love the flutter more and more. Great job bro. Send me a Flutter t-shirt plzzzzzzzzzzz
Best explanation of Stateful Widgets still
this is excatly what flutter has been lacking!!!
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.
Excellent Explanation, Thoroughly Enjoyed
This is extremely helpful
Awesome tutorial !!! Simple, crisp and to the point !!!
When we have StreamBuilders and the BLoC pattern, do we need stateful widgets?
Who else come here from the Flutter code
Thank you for the video. btw, Could anybody tell me what theme and font did Andrew use to demonstrate the codes?
Code is better than explanation
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.
Loving Flutter
Can someone help me out?
At 1:26, why is that final String name even needed?
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.
Thank you. I am good.
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.
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?
thanks 🧡
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 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 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?
At 1:15, isn't there a definition loop between ItemCounter and _ItemCounterState? ItemCounter needs _ItemCounterState definition, and vice versa.
I love flutter, but i want support google maps , PLEASE
4:32 if Stateless Element updates itself to reference a new widget, that it is not so stateless after all
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.
This guy is a f***ing genius
great
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
Thanks for these! Now to fix that RUclips LIVE thumbnail upload JSON error... ;)
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.
I feel privileged
I have the video next
Stop with these cliffhangers!
Hi
i couldnt understand
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!
wait, wot?