Anyone using bloc in production?

[sawankumarbundelkhandi]

Similar to: reactiveui/ReactiveUI#979 PrismLibrary/Prism#1016 orientechnologies/orientdb#4806 brianegan/flutter_redux#86

Use the following template:

If available on stores iOS: Android:

If open source Source Code:

Your opinion Version: ? Years of experience: ? Good: ? Bad: ?

Thank you very much!

[jorgecoca]

We do! But of course, we/Felix also wrote the package... we are very happy with the results so far, and as you can see in the examples/docs/articles, we are investing more and more to make this package as good, easy, performant and high quality as possible ;)

[nhwilly]

The impressive part of this package is the documentation and fully filled out examples. The number of "counter" apps that really don't tell you about localization, authentication and other real problems has just swamped the search process.

I intend to build a complex app with this (after trying 3 others) and feel good about the chances of success after see the docs and samples.

Thanks so much for sharing this.

[jorgecoca]

@nhwilly let us know about your experience! we hope you find this package very easy to use 🤞 but if you have any issues/questions, we will gladly help you!

[warriorCoder]

@nhwilly Can you define "complex app" for me?

I've also been considering adding complexity to the sample apps. Mainly I'm thinking of extending the todo app to include a layer above the todo's called projects, adding side navigation and a firebase login with Google, Facebook, Phone Number, and Email.

Personally, I feel like that would constitute a complex app.. would you agree or are there other things you think it should have?

[nhwilly]

I'll just point out some things that I think I'll have to work out:

• Centralized web api calls that can handle an authentication failure (401), prompt the user for a password if the refresh token fails and then automatically try the operation again.
• A side drawer menu that deals with permissions for presenting some menu items.
• A reusable crud block to handle the basics stuff from so many items
• A barcode scanner (this can be done with ML, I think, if they've opened up the camera stream.)

Those are just some of the things that come to mind on the fly here.

[nhwilly]

Saw some recent changes. They look great.

[ftognetto]

I’m just about to start a porting of an app from ionic to flutter and after digging around about state management in flutter i choosed to use flutter_bloc because is the only one which gave me some practical examples about authentication or managing long lists. Thank you!

[craiglabenz]

I'm grinding every day on a soon-to-be production app using flutter_bloc. Unbelievably happy so far!

[ammaratef45]

I wonder how much I time I would spend to refactor exacting repo into using bloc. Any Ideas? I'm mainly talking about https://github.com/ammaratef45/Attendance if you may take a look.

[felangel]

@ammaratef45 I think you can do it in less than a week. If you decide to give it a shot, I’m happy to help 👍

[ammaratef45]

@felangel I will be glad to have your help I will use this issue to track the work ammaratef45/Attendance#88 Can you leave some instruction and hints? PRs are very welcome too.

[ammaratef45]

I've started refactoring with the help of @felangel I hope is facilitates unit testing and maintainability, I will write a blog post about my experience with it and share it with you guys next week 👍

[bobwiller]

Love the recent updates - especially w/the Listener and Tree classes. One area I am still struggling with from a design perspective is how "big" or "small" a bloc should be. I am getting to the point where every piece of UI that has its own state has its own bloc, which seems like a lot of overhead - would love to hear from everyone else if they have any lessons learned or best practices around bloc "size" and scope?

[felangel]

@bobwiller thanks for the positive feedback! We really appreciate it 😄

Regarding your question, I would love to hear more about the overhead you are referring to and some sample use-cases you have in your own applications.

In general, I think it's a tough question to answer but I would say a good rule of thumb is if your bloc's state has properties that are unrelated, then it's probably managing state that is too broad and can be split into multiple, smaller blocs. I would try to keep blocs as small and as focused as reasonably possible (a bloc should only manage state for a single feature) but you should definitely not feel like there's a lot of overhead associated with managing these blocs; that might be a sign that your blocs are too small.

It'd be awesome if you can share some concrete use-cases and we can try to give some suggestions about how to break them up into one or more blocs 👍

[erwintan96]

hi @felangel, may I ask your opinion about this article https://medium.com/flutterpub/effective-bloc-pattern-45c36d76d5fe?

especially this part :

You can clearly see that multiple BLoC providers are nested. Now you must be worried that if you keep adding more BLoCs in that same chain then it will be a nightmare and you will conclude that BLoC pattern cannot scale. But let me tell you that there can be a special case(a BLoC only holding the UI configurations which is required across the app) when you need to access multiple BLoCs anywhere down the Widget tree so for such cases the above nesting is completely fine. But I would recommend you to avoid such nesting most of the time and provide the BLoC from where it is actually needed.

because i read a lot of articles about BLoC Pattern and I was confused. Maybe your opinion can make me not confused anymore btw, this package is cool and has great examples! Thank you so much :beers: :beers:

[felangel]

Hey @erwintan96 👋 I think overall the article is pretty good. For the specific section you mentioned, I would add that you should always keep state/blocs scoped to the part of the widget tree that needs it. Avoid making all blocs global unless they need to be. In addition, if you’re using the bloc library, you can use BlocProviderTree to avoid nesting when providing multiple blocs.

Thanks for the positive feedback and hope that helps! 👍

[erwintan96]

hi @felangel :beers: , i want to ask again.. why did you use stateless widget rather than statefull widget on your example https://medium.com/flutter-community/flutter-todos-tutorial-with-flutter-bloc-d9dd833f9df3 at detail screen, and etc.. you used bloc on detail screen but you didn't dispose it.. Is it okay? stateless widget doesn't have dispose method.. :sweat_smile: :sweat_smile:

[felangel]

Hi @erwintan96 the Detail Screen didn't create the bloc, it just accessed it using the BlocProvider so it does not need to be stateful and does not need to dispose the bloc. The bloc was created and disposed in the Home Screen. Hope that helps 👍

[ftognetto]

Hi @felangel i’m starting the porting of a social network app from ionic to flutter.

What do you think about bloc for global state management?

For example i will have to implement a bloc for authenticated user, one for the posts, one for notification, one for logged user followers/followings and so on, and many of them should stay at the top of the app widget tree to let app to be synced. Is this good for performance?

When I press like in a screen and then navigate to another screen where there is the same post I have to find that post already liked or when I follow someone and then I navigate to my profile I have to find the same followed user.

I normally used redux for this kind of central state management but now I would like to manage everything with bloc and not only use it for local state and then falling back to redux for global state.

Thank you 🙏 ☺️

[felangel]

@quantosapplications that should be fine if you need them to be globally available. Only the portions of your app wrapped in BlocBuilder will be rebuilt when the respective bloc's state changes 👍

[ftognetto]

Thank you @felangel, so you do think that there are no worries about putting 5/10 different bloc on top of material app? And also do you think that this is a good design pattern?

I’m stucked on where to put blocs, if is more correct a bloc-per-page way or design one bloc every big functionality of the app.

[felangel]

@quantosapplications I think it's fine as long is it makes sense. Things like AuthenticationState make sense to be global because they have an impact on the entire application. I would argue that other things like followers/following should probably not be global because they aren't needed globally. If you're logged out of the application that state probably doesn't make sense. I would always define and provide the bloc at the closest common ancestor of all the widgets that rely on that state. It might help to draw your widget tree and circle all widgets that rely on the state. Then, you can find their closest common ancestor and provide the bloc there. Hope that helps 👍

[x1z7]

I’m just about to start a porting of an app from ionic to flutter and after digging around about state management in flutter i choosed to use flutter_bloc because is the only one which gave me some practical examples about authentication or managing long lists. Thank you!

You might wanna update your avatar as well :)

