Response to provider scalability.

[modulovalue]

This started out as an E-mail and a response to this

Hey Remi,

Firstly, I admit that my response, especially around your package provider, may have sounded a little derogatory. That's not what I meant to do. I highly value your work, I've seen the contributions you have made (and are trying to push forward) and I am completely on your side.

Let me give you my concerns (in no particular order) from the perspective of someone evaluating provider for the use as a state management solution.

1. Are there any samples that show complex use cases?

#65 I believe, no.

2. Can I be assured that Google has committed to this package and it is a common best
   practice and will receive support in the future?

No, it is a community package, one wouldn't want to bet his services future success on the contributions of a single person. contributors

3. Does it actively encourage me to write a great architecture that I can, in case of new requirements, easily adapt to other frameworks?

No, it probably isn't even 'provider's responsibility. But if it can do that, it has to be proven by providing examples on how to do that.

To be more concrete, here is a real-world example:

Your entities are:

• a list of messages with id's
• a list of favorite id's
• a condition whether only favorites should be shown
• a string to filter the currently shown list of messages

(insert network handling if not complex enough)
(insert storage if not complex enough)

This logic should be independent of Flutter and the UI shouldn't concern itself with the details but only present data. How can a beginner quickly achieve that with flutter? The answer is easy if he is willing to break one of the fundamental principles of software engineering.

A class should have one and only one reason to change, meaning that a class should have only one job.

I'll elaborate more on that if requested.

--

I admit that I could be asking for too much, good architecture is only achieved with great craftsmanship. But flutter should instill confidence by showing that at least its team has figured this problem out.

I spent the vast majority of the last 16 months constantly refactoring my app as it grew (as a rough metric, to a 100KLOC). I put trust into the best practices of early 2018 of using setState (that was a bad decision). I moved onto bloc's, and it quickly became evident that they are too verbose (which was recently solved by flutter_hooks) but the single-frame issue still is a problem.
I confidently used RxDart but some bugs made it impossible to treat Observables as a Monoidal structure (and these bugs are not present in RxJS).

I'm currently happy with where I'm at and I have roughly described my solution in the first link but it shouldn't have taken me that long. There are proven best practices for all established frameworks but flutter is lazily avoiding that problem by telling its users they are free to use what they want. That might be acceptable but it is not ok.

--

What do the biggest non-trivial open source flutter apps put at the center of their app:
InKino Redux
Openbook Nothing. InheritedWidgets and a mostly flutter independent service provider.
Kalium Event Bus!

I don't want to offend anyone but there is a reason they do that. Mainly because of established software engineering practices that start to make sense once the app grows beyond a certain size.

I hope my concerns have been stated clearly this time. Please let me know if I'm wrong. I don't have all the answers and am more than willing to admit if I am wrong.

[rrousselGit]

Thanks for your detailed answer!

I'm not sure how the lack of complex example using it or that Google isn't its author has any impact on scalability. But I'll try to answer as much as I can.

1. Are there any samples that show complex use cases?

I apologize for that.
There are some complex apps built with it, sadly they are not public.

I plan on correcting that with the upcoming release of v3 and an article I'm working on.

2. Can I be assured that Google has committed to this package and it is a common best
   practice and will receive support in the future?

While I do not represent Google in any way, I suppose that we have a relationship based on trust.

Google was committed to making their version of provider named provide.
I just passed there google/flutter-provide#3 and expressed my concerns about the sanity of their approach and managed to convince them.

provider is under the MIT license. They could freely have forked it and make it their own, or take my feedback into consideration to improve their version.

3. Does it actively encourage me to write a great architecture that I can, in case of new requirements, easily adapt to other frameworks?

It does and is in fact very strict about it – especially with the new version that should be released relatively soon.

The release will be accompanied by an article that explains this further, but TL;DR, provider acts as a bridge between your different entities to force a few things:

• an uni-directional dataflow.
• a declarative API
• an abstraction layer
• reactivity

If your app does not have all of these, then you ejected provider for something different.

provider does not claim to solve all state management problems. It exists to complement existing ones – hence the built-in support for Listenable and the partnership with Mobx (and maybe flutter_bloc soon) and why I made flutter_hooks.

[modulovalue]

I agree with everything you said.

One last thing. It might be too much to ask, but could you try to make any best practices developed by the analytics team in regards to provider and reusing code with AngularDart public?
One of the reasons why blocs were so accepted, I believe, is that the analytics team has given their stamp of approval by inventing them. Any 'official' words by Googles arguably most important Team would really send the signal that I'm looking for, for the community.

And if they're still using BLoC's the way that they were introduced, just now with provider, then there is still the single-frame isssue It would be useful to know, how they are dealing with that.

I don't see a way how that issue can be cleanly solved with the current state of Streams and have a way to share code between flutter and angular. Do you agree with me on that observation?

Thank you.

[rrousselGit]

provider has nothing to do with sharing code with Angular.

That's a situation where one might want to use provider + something, be it Mobx, redux, or something else.

But I'd argue that flutter_web will soon solve this question.

[modulovalue]

I wrote this response under the assumption that your intent was, besides developing this package, showing the community a better way to develop flutter applications (and solving common problems that occur while one is learning flutter) There are many culprits that can easily be avoided and to make flutter flourish around new developers imho they have to be eliminated as much as possible.

Taking that out of the way, I also believe provider is the best way of passing data to subtrees. Thank you for your work and I'll make sure to check out v3.