Replies: 2 comments 6 replies
-
Could the above be refactored like so? The original implementation might be exhibiting the sharing-code-with-actions pattern. import ComposableArchitecture
import SwiftUI
@Reducer
struct Feature {
@ObservableState
struct State: Equatable { }
enum Action {
case didPullToRefresh
case refreshData1Returned
case refreshData2Returned
}
var body: some Reducer<State, Action> {
Reduce { state, action in
switch action {
case .didPullToRefresh:
return .concatenate(
.run { send in
// ...
await send(.refreshData1Returned)
},
.run { send in
// ...
await send(.refreshData2Returned)
}
)
case .refreshData1Returned:
return .none
case .refreshData2Returned:
return .none
}
}
}
} I believe any |
Beta Was this translation helpful? Give feedback.
5 replies
-
@jpsim Refreshable should be tied to all "child" effects spawned from the original, so I believe it already works the way you expect. You can verify in the refreshable case study by moving the refresh logic to a child action called from the parent Do you have an example of this not working? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Similar to
ViewStore.send(_:while:)
, it can be useful to wait for a specific state change to occur before resuming control flow.I believe the recommendation when migrating from
ViewStore.send(_:while:)
toStore.send(...)
is to appendStoreTask.finish()
, which is a much cleaner solution much of the time, when the duration of the effect from sending the action into the store is exactly tied to the operation, but isn't quite as flexible as thewhile
predicate API fromViewStore
.For example, here it would be useful to do
await store.send(.didPullToRefresh, while: \.isRefreshing)
, which would behave differently fromawait store.send(.didPullToRefresh).finish()
:Beta Was this translation helpful? Give feedback.
All reactions