Replies: 35 comments 161 replies
-
|
no one: |
Beta Was this translation helpful? Give feedback.
-
|
Hi @acosmicflamingo, I just pushed a fixed for this. |
Beta Was this translation helpful? Give feedback.
-
|
@mbrandonw Works like a charm now! I would've pushed a PR for you but I didn't want to overcomplicate your process, given how many branches you all have to maintain all at once. |
Beta Was this translation helpful? Give feedback.
-
|
Not at all, PR's are definitely welcome, just be sure to target the correct branch! We will happily merge PR's with typo fixes or any kind of fix you find. |
Beta Was this translation helpful? Give feedback.
-
|
Okay! I'll know for next time then :) |
Beta Was this translation helpful? Give feedback.
-
|
How does deep-linking work on this beta branch? I've been playing around with it and things seem to work until I try to deep-link to a presentation state, but when I launch my app, nothing happens. struct CategoryListFeature: ReducerProtocol {
struct State: Equatable {
var categories: IdentifiedArrayOf<Category> = []
@PresentationState var selection: CategoryDetailFeature.State?
}
enum Action: Equatable {
case categoryTapped(Category)
case selection(PresentationAction<CategoryDetailFeature.Action>)
}
var body: some ReducerProtocol<State, Action> {
Reduce { ... }
.ifLet(\.$selection, action: /Action.selection) {
CategoryDetailFeature()
}
}
}
struct CategoryListView: View {
let store: StoreOf<CategoryListFeature>
var body: some View {
NavigationStack {
listView
.navigationTitle("Categories")
}
}
@ViewBuilder
private var listView: some View {
WithViewStore(store, observe: \.categories) { viewStore in
List { ... }
.navigationDestination(
store: self.store.scope(
state: \.$selection,
action: CategoryListFeature.Action.selection
),
destination: CategoryDetailView.init
)
}
}
struct ContentView: View {
var body: some View {
CategoryListView(
store: .init(
initialState: CategoryListFeature.State(
categories: [
.plumbing,
.electrical,
.hvac
],
selection: CategoryDetailFeature.State(category: .hvac)
),
reducer: CategoryListFeature()._printChanges()
)
)
}
}
When I try to initialize the store with a selection, the app does not navigate to the details screen, it stays on the list screen and then navigation is broken because selection is already non-nil, so when I tap on a list item, nothing happens either. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @matt-dewitt, this is unfortunately a bug in SwiftUI, and even affects vanilla SwiftUI. We have filed a feedback here. It seems this bug is somewhat fixed in the newest Xcode 14.3 beta, but there is another bug that causes other problems that we haven't gotten around to filing a feedback for. We do have hacks we employ in our SwiftUINavigation library to kinda work around this, but it just kicks the can down the road because it causes other issues later. We could port those hacks over to the TCA navigation tools, but at the end of the day, The But, outside of all of the above caveats, what you have written is supposed to work just fine. If you were to use a sheet instead of a |
Beta Was this translation helpful? Give feedback.
-
|
Ah, ok, great, thanks for the info! I remember you fixing it in the Vanilla SwiftUI series and wanted to see if it worked with the new stuff as well. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, we could port over those hacks, but seeing as how things are maybe fixed in Xcode 14.3+, it kind of complicates things. The problem is if we apply the hack now, then the day Xcode 14.3 comes out we would want to special-case the hack so that it is not applied for people who can target the latest and greatest. But that incurs the cost of an |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good. Looking forward to seeing the new NavigationStack binding stuff! |
Beta Was this translation helpful? Give feedback.
-
|
@mbrandonw - I am in favor of kicking the can down the road. My app persists all of its AppState and restores it upon initial loading. I have been using my own TCA compatible version of View.navigationDestination which depends on the patched versions in SwiftUINavigation. This has worked well up to this point. Since you already have a patch for the most egregious issue caused by this bug (leaving navigation broken due to the control state remaining true after deep linking with no way to recover), why not use it. I am using the prerelease/1.0 version of TCA. Replacing line 70 of file NavigationDestination in struct PresentationNavigationDestinationModifier: with the following: fixes the issue in my app. This will utilize the patched SwiftUINavigation version of View.navigationDestination(unwrapping:destination:) instead of the broken vanilla SwiftUI version of View.navigationDestination(isPresented:destination). Since you will need to address the patch in SwiftUINavigation after Apple fixes the issue anyways, this seems like a simple solution without additional burden. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
Is there a rough timeline for switching the prerelease 1.0 to track the new navigation beta? We recently made the switch over to it and would like to get to grips with the new navigation toys too. Thanks 🙏🏻 |
Beta Was this translation helpful? Give feedback.
-
|
It's updated now! If you pull the newest |
Beta Was this translation helpful? Give feedback.
-
|
Amazing 🤩 Thanks |
Beta Was this translation helpful? Give feedback.
-
|
In past discussions and episodes, you have encouraged us to represent our destination state as an enum. public struct MyFeature: Equatable {
@PresentationState public var destination: Destination?
public enum Destination: Equatable {
case featureA(FeatureA.State)
case featureB(FeatureB.State)
case alert(AlertState<Action>)
}
}
public enum Action {
case destination(PresentationAction<Destination>)
public enum Destination: Equatable {
case featureA(FeatureA.Action)
case featureB(FeatureB.Action)
}
}Is this currently possible to do this on the beta branch? Or will it be? I'm not sure how to switch on the destination using the new .ifLet func for |
Beta Was this translation helpful? Give feedback.
-
|
Ah yeah, I thought I had replied to that part already, sorry. There's 2 things to mention with that line:
|
Beta Was this translation helpful? Give feedback.
-
|
Gotcha, thanks for explanation |
Beta Was this translation helpful? Give feedback.
-
|
@corysullivan The ability to present a sheet from alert should be fixed if you pull the latest (Note that the reverse, presenting an alert while dismissing a sheet, is not possible in SwiftUI and must be spaced out, as @mbrandonw suggests earlier.) |
Beta Was this translation helpful? Give feedback.
-
|
@stephencelis Nice! I just did a quick test, and it is indeed working. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
I have a feeling this is going to be something people run up against quite often so I filed a feedback here. |
Beta Was this translation helpful? Give feedback.
-
|
Just a quick check on intended usage. When using |
Beta Was this translation helpful? Give feedback.
-
|
Nothing at all! You can do: .ifLet(\.$alert, action: /Action.alert)Alerts and confirmation dialogs have been special-cased for |
Beta Was this translation helpful? Give feedback.
-
|
Perfect! Thanks 🚀 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! That works. I thought I was seeing a bug but realised I hadn't put the |
Beta Was this translation helpful? Give feedback.
-
|
For all the TCA Boundary fans out there (examples can be found here: #1440), this extension should prove useful: extension Reducer where Action: TCAAction {
public func ifLet<DestinationState, DestinationAction, Destination: ReducerProtocol>(
_ toPresentationState: WritableKeyPath<State, PresentationState<DestinationState>>,
action toPresentationAction: CasePath<
Action.InternalAction, PresentationAction<DestinationAction>
>,
@ReducerBuilder<DestinationState, DestinationAction> then destination: () -> Destination,
file: StaticString = #file,
fileID: StaticString = #fileID,
line: UInt = #line
) -> _PresentationReducer<Self, Destination>
where Destination.State == DestinationState, Destination.Action == DestinationAction {
return self.ifLet(
toPresentationState,
action: (/Action._internal) .. toPresentationAction,
then: destination
)
}
} |
Beta Was this translation helpful? Give feedback.
-
|
I'm so close! I imagined that I'd be able to use the new navigation tools like this in UIKit: class SettingsViewController: UIViewController {
...
func setupBindings() {
store.scope(
state: \.$fontManager,
action: /Action.fontManager
).ifLet { [weak self] store in // <= error happens here because .ifLet does not work on scope that is never nil
guard let self, let navigationController = self.navigationController else { return }
let viewController = FontManagerViewController(store: store)
navigationController.pushViewController(viewController, animated: true)
} else: { [weak self] _ in
guard let self, let navigationController = self.navigationController else { return }
navigationController.popToViewController(self, animated)
}
.store(in: &cancellables)
}
}However, the error arises because store.scope will never return a non-nil: Key path value type 'PresentationState<FontManager.State>' cannot
be converted to contextual type 'PresentationState<FontManager.State>?'Am I doing something wrong here or is there no support for UIKit at this time? |
Beta Was this translation helpful? Give feedback.
-
|
@rowellx68 wow fancy!!! This would absolutely be beneficial to me :) I was trying to think of how to port the equivalent SwiftUI approach to UIKit but it looks like this is most definitely the way to go 😵 thank you! |
Beta Was this translation helpful? Give feedback.
-
|
https://i.gifer.com/YwfU.gif I might have to integrate some of that functionality in what I currently use: import Combine
import ComposableArchitecture
import Foundation
import UIKit
public protocol TCAStoreSupport: AnyObject & CombineSupport {
associatedtype State
associatedtype Action: TCAAction
associatedtype ViewState
var store: Store<State, Action> { get }
var viewStore: ViewStore<ViewState, Action.ViewAction> { get set }
var cancellables: Set<AnyCancellable> { get set }
func setupUI()
func setupBindings()
func setupActions()
}Maybe if there's usefulness, I could upstream some changes to your codebase too. We'll see ;) |
Beta Was this translation helpful? Give feedback.
-
|
I like yours, I might have to add a |
Beta Was this translation helpful? Give feedback.
-
|
Protocols are the best! I used to be all for creating subclasses, but then I found that I relied too much on the Object-Oriented approach instead of the Protocol-oriented approach. I realized this when I was debugging my SettingsViewController, which was a subclass of CFSplitScreenController, which was a subclass of CFViewController. I have no clue what is actually available in the subclasses because lots of functionality is hidden, and where the source of the problem (and whether it's because I called the super method in the wrong place). By utilizing protocols, now I can pinpoint behavior so much easier, I see what properties are available, and you can even extend protocols with functions so you get that benefit you usually get from subclassing. |
Beta Was this translation helpful? Give feedback.
-
|
@rowellx68 by the way, passing the reference type into the ifLet/else closures introduces a retain cycle. This can be easily fixed by weakifying it: import Combine
import ComposableArchitecture
import UIKit
public extension Store {
func sheet<Wrapped>(
for presenter: UIViewController,
_ sheet: @escaping (Store<Wrapped, Action>) -> UIViewController,
animated: Bool = true,
animatedOnDismiss: Bool = true
) -> Cancellable where State == Wrapped? {
- ifLet { store in
+ ifLet { [weak presenter] store in
+ guard let presenter else { return }
presenter.present(sheet(store), animated: animated)
- } else: {
+ } else: { [weak presenter] store in
+ guard let presenter else { return }
presenter.presentedViewController?.dismiss(animated: animatedOnDismiss)
}
}
func navigationDestination<Wrapped>(
for presenter: UIViewController,
_ destination: @escaping (Store<Wrapped, Action>) -> UIViewController,
animated: Bool = true,
animatedOnPop: Bool = true
) -> Cancellable where State == Wrapped? {
- ifLet { store in
+ ifLet { [weak presenter] store in
+ guard let presenter else { return }
presenter.navigationController?.pushViewController(
destination(store),
animated: animated
)
- } else: {
+ } else: { [weak presenter] store in
+ guard let presenter else { return }
presenter.navigationController?.popToViewController(
presenter,
animated: animatedOnPop
)
}
}
}You can also use |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if this is a question on here or for TCA in general or even for the SwiftUI Navigation repo. 😅 There are a couple of instance of this pattern in our app at the moment but this is the easiest to explain. We have certain We created a In the navigation beta the general concept seems to be to use the state of the child to control the navigation. But... the state of the child would just be the same as the state of the parent. eg... At the moment we have no actions or anything in the article (but we will in the future). So I could update this to ... But then creating the I guess that's not too bad but I just wanted to sanity check myself on this. Is there a better way of doing this other than duplicating the data into a child state? Or is this ok to do? We wouldn't be editing the article in this case. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
If you can push a single article at the same time it’s better to have the parent do the navigation this way you are guaranteed that there is only one push at the same time possible. I would have a delegate style action that ask the parent to go to the next step and the parent would handle the nav state. I tend to have completely independents screens and a parent feature that mostly just handle navigation. |
Beta Was this translation helpful? Give feedback.
-
|
OK, interesting. Yeah, that's def the other approach we talked about. That way, each screen that shows an article has to then deal with the navigation to that article. But I guess with the navigation tools in this branch that is made much easier. So it's a bit more work. But then you end up with a navigation system that is impossible to define incorrectly. (If done right). I think we have some changes to make in the app. 😅 Also... this would potentially remove the initial question that I opened with. Because the Thanks |
Beta Was this translation helpful? Give feedback.
-
|
I will also be more practical when you handle deeplinks, you don’t have to choose which cover should be selected. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that's our ultimate goal. To have deep linking anywhere in the app "for free". |
Beta Was this translation helpful? Give feedback.
-
|
That’s where tca shines the most ! |
Beta Was this translation helpful? Give feedback.
-
|
I have a failing test after moving to the navigation beta branch (I'm on prerelease/1.0) and I can't work out where it's coming from. The test is small. I send an action to the test store that creates a child state which is now It is failing telling me that there is an unfinished effect. The test... Reducer... Error...
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @oliverfoggin, while the error message isn't great, this is happening because the sheet has been presented and has not been dismissed. Technically behind the scenes there's a long living effect running that represents the child feature being presented (watch next week's episode for more information :). We do want to improve this situation, but it is very tricky. Hopefully we will have more to say about it soon. For now, if you simply send a dismiss action |
Beta Was this translation helpful? Give feedback.
-
|
Ah! That worked. Thanks. I can see why it is that way now with the explanation. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
@oliverfoggin We just pushed some updates to |
Beta Was this translation helpful? Give feedback.
-
|
Hey @mbrandonw, is this also fixed in the prerelease branch? I am on the newest prerelease commit and got the exact same test failure |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I had a |
Beta Was this translation helpful? Give feedback.
-
|
As you may have seen in recent episodes, it is often more flexible to contextualize a presented view at the presenting stage (where we have explicit information), rather than parametrizing the presented view with configuration flags. SwiftUI works mostly OK in this setup. Since iOS 13, UIKit ships with a dedicated dismiss control (the dark grey xmark inside a grey circle) under the form of a Fortunately we can bundle this button using a view representable in a very convenient You use this button like: .sheet(store.scope(…)) {
PresentedFeature(store: store)
.toolbar {
DismissButton()
}
}( I'm not saying that this should ship with the library (it shouldn't in TCA for sure), but I guess this is something nice to have in our tool belt. Here is the code1: #if canImport(UIKit)
public struct DismissButton: View {
public init() {}
@Environment(\.dismiss) var dismiss
public var body: some View {
UICloseButton {
self.dismiss()
}
}
private struct UICloseButton: UIViewRepresentable {
let action: () -> Void
final class Coordinator {
var action: () -> Void
init(action: @escaping () -> Void) {
self.action = action
}
}
func makeCoordinator() -> Coordinator {
Coordinator(action: self.action)
}
func makeUIView(context: Context) -> some UIView {
UIButton(
type: .close,
primaryAction: .init(handler: { _ in
context.coordinator.action()
}))
}
func updateUIView(_ uiView: UIViewType, context: Context) {
context.coordinator.action = self.action
}
}
}
#endifFootnotes
|
Beta Was this translation helpful? Give feedback.
-
|
Is there a bug with alerts and confirmation dialogs or am I doing something wrong? Seems whenever I add a custom button/action to either one, when I click the button to send the action, I get this runtime warning: Here is my simple code example: import ComposableArchitecture
import SwiftUI
struct AlertsAndDialogsFeature: ReducerProtocol {
struct State: Equatable {
@PresentationState var destination: Destinations.State?
}
enum Action: Equatable {
case destination(PresentationAction<Destinations.Action>)
case alertButtonTapped
case confirmationButtonTapped
}
var body: some ReducerProtocol<State, Action> {
Reduce(core)
.ifLet(\.$destination, action: /Action.destination) {
Destinations()
}
}
private func core(into state: inout State, action: Action) -> EffectTask<Action> {
switch action {
case .alertButtonTapped:
state.destination = .alert(
AlertState {
TextState("Alert Dialog")
} actions: {
ButtonState(role: .cancel) {
TextState("Cancel")
}
ButtonState(action: Destinations.Action.Alert.alertConfirmButtonTapped) {
TextState("Confirm")
}
} message: {
TextState("Please confirm this alert")
}
)
return .none
case .confirmationButtonTapped:
state.destination = .confirmation(
ConfirmationDialogState {
TextState("Confirmation Dialog")
} actions: {
ButtonState(role: .cancel) {
TextState("Cancel")
}
ButtonState(action: Destinations.Action.Confirmation.confirmationConfirmButtonTapped) {
TextState("Confirm")
}
} message: {
TextState("Please confirm this confirmation dialog")
}
)
return .none
case .destination:
return .none
}
}
}
extension AlertsAndDialogsFeature {
struct Destinations: ReducerProtocol {
enum State: Equatable {
case alert(AlertState<Action.Alert>)
case confirmation(ConfirmationDialogState<Action.Confirmation>)
}
enum Action: Equatable {
case alert(Alert)
case confirmation(Confirmation)
enum Alert: Equatable {
case alertConfirmButtonTapped
}
enum Confirmation: Equatable {
case confirmationConfirmButtonTapped
}
}
var body: some ReducerProtocol<State, Action> {
Scope(state: /State.alert, action: /Action.alert) {}
Scope(state: /State.confirmation, action: /Action.confirmation) {}
}
}
}
struct AlertsAndDialogsView: View {
let store: StoreOf<AlertsAndDialogsFeature>
var body: some View {
WithViewStore(store, observe: { $0 }) { viewStore in
List {
Button("Show Alert") {
viewStore.send(.alertButtonTapped)
}
Button("Show Confirmation") {
viewStore.send(.confirmationButtonTapped)
}
}
.alert(
store: self.store.scope(
state: \.$destination,
action: AlertsAndDialogsFeature.Action.destination
),
state: /AlertsAndDialogsFeature.Destinations.State.alert,
action: AlertsAndDialogsFeature.Destinations.Action.alert
)
.confirmationDialog(
store: self.store.scope(
state: \.$destination,
action: AlertsAndDialogsFeature.Action.destination
),
state: /AlertsAndDialogsFeature.Destinations.State.confirmation,
action: AlertsAndDialogsFeature.Destinations.Action.confirmation
)
}
}
}It seems that the custom action is nilling out the state instead of waiting for the dismiss action to do it? |
Beta Was this translation helpful? Give feedback.
-
|
Are you using |
Beta Was this translation helpful? Give feedback.
-
|
I'm actually trying to get this working in UIKit, so I don't just get that behavior out-of-the-box :( I currently use Store's ifLet to scope a Destination enum property to a store that I can then pass to a UIAlertController via this extension: extension UIAlertController {
public convenience init<ConfirmationDialogAction: Equatable>(
store: Store<ConfirmationDialogState<ConfirmationDialogAction>, ConfirmationDialogAction>
) {
let viewStore = ViewStore(store, observe: { $0 }, send: { $0 })
self.init(
state: viewStore.state,
send: {
if let action = $0 {
viewStore.send(action)
}
}
)
}
}That would allow me to do this: store.scope(
state: {
(/AcknowledgmentsWebsite.Destination.State.confirmationDialog).extract(
from: $0.destination
)
},
action: { ._internal(.destination(.presented(.confirmationDialog($0)))) }
) .ifLet { [weak self] store in
guard let self else { return }
let alertController = UIAlertController(store: store)
self.present(alertController, animated: true, completion: nil)
} else: { [weak self] in
guard let self else { return }
self.presentedViewController?.dismiss(animated: true)
}
.store(in: &cancellables)But unfortunately, unlike child view controllers and child features, this is a little different. I don't have an AlertFeature that allows me to send effect actions out from its reducer, so I don't know how to ever dismiss the presented alert controller. Edit: this does work after all! |
Beta Was this translation helpful? Give feedback.
-
|
Wow...I'm so silly. I'm 100% wrong; it does work as you'd expect! |
Beta Was this translation helpful? Give feedback.
-
|
Actually, I am seeing in the UIKit example that when you select the cancel button, the destination enum is never set to nil :O in fact, the Destination reducer is never even called when hitting cancel! If I were to go the basic Reducer extension that handles Presentation wrapping and insert breakpoints, this is what is called when I hit the "Confirm" button and everything goes well: Line 161. If I hit cancel, neither Line 161 nor Line 183 is called. In addition, I don't know if its intentional that presenting a UIAlertController powered by AlertState would call line 161 when the comment in 183 says that function will be called for confirmation dialogs and alerts. I tried making a reproducer in the LoginCore and LoginViewController code, but that's leading to more problems than I was hoping. Hopefully what I brought up is enough to diagnose the problem, but I can try and create a reproducer too if you need it. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps I needed sleep since it just occurred to me this morning that all buttons have an action parameter, even for cancel buttons. What I did to fix this is just made sure that the Destination reducer has a cancel action and that in the main reducer, I nil out the destination property: extension AcknowledgmentsWebsite {
public struct Destination: Reducer {
public enum State: Hashable {
case actionSheet(AlertState<Action.ActionSheet>)
}
public enum Action: Hashable {
case actionSheet(ActionSheet)
public enum ActionSheet: Hashable {
case actionSheetConfirmButtonTapped(URL)
case actionSheetCancelButtonTapped
}
}
public func reduce(into state: inout State, action: Action) -> Effect<Action> {
.none
}
}
}
public struct AcknowledgmentsWebsite: Reducer {
// ...
public var body: some ReducerOf<Self> {
Reduce<State, Action> { state, action in
switch action {
case let .view(viewAction):
switch viewAction {
// ...
case .openInBrowserButtonTapped:
guard let url = state.item.url
else { return .none }
state.destination = .actionSheet(
AlertState {
TextState("Confirmation Dialog")
} actions: {
ButtonState(
role: .cancel,
action: Destination.Action.ActionSheet.actionSheetCancelButtonTapped
) {
TextState("Cancel")
}
ButtonState(
action: Destination.Action.ActionSheet.actionSheetConfirmButtonTapped(url)
) {
TextState("Confirm")
}
} message: {
TextState("Please confirm this confirmation dialog")
}
)
return .none
}
case let ._internal(internalAction):
switch internalAction {
// ...
case let .destination(.presented(destination)):
switch destination {
case let .actionSheet(actionSheetAction):
switch actionSheetAction {
case let .actionSheetConfirmButtonTapped(url):
return .run { _ in
_ = await applicationClient.open(url)
}
case .actionSheetCancelButtonTapped:
state.destination = nil
return .none
}
}
}
}
}
.ifLet(\.$destination, action: /Action.InternalAction.destination) {
Destination()
}
}
public init() {}
} |
Beta Was this translation helpful? Give feedback.
-
|
As soon as I use the new .ifLet(\.$destination, action: /Action.destination) {
Scope(state: /DestinationState.editFolder, action: /DestinationAction.editFolder) {
EditFolder()
}
}As a workaround you have to specify the full paths. Are there any better solutions? .ifLet(\Feature.State.$destination, action: /Feature.Action.destination) {
Scope(state: /Feature.DestinationState.editFolder, action: /Feature.DestinationAction.editFolder) {
EditFolder()
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, yes I have already done that, but in this case it doesn't help. |
Beta Was this translation helpful? Give feedback.
-
|
There are huge improvements to result builders coming in Swift 5.8 and we've already made some changes to |
Beta Was this translation helpful? Give feedback.
-
|
I'm using this workaround for now: public var body: some ReducerProtocol<State, Action> {
Reduce(core)
.ifLet(\.$destination, action: /Action.destination) {
Scope(
state: /DestinationState.featureA,
action: /DestinationAction.featureA
) {
FeatureA()
}
Scope(
state: /DestinationState.featureB,
action: /DestinationAction.featureB
) {
FeatureB()
}
}
}
private func core(into state: inout State, action: Action) -> EffectTask<Action> {
switch action {
...
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Ah yes, that's a good alternative too. Glad it works! |
Beta Was this translation helpful? Give feedback.
-
|
I've been having autocomplete issue for particular files but I thought it was just my XCode messing with me 😀 Didn't pay attention to those stuff and gonna check it out. Thanks for the tips 👍🏻 |
Beta Was this translation helpful? Give feedback.
-
|
Hi Folks, I might have missed something from the recent episode and the new navigation tools being released but I was wondering if anyone could tell me why I am getting these purple runtime warning when I am using the new sheet(store: .. API Here is a snippet of the code I used to test the API: and here is a screenshot of the error I am getting. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Dominic263, there is a bug in SwiftUI textfields that causes them to write to their bindings way more often than necessary, including when the textfield is removed from the screen. That causes an action to be sent when state has been We know it's a problem and plan to fix it soon. For now you can just ignore the warning. |
Beta Was this translation helpful? Give feedback.
-
|
As @mbrandow mentioned this is a SwiftUI binding bug that is really brought to light by the use of bindings in TCA and has existed before the navigation APIs were introduced. I've played around with this quite a bit and the behavior is quite odd, especially with regards to focus and autocomplete. In my app, I use If the user dismisses the sheet using a swipe down gesture, then the focus field binding will be invoked and set to nil before the sheet is dismissed, so there will be no runtime warning from TCA. If the text field currently has an autocompletion pending indicated by the text being highlighted, then the focus will first be set to nil, then the autocomplete will be applied and the textfield binding invoked with the autocomplete value, before dismissing the sheet. So again, no runtime errors. Now, if you programmatically close the sheet, then the bindings are invoked after the sheet is dismissed. So the child state is nil and TCA appropriately issues a runtime warning. However, the bindings are also fired in a reverse order. So that first the the autocomplete (if active) is applied by updating the field's value and then the field's focus is set to nil. In my app, I chose to try to emulate the built-in swipe to dismiss gesture. So on a user action that would dismiss the sheet, I first set the focus to nil, and then "wait" for any potential autocomplete to be applied before continuing the dismissal. Here's a simple example for a cancel: case .view(.cancelTapped):
state.focusedField = nil
// or if not syncing focus, can call resignFirstResponder instead
// UIApplication.shared.sendAction(#selector(UIResponder.resignFirstResponder), to: nil, from: nil, for: nil)
return .task {
try await Task.sleep(nanoseconds: 100 * NSEC_PER_MSEC) // 100ms seems to work well
return .delegate(.dismiss) // or use new dismiss dependency call
}Note, even though I'm not using the autocomplete value in a cancel case, I have to wait to for it to potentially be applied to avoid the runtime warning. The save case is more complicated because you typically want to wait for the auto-complete to be applied before verifying and saving the data if you want to match the typical Apple application behavior which is to apply autocomplete on any focus loss. In that case, I do the same code as above, but then just send a new effect back to the reducer to execute validation and save logic. Would be nice if TCA could offer a built-in robust solution to this problem. |
Beta Was this translation helpful? Give feedback.
-
@scogeo Yep, that's the plan! Some of the most recent pushes we made fixed half the problem, we just have a bit more to go for a full solution. :) |
Beta Was this translation helpful? Give feedback.
-
|
Is it forbidden to present another I'm trying to present alert over my sheet. but when I drag down my sheet to dismiss, my application stops. my code is like this import ComposableArchitecture
struct ParentFeature: Reducer {
@PresentationState var sheet: SheetFeature.State?
// ...
var body: some ReducerOf<Self> {
Reduce(core)
.ifLet(\.$sheet, action: /Action.sheet)
}
}
struct SheetFeature: Reducer {
@PresentationState var alert: AlertState<AlertAction>?
// ...
} |
Beta Was this translation helpful? Give feedback.
-
|
One thing that can happen easily is to forget adding the |
Beta Was this translation helpful? Give feedback.
-
|
For example the following code that is copy/pastable as import ComposableArchitecture
import SwiftUI
struct Parent: ReducerProtocol {
struct State {
@PresentationState var sheet: Child.State?
}
enum Action {
case present
case sheet(PresentationAction<Child.Action>)
}
var body: some ReducerProtocol<State, Action> {
Reduce { state, action in
switch action {
case .present:
state.sheet = .init()
return .none
case .sheet:
return .none
}
}.ifLet(\.$sheet, action: /Action.sheet) {
Child()
}
}
}
struct Child: ReducerProtocol {
struct State {
@PresentationState var alert: AlertState<Int>?
}
enum Action {
case alert(PresentationAction<Int>)
case show
}
var body: some ReducerProtocol<State, Action> {
Reduce { state, action in
switch action {
case .alert:
return .none
case .show:
state.alert = .init(
title: {
TextState("Alert")
},
actions: {
ButtonState(action: 0) {
TextState("Action")
}
})
return .none
}
}
.ifLet(\.$alert, action: /Action.alert) // Comment this line to see the alert state not being nil'd out
}
}
struct ContentView: View {
let store = Store(initialState: .init(), reducer: Parent()._printChanges())
var body: some View {
Button("Present sheet") {
ViewStore(store.stateless).send(.present)
}
.sheet(store: store.scope(state: \.$sheet, action: Parent.Action.sheet)) { store in
NavigationStack {
ChildView(store: store)
.toolbar {
Button("Close") {
ViewStore(self.store.stateless).send(.sheet(.dismiss))
}
}
}
}
}
}
struct ChildView: View {
let store: StoreOf<Child>
var body: some View {
Button("Show alert") {
ViewStore(store.stateless).send(.show)
}
.alert(store: store.scope(state: \.$alert, action: Child.Action.alert))
}
}
struct ContentView_Previews: PreviewProvider {
static var previews: some View {
ContentView()
}
} |
Beta Was this translation helpful? Give feedback.
-
|
I think the problem is I'm using |
Beta Was this translation helpful? Give feedback.
-
|
Feel free to open a standalone discussion if the issue persists after updating |
Beta Was this translation helpful? Give feedback.
-
|
Is there a way to create custom ViewModifier like a PresentationSheetModifier? But PresentationSheetModifier relies on internal function and variable, so I think I can't create custom navigation tools. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @kalupas226, this is not currently possible but it is something we want to support. We would like to expose enough API so that you can build your own presentation helpers. |
Beta Was this translation helpful? Give feedback.
-
|
I'm glad to hear that! |
Beta Was this translation helpful? Give feedback.
-
|
@kalupas226 We've added a tentative They drive all the modifiers shipping with the library. For example, Let us know if this works for you or if there are any issues! |
Beta Was this translation helpful? Give feedback.
-
|
@stephencelis - After updating to the latest version of swift-composable-architecture prerelease/1.0 which was released on 05/24/2023, my Navigation view modifiers and ForEachStore views no longer compile. The toChildState transform function in store.scope used to be fine taking a key path literal. Now it produces compiler errors at the commented out lines. To resolve the errors I had to replace each key path literal with a closure. See the code example, which now compiles: (1): Key path value type 'IdentifiedArrayOf' (aka 'IdentifiedArray<Tagged<Payer, Int>, Payer>') cannot be converted to contextual type 'IdentifiedArray<Payer.Id, _>' (aka 'IdentifiedArray<Tagged<Payer, Int>, _>') (2): Key path value type 'PresentationState<MultiPayerReducer.Destination.State>' cannot be converted to contextual type 'PresentationState<MultiPayerReducer.Destination.State>' Any thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
I have been testing the struct ChildView: View {
let store: StoreOf<ChildFeature>
var body: some View {
WithViewStore(store, observe: { $0 }) { viewStore in
VStack(spacing: 50) {
Button {
viewStore.send(.dismiss)
} label: {
Text("Dismiss \(viewStore.id)")
}
}.onDisappear {
viewStore.send(.onDisappear)
}
}
}
}Is this expected? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @corysullivan, yes this is expected. Basically |
Beta Was this translation helpful? Give feedback.
-
|
Is there any API (or examples) to create own custom View presentations using new navigation API? |
Beta Was this translation helpful? Give feedback.
-
|
@larryonoff not yet, but it's on our list of things to do to make it so that custom UI components can be powered by the new APIs. |
Beta Was this translation helpful? Give feedback.
-
Looking forward to it. I already have components that needs custom presentation, so I'll use own custom things for the moment. |
Beta Was this translation helpful? Give feedback.
-
|
@larryonoff We've added a tentative They drive all the modifiers shipping with the library. For example, Let us know if this works for you or if there are any issues! |
Beta Was this translation helpful? Give feedback.
-
|
@stephencelis thanks for the update! I analysed and looks exactly what I need. |
Beta Was this translation helpful? Give feedback.
-
|
I have been messing around with the navigation beta and came across an issue I cannot seem to solve. struct ExampleButton: View {
@State private var isLoading: Bool = false
var onTapped: () async -> Void
var body: some View {
Button {
if self.isLoading {
return
}
self.isLoading = true
Task {
await self.onTapped()
await MainActor.run {
self.isLoading = false
}
}
} label: {
HStack {
Text("Tap me!")
Spacer()
if isLoading {
ProgressView()
} else {
Text(">")
}
}
}
}
}It shows a ProgressView when tapped until the onTapped handler finishes.
To accomplish this I have written the following code: public struct Example: Reducer {
public struct State: Equatable {
@PresentationState public var destination: Example.State? = nil
}
public enum Action: Equatable {
case _finishNavigation
indirect case destination(PresentationAction<Example.Action>)
case startNavigation
}
@Dependency(\.suspendingClock) var clock
public init() {}
public var body: some Reducer<State, Action> {
Reduce { state, action in
struct CancelNavigationID {}
switch action {
case ._finishNavigation:
state.destination = .init()
return .none
case .destination(_):
return .none
case .startNavigation:
return .concatenate(
.cancel(id: CancelNavigationID.self),
.task {
try? await clock.sleep(for: .seconds(1))
return ._finishNavigation
}.cancellable(id: CancelNavigationID.self, cancelInFlight: true)
)
}
}
.ifLet(\.$destination, action: /Action.destination) {
Self()
}
}
}
public struct ExampleView: View {
let store: StoreOf<Example>
public init(store: StoreOf<Example>) {
self.store = store
}
public var body: some View {
List {
ExampleButton {
await ViewStore(self.store.stateless).send(.startNavigation).finish()
}
ExampleButton {
await ViewStore(self.store.stateless).send(.startNavigation).finish()
}
}
.navigationDestination(store: self.store.scope(
state: \.$destination,
action: Example.Action.destination
)) {
ExampleView(store: $0)
}
}
}This meets most of my requirements: the ProgressView gets shown when the user taps a button, when the user taps another button whilst loading the first effect gets cancelled, and when the effect gets to finish it navigates to the next view. My issue is that when the child view gets dismissed the ProgressView on the button is still showing. It disappears when dismissal finishes, so I assume that whatever long-living effect deals with navigation gets caught in ViewStore.send().finish(). Is there any way to allow the onTapped handler to finish before/during navigation without storing the button's loading state in TCA state? |
Beta Was this translation helpful? Give feedback.
-
|
First of all thanks for all the great work on TCA. Any chance of fixing this issue? |
Beta Was this translation helpful? Give feedback.
-
|
I have the same error. Using a |
Beta Was this translation helpful? Give feedback.
-
|
This was discussed further up in the thread (see here). tldr; there are still lots of bugs in SwiftUI navigation, especially |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, this problem does not occure with the Xcode 14.3 Beta 3 |
Beta Was this translation helpful? Give feedback.
-
|
I'm seeing what looks like the same problem. I'm working around it for now by in the 'level 2' view, using an |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible to support |
Beta Was this translation helpful? Give feedback.
-
|
Hey! First of all, great work! I am just about migrating some of my views, which works pretty well. |
Beta Was this translation helpful? Give feedback.
-
|
During migration, I've run into a situation which seems like it would be common place, and I'm wondering if there is a better way to approach it (perhaps through enhancements to the new navigation features). This is the flow:
I had previously implemented this by having an "Exit" button on the form, which would send a With the new navigation features, I've been able to get the same flow working, with the slight improvement that I can now use the So I guess my question is - should the "Change Confirmation" alert be the responsibility of the child reducer or the parent? If the parent, is there a way to leverage (or enhance) the new navigation features to accomplish this? I naively tried to observe the |
Beta Was this translation helpful? Give feedback.
-
|
Hi @nmccann, this sounds similar to some of the discussions we've had in recent episodes. In particular, the moments we decided to attach toolbars with close/cancel/save buttons to modals from the parent rather than the child. That allows the parent to implement all of this logic without the child needing to know anything about it. So, tapping the close button would send a parent action, handling that action would determine if it should close immediately (
Just a side note: this is guaranteed by the navigation tools. When observing |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the quick response! I like how that approach makes the child completely unaware of those presentation-specific pieces of functionality. I'll experiment with incorporating that.
Glad to hear this is intentional - maybe there is somewhere that could be documented? Such as on the Presentation reducer. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that is definitely the plan. We haven't spent much time on documentation yet. |
Beta Was this translation helpful? Give feedback.
-
|
Hi there. I'm experiencing some rather funky behaviour when using sheets; my sheet is being dismissed when I send actions which don't even Below are the actions sent when the button is pressed (the UI exhibits the above behaviour): The erroneous dismissal happens immediately after the first action is received. Below is the source code for that particular action: // In VerifyEmailFeature:
case .didTapCheckVerification:
state.isCheckVerificationInProgress = true
return .run {
do {
let me = try await UserClient.shared.me()
await $0.send(.didCompleteCheckVerification(
isEmailVerified: me.isEmailVerified,
error: nil
))
} catch {
await $0.send(.didCompleteCheckVerification(
isEmailVerified: nil,
error: error.localizedDescription
))
}
}.animation()
case let .didCompleteCheckVerification(isEmailVerified, error):
state.isCheckVerificationInProgress = false
if let error {
state.alert = .error(error)
return .none
}
guard let isEmailVerified else {
return .none
}
state.isEmailVerified = isEmailVerified
guard isEmailVerified else {
return .none
}
return .run {
await $0.send(.dismiss(didCancel: false, didDeleteAccount: false))
}
// In OnboardingFeature:
case let .verifyEmail(.presented(.dismiss(didCancel, didDeleteAccount))):
state.verifyEmailState = nil
guard !didCancel && !didDeleteAccount else {
return .none
}
state.updateProfilePictureState = .init()
return .none
case .verifyEmail:
return .none |
Beta Was this translation helpful? Give feedback.
-
|
Scratch that, it crashes when other sheets get presented too!: |
Beta Was this translation helpful? Give feedback.
-
|
Oh no, it really messes up if actions are sent in onAppear 😂: RPReplay_Final1679799939.MP4 |
Beta Was this translation helpful? Give feedback.
-
|
I've spent the last few hours stepping through in the debugger to see if I can figure it out… and I can't 🥲. As far as I can tell, sending any action inside This is so cursed, my eyes hurt 😵💫. At the end of the day, I've probably done something stupid (I really hope I have) 😅. |
Beta Was this translation helpful? Give feedback.
-
|
I haven't looked in depth into your issue but two things come to mind. First, many times when you observe too much state, causing the Another thing to be aware of is that there are known bugs in SwiftUI that prevent you from immediately dismissing and presenting certain kinds of UI. For example, it is not possible to simultaneously dismiss a sheet and show an alert. There needs to be a small delay between those events. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that seemed to be the issue — I revised the article you linked, revised my uses of |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I have spotted something strange with
Has anyone experienced this? I am on the most up to date |
Beta Was this translation helpful? Give feedback.
-
|
When you update your observing to ViewState you will need to make sure that that update happens all the way from the root of your app to the leaf feature. Just updating the leaf feature to observe view state is not enough if you have a parent that happens to be observing { $0 }. |
Beta Was this translation helpful? Give feedback.
-
|
This |
Beta Was this translation helpful? Give feedback.
-
|
I'm getting the dreaded "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" error when trying to use Removing the presentation specific augmentations in the feature (@presentation, PresentationAction, etc.) and adding an HistoryListFeature.... Also, is there a corresponding In addition, it seems like there is a gap in Apple's |
Beta Was this translation helpful? Give feedback.
-
|
Also, it seems like we'll need a |
Beta Was this translation helpful? Give feedback.
-
|
Hi @lightandshadow68, good catch! We don't support |
Beta Was this translation helpful? Give feedback.
-
|
Any news regarding the |
Beta Was this translation helpful? Give feedback.
-
|
Yes this is supported. Is it not working for you? |
Beta Was this translation helpful? Give feedback.
-
|
My bad. |
Beta Was this translation helpful? Give feedback.
-
|
On macOS, when I send
But actually, when I call
I guess the current implementation was done with iOS in mind. The behavior may need to be adjusted for macOS. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, looking more closely, you don't have a presented view in the first place that dismiss could get rid of. You would need this view to have associated optional state that drives the presentation of it using PresentationState. |
Beta Was this translation helpful? Give feedback.
-
|
@oliverfoggin Don't know what you're talking about. How can I have a parent on the app level? I'm talking about window management here. It should work on the top-level without a child, No? 🤷♂️ |
Beta Was this translation helpful? Give feedback.
-
|
@Jeehut You need to re-evaluate what the You are using it in a place that has no parent or child state. So it cannot work in the way that you are using it. SwiftUI.dismiss is not the same as TCA.dismiss. The way they work is fundamentally different. |
Beta Was this translation helpful? Give feedback.
-
|
For the TCA dismiss to work you first need to present some view by setting some PresentationState to be non-nil. This then triggers a view associated with that state to be presented. Then when you run the associated Without the state set up in that way the dismiss action won't do anything. Which is what the error message is telling you. |
Beta Was this translation helpful? Give feedback.
-
|
I totally get the error and the current behavior. But I don't think a dependency in TCA should be called dismiss if it doesn't behave like the SwiftUI dismiss. I would expect it to work here, too. If not, it should have a different name or it will confuse anyone else working on the Mac. |
Beta Was this translation helpful? Give feedback.
-
|
I noticed that there is no counterpart of extension View {
@ViewBuilder
public func alert<State, Action: Equatable, AlertAction>(
store: Store<PresentationState<State>, PresentationAction<Action>>,
state toDestinationState: @escaping (State) -> AlertState<AlertAction>?,
action fromDestinationAction: @escaping (AlertAction) -> Action,
dismiss: Action
) -> some View {
self.alert(
store.scope(
state: {
$0.wrappedValue
.flatMap(toDestinationState)
.flatMap {
$0.map {
$0.map(fromDestinationAction)
}
}
},
action: {
.presented($0)
}
),
dismiss: dismiss
)
}
}However, when using this helper function in following demo, an runtime warning occurs. import ComposableArchitecture
import SwiftUI
struct AlertDemo: Reducer {
struct State: Equatable {
@PresentationState var destination: Destination.State?
}
enum Action: Equatable {
case showAlert
case destination(PresentationAction<Destination.Action>)
}
struct Destination: Reducer {
enum State: Equatable {
case alert(AlertState<Action.Alert>)
}
enum Action: Equatable {
case alert(Alert)
enum Alert: Equatable {
case dismiss
case confirm
}
}
var body: some ReducerOf<Self> {
EmptyReducer()
}
}
var body: some ReducerOf<Self> {
Reduce { state, action in
switch action {
case .showAlert:
state.destination = .alert(
AlertState(
title: TextState("Alert Demo"),
message: TextState("This is an Alert"),
primaryButton: .cancel(TextState("Cancel")),
secondaryButton: .destructive(
TextState("Confirm"),
action: .send(.confirm)
)
)
)
return .none
case .destination:
return .none
}
}
.ifLet(
\.$destination,
action: /Action.destination,
then: Destination.init
)
}
}
struct AlertDemoView: View {
let store: StoreOf<AlertDemo>
var body: some View {
WithViewStore(self.store, observe: { $0 }) { viewStore in
Button {
viewStore.send(.showAlert)
} label: {
Text("Show Alert")
}
.alert(
store: self.store.scope(
state: \.$destination,
action: AlertDemo.Action.destination
),
state: /AlertDemo.Destination.State.alert,
action: AlertDemo.Destination.Action.alert,
dismiss: .alert(.dismiss)
)
}
}
}
So when I hit the
It seems after receiving How to avoid this? |
Beta Was this translation helpful? Give feedback.
-
|
@ylorn It looks like you're using the older |
Beta Was this translation helpful? Give feedback.
-
|
@stephencelis Yes, we did. But the newer version that does not requires a |
Beta Was this translation helpful? Give feedback.
-
|
I am trying to follow episode 224, in particular to introduce a add item sheet to my sample app. import SwiftUI
import ComposableArchitecture
@main
struct sampleSheetsNotWorkingTCA_BikesApp: App {
var body: some Scene {
WindowGroup {
BikesView(
store: ItemsDomain.sampleStore
)
}
}
}
struct ItemsDomain: ReducerProtocol {
struct State: Equatable {
var items: IdentifiedArrayOf<Item>
@PresentationState var addItem: ItemDomain.State?
}
enum Action {
case addItem(SheetAction<ItemDomain.Action>)
}
var body: some ReducerProtocolOf<Self> {
Reduce { state, action in
switch action {
case .addItem(_):
return .none
}
}
// This throws the compiler error
// "Cannot infer key path type from context; consider explicitly specifying a root type"
.sheet(state: \.addItem, action: /Action.addItem) {
ItemDomain()
}
}
}
enum SheetAction<Action> {
case dismiss
case presented(Action)
}
extension SheetAction: Equatable where Action: Equatable {}
struct BikesView: View {
let store: StoreOf<ItemsDomain>
var body: some View {
WithViewStore(self.store, observe: \.items ) { itemsStore in
NavigationStack {
List {
ForEach(itemsStore.state) { item in
Text(item.id.uuidString)
.font(.caption)
}
}
.navigationTitle("Items")
.toolbar {
ToolbarItem(placement: .primaryAction) {
Button {
} label: {
Label("Add", systemImage: "plus")
}
}
}
}
}
//TODO: needs implementation …
// .sheet(
// store: self.store.scope(
// state: \.addItem,
// action: ItemsDomain.Action.addItem
// )
// ) { store in
// EmptyView()
// }
}
}
extension ItemsDomain {
static let sampleStore = Store(
initialState: ItemsDomain.State(
items: [
Item(
id: UUID(),
titel: "Some fancy item …"
)
]
),
reducer: ItemsDomain()
)
}
struct BikesView_Previews: PreviewProvider {
static var previews: some View {
BikesView(store: ItemsDomain.sampleStore)
}
}
struct Item: Identifiable, Equatable {
let id: UUID
var titel: String
}
struct ItemDomain: ReducerProtocol {
struct State: Equatable {
var item: Item
}
enum Action: Equatable {}
func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
.none
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Hi @appfrosch, the navigation-beta has the "final" form of the tools, whereas the episodes build the tools from scratch, so you won't be able to take what we do in the episodes and rebuild it using what's in the navigation-beta branch. In particular, there is no |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot for your explanation. Seems to be a bit early for me in this case–I guess there is going to be videos on the final version? Will have to revisit then, if so. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks all of following and contributing to the discussion here! We're kicking off a new discussion for "beta 2", so please continue there: #2048 |
Beta Was this translation helpful? Give feedback.
-
Full cover sheet showed perfectly on preview but nothing showed in simulators or real device debug prints |
Beta Was this translation helpful? Give feedback.
-
|
after close looking i found .ifLet(.$forceUpdate, action: /Action.forceUpdate) { ----} Is called before _forceUpdate: ForceUpdateFeature.State(viewState: .loaded) is updated I don't know why |
Beta Was this translation helpful? Give feedback.
-
|
Hi @BakrMohamedRBM, this discussion has been closed for awhile, and so I'm not sure why GitHub is allowing new comments to it. Can you start a new discussion, and it would be best to provide more context, and ideally a compiling project that reproduces the problem you are seeing. |
Beta Was this translation helpful? Give feedback.
-
|
Moved to #2125 |
Beta Was this translation helpful? Give feedback.
and others
-
We’ve been teasing navigation tools for the Composable Architecture for a long time, and been working on the tools for even longer, but it is finally time to get a preview of what is coming to the library.
The tools being previewed today include what has been covered in our navigation series so far (episodes #222, #223, #224), as well as a few tools that will be coming in the next few episodes. In particular, this includes the tools for dealing with alerts, confirmation dialogs, sheets, popovers, fullscreen covers, pre-iOS 16 navigation links, and
navigationDestination. Notably, this beta does not currently provide the tools for the iOS 16NavigationStack, but that will be coming soon.All of these changes are mostly backwards compatible with the most recent version of TCA (version 0.51.0 right now), which means you can point any existing project to the beta branch to get a preview of what the tools have to offer. If you experience any compiler errors please let us know.
The basics
We aren’t going to give a detailed overview of the tools in this announcement and how we motivated and designed them (that’s what the episodes are for 😀), but most of the case studies and demos in the repo have been updated to use the new tools and there is an extensive test suite. There hasn’t been much documentation written yet, but that will be coming soon as the episode series plays out.
Here is a very quick overview of what you can look forward to:
When a parent feature needs to navigate to a child feature you will enhance its domain using the new
@PresentationStateproperty wrapper andPresentationActionwrapper type:Then you will make use of the new, special
ifLetreducer operator that can single out the presentation state and action and run the child feature on that state when it is active:That is all that is needed as far as the domain and reducer is concerned. The
ifLetoperator has been with the library since the beginning, but is now enhanced with super powers, including automatically cancelling child effects when the child is dismissed, and a lot more.There is one last thing you need to do, and that’s in the view. There are special overloads of all the SwiftUI navigation APIs (such as
.alert,.sheet,.popover,.navigationDestinationetc.) that take a store instead of a binding. If you provide a store focused on presentation state and actions, it will take care of the rest. For example, if the child feature is shown in a sheet, you will do the following:And that is basically it. There’s still a lot more to the tools and things to learn, but we will leave it at that and we encourage you to explore the branch when you get a chance.
1.0 Preview
As you may have heard recently we have a 1.0 preview available to everyone who wants a peek at what APIs will be renamed and removed for the 1.0 release. Currently that branch is targeting
main, but soon it will target thisnavigation-betabranch, which means you can simultaneously see how to modernize your codebase for the 1.0 and check out the new navigation tools.Trying the beta
To give the beta a shot, update your SPM dependencies to point to the
navigation-betabranch:This branch also includes updated demo applications using these APIs, so check them out if you're curious!
We really think these tools will make TCA even more fun and easier to use! If you take things for a spin, please let us know (via Twitter, Mastodon or GitHub discussions) if you have any questions, comments, concerns, or suggestions!
Beta Was this translation helpful? Give feedback.
All reactions