You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Disclaimer: This is not about changing anything in the DSL per se, this is about rewriting some internals of FlowRedux.
At the moment FlowRedux internally uses Flows as some sort of broadcast channel to publish state changes to the outside but also to the inside (like DSL specific blocks that then trigger) and dispatch actions.
Especially blocks of the DSL (i.e. inState<State> {...}) where cancellation of ongoing background work is required and need to be managed is complex with pure Flows.
@gabrielittner came up with un interesting idea to basically use Jetpack Compose (compiler + runtime) because it is build around State and changes over time on State and has concepts of starting and canceling background work when state changes. That seems to be what we need in FlowRedux and with Compose and @Composable we could probably achieve the same functionality as we have today with our Flow based implementation but with lower complexity (mental overhead) for maintainers of the FlowRedux library itself.
In my head, this is something that we can tackle after FlowRedux 1.0 has been released as the goal is to refacor internals (so private APIs) and not the public API of the DSL etc.
The text was updated successfully, but these errors were encountered:
Disclaimer: This is not about changing anything in the DSL per se, this is about rewriting some internals of FlowRedux.
At the moment FlowRedux internally uses
Flow
s as some sort of broadcast channel to publish state changes to the outside but also to the inside (like DSL specific blocks that then trigger) and dispatch actions.Especially blocks of the DSL (i.e.
inState<State> {...}
) where cancellation of ongoing background work is required and need to be managed is complex with pureFlow
s.@gabrielittner came up with un interesting idea to basically use Jetpack Compose (compiler + runtime) because it is build around State and changes over time on State and has concepts of starting and canceling background work when state changes. That seems to be what we need in FlowRedux and with Compose and
@Composable
we could probably achieve the same functionality as we have today with ourFlow
based implementation but with lower complexity (mental overhead) for maintainers of the FlowRedux library itself.In my head, this is something that we can tackle after FlowRedux 1.0 has been released as the goal is to refacor internals (so private APIs) and not the public API of the DSL etc.
The text was updated successfully, but these errors were encountered: