使用flutter_bloc库有什么缺点 [英] What are disadvantages of using flutter_bloc library

问题描述

有很多实现BLoC模式的版本.其中之一是Felix Angelov的flutter_bloc.在其中一种社交媒体上，我遇到了关于flutter_bloc的声明对于该项目而言，它不是一个很好的选择，而应该选择另一个BLoC或另一个状态管理.

实际上，这是一个小型的标准项目，分为领域，应用程序，基础结构和表示层.没什么特别的.

所以抱怨选择错误的那个人说的是flutter_bloc:

1. 隐藏实施细节
2. 保留一个状态对象(为什么，如果它确实起作用，那么您就不会这样做)
3. 暗示了使用 mapToState 的首选方式-使用 async 生成器而不是流

如果有人可以详细说明此声明并列出使用flutter_bloc的真正缺点，我将不胜感激.例如，对我来说，要点1)隐藏实现细节是一个优势，因为我不必直接处理RxDart.但是也许我错过了一些东西.我没有完全得到第2点.

解决方案

flutter_bloc 的工作方式是将输入明确映射到状态，否则将无法正常工作.

我想通过保留状态对象"来表示.您的朋友的意思是，任何在任何时候收听che BLoC实例状态的人都将返回相同的状态，这与使用 rxDart 的 BehaviorSubject 获得的状态相同.

我对 flutter_bloc 的个人看法是，在复杂的情况下它可能会过于局限，因为它允许创建仅处理一个输入和一个输出的 BLoC .

>

让我为您展示我在谈论这个话题时所举的典型例子.

假设您在屏幕的上半部分有一个带有轮播的页面，上面有一些卡(假设这些卡是借记卡).屏幕的后半部分显示带有该卡当前余额的标签，以及使用该卡进行的付款清单.

让我们说，您需要从两个具有不同响应时间的api中检索这两个不同的信息(余额远比付款清单快).

在这种情况下，我会使用一个 BLoC :

• 输出卡列表的 stream
• 输入接收器进行卡选择
• 输出 stream 保持平衡
• 输出 stream 支付清单

滚动轮播时，您下沉选定的卡，然后这两个小部件(余额和列表)将侦听它们自己的流，并相应地更新为信息加载状态和数据.

如果您想使用flutter_bloc进行相同的操作，则必须将其拆分为三个不同的 BLoCs ，以确保:

• BLoC 服务卡列表
• BLoC ，其中以卡为输入，余额为输出状态
• BLoC ，其中有一张卡作为输入，而付款清单则作为输出状态

我们可以肯定地说，出于单一责任和可测试性的原因，要针对三种不同的信息使用三个独立的 BLoC ，但是(同样，这是我非常非常个人的看法)最好将相同页面/功能的内容包装在相同的 BLoC 中.

此外，在某些情况下(不是这样)，您必须执行 BLoC 到 BLoC 通信，这意味着要具有 BLoC 取决于其他 BLoC (在某些情况下，这让我有些恐惧)

我喜欢按功能对 BLoC 进行分组.

在上述情况下，所有这些都是与借记卡信息屏幕相关的，如果我需要导航至一些详细信息，则可以将所有逻辑集中在一个 BLoC 中.

>

如果BLoC具有其他 BLoC 所共有的部分功能，则将其提取到通用的 BLoC 中，并使用 BLoC进行 BLoC 通信(例如此).

请注意，由于使用 flutter_bloc 强制，即使没有必要，您也会具有多个 BLoC ，因此您会有更高的更改必须执行 BLoC 到 BLoC 通信的问题.

同样，我们可以说这个答案可能是有偏见的，因为它标明了我的一些个人观点，因此应将其视为一堆考虑因素，而不是法律".我很高兴收到不同意我的人的反馈，因为我的 BLoC 哲学仍在进步，并且我经常对哪种最佳方法感到矛盾！

There are many versions of implementation of BLoC pattern. One of them is flutter_bloc by Felix Angelov. On one of the social medias I came across of the statement that flutter_bloc is not a good choice for the project and another BLoC or another state management should be chosen instead .

Actually it was a small standard project separated into layers:domain,application,infrastructure and presentation. Nothing special about it.

So the guy who complained about the wrong choice was saying that flutter_bloc:

1. hides implementation details
2. retains a state object (why, if it is truely functional then you wouldn't do this),
3. implies a preferred way of using mapToState - to use async generator rather than streams

If someone could elaborate on this statement and list the real disadvantages of using flutter_bloc I would be very grateful. For example for me point 1) hides implementation details is an advantage because I do not have to deal direcly with RxDart. But maybe I am missing something. I do not get point 2 completely.

解决方案

flutter_bloc works by explicitly mapping inputs to states and cannot work otherwise.

I suppose that by "Retains a state object" your friend is meaning that anyone who listens to che BLoC's instance state at any moment will get back the same state which is the same thing you get by using rxDart's BehaviorSubject.

My very personal opinion about flutter_bloc is that it can be too limiting in complex scenarios because it allows creating BLoCs that deal only one input and one output.

Let me show you the typical example I bring to the table when talking about this.

Suppose you have a page with a carousel on the top half of the screen with some cards (let's say those are debit cards). The second half of the screen shows a label with the current balance of the card and a list of payments made with that card.

Let's say that you need to retrieve these two different pieces of information from two different apis with very different response times (the balance will be far faster than the payments list).

For this situation I'd use one BLoC with:

• output stream for cards list
• input sink for card selection
• output stream for balance
• output stream for payments list

When scrolling the carousel, you sink the selected card, then the two widgets (balance and list) will listen to their own streams and update accordingly to the info loading state and data.

If you wanted to do the same thing using flutter_bloc you'd have to split this in three different BLoCs for sure:

• BLoC to serve the cards list
• BLoC that has a card as an input and the balance as an output state
• BLoC that has a card as an input and the payments list as an output state

We can surely talk about having three separate BLoCs for the three different information for single responsibility and testability reasons, but (again, this is my very, very personal opinion) in some cases I think it would be better to wrap stuff for the same page/feature within the same BLoC.

Plus, in some cases (not this), you'd have to perform a BLoC to BLoC communication, which means having BLoCs depending from other BLoCs (which kinda scares me in some situations)

I like to structure my BLoCs grouping them per feature.

In the case above, these are all things relative to debit cards information screen, and if I need to navigate to some details I can do so keeping all my logic centralised into one BLoC.

If a BLoC has a part of features that can be common across other BLoCs I'll extract them in a generalised BLoC and go with the BLoC to BLoC communication (like this).

Note that since using flutter_bloc forces you to have multiple BLoCs even when it might not be necessary, you'll have higher changes of having to perform a BLoC to BLoC communication.

Again, we can say this answer might be biased, since it stars some personal opinions of mine, so take it as a bunch of considerations and not as "law". I'd be happy to receive some feedback from whoever disagrees with me, because my BLoC philosophy is still progressing and I'm often conflicted about what can be the best approach!

这篇关于使用flutter_bloc库有什么缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！