New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The new Reducer protocol forcing a reducer to hydrate the state #65
Comments
@soapsign, you are bringing up a good point! The current protocol fairly closely resembles the Redux implementation. It has the advantage that you can initialize a Store without the need of initializing the state. In many cases you won't have all information to provide an initial state at that point in time. The idea of the current protocol is, that a reducer owns a slice of your state and thus should know best how to initialize it. I however agree that this assumption might not always be correct. Could you maybe share your example? That would make the discussion easier. I could imagine that it makes sense to offer to initialization paths:
Using a separate protocol we could accomplish this. Definitely worth discussing. Thanks for bringing this up! |
Consider my
It is defined as Then I have a The possible solution for 2nd problem is allow a reducer to return For the 1st Problem, it seem that the only possible way is the create another Maybe I am doing this optional subState in a wrong way, but this is the problems I face when I want to achieve this optional subState. |
struct AppState: StateType, HasStateA, HasStateB {
var stateA: State
var stateB: State?
}
struct State {
var value: String
}
protocol HasStateA {
var stateA: State { get set }
}
protocol HasStateB {
var stateB: State? { get set }
}
enum StateAAction: Action {
case ChangeValue(String)
}
enum StateBAction: Action {
case ChangeValue(String)
}
struct StateAReducer: Reducer {
func handleAction(action: Action, var state: HasStateA?) -> HasStateA {
// filtering action
guard let action = action as? StateAAction else {
return state!
}
switch action {
case .ChangeValue(let value):
state?.stateA.value = value
return state!
}
}
}
struct StateBReducer: Reducer {
func handleAction(action: Action, var state: HasStateB?) -> HasStateB {
// filtering action
guard let action = action as? StateBAction else {
return state!
}
// hydrating state if nil
var stateB = state?.stateB ?? State(value: "B")
switch action {
case .ChangeValue(let value):
stateB.value = value
state?.stateB = stateB
return state!
}
}
} I finally manage to implement the optional sub state, turn out that the |
@soapsign Thanks a lot for all the details! Yes, a part of the reducer API is a little bit confusing, since it is currently a mix of the original Swift Flow way of handling reducers and the ReduxKit way. I actually prefer many aspects of the ReduxKit approach, because it makes handling substates easier. I don't have time for a fill write-up now, but I will get back to this 😃 Thanks a lot for the input! |
With the new
Reducer
protocol beingsIt force every reducer observing a particular
ReducerStateType
to hydrate the state.If I have a reducer that do not want to hydrate the state or only want to handle the
Action
if the targetedState
exits, I can't achieve it due to this protocol.I think we should have a better way to handle this.
The text was updated successfully, but these errors were encountered: