I was on the first screen of my app, and I had a lot of interactions between UI widgets (the screen and the interactions are shown at the end) like this :

When a text field has more than 4 characters a button which was disabled should be enabled, and the inverse is true, less than 4 characters, the button should be disabled again

When a button is clicked other UI widgets need to be shown on the screen

Sometimes a progress indicator need to appear

Sometimes an informative error message should pop depending on the context

A button to reinitialize the UI state is also required and so on

First I used the famous setState() function to handle the state of the screen. Back then, I said to myself: the page only contains straightforward interactions and I can do it with this function, but, Oh I’ll be damned!

My first screen, even though it is simple and doesn’t contain the heavy blocks of my app, thanks to setState() it started to look like hell, gibberish texts here and there.

In addition to this, the app would always crash and complain about something related to setState(). Flutter didn’t really offer helpful error messages to help me pinpoint the problem, but at that level, I didn’t blame it for not understanding my code, as I didn’t understand it either 😄.

I took a step back, removed every single setState() function from my code, as I do hate this function now and you should too. Then I started researching BLoC (Business Logic Component) as an alternative mechanism to managed states. After all, BLoC is the method that Google recommends.

For someone new to reactive programming, BLoC was not so easy to grasp at the beginning, especially with overwhelming technical terms like: Observable, observer, subjects, streams and so on. Yet, what matters is the programmer mentality, and so I managed to understand it at the end.

Afterwards, I used BLoC in my code, and it worked like a charm. My code was easy to read, test and debug, my presentation layer is separated from my business logic, and it just felt right, everything was in place.

I started to tweak my code here and there, doing some refactoring and optimizations, like encapsulating code that I will reuse and so on. I mean these normal stuff that every developer would do.

After many tweaks and optimizations, I found myself creating a simple yet powerful pattern that could help to manage widgets’ states among all my app screens, in an intuitive and easy manner.

First, I wanted to expose this pattern as a reusable function in my app so I could use it in many screens. Then I though that I should create this pattern as a separate package so I could import it into all my Flutter projects later on. However, when I was at the point of doing it, I even saw a pattern in my pattern, and then I said why don’t I automatically generate the source code of this pattern, so other Flutter developers could take advantage of it with minimum efforts.

Thus, this brought me into source generation.