Bloc: Awkwardness around the final build() before BlocListener navigates

[craiglabenz]

Is your feature request related to a problem? Please describe.
BlocListener is amazing, but its dependence on State instances instead of Event instances means that, when the BlocListener is going to navigate us to a new screen, there's always one final, unwanted render first. (Obviously, if the BlocListener is not navigating, but doing something on the page, then this is not a problem.)

If I'm thinking about everything correctly, the current lifecycle looks like this:

  Previous Event ->
  Bloc yields State capable of satisfying `build()` ->
  User triggers an Event that should lead to navigation ->
  Bloc has to `yield` a new state class that maintains everything the previous state knew to successfully render ->
  Widget calls `build()` one final time against this new `State` type
  BlocListener gets a turn, sees this new `State`, and navigates

Describe the solution you'd like

Unless I'm missing something, this series of events would probably be more friendly:

  Previous Event ->
  Bloc yields State capable of satisfying `build()` ->
  User triggers an Event that should lead to navigation ->
  BlocListener goes before Bloc and navigates

Describe alternatives you've considered

Because the BlocListener requires a new State type to indicate the desire to navigate, I so far have been making my should-navigate States subclasses of renderable States. However, that's obviously quite coupled and sometimes actually incoherent in the code.

Should BlocListeners deal with Events entirely, instead of States?

[felangel]

Hi @craiglabenz 👋
Thanks for opening an issue and great question!

You make an interesting point about using events instead of states; however, we only intended BlocListener to be used when a state change triggers a "one-time action".

I think (unless I'm misunderstanding) if you are creating "no-op" states just for the sake of navigation, then you probably don't need to use BlocListener and can just do the navigation as you normally would (in response to an onPressed or other user action).

We didn't mean for BlocListener to be used for all navigation it was only intended for those cases where some async event or business logic needed to happen before we could determine what do to next. Does that help? If you still feel like using events instead of states for BlocListener makes more sense I would love to hear about your specific use-case. 😄

Thanks!

[craiglabenz]

Thanks for the quick response!

That makes sense - coming from Redux land in the web, I'm used to trying to also think of app location as itself just more state, but I think what you're saying probably makes sense.

I'll report back soon after I've tried it out. :smile:

[felangel]

Closing for now but feel free to comment with additional findings/observations and I'm happy to continue the discussion 👍