Frank Moreno

@pythonhubpy  The idea behind `riverbloc` is to avoid the dependence on `context`, not to be more efficient because the difference won't be relevant. Thanks for consider my package as a...

@felangel, I'm open to your ideas to drive `riverbloc` to be a package that can be integrated to [https://bloclibrary.dev/](https://bloclibrary.dev/) if you agree. I maintain it continuously and adding more functinalities.

@omidraha please could you say how fountain can help in this feature request? `fountain` has different approach to `riverpod` to inject dependencies and differs from `bloc` in that it handles...

`StateNotifier` is very similar to `Cubit`, but `Cubit` is asynchronous. In `riverbloc` package, you can find a `BlocProvider` that works with both `Bloc` and `Cubit` (or any `BlocBase`).

@lhmzhou There is no advantage in the async vs sync. The real advantage is `onChange` that let you track how your states change. I could be implemented for `StateNotifier`, but...

I agree with @e200. The `FlowBuilder` or `FlowController` could have a field `allowPop`.

@tyranron GraphQL use typically JSON but could use anything. The server response and the client variables could be serialized in CBOR too. In fact I'm looking for this feature too...

@grantperry Sometimes I use GQL in MQTT or NATS for small queries. It also could be UDP to speed up the data transfer, but it is more used in local...

@grantperry @tyranron the solution is not changing the Juniper core, but also the http adaptors (juniper\_rocket, juniper\_warp, etc). In the end, all adaptors call to `juniper::execute` after parsing JSON data,...

@grantperry yes, but if it can be serialized when the server response, it also can be deserialize when the client make a request. For IoT is important both cases. I...