[LukeBrumfield]

I am working with Bloc to recreate an app done in react native to an app that have mobile and web versions. I am using flutter and angulardart, hopefully using just flutter and its web version when the development preview goes prime time. It is a very simple app in terms of what it does on the front end (login and submit small bits of data with a more complicated backend). Maybe 4 screens when finished and all the state management shown in the firebase login example.

[azimuthdeveloper]

I'm about to start transitioning from my Xamarin Forms application to flutter, using this package. I'm super keen for any refactoring help that anyone could offer.

It's a huge change for me (learning dart etc) but I just can't use XF any more. So many breaking changes in the latest release ;_;. Plus that hot reload!

[nhwilly]

I had the same problem with Xamarin Forms. Love the idea and the MS team, but I fought the tooling for a year before I gave up. I've actually been working for longer than I'll admit on this, and Xamarin was over 1/2 the time wasted.

This library is very cool and so far it's working great for me. If you haven't done any reactive programming, that'll take some getting used to. Enums are a bit limited and I've just run into a nasty DateTime parsing problem/incompatibility with the ASP.NET Core backend.

I'm super happy with the language, the tools and especially flutter_bloc.

Fabulous community, too.

[azimuthdeveloper]

@nhwilly I'm intersted in that date/time parsing incompatibility issue you're experiencing. I reckon I'd hit that sooner rather than later with what I'm doing...

This is off topic, but one thing I've had a hard time trying to work out is how to do dependency injection in Flutter... Coming from Xamarin Forms with Prism, you'd register your interfaces and services at runtime, and then inject them into your constructors as needed. I can't see an equivalent way of doing this in Flutter or Flutter bloc (I could be missing something).

I also have a hard time conceptualising how objects are created in Dart. In C# its var boom = new WhateverClass(). I don't think I've seen the "new" keyword used in Dart just yet (I could be missing something again, its incredibly early days).

[nhwilly]

Easy stuff.

There is no new keyword. That went away some time ago. You’ll get used to it.

There are some great initializer shortcuts, including some new ones for collections.

DI is basically done using Bloc Providers and other things. There's a package called ‘get_it’ that behaves like ‘Splat’ in the C# world.

I opted to follow this package, but it can be confusing...

I'll post my date fix later tonight...

[nhwilly]

public class DartDateTimeConverter : IsoDateTimeConverter

    {

        public DartDateTimeConverter()

        {

            DateTimeFormat = "yyyy'-'MM'-'dd'T'HH':'mm':'ss.FFFFFFK";

        }

    }

Note the format only has six positions for fractional seconds.

[nhwilly]

Stupid browser...