DEMYSTIFYING WIDGETS AND RENDER_OBJECTS MYTHS.
Have you ever thought about the mystery behind Widgets and RenderObjects in Flutter?
I mean the rendering myth that converts the widgets to pixels on the screen? No.
Okay, Let’s get started.
Although, before getting a detailed illustration , I believe understanding the relationship between a widget and its corresponding RenderObjects is of utmost importance. Getting to know how a particular technology operates and works is the difference between a random developer and a 10x developer. Painting and laying out the myths of Widgets and RenderObjects is the main aim we are going to be leveraging on, in this post. However an overview of what RenderObjects and widgets are won’t be omitted. Its is a common saying that “everything’s a widget”. However, It’s un-categoriseable “smiles”, but in reality that’s not necessarily the case.
Why?
“A widget is an immutable description of part of a user interface “. Thinking about it, you might be surprised because “IMMUTABILITY” in user interface doesn’t go hand in hand. User interfaces are not immutable, different parts of the User interface, you take and change. User interface are in flocks, new widgets come in and go and get swapped in and out, but if widgets are immutable then…
HOW DOES FLUTTER MANAGES THE STATE OF YOUR USER INTERFACE?
HOW DOES IT REPRESENTS CHANGE?
In reality, flutter has three concepts for this, i.e it doesn’t have
one widget tree, it actually has three trees widgets which are.
- Widget Tree
- Element Tree
- RenderObject Tree
These three different concepts ‘ll compile together to make the rendering of the User interface as performant as it possibly can. (This is a new concept maybe for some folks).
Nevertheless, a widget is immutable, that kinda makes sense because you are working with a declarative framework i.e you declare what the UI is gonna look like and so you configure it, and you configure it with widgets. Therefore widgets describe the configuration of an element.
SO, WHAT DOES THAT MEANS FOR AN ELEMENT ?
What it means is that an “Element is an instantiation of those widgets”, it’s the mutable piece of the tree. It manages updating and changing of the User interface. It controls everything (it’s safe to say it’s managing the lifecycle of widgets. Now, the RenderObject which is an object in the render tree, basically handles size, layout and painting of the User interface. When Flutter draws User interface, It doesn’t look at the tree of widgets, it looks at the tree of RenderObject which controls all these things.
NOW LET LOOK AT IT FROM A SLIGHTLY DIFFERENT PERSPECTIVE.
- Configure.
- Lifecycle
- Paint.
Configure, when you configure your User interface, basically you’re assigning properties and values to the components and you are doing it through an API and that’s what ends up as your widget tree. Lifecycle is going to manage what components exist in the User interface hierarchy. It’s going to manage the relationship between the elements and handle their mutational welfare. Paint concept on its own case draws those things on screen, i.e you have to paint your UI, and that’s where RenderObjects comes in. Each component knows how to paint itself, but importantly RenderObjects provides
constraints for its children.
You need to be able to customize things otherwise, why are you using a UI framework ?
Anyways, it’s never too late to demystify!
“I highly recommend opening your favorite IDE and following along the concepts in the code often creates those amazing moments. Android Studio, VS Code or IntelliJ are cool ones you can opt for based on your choice.”
Let’s take a look at this RenderBox example below, it’s a CenteredColoredBox.
Another illustration is this customized ImageSliderWidget
Conclusively,
widgets are basically configurations for your render objects.
Getting acquainted with Flutter, you’ll find yourself developing what you want to appear
on the screen using a mixture of widgets. Each time you use a widget, you’re setting
properties on it or nesting other widgets within it. You use widgets to describe what the
visual hierarchy should look like at a point in time. You can think of widgets holding
configuration information about the visual hierarchy, or being a template for the
visual hierarchy.
When your application runs and an instance of a widget is created it’s associated with an Element. Where widgets are immutable and may be recreated based on the changing state of the application, Elements mutate based on the widget that they’re associated with. Elements combine in a tree structure to define the current layout of the application. You’d think that if an Element defines the current layout of the application it would be what draws, or renders, each widget. This role actually resides with the RenderObject which is attached to a RenderObjectElement, a sub-class of Element (in contrast to a ComponentElement which is predominantly responsible for composition of other Elements). The RenderObjects provides the basic infrastructure for managing your tree of visual elements. It defines the general protocol for performing layout, painting, and compositing. You need to get the point that RenderObjects hierarchy is used by the Flutter Widgets library to implement its layout and painting back-end.
Keep rendering because these are the benefits.
- Full control over the layouts.
- Full control over performances
- Full control over painting.
It’s nice getting in touch with you and thanks for the read. For comments, critics, questions and observation. Check me out on the following platforms. Twitter, GitHub, LinkedIn,
