Flutter Deep Dive, Part 2: “RenderFlex children have non-zero flex…”
This article is part of a four-part series. You can find the others here:
This article is part of a four-part series. You can find the others here:
- Part 1: “RenderFlex children…”, wading into the Baby Pool
- Part 2: Taking the Plunge
- Part 3: A Flex is not a flex
- Part 4: The Flex Layout Algorithm
Welcome to Part 2 of our series on dealing with RenderFlex and other, similar errors in Flutter. Here, we’re going to take a look at the basic “conversation” that goes on during layout, get an overview of Flutter’s “three layer cake” and I’ll give you an introduction to the Widgets that we’ll be digging into a lot more in Part 3.
So grab a drink (and maybe some headache medication) and let’s get started!
Taking the Plunge
In Part 1 we waded into the baby pool, but here we’re going a lot deeper. I can think of no better place to start than by explaining what’s happening in terms that can be understood by a human being.
First, you want to understand there are a few Widgets that rely on others to tell them what size to be. Some of these Widgets are Flex, Column, Row, SingleChildScrollView and List.
When laying out UI elements in Flutter, there is a kind of “conversation” that goes on. Let’s take a look…
In our example, we have three Widgets. The first is “Parent”. Parent has both a Child and a Grandparent. Parent is one of the Widgets that need to be told what size to be because, just like a real parent, it has no idea what’s going on.
- Grandparent to Parent: “How big do you want to be? You can be as big as you want, all the way to infinity.”
- Parent to Grandparent: “Let me get back to you on that.”
- Parent to Child: “What size do you want to be?”
- Child to Parent: “I want to be as big as I possibly can, make me to the biggest size you can let me be!”
Parent is confused and looks at the ground. Grandparent didn’t tell it what size to be, Child didn’t tell it what size to be either, and the only thing in the try/catch block is a three-month-old comment from Bill about Taco Tuesday.
This is when the Magic Smoke leaks out of your laptop, the screen goes black and your test device displays “the red screen of death”.
What’s happening is the child wants to “flex” to infinity (children have non-zero flex) and the Grandparent says it can be as big as it wants to be (but incoming height constraints are unbounded).
Does this make a little more sense now? Good. Now that you have a grasp of the basics, tie a rope around your waist and let’s really dive down the rabbit hole.
Under the Hood
I’m assuming you already know about the Widget, Element and Render layers but, if not, here’s the tl;dr version of “Flutter’s Three Layer Cake”:
- The Widget layer contains Widgets, which are like blueprints for whatever you want to make.
- The Element Layer is where you find the Elements that are sort of skeletal representations you build from each Widget. They’re like mockups or empty shells. An Element only contains a Type and, if there is one, a Key. During the process of rendering each frame, you’re going to check to see if the Widget for this frame still matches up with the Element from the last frame. If they match, then you can just leave it alone and move on. If they don’t match, then you set a flag for it to be destroyed, so you can build a new one later.
- The Render layer contains the objects that Android and iOS devs would most closely associate with “Views” (Android and iOS don’t really have an equivalent to the Widget or Element layers). Render Objects are (basically) created from the Elements and only get changed when needed.
There’s a lot more to it than that but, for this article, we don’t need to go into any more detail. If you want to go digging into the Widget, Element and Render layers, then I suggest you start with “Flutter, what are Widgets, RenderObjects and Elements?”, by Norbert Kozsir.
To misquote Shakespeare: “A Rose, is a Rose, is a Turkey Sandwich”
There are three things you want to make sure you understand when dealing with Rows and Columns:
FlexFlexibleFlexFit
<sarcasm alert>
These are easy to keep straight in your head:
- One is a multi-child layout widget that takes multiple children.
- The second is classified as a multi-child layout widget but actually won’t take more than one child. (Wait, what?!?)
- The third determines how the second fits into the first, determining the size of the first. But, because there are outside factors telling it to sit down and shut up, it really doesn’t do much of anything… well, except keep the second from trying to force the first to be bigger than you can imagine (you know, like “the Force” in Star Wars). So, in a way, I guess it does help determine the size of the first… but not really.
See how easy that was!
</sarcasm alert>
(That’s a joke, people… It’s confusing as hell.)
It’s also where we’re going to pick things back up in Part3. See you there!
You can stalk the author on Twitter at https://twitter.com/scottstoll2017
