StatelessWidget: Flutter's Immutable UI Blueprint

WHY IT EXISTS Flutter needs a simple, efficient way to render UI that doesn't change. By creating a widget type that guarantees immutability, the framework can heavily optimize rendering, skipping rebuilds for widgets whose configuration hasn't changed. This provides a performant baseline for building UIs.

THE MENTAL MODEL A StatelessWidget is like a rubber stamp. You configure it once (the ink color, the design) when you create it. Every time you "stamp" it by calling its build method, it produces the exact same impression based on that initial configuration. It can't change its own ink color midway through stamping.

HOW IT WORKS A StatelessWidget has one primary job: to override the build method. This method takes a BuildContext and returns a Widget. All of its properties, like color or text, are declared as final and are passed in via its constructor. The build method is only called in three main situations: when the widget is first inserted into the tree, when its parent changes its configuration, or when an InheritedWidget it depends on changes. Because it's stateless, Flutter can apply significant optimizations, especially if the widget is declared as const, which allows Flutter to short-circuit the rebuild process entirely.

WHEN TO USE IT Use StatelessWidget for any UI that depends only on its configuration and doesn't need to change internally. This includes most presentational components: icons, text labels, buttons with simple callbacks, styled containers, and layout widgets like Row or Column whose children are determined by a parent. It should be your default choice until you explicitly need internal state.

WHEN NOT TO USE IT Do not use a StatelessWidget if the widget needs to change its appearance in response to user interaction (like a checkbox), data fetched from an API, or any other internal event. For any UI that needs to manage its own mutable state, you must use a StatefulWidget. Trying to manage state inside a StatelessWidget is a common beginner mistake that simply won't work.

ONE CANONICAL EXAMPLE A simple AppLogo widget is a perfect use case. It takes a size but doesn't change on its own. A parent would create it like AppLogo(size: 100.0). The class definition would look like: class AppLogo extends StatelessWidget { const AppLogo({ super.key, this.size = 60.0 }); final double size; @override Widget build(BuildContext context) { return FlutterLogo(size: size); } }. This widget is configured by its parent and only rebuilds if its parent passes it a different size. It's efficient and predictable.