Core Tenets

The following is a brief overview of the core principles and beliefs that drive Flutter Forge.


One key driver for Flutter Forge is to try and help developers write better designed software. We follow the generally accepted definition of good software design being loosely coupled & strongly cohesive. The one software design pattern that is in alignment with being loosely coupled & strongly cohesive while also aligning with our other tenets is Modular Software Design.

This facilitates more easily making changes over time. Or even doing things like replacing a component without having to touch the other components. It also facilitates being able to easily extract components into libraries.

Design without Thought

One of Flutter Forge's goals is to provide a library that will provide just enough structure so that if the developer follows it they will end up with loosely coupled Modular components. We like to think of this as helping our consumers achieve Software Design without having to think heavily about the software design. Obviously, Flutter Forge only facilitates this in the UI Component space.


We are big believers in TDD and Outside-In development. However, a lot of tools in the community make both of those things harder than they have to be. Often they require complex testing setup, etc. Flutter Forge strives to provide the best testing experience possible supporting Outside-In development and TDD with no magic. The Flutter Forge library design and concepts are key to meeting this goal.


It is a beautiful thing to be able to develop a component in isolation. Away from all the complexities in the application. The various Storybook implementations have facilitated doing this for simple stateless widgets and stateful widgets that have been designed in a modular fashion. However, developing more complex widgets in isolation has always been much more painful.

Flutter Forge is designed with this as a core principle, making this easy. Beyond that, it makes it easier to develop components in a simple two phase process.

  1. Develop the component in isolation, not worrying about integration complexities.
  2. Integrate the component, likely with the aid of Flutter Forge's composition support.


This is the concept that we can easily build more complex components up from other components.

State Based

This means that it is designed such that each component has its own state and that state defines how the view is presented to the user. At a high conceptually level you can think of state based UI as a simple function that takes in the current state and outputs the view to the user.

Controlled State Change

Static state by itself isn't very interesting though. Generally, things are interesting when you change state over time. This can however be pretty tricky to get right with the existing tools in the community. Flutter Forge strives to provide a mechanism to facilitate state change in a controlled unidirectional manner that eliminates the tricky gotchas that other libraries have.

UI Override

This is the idea that a component can be used with all its business logic, etc. while just the UI piece can be overridden. This is especially useful when you have extracted components into a library so that you can easily drop them into your various apps. However, you may want to change how the component visibly looks so that it is styled to match each respective app.