-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BlocListener/BlocBuilder condition confusion #709
Comments
I agree that sudden breaking changes are bad, and I agree to the enum solution. |
Hi @ezamagni 👋 I'm really sorry for the inconvenience! We viewed #678 as a bug fix rather than a feature request. Are you able to share a link to a sample app which reproduces the issue you're having? I would love to take a look and determine the next steps 👍 I would prefer to see if we can work with the existing implementation but obviously if that's not possible then I'm happy to look at other options. |
Hi @felangel 👋 |
Hi @ezamagni 👋 import 'package:bloc_condition/bloc/bloc.dart';
import 'package:flutter/material.dart';
import 'package:flutter_bloc/flutter_bloc.dart';
void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return MaterialApp(
home: BlocProvider<SimpleBloc>(
create: (_) => SimpleBloc(),
child: MyHomePage(),
),
);
}
}
class MyHomePage extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: Text('Example'),
),
body: Center(
child: BlocListener<SimpleBloc, SimpleState>(
condition: (prevState, currentState) =>
currentState is! ResourceLoadingSimpleState,
listener: (context, state) {
Scaffold.of(context).showSnackBar(
SnackBar(
content: Text(
state is ErroredSimpleState
? state.error
: "Resource loaded successfully",
),
),
);
},
child: BlocBuilder<SimpleBloc, SimpleState>(
builder: (context, state) {
if (state is ResourceReadySimpleState) {
return Text(state.resource);
} else if (state is ResourceLoadingSimpleState) {
return CircularProgressIndicator();
} else {
return Container();
}
},
),
),
),
floatingActionButton: FloatingActionButton(
onPressed: () =>
BlocProvider.of<SimpleBloc>(context).add(SimpleLoadEvent()),
child: Icon(Icons.add),
),
);
}
} Let me know what you think? |
Hi @felangel, Your code surely solves the problem in this very simple example, but I don't see it as an ideal solution: I'm still a bit concerned about the weird semantic that version ^2.0.1 gives to the Let's have a more general ultra-simple example: a bloc with state A and B. Ultimately, I think that with this change, To sum up: the point of this issue is the semantic meaning of Sorry for being pedantic 👋😅 |
Addressed in #733 and will be included in v3.0.0 |
I don't think the original behavior is more intuitive. State HandlingI think the problem is in the way of handling the Some are using the
|
Is your feature request related to a problem? Please describe.
I'm having a hard time dealing with change #678 introduced in 2.0.1 in which the behavior of the BlocListener/BlocBuilder condition parameter was changed.
BlocListener
suddenly stopped workingprevState
andstate
in whichprevState
is not the previous state of the bloc as one would easily guess, but the last state that filtered through this same condition??i have a bloc that emits states Ready, Updating or Failed. I was using a
BlocListener
to catch transitions from the Updating state to inform the user wether an operation failed or succeeded. It was easy:now i have no way to fix this without changing my widget tree or resorting to other workarounds.
Describe the solution you'd like
If there are no valid use cases or motivation for the changes introduced in #678 i would suggest to simply revert it.
I realize this would be another breaking change.
Describe alternatives you've considered
It would be great to have the best of the two worlds without a breaking change, provided that both behaviors are effectively useful.
The user should then be able to select between the two
prevState
meaning with an enumeration like so:My concern is that this solution would be quite difficult to understand.
Another solution would be having a single
condition
accepting a function with three parameters: prevState, state and prevBlocState, but i'm not really fond of this solution.The text was updated successfully, but these errors were encountered: