Bloc: Don't use skipWhile in _bindEventsToStates()

[PlugFox]

@felangel , please, don't use .skipWhile() for filtering states in _bindEventsToStates() method.
It is not able to fully replace things like 'myBloc.whereType<MyState>().distinct()' in UI layer, but can may cause unobvious behavior.

https://github.com/felangel/bloc/blob/4f2631aec288fc2de5ebaef5fddd8948315031b4/packages/bloc/lib/src/bloc.dart#L191

       }).skipWhile((transition) {
          return state == transition.nextState || _stateController.isClosed;

If u do this, pls, give the opportunity to redefine this behavior with @override or something like this.

PS: thank you very much for the excellent library.

[iKrupp]

It might be nice to have a parameter to define this behavior or a mechanism to override. In my opinion this change makes bloc less flexible

[felangel]

Hi @PlugFox 👋
Thanks for opening an issue and for the positive feedback!

Can you please provide some more context around the use case you have? It would be really awesome if you could create a sample app which illustrates the problem you're having and share a link to it 👍

[PlugFox]

Okey, no problem.
See ya soon)

[PlugFox]

Can you please provide some more context around the use case you have? It would be really awesome if you could create a sample app which illustrates the problem you're having and share a link to it 👍

@felangel
You can try it in flutter web:
https://plugfox.github.io/bad_bloc_feature/

Source code:
https://github.com/PlugFox/bad_bloc_feature/blob/cc57bddde61d90a43802730aa0c613f30aeed74f/lib/ticker.dart#L144

States are not always something new, often it is a repeating old, like "tickers", "void callbacks", constants and singletons.

In addition, the specific check cannot fully perform its function. Since we can "listen" block in different widgets, applying on him .where() and .whereType(). In big BLoC with many parallel events and states this check useless,

We sacrifice flexibility in favor of "protection from the fool" and we get unobvious behavior.

Mb make public _bindStateSubject() => bindStateSubject()
or remove (state == nextState)
or create new interface for states comparison
or create new field "compareState" and then (state == nextState) && compareState

[felangel]

Hey @PlugFox thanks for sharing the sample!

I opened a pull request with some suggestions to resolve the issue. The reason I don't want to remove the equality check from the bloc is because by definition there should be no state change if the state has not changed.

In the case of the example you shared, you were overriding == and hashCode for ImmutableTick (forcing a value comparison) and you were also using a const instance. I would recommend removing the == and hashCode overrides and yielding a new instance (non-const) of ImmutableTick if you want it to be treated as a new state.

I also noticed you weren't using the flutter_bloc package so I added a flutter_bloc_main.dart to show what the flutter code could look like if you used the flutter_bloc package.

Let me know what you think!

[felangel]

@z-dmitri it would help if you could explain why you've 👎 my reply, thanks!

[PlugFox]

I opened a pull request with some suggestions to resolve the issue.

I know where the "problem" is, therefore I created this issue with requesting extension of functionality)

The reason I don't want to remove the equality check from the bloc is because by definition there should be no state change if the state has not changed.

@felangel
As I said above, this is useless in cases where BLoC has many different states, which are subsequently filtered in StreamBuilder. All you do is take away the ability to use BLoC like Redux, without even giving you the opportunity to override this behavior.

Let there be a check, but let be able to redefine the behavior without forking this wonderful library.

[felangel]

@PlugFox might be easier to discuss this on discord. I think there are some misunderstandings and I'd love to hop on a call and talk through everything 👍

The behavior change you're requesting would enable bloc to be used with mutable state which is not desired. In addition, the rule is simply preventing duplicate states from being emitted by the bloc. If a state hasn't changed (as defined by the equality operator) then there is no need for a state change (transition) and for a subsequent UI rebuild. With that definition, you as a developer are in complete control of how states are represented and how equality comparisons are done.

As I mentioned, I would love to get on a call and discuss this so please let me know if that's something you're interested in 👍

[felangel]

@PlugFox any thoughts? Are you willing/able to discuss this via discord?

[felangel]

Closing for now since there has been no response. Feel free to comment if you're still willing to discuss this and I'm happy to reopen it 👍