Flutter Warsaw interview with Felix Angelov


Before Flutter Warsaw #14, we interviewed our speakers, and asked them about their development path in Flutter, what was the most challenging for them while using this technology, and who is their biggest Flutter inspiration.

Felix Angelov is a Senior Software Engineer at Very Good Ventures. He previously worked at BMW where he pioneered the transition to Flutter and is also a dedicated open-source creator and maintainer. When he's not coding, he's searching for new coffee shops and practicing his latte art.


Mateusz Wojtczak


Senior Flutter Developer @matiwojt

Felix Angelov



[Mateusz Wojtczak] What's your background as a developer?

[Felix Angelov] I started my career in mobile development and worked primarily on iOS (Swift) but also had some Android (Java) experience. Later I transitioned into web development and worked for several years with Angular and React using Typescript. I also had the opportunity to work on backend systems using Node.js and Express as well as microservices with Nest.js (all in TypeScript). Eventually when I heard of Flutter and realized how many problems it could solve I quickly switched gears and have been developing using Dart and Flutter full-time ever since.

What have you been using before creating the Bloc package?

Before the bloc package my team and I tried using scoped_model, redux, and the manual BLoC design pattern using RxDart.

What inspired you to create Bloc? Have you seen similar solutions in some other languages or frameworks?

I really liked the principles of the BLoC design pattern because it allowed my team to decouple business logic from the UI making it easy to test and reuse code. At the same time, I felt the pattern enabled us to scale effectively as each feature was able to manage its own state as opposed to having a global store.
After experimenting, my team and I decided we liked the pattern but didn't like the boilerplate and complexity of manually creating BLoCs. We also really wanted to limit the exposure of Rx because in the past we had experienced deterioriation of code quality due to the misuse of Rx. I decided to try to create an abstraction which would allow developers to still think in terms of events and states and create reactive applications but without having to interact with Rx. At its core, the library was intended to facilitate testability, traceability, and predictability which could scale from a few developers to hundreds of developers.

In your day to day work, do you create more blocs or cubits?

In my day to day, I tend to create more blocs because for most production applications I've found it's important to have the ability to trace all state changes (including events) in the application for debugging, logging, and analytics. I still use cubits a lot in my side projects since they are simple, quick, and lightweight and I can choose to refactor to blocs as needed without much overhead.

What are other state management options you found and liked? What about e.g. mobx_dart?

I like Provider and ValueNotifier as a simple state management solution. RiverPod and StateNotifier is another great combination that I've experimented with.

Do you have any big plans, e.g. creating some new package?

I do have some exciting plans around new tooling which will hopefully help speed up development and improve consistency & code quality so stay tuned for more details.

What's your opinion about form_bloc?

Forms are something that people feel that needs to be optimized with some library but there's always a lot of edge cases and exceptions that eventually become an obstacle. I think form_bloc is a great package which was developed by one of the members of the community. In general, I have found that forms are very tricky because many abstractions fall apart when it comes to edge cases and custom behaviors. We created a tiny Dart package called formz as part of the Chicago Flutter organization which attempts to standardize how form inputs are represented and validated but there's definitely a lot of room for improvement especially when it comes to integration with Flutter.

Best package you have discovered lately is… ?

I've really been enjoying the `integration_test` package and am hoping to integrate it into more of my projects (no pun intended).

One feature you crave the most in Flutter or Dart is…?

I would really love it if Dart had Data classes and if there was better support for generic type inference in Dart

The talk

Cubit: Advanced Topics

Discussing the experience of building an app & CLI to manage Flutter SDK versions. Experiences with Flutter Desktop, and why Dart & Flutter is the future of dev tools.

Read more

Implementing live whiteboard with Flutter and Firestore database

In this blog post, we will explore a possible implementation of such a whiteboard using Flutter to create a mobile application and Firestore database as backend.

Using Flutter in the Enterprise environment

Building one of the biggest Fintech applications in Flutter was very challenging. Jakub Biliński is responsible for the architecture, approach and development of a new version of the mobile application for strategic and corporate clients of the bank. In his, he shows how his team had to adjust to FinTech security compliance,  write a custom HTTP client, maintain application scalability and more.

The Powers of Immutable State

Managing a state can be a stressful ordeal if you dive into it without any thought. This kind of monstrous code can be tamed with the principles of immutability. And as if cleaning your code wasn't enough in itself, immutable state comes with a handful of hidden superpowers! Come along for the journey to find out how to use them.

Why Firestore, Part I: reasons to love it

Firestore & Firebase suite are great technologies. They allow us to build some features really fast. However, Firestore has also many pain points that outweigh the pros in most of the more advanced cases.

Case studies



.NET Core


We build communities

No match for you?

No problem, send us your resume, we constantly look for new talents. Write on office@leancode.pl