concept element in category flutter

This is an excerpt from Manning's book Flutter in Action. Login to get full access to this book.

“Everything is a widget” is a potentially misleading statement that you’ll see everywhere on the internet, including in the official documentation. This doesn’t mean there aren’t other objects in Flutter. Rather, it means that every piece of your app is a widget. Styles, animations, lists, text, buttons, and even pages are widgets. For example, there isn’t an object called “App” that defines the root of your application. The root of your application can technically be any widget. To be sure, there are other objects in the Flutter SDK (such as elements), which we’ll discuss later.

Looking at figure 3.15, this just leaves the layer in between the widgets and dart:ui: rendering. It turns out that there’s yet another tree in your Flutter app: the element tree. The element tree represents the structure of your app, in much the same way the widget tree does. In fact, there’s an element in the element tree for every widget in the widget tree.

Earlier in the book, I described widgets as blueprints that Flutter will use to paint elements on the screen. When I said elements in that sentence, I literally meant the Flutter Element class. Widgets are configurations for elements. Elements are widgets that have been made real and mounted into the tree. Elements are what are actually displayed on your device at any given moment when running a Flutter app.

Each Element also has a RenderObject. All of these render objects make up the render tree. Render objects are the interface between our high-level code and the low-level dart:ui library. With that in mind, you can think of the element as the glue between the widget and render trees (see figure 3.16).

Elements have references to widgets.

The relationship between a single stateful widget, an element, and a state object is shown in figure 3.17.

Figure 3.17. The relationship between an element and a widget

It’s helpful for me if I consider the element the brains of the operation. Elements are simple in that they only contain meta information and a reference to a widget, but they also know how to update their own reference to a different widget if the widget changes.

Anytime Flutter is rebuilding, the element’s reference points to the new widget in the exact location in the widget tree of the element’s old reference. When Flutter is deciding what to rebuild and re-render after build is called, an element is going to look at the widget in the exact same place as the previous widget it referenced (see figure 3.18). Then, it’ll decide if the widget is the same (in which case it doesn’t need to do anything), or if the widget has changed, or it’s a different widget altogether (in which case it needs to re-render).

Figure 3.18. Each element points to a different widget and knows its type.

So, when you swap those two buttons, they replace each other in the widget tree, but the element’s reference points to the same location. Each element is going to look at its widget and say, “Has this widget changed? Or is it a new widget altogether?” So, we’d expect the element to see that the widget’s color property has changed, so it should in fact update its reference to the new widget.

The problem is what elements look at to decipher what’s updated. They only look at a couple of properties on the widget: