u/Nowm

First you should read the Flutter official intros for a broad feeling, https://flutter.dev/docs/development/data-and-backend/state-mgmt/intro

For state managements frameworks, they all provide decent/lengthy tutorials,

https://bloclibrary.dev/

https://mobx.pub

etcs

For BLoC Patter,

https://www.didierboelens.com

A decent tutorial site, cover a broad range of things.

https://resocoder.com

Furthermore, architecture wise, the Provider package is basically the "defacto" for denpendency injection regardless architecture, and you will found its widely used in other libraries/patterns.

The simplest is MMVM, in that architecture, you can optionally use Mobx library for state management.

if you want to pursue Clean Architecture + TDD, I would suggest FRP(with or without RxDart) + BLoC Patter. You can implement it yourself, or you can checkout the Bloc library (with a bit spice of reduxyy).

if you come from web dev background, Redux is not a bad option.

about tdd tutorial https://resocoder.com/category/tutorials/flutter/tdd-clean-architecture/

Use the search bar mate! the search bar is really your best friend!

Personally, I use TDD on iOS, pretty new into the flutter world i guess.

This question has been asked over and over again....

Yes, the Provider is simply, at core, a dependency injection package.

It's save you the trouble to write the bloc_provider yourself.

You have reposted my answer as if you wrote it everywhere on dev.to, twitter, your own website! You cannot simply add a title, and treat it as your own writing!

https://dev.to/sadmansamee/bloc-or-provider-flutter-state-management-dilemma-3bmi

You need give proper attribution, or please take the article down!

Your action is hurting the open community.

I took an hour to write the answer out of kindness to help new flutter developers. NOT to become your article!

Open source is NOT EQUAL to stealing!

You have reposted my answer as if you wrote it everywhere on dev.to, twitter, your own website! You cannot simply add a title, and treat it as your own writing!

https://dev.to/sadmansamee/bloc-or-provider-flutter-state-management-dilemma-3bmi

You need give proper attribution, or please take the article down!

Your action is hurting the open community.

I took an hour to write the answer out of kindness to help new flutter developers. NOT to become your article!

Open source is NOT EQUAL to stealing!

BLoC pattern and Provider package, neither is architecture.

BLoC pattern is loosely defined, there are a dozen implementations. However the core principal is to use stream in the back, StreamBuilder in the UI, to build up reactivity around stream. I suggest you read Boelens blogs.

The main advantage of stream is that each StreamBuilder listen to a stream, and only update when that stream changes. Therefore stream solved the problem of setState, and achieved clean reactive binding between back and frontend.

One of the BLoC implementation use pure reactive programming in the backend with the help of RxDart, though, both its advantage and disadvantage are RxDart, as your entire backend is programmed "streamfully". The pure BLoC is very flexible, you can strictly implement event_stream-->BLoC-->state_out, you can also value_stream-->BLoC-->value_stream_out

Another popular implementation is the flutter_bloc package, which map event to state, and your backend is not strictly speaking filled with stream. (personally I think its an entirely new architecture that has redux-ish event->state for state management, and MVVM-ish for app structure, BLoC-ish using stream and streambuilder to bind state to ui).

Provider package has two huge part, dependency injection and various value consumption. For example, your can use Provider to inject your BLOC into UI, and simply using a stateless widget. For example, the flutter_bloc package has adopted Provider into its highly customized bloc_providers.

For the most people saying Provider, often means using foundation: ChangeNotifier as a mean of state management. And using Provider.ChangeNotifierProvider to inject and binding to the UI. Thus MVC, MVVM are both very good architectures. It is indeed simple, however, ChangeNotifier has a serious problem, say you have a class A extends ChangeNotifier. And this class A has three state variables, a, b, c. Let's assume in your current page you have 5 elements/widgets listening to classA, then whenever any of a, b, c notify changes, all your 5 elements need to update. Effectively, your UI is reactive to the ChangeNotifier class, instead of member of ChangeNotifier class. Ofc, you can split it as small as possible, some waste in UI update is inevitable. There was a proposal in dart issues that suggests spin-out the ValueNotifier from ChangeNotifier, but its long buried anyway.

Its simplicity is mainly due to the fact that you can maintain the traditional way of programming (non-reactive).

Furthermore, There is another framework which has been ported from the reactjs world, called MobX. It achieve reactive programming different to Stream/RxDart that it reactive to value. In other word, your UI can listen to a member of a class. None the less, you still need programming in the reactive way. But that's another story.

When you chose an architecture/framework, you'd need to consider the nature of your app, and your developers preferences.

For example, does your app need to behave/analysis/record UI events? if so, you need to use a event->state framework like redux, fishdux, flutter_bloc, or do it yourself with BLoC, MobX, etcs.

Further, does your UI need distributed stores? if so, redux is a terrible choice and for instance flutter_bloc is much better.

How many people is in your team? for example, you cannot expect a dozen people all write code the same way without strict guidelines. Simple state management could result in horrific spaghetti in a large team.

How complex is your state, for example, if your view store only have a few members, who cares some duplicated updates in the UI and why not use setState or ChangeNotifier.

And if your backend is filled with streams, why not just use RxDart with BLoC pattern?

I think the problem with Flutter architecture is that we lack articles that explain the core concepts, pros and con, applicable scenarios and extensive examples. But this is dev's life, how nice.

Flutter is a young framework indeed, but it is, so far, one of the most promising way of achieving true cross platform development. Flutter has the potential to share a large percentage of a code base across android and ios, even across mobile, tablet, web, desktop. If you consider the amount of work needed to share a C++ core library across platforms, or ensuring your shared js framework doesn't crash, you would see the future value of dart-flutter.

Meanwhile, the core of flutter is a 2D rendering engine, plus channeling with native platform. Theoretically, it offers us the ultimate flexibility to build whatever we want. there could be a point, the community comes up with entirely different frameworks that adopting a variety of design principals. That's the power of today's web development, pure flexibility and creativity across all platforms without the restriction of browser or a webview.

Flutter is young, please helping developing it. And cross our finger hoping that google won't mess it up this time QwQ.

It really depends on what you are building.

BLoC itself is only a pattern, there are many approch to it, and offering you extreme flexibility on how to architecture.

Generally speaking BLoC meaning you seperate all the logics from view, so that each BLoC group a set of logics. Ideally, a BLoC accepts streams and emmit streams, and anything inside it is reactive programming, i.e. everything is a stream. However, in reality, its often overkill, so there are many simplifications to avoid making everything a stream.

The state management part, is merely a part of BLoC partern, as it emmits streams, and Flutter has this StreamBuilder widget.

Therefore, if your application logic is stream/async heavy, BLoC probably be your best buddy.

Otherwise, Provider+ChangeNotifier, MobX, probably be a better choice.

Also, I the Provider package is high recommended. Even you use BLoC, you can use Provider instead of writting your own BLoCProvider using inherited widgets, like most tutorials said.

npm i yourpackage

thanks

Saying I've wrote an opensource pacakge in swift, how can I publish to SPM? Similarly, is there a place to look up opensouce packages?

"The Flutter Architecture Samples project demonstrates strategies to help solve or avoid these common problems. This project implements the same "Todos" app using different architectural concepts and tools."

http://fluttersamples.com

https://github.com/brianegan/flutter_architecture_samples

Why use state management or why not just setState everywhere

State Management in Flutter by Shubham Kumar

this blog explained well at its beginning.

1. parent setState will render the entire widget tree including its children
2. cannot triger child to child rendering

Survey Article

BLoC - ScopedModel - Redux - Comparison

Top quality survey by Didier, clear illustration of concepts, real example comparisons.

It's satisfying enough to be able to replace android alone QwQ.

This article really should be put in the package readme. so brilliant!

its often with /rss or /index

I also recommend Reeder if you're using mac. For most website, you can add using the website url and let the app searching for a rss feed.

I just tried a side project with the "raw" Provider + Provider&Notifier, It indeed cut-off a lot of boilerplates.

Though, to be honest, I don't feel it is "easier" than Bloc+Rx approach. As there are many cautions that one needs aware of and take extra care both architecture and implementation. For the moment, there is very few established documentations, design patterns, code structure.

I think, its definitely a trend, but if you are familiar or already using bloc+Rx in production. Maybe you want to wait a month or two, until we can establish a tested pattern to be used with Provider.

Thanks for this amazing tutorial!

In the example, you initiated all the providers and build at the top level. Will this affect performance, and violate the principal that providing the provider at the lowest level as possible?

I feels it very similar to MVVM architecture.

sounds promising.

it could become way too complex for production apps.

I am following this tutorial at the moment :) Still in the middle of it. For async heavy app, plus a lot of database CRUD, do you think we can get rid of RxDart entirely? or we still use some portion of Rx?

Its MVVM approach, though a bit off-topic, makes me think what app architecture is best for Provider. As provider is really flexible. Have you found any tutorial using bloc pattern with provider?

It's the Provider package + built-in Provider&ChangeNotifier approach.