Background Of Flutter with Dart Programming Language
As before, don’t get too hung up on the details of this because there’s no expectation that you should understand this code yet as we’ll get into it all in later chapters, beginning with the next chapter with which you’ll build up some Dart knowledge. But, also as before, I’d bet you get the basic idea of what’s going on here anyway because it’s fairly obvious I think. At least for the most part that is – how the widget code and its state object interact and relate probably is a bit less than obvious, but not to worry, that won’t
be the case for long! Going back to stateless widgets for a moment, it should be noted that the term “stateless” is a little bit of a misnomer here because being Dart classes, which can have properties and data encapsulated in them, stateless widgets do, in a sense, have state. The core difference between a stateful and a stateless widget though is that a stateless widget doesn’t automatically get re-rendered by the Flutter core framework when its “state” changes, whereas a stateful widget does. When the state of a stateful widget changes, regardless of what causes the change, certain lifecycle events fire. Those trigger lifecycle event hook functions getting called, which results, ultimately, in Flutter re- rendering the portion of the screen where the widget resides (assuming a change was necessary – Flutter makes that determination for you because it knows what the state of the widget was before as well as after the event). Think of it this way: both types of widgets can in a sense have state, but only a stateful widget has state that Flutter it aware of and even manages to some extent. Therefore, only a stateful widget can be automatically re-rendered when appropriate, all controlled by the Flutter framework itself, rather than you having to do anything manually in your code.