RenderObjectElement class abstract

An Element that uses a RenderObjectWidget as its configuration.

RenderObjectElement objects have an associated RenderObject widget in the render tree, which handles concrete operations like laying out, painting, and hit testing.

Contrast with ComponentElement.

For details on the lifecycle of an element, see the discussion at Element.

Writing a RenderObjectElement subclass

There are three common child models used by most RenderObjects:

• Leaf render objects, with no children: The LeafRenderObjectElement class handles this case.

• A single child: The SingleChildRenderObjectElement class handles this case.

• A linked list of children: The MultiChildRenderObjectElement class handles this case.

Sometimes, however, a render object's child model is more complicated. Maybe it has a two-dimensional array of children. Maybe it constructs children on demand. Maybe it features multiple lists. In such situations, the corresponding Element for the Widget that configures that RenderObject will be a new subclass of RenderObjectElement.

Such a subclass is responsible for managing children, specifically the Element children of this object, and the RenderObject children of its corresponding RenderObject.

Specializing the getters

RenderObjectElement objects spend much of their time acting as intermediaries between their widget and their renderObject. It is generally recommended against specializing the widget getter and instead casting at the various call sites to avoid adding overhead outside of this particular implementation.

class FooElement extends RenderObjectElement {
  FooElement(super.widget);

  // Specializing the renderObject getter is fine because
  // it is not performance sensitive.
  @override
  RenderFoo get renderObject => super.renderObject as RenderFoo;

  void _foo() {
    // For the widget getter, though, we prefer to cast locally
    // since that results in better overall performance where the
    // casting isn't needed:
    final Foo foo = widget as Foo;
    // ...
  }

  // ...
}

Slots

Each child Element corresponds to a RenderObject which should be attached to this element's render object as a child.

However, the immediate children of the element may not be the ones that eventually produce the actual RenderObject that they correspond to. For example, a StatelessElement (the element of a StatelessWidget) corresponds to whatever RenderObject its child (the element returned by its StatelessWidget.build method) corresponds to.

Each child is therefore assigned a slot token. This is an identifier whose meaning is private to this RenderObjectElement node. When the descendant that finally produces the RenderObject is ready to attach it to this node's render object, it passes that slot token back to this node, and that allows this node to cheaply identify where to put the child render object relative to the others in the parent render object.

A child's slot is determined when the parent calls updateChild to inflate the child (see the next section). It can be updated by calling updateSlotForChild.

Updating children

Early in the lifecycle of an element, the framework calls the mount method. This method should call updateChild for each child, passing in the widget for that child, and the slot for that child, thus obtaining a list of child Elements.

Subsequently, the framework will call the update method. In this method, the RenderObjectElement should call updateChild for each child, passing in the Element that was obtained during mount or the last time update was run (whichever happened most recently), the new Widget, and the slot. This provides the object with a new list of Element objects.

Where possible, the update method should attempt to map the elements from the last pass to the widgets in the new pass. For example, if one of the elements from the last pass was configured with a particular Key, and one of the widgets in this new pass has that same key, they should be paired up, and the old element should be updated with the widget (and the slot corresponding to the new widget's new position, also). The updateChildren method may be useful in this regard.

updateChild should be called for children in their logical order. The order can matter; for example, if two of the children use PageStorage's writeState feature in their build method (and neither has a Widget.key), then the state written by the first will be overwritten by the second.

Dynamically determining the children during the build phase

The child widgets need not necessarily come from this element's widget verbatim. They could be generated dynamically from a callback, or generated in other more creative ways.

Dynamically determining the children during layout

If the widgets are to be generated at layout time, then generating them in the mount and update methods won't work: layout of this element's render object hasn't started yet at that point. Instead, the update method can mark the render object as needing layout (see RenderObject.markNeedsLayout), and then the render object's RenderObject.performLayout method can call back to the element to have it generate the widgets and call updateChild accordingly.

For a render object to call an element during layout, it must use RenderObject.invokeLayoutCallback. For an element to call updateChild outside of its update method, it must use BuildOwner.buildScope.

The framework provides many more checks in normal operation than it does when doing a build during layout. For this reason, creating widgets with layout-time build semantics should be done with great care.

Handling errors when building

If an element calls a builder function to obtain widgets for its children, it may find that the build throws an exception. Such exceptions should be caught and reported using FlutterError.reportError. If a child is needed but a builder has failed in this way, an instance of ErrorWidget can be used instead.

Detaching children

It is possible, when using GlobalKeys, for a child to be proactively removed by another element before this element has been updated. (Specifically, this happens when the subtree rooted at a widget with a particular GlobalKey is being moved from this element to an element processed earlier in the build phase.) When this happens, this element's forgetChild method will be called with a reference to the affected child element.

The forgetChild method of a RenderObjectElement subclass must remove the child element from its child list, so that when it next updates its children, the removed child is not considered.

For performance reasons, if there are many elements, it may be quicker to track which elements were forgotten by storing them in a Set, rather than proactively mutating the local record of the child list and the identities of all the slots. For example, see the implementation of MultiChildRenderObjectElement.

Maintaining the render object tree

Once a descendant produces a render object, it will call insertRenderObjectChild. If the descendant's slot changes identity, it will call moveRenderObjectChild. If a descendant goes away, it will call removeRenderObjectChild.

These three methods should update the render tree accordingly, attaching, moving, and detaching the given child render object from this element's own render object respectively.

Walking the children

If a RenderObjectElement object has any children Elements, it must expose them in its implementation of the visitChildren method. This method is used by many of the framework's internal mechanisms, and so should be fast. It is also used by the test framework and debugDumpApp.