In the previous article Constraints go down, we learn that flutter constraints follow this simple rule.

Constraints go down. Sizes go up. Parent sets position.

This is my attempt to explain how the flutter constraints work and how we can use them in our day-to-day flutter development.

The series is divided into three articles based on the above rule, explaining each rule with examples, common errors, and its solutions.

This article focuses on the second rule “Sizes go up”.

So Let’s get started.

What does “Sizes go up” mean?

The constraints are passed from top to bottom in the tree. But what size a widget should take within the given constraints is decided by the widget itself.

A parent can only pass box constraints, not size.

The parent cannot say its child to be of the size 50×50. Until it is forced upon using tight constraints. Check Rule 1

It can tell its child…

Hey child I am giving you a box of 100×150 with loose constraint, you can be whatever size you want in this box.

Now child widget decides to be of size 50×50 and give information back to its parent.

It’s a child widget itself that decides its own size within the given constraints by its parents.

Now based on the size information provided by the child, the parent aligns the position of the child on the screen. (More in next article)

So from the widget tree perspective, the size is passed from bottom to top hence the rule “Sizes go up”

Since its widget tree, the same rule applies to the child when it becomes a parent.

Now the important question is…

How does the widget choose its size?

Well, the answer is “It’s complicated”.

Although the widget follows the constraint system rules, how they define its size is completely depends on its implementation and how the author has designed it.

Let’s take an Icon widget. In the below example, we are passing a tight constraint to force the Icon size to be 150.

But we can see from the output it’s not taking size 150.

Why?

It’s because the Icon widget is a design based on Material theming. It takes its size of 24 from the IconThemeData object from the MaterialApp theme.

How do I know this?

By reading Icon widget documentation and source code.

So how do we change the size of an Icon?

Simply pass the size value in the Icon widget or change the icon size in the material theme.

For a theme-based solution, let’s take the second approach.

Now it’s working as expected.

Each widget is designed to solve a specific problem and have its own specific behavior, to correctly predict a widget’s final size, we should be aware of not only the general rules but also the layout widget-specific constraint rules.

For example

Container will by default takes maximum height/width of constraints passed from the parent.

DecorationBox will take the minimum height/width of constraints passed from the parent.

Text will style it text from DefaultTextStyle from Material theme widget. For more info on text check the below video.

For more examples checkout this codepen and github repo by Marcelo Glasberg.

To summarize

Generally, the final widget size may end up being one of the following three sizes.

1. It may become as big as possible under loose constraints.
2. It may become as small as possible under loose constraints.
3. It may become a particular size under tight constraints.

This makes the widget constraints behavior somewhat complicated as now we need to understand each widget’s specific behavior under different conditions.

The best way to understand how the widget decides its size it to go through the documentation or the source code.

Limitations

• Since the parent’s size and position, in its turn, also depends on its own parent, it’s impossible to precisely define the size and position of any widget without taking into consideration the tree as a whole.
• We cannot get the size of the child in the build method as we do with constraints. Here is the article explaining how to get the size and position of the widget.

Common widget size problems and solutions

Black and yellow stripes shown on screen overflow.

This is one of the common errors developers face while building UI.

And most of the time we find it while building the Row and Column widget. This happens when children try to be of bigger size than the given constraints by parents.

We can fix the this in Row/Column widget by using Flexible or Expanded widget to wrap each child. Or change the column or row widget to a list view.

Resources and Credits

1. https://flutter.dev/docs/testing/common-errors
2. https://medium.com/flutter/how-to-debug-layout-issues-with-the-flutter-inspector-87460a7b9db#738b
3. From the official flutter, doc check out Understanding constraints.
4. A Deep Dive Into Flutter Box Constraints by Naresh Idiga

That’s it for the second rule folks!!

If you have any questions please let me know in the comments.

Stay tuned for the remaining part of the series and to get notified first, subscribe to this blog.

Photo by Markus Winkler on Unsplash