jacobtipp / bloc-state Goto Github PK

I just wanted the bring up this feature request that doesn't exist in the original bloc ecosystem and listen to your perspective on it.

As things are, it's not possible to apply transformers on the stream that includes all events for a given bloc without using ad-hoc, non-declarative solutions that are hard to read on felangel/bloc. Considering all event handlers mutate the same state which belongs to a given bloc instance, this shortcoming eliminates one of the primary use cases of sequential event handling, concurrency, and using event driven architectures in the first place: write blocks.

I.e: If one event increases the stock levels, and the other consumes the stock, we are unable to ensure the second event is processed after the first one by leveraging the expressed bloc API. The suggested workaround to this problem is doing something similar to this:

class ExampleBloc extends Bloc<ExampleEvent, ExampleState> {

  constructor() {
    super(new ExampleInitial());  
    on<ExamepleEvent>(_onEvent, transformer: sequential());
  }
  
  async  _onEvent(event: ExampleEvent, emit: Emitter<ExampleState>) {
      if (event is ExamepleEventOne) { return await _onExamepleEventOneevent, emit);}
      else if (event is ExamepleEventTwo) { return await _onExamepleEventTwo(event, emit);}
      else if (event is ExamepleEventThree) { return await _onExamepleEventThree(event, emit);}
  }

....
}

While this is usable, it's in my opinion clunky and needs commentary on why the code was organised this way to be readable. I don't have any suggested APIs for this use case but still wanted to bring it to your attention.

Best

First of all, let me share my thanks for attempting to undertake a huge project like this. We are in a situation where we need to port a huge flutter application that makes very extensive use of most of the unported packages and newer features of the bloc ecosystem to js and react, and bloc-state has been a life saver.

One question (as the first one of potential many others), I would like to know if anything similar to the BlocBuilder pattern within react-bloc package is available or in the works. It seems like while listening to a bloc to handle side-effects are possible, there is no component that enables rebuilding according to changing state. Is this by design?

Best

Description
react-bloc is currently not compatible with react fast refresh

Steps To Reproduce

1. add a BlocProvider to your react app
2. update some code in the Bloc you are providing

Expected Behavior
Whenever code changes for a Bloc, fast refresh should remount a BlocProvider and recreate a new Bloc instance that has the new code changes.

Currently, any code changes made to a Bloc are not reflected with fast refresh.

Description

Add a view agnostic devtools implementation based around a BlocObserver

Desired Solution

A clear and concise description of what you want to happen.

• The devtools should have its own markup without depending on vue, react, angular to update,
• The devtools should be isomorphic. It should not cause any issues in non browser environments (SSR).
• The devtools should be a mixin for BlocObserver. An app should be able to conditionally wrap their own BlocObserver in a mixin without having to extend a devtools class.

Alternatives Considered

None