devonfw-forge / devon4flutter-non-bloc-arch

A guide aiming to bridge the gap between the absolute Flutter basics and clean, structured Flutter Development
https://github.com/devonfw-forge/devonfw4flutter/wiki
309 stars 37 forks source link

Separate the BLoC Pattern and the bloc library. #1

Closed miyoyo closed 4 years ago

miyoyo commented 4 years ago

Hey, first of all, great work! Good slab of text that details the development process quite accurately. However, there is one nitpick I cannot ignore, and it is the difference between the BLoC pattern and the bloc library.

The library, fundamentally, is actually something many would describe as "Redux, but with smaller stores.".

  1. It maps almost 1:1 in the items you interact with
    • Events : Actions
    • "bloc" : Store
    • mapEventToState : Reducer
  2. Uses a single stream output, exactly like Redux (Would this mean that Redux.dart is BLoC?)
  3. One could argue that wrapping the input in an Action violates the 'Components should send inputs "as-is"'

There is even a proper description and example of a bloc as a source!

This line is, as far as I can tell, not accurate. The library is similar, but the pattern itself is not. Redux stands for a single source of truth modified by clearly defined, "static" actions that predictably change said single source of truth. BLoC stands for the power of streams, both in and out, in some cases even inside.

I'm not saying that the library is bad, it's widely used and proves to be reliable, however, it is a car pretending to be a bike.

tenhobi commented 4 years ago

Let me copy the rules from Paolo Soares talk at DartConf (January 2018):

  1. Input and Output of the BLOC are simple Streams and Sinks.
  2. Dependencies must be injectable and Platform agnostic.
  3. No platform branching is allowed
  4. Implementation can be whatever you want as long as you follow the above rules.

And UI design guidelines:

  1. Each "complex enough" component has a corresponding BLoC
  2. Components should send inputs "as is"
  3. Components should show outputs as close as possible to "as is"
  4. All branching should be based on simple BLoC boolean outputs

Implementation from @felangel does not violate any of these rules IMO.

Yes, it reduces the number of input and output streams to 1 and it uses events and states as a representation of what is going on. It might be closer to the Redux than the general BLoC, but why is that an issue? If that works for people's benefits, I do not care.

miyoyo commented 4 years ago

Using that rethoric, Redux is also BLoC, why is it separate then? It uses functions as input, sure, but the library also did that up until recently, so clearly you wouldn't care either.

The inputs are transformed, they must be put inside of an Action before they can be ingested, thus not falling in line with rule 2 either.

The issue is that by claiming that it IS BLoC, and, by your own admission, being able to claim that It might be closer to the Redux than the general BLoC, people without knowledge of flutter (which are the focus of this document) will be mislead.

I am not against it being put in this document, I am against it being representative of what BLoC is.

felangel commented 4 years ago

@miyoyo I would ask that if you have a problem with the bloc library that you please open an issue in the bloc repository. This project is not the right place to discuss this in my opinion.

In any case, BLoC is a design pattern which has several rules outline above by @tenhobi. I'm not sure why you're so against acknowledging that the bloc library conforms to those rules and consequently the design pattern as a whole. While it's true that the bloc library enforces a few rules beyond what the raw BLoC design pattern outlines (namely single input/output), I don't think it makes it non-conformant with the BLoC design pattern as a whole.

On the other hand, the three principles of Redux are:

  1. Single source of truth
  2. State is read-only
  3. Changes are made with pure functions https://redux.js.org/introduction/three-principles

The bloc library clearly violates the very first principle.

Ultimately, BLoC is a design pattern like MVVM, MVC, etc...there are multiple frameworks/libraries that help implement those design patterns. I think it would benefit you to re-evaluate the library with an open mind. If you compare your current BLoC implementation with one using the bloc library I think you'll find they are quite similar. You can even take a look at the evolution of state management at BMW and how we came upon the bloc library after having used RxDart to implement BLoC at https://slides.com/felixangelov/state-mgmt-with-bloc-library.

Cheers!

miyoyo commented 4 years ago

I do not have a problem with the library, as I often stated, I have a problem with it's name, and with it attempting to take over the meaning of BLoC.

And no, None of the BLoC implementations I ever had were redux-likes.

felangel commented 4 years ago

@miyoyo the meaning of BLoC is business logic component and it is defined by the rules above. The whole point of design patterns is the implementation details should not matter. If you want to keep implementing the BLoC pattern using pure RxDart that's fine but it does not invalidate other implementations. I've had conversations with developers on the Flutter team and they've had no problem with the bloc library and have agreed to include it under the BLoC State Management Options. Trying to enforce a single way to implement a design pattern does not benefit the community so I would really appreciate it if you would please stop. Thanks 🙏

miyoyo commented 4 years ago

I will not stop and drop distinctions between the pattern and the library, they are two different things and ignoring the distinction between both by having the same name only leads to the death of the original.

All I ask, is that the text here increases distinctions and states that, instead of the pattern, every distinction and comparisons to other things are done purely based on the library and it's redux-like implementation.

narcodico commented 4 years ago

Have a break, have a KitKat!

Fasust commented 4 years ago

Hello Everyone,

Sorry for joining this issue so late. I feel like the discussion in this issue went a bit of track. First of all, @miyoyo , I hear your criticism. If I understand correctly, you created this issue not start a discussion over the Bloc-Package and its quality. You just wanted to point out that I did not clarify the difference between the original pattern defined by Paolo Soares and @felangel 's Bloc-Package.

I will go through the BLoC Section of the guide and make this distinction more clear.

They are two separate things. One is a pattern, the other one is an implementation of that pattern.

Regards, Sebastian

Fasust commented 4 years ago

I believe this issue is resolved, so I'll close it for now 😊