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
Just a random thought about something for a potential v2, I haven't fully thought through all use cases yet.
We currently have our State class looking like this:
public class State<InputState : Any>(
public val snapshot: InputState,
) {
fun mutate(reducer: InputState.() -> InputState): ChangedState<InputState>
fun <S : Any> override(reducer: InputState.() -> S): ChangedState<S>
fun <S : Any> noChange(): ChangedState<S>
}
In the DSL we when have
onEnter { state ->
onEnterEffect { stateSnapshot ->
on<...> { action, state ->
onActionEffect<...> { action, stateSnapshot ->
collectWhileInState { item, state ->
collectWhileInStateEffect { item, stateSnapshot ->
This has 2 inconsistencies:
for effect merhods you get the snapshot directly instead of something that allows you to access the snasphot (as a side effect there is nothing that enforces how you call the parameter which makes it easy to just call it state and forget that it's a snapshot)
for enter you only get the state/snapshot and could use it for it while for the others you get 2 parameters which need to be written out
We could make 2 changes for v2:
Split State into 2 classes. The first class only has snapshot access and the other one extends that one and offers our mutation methods. This way we can always use one of these 2 classes as parameter to the DSL builders and you always call state.snapshot to access the snapshot.
public open class State<InputState : Any> internal constructor(
public val snapshot: InputState,
)
public class MutableState<InputState : Any>(snapshot: InputState) : State(snapshot) {
fun mutate(reducer: InputState.() -> InputState): ChangedState<InputState>
fun <S : Any> override(reducer: InputState.() -> S): ChangedState<S>
fun <S : Any> noChange(): ChangedState<S>
}
onEnter { state ->
onEnterEffect { state ->
on<...> { action, state ->
onActionEffect<...> { action, state ->
collectWhileInState { item, state ->
collectWhileInStateEffect { item, state ->
Building on top of that the DSL blocks can use State or MutableState as a receiver which unifies the state access between onEnter(Effect) and the others. For those that previously had 2 parameters it's up to the caller whether to be explicit with the remaining parameter like below or to just use it.
Just a random thought about something for a potential v2, I haven't fully thought through all use cases yet.
We currently have our
State
class looking like this:In the DSL we when have
This has 2 inconsistencies:
it
for it while for the others you get 2 parameters which need to be written outWe could make 2 changes for v2:
Split
State
into 2 classes. The first class only has snapshot access and the other one extends that one and offers our mutation methods. This way we can always use one of these 2 classes as parameter to the DSL builders and you always callstate.snapshot
to access the snapshot.Building on top of that the DSL blocks can use
State
orMutableState
as a receiver which unifies the state access betweenonEnter(Effect)
and the others. For those that previously had 2 parameters it's up to the caller whether to be explicit with the remaining parameter like below or to just useit
.The text was updated successfully, but these errors were encountered: