Package-level declarations
Types
Each Bloc receives a BlocContext.
A Bloc than can be observed by subscribing to state and side effect updates (has a subscribe function).
A class is a BlocObservableOwner if it holds and exposes a BlocObservable.
A StateStream is a source of asynchronous (state) data. It's a hot stream, identical to kotlinx.coroutines.flow.StateFlow without exposing the replayCache and meant to deal with State data (compared to SideEffectStream for SideEffects).
Functions
Creates a Bloc instance using a BlocBuilder.
Create a BlocContext from a ViewModel. The lifecycle will be the "lifecycle" of the ViewModel.
Use this from an Activity or a Fragment to get or create a "Component" without directly involving a ViewModel, e.g.:
Submit a Reducer without side effects to a BlocOwner/Bloc to be run. The reducer will receive the state but no action (since it was triggered "manually", not by sending an action to the Bloc).
Submit a Reducer without side effects to a Bloc to be run. The reducer will receive the state but no action (since it was triggered "manually", not by sending an action to the Bloc).
Submit a Reducer with side effects to a BlocOwner/Bloc to be run. The reducer will receive the state but no action (since it was triggered "manually", not by sending an action to the Bloc).
Submit a Reducer with side effects to a Bloc to be run. The reducer will receive the state but no action (since it was triggered "manually", not by sending an action to the Bloc).
Submit a SideEffect to a BlocOwner/Bloc to be emitted. The side effect will receive the state but no action (since it was triggered "manually", not by sending an action to the Bloc).
Submit a SideEffect to a Bloc to be emitted. The side effect will receive the state but no action (since it was triggered "manually", not by sending an action to the Bloc). Note: the proposal is irrelevant for sideEffect so we set it to Unit
Subscribes to a BlocObservableOwner (typically a ViewModel, a Fragment or an Activity). The subscription is tied to the lifecycle of a LifecycleOwner (normally an Activity or Fragment).
Same as above for a BlocOwner
Same as above for a Bloc
Submit a Thunk to a BlocOwner/Bloc to be run. The thunk will receive the dispatch and the getState function but no action (since it was triggered "manually", not by sending an action to the Bloc). The dispatch function dispatches to the first matching thunk/reducer/side-effect in the Bloc.
Submit a Thunk to a BlocOwner/Bloc to be run. Simplified version with Proposal = State.
Submit a Thunk to a Bloc to be run. The thunk will receive the dispatch and the getState function but no action (since it was triggered "manually", not by sending an action to the Bloc). The dispatch function dispatches to the first matching thunk/reducer/side-effect in the Bloc.
Submit a Thunk to a Bloc to be run. Simplified version with Proposal = State.
The same for Activities / Fragments
Expose a Bloc as LiveData
If a components implements the BlocObservableOwner interface it needs to provide
The assumption is that all Blocs use the same BlocState with the same type parameters (enforced at compile time) but also that they share the same instance of a BlocState (not enforced at all). Under that assumption we only need to observe the state of the first Bloc to observe all state changes. The edge-case that one passes in multiple Blocs using different BlocStates could be covered by using a UUID for BlocState instances and then verify that all BlocStates have the same UUID but that would be over-engineering imo.
Same as above but combine just two Blocs to BlocObservable.