Post

🤯 Just had a massive Eureka moment revisiting Design Patterns. We often treat #Flutter’s BuildContext as some sort of "magic" variable, but while reading about the Strategy Pattern on refactoring.guru today, everything just clicked. Flutter applies this pattern beautifully. 🧵👇

I was reading the definition of "Context" in the Strategy Pattern and found this: "The context isn’t responsible for selecting an appropriate algorithm... the client passes the desired strategy to the context. In fact, the context doesn’t know much about strategies." Sound familiar? 🤔

If we map this directly to Flutter's internal architecture, it fits perfectly: 1️⃣ The Context: It represents the Element (accessed via BuildContext). It persists in the tree. 2️⃣ The Strategy: It represents the Widget. It is the immutable configuration of "how" something should behave or look.

The Element (Context) acts as a generic container, it doesn't know how to paint or layout on its own. In every build() method, we (the Client) pass a NEW "Strategy" (a new Widget) to the Context. "Here Element, this is your new configuration. Run it."

This explains exactly why Widgets must be final and immutable. In the Strategy Pattern, you often don't mutate the active strategy; you simply replace it with a new one to change behavior. Flutter does exactly this: it swaps the Strategy (Widget) to update the UI state.

Sometimes we get obsessed with learning the latest framework features and forget that fundamental Software Engineering concepts (like Design Patterns) run the show under the hood. Understanding the pattern = Understanding the tool. 🛠️ #FlutterDev #SoftwareEngineering #Dart #DesignPatterns

if one re visits the design token strategy flutter team uses with figma, one can transform it into a MD conforming model pattern to make sure themes, widgets have immutable const fields for big performance improvements.

Interesting take on Figma tokens → const fields. But how does this handle runtime theming (Dark/Light/Custom)? Wouldn't swapping the active constant set still force a full tree rebuild, or is there a specific pattern to optimize that?

0 reposts1 like

you do BulldContext access to the tokens...the token is value based but the model using the value tokens that translates to a const field when one gets to the themes and custom widgets...simple example is how one should do the breakpoints...enum hides the value but everything up from that const

Ah, I see. Using enums as const tokens keeps the widget tree structure immutable, while the context resolves the actual value only at the leaf nodes. It aligns perfectly with the Strategy concept: separating the const token from the runtime resolution. It sounds like a robust optimization

Do you have a 'before vs after' example or a playground project? It would be great to visualize how the build scope shrinks with this pattern compared to the traditional cascading rebuilds