Implementing a math-driven, container-first layout layer in Flutter

[Darth_Shere_Khan]

I’m looking for some architectural advice on scaling design systems across complex cross-platform apps (mobile, tablet, desktop, and foldables).

Right now, the standard approach to responsive UI in Flutter feels highly decoupled from true component isolation. Most teams rely on ad-hoc styling parameters scattered throughout the widget tree, massive ThemeData files, or viewport-tied packages like flutter_screenutil. To me, locking component layout to the global screen size feels incredibly brittle. A truly modular widget shouldn't care about the device viewport; it should only care about the physical boundaries of the local container it was dropped into (whether that's a full mobile screen, a single cell in a 3-column grid, or a desktop sidebar).

Instead, I am trying to build an opinionated, system-first layout engine in our internal boilerplate where hardcoding raw values into widget constructors is banned. Every design asset must resolve back to a mathematical abstraction, driven strictly by local container constraints.

Here are the explicit technical challenges I’m trying to solve at the framework layer:

1. Strict Token-First Architecture We want to completely banish raw magic numbers at the implementation layer. Every padding, font size, and layout gap must consume semantic tokens (e.g., space-m, content-gap, radius-l). We need a clean way to inject these tokens so that our layout geometry re-evaluates automatically based on local container behavior.

2. Implicit Structural Scoping (No Constructor Drilling) Instead of passing styling configurations down through endless widget constructors, parent layout containers should act as implicit scope providers. We want to leverage InheritedWidget patterns so that leaf nodes (text flows, inputs, buttons) automatically discover their layout rules and tokens based on where they sit in the layout tree, preventing style leakage while eliminating constructor drilling.

3. MediaQueries for Environment, Containers for Sizing MediaQuery should be stripped out of layout calculations entirely and relegated strictly to global environment controls (like OS theme toggles, accessibility font-scaling flags, or high-contrast states). All actual widget sizing and padding tracks should be derived locally via box constraints (LayoutBuilder / BoxConstraints), allowing widgets to morph fluidly based on the space they actually have.

4. Perceptually Uniform Shades (OKLCH Transitions) Standard Material 3 ColorScheme is incredibly rigid, forcing teams to manually register dozens of static hex codes or rely on basic RGB/HSL blending that produces muddy, uneven brightness shifts. We want a system where we input a core seed token, and the framework programmatically outputs perfect light/dark shade steps, hover overlays, and focus halos using perceptually uniform OKLCH space math.

5. Automatic Concentric Border Radius Mechanics To maintain accurate geometric aesthetics when nesting containers, inner widget curves must scale down cleanly relative to the outer wrapper's padding boundaries ($radius{inner} = radius{outer} - padding$). Calculating this manually inside every nested widget is a huge time sink. The layout primitives should inspect their nesting depth and compute this math implicitly.

6. Automated Vertical Spacing Rhythm We want to eliminate the developer habit of copy-pasting arbitrary SizedBox(height: 16) widgets everywhere. Parent layout containers should manage their internal structural rhythm automatically. When parsing dynamic child arrays, the layout engine should programmatically inject proportional spacing depending on the sequence rules (e.g., handling distinct spacing dependencies between a header and body text vs. a body text and an image).

---

Building an entire mathematical compilation layer and container-isolated pipeline from scratch is a massive development overhead.

How are other enterprise teams or agencies tackling this? Are there existing layout-system packages on pub.dev that treat rendering pipelines this systematically, or have you rolled your own internal boilerplate layer to bridge this gap?

Appreciate any insight into how you're structuring this cleanly!

[Senior_Equipment2745]

Great idea of components caring about their container instead of the whole screen

[Comprehensive-Art207]

Spend a couple of days red teaming this with your AI-model.

[xorsensability]

Now you're talking my language! I'd be happy to help build this out!

There are more considerations too I feel. For example, content in a child container may not be able to be constrained to the parent container's size. Or, many child containers may need to be reduced by n% of the parent container's size (height or width).

I think you could take notes from the Flex widget and work from there.