-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Refactor FXIOS-8971 Tweaks to redux actions #19823
Changes from all commits
2097a49
9962803
6126585
8c0c79e
2f27af3
963aa23
dd36f39
a7b8b50
1efee92
d0f8c2c
2284303
d7b61ac
79026e6
f2d38b4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,15 +11,17 @@ struct FakeReduxState: StateType, Equatable { | |
var isInPrivateMode = false | ||
|
||
static let reducer: Reducer<Self> = { state, action in | ||
switch action { | ||
case FakeReduxAction.initialValueLoaded(let value), | ||
FakeReduxAction.counterIncreased(let value), | ||
FakeReduxAction.counterDecreased(let value): | ||
return FakeReduxState(counter: value, | ||
guard let action = action as? FakeReduxAction else { return state } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One minor concern: it seems like with this change, reducers/middlewares that are interested in handling several different Action subclasses are going to have to check the class type of the incoming action against every subclass they want to handle 1 or more types for. Not a big deal, but that might lead to some clunky boilerplate of its own since we'll need to have multiple switches against the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree this is a concern. It touches on one of the other actions items I have to follow up on and that is how we have broken down and organized our states/middlewares and reducers. They are too big and broad right now, we have some switch statements that are already hundreds of lines long. |
||
|
||
switch action.actionType { | ||
case FakeReduxActionType.initialValueLoaded, | ||
FakeReduxActionType.counterIncreased, | ||
FakeReduxActionType.counterDecreased: | ||
return FakeReduxState(counter: action.counterValue ?? state.counter, | ||
isInPrivateMode: state.isInPrivateMode) | ||
case FakeReduxAction.setPrivateModeTo(let value): | ||
case FakeReduxActionType.setPrivateModeTo: | ||
return FakeReduxState(counter: state.counter, | ||
isInPrivateMode: value) | ||
isInPrivateMode: action.privateMode ?? state.isInPrivateMode) | ||
default: | ||
return state | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it would be beneficial to use enums for actions, mainly for two reasons. Firstly, the autocomplete feature in Xcode significantly enhances action discoverability. It conveniently allows you to view all options in one place. Secondly, using enums helps ensure that every new action added is handled properly because the compiler will flag an error if any action is overlooked. This approach helps avoid the potential oversight that might occur with a default case in switch statements.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The objects that conform to ActionType are enums.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you switch on ActionType, you loose this capability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may not be understanding. Are you proposing we have one big ActionType enum for all actions in the project?