[Proposal] Extend LayoutBuilder to handle full app cases. about flutter HOT 2 OPEN

I am confused about what this is asking for. Some questions/comments inline:

The wrong way is easy to use and hard to catch in code review because of the similarity.

This could be resolved with a lint, for which there's already a request: dart-lang/linter#4448

In contrast if you want a widget to branch on the space available then LayoutBuilder's api works well.

If you want to branch on "space available" LayoutBuilder is the right choice. MediaQuery will always give you the size of the screen, which is often NOT the available space.

This proposal suggest adding a sibling object to the existing builder of LayoutBuilder

How does adding something new that nobody know about solve the discoverability problem mentioned in the first paragraph?

that under the hood uses MediaQuery.sizeof and then converts that data into a boxConstraints

Why would you want to do that? What is the use case here? If you want to build a UI based on the available space you should NOT use MediaQuery.sizeOf. Instead, the existing LayoutBuilder (or some custom RenderObject) is the way to go.

It took me a long time to discover Dialog.fullscreen

How does Dialog.fullscreen relate to this discussion? That seems to be a different API for something different?

from flutter.

I am confused about what this is asking for. Some questions/comments inline:

The wrong way is easy to use and hard to catch in code review because of the similarity.

This could be resolved with a lint, for which there's already a request: dart-lang/linter#4448

Yes lint might be the easiest way to catch this class of error.

In contrast if you want a widget to branch on the space available then LayoutBuilder's api works well.

If you want to branch on "space available" LayoutBuilder is the right choice. MediaQuery will always give you the size of the screen, which is often NOT the available space.

kind of, but the spirit of this proposal is to have layout builder give you either the size of the app (what media query does) or the size of the available space. Media query does not give the size of the screen as I understand screen it gives the size of the app's drawing window which is a subset of the Display. Display maps more closely to screen in my mind.

This proposal suggest adding a sibling object to the existing builder of LayoutBuilder

How does adding something new that nobody know about solve the discoverability problem mentioned in the first paragraph?

If we had LayoutBuilder.localBuilder and LayoutBuilder.appBuilder then when you used (or searched for how to fork widgets based on space) one you could find the other more easily than having to know (or search) about different classes.

that under the hood uses MediaQuery.sizeof and then converts that data into a boxConstraints

Why would you want to do that? What is the use case here? If you want to build a UI based on the available space you should NOT use MediaQuery.sizeOf. Instead, the existing LayoutBuilder (or some custom RenderObject) is the way to go.

This question makes me think I did a poor job of explaining the proposal. I know when to use MediaQuery.sizeOf and when to use LayoutBuilder. The proposal is to use layout builder to do both jobs.

It took me a long time to discover Dialog.fullscreen

How does Dialog.fullscreen relate to this discussion? That seems to be a different API for something different?

This is an example of the issue of default constructors mixed with named constructors making natural discoverability more difficult. Natural in this case means finding functionality while writing code.

from flutter.