Question

What would cause a view not to appear after pushing a screen onto the nav stack?

Problem description

I added debug() to my navigator. On the left is the initial navigation event that happens when the app loads. On the right is after sending a navigation event like this:

environment.navigator.go(to: TabNavigationScreen(), on: screenID)

where screenID is the ID of the screen that has the button. It also happens to be the root screen, i.e. 00000000-0000-0000-0000-000000000000.

I don't have a concise code sample to post, and I'll be making a sample project as my next debugging step, but I wanted to post this in case there was something obvious I was missing. How can I get hasAppeared: false to turn into hasAppeared: true?

Question

[//]: # Is it possible to have a Screen that contains itself in its nesting?

(I'm not sure if this is more of a question or a bug)

Problem description

[//]: # I first observed this behavior when I had a screen (A) that could nest a screen (B) that could then nest the original screen (A) again. The compiler would crash with the error Illegal instruction: 4. I was able to reproduce the issue in the example and it happens if you simply try to nest screen A inside of screen A.

Is there a recommended approach to solve this issue?

struct DetailScreen: Screen {
  let train: Train
  let presentationStyle: ScreenPresentationStyle = .push
  
  struct Builder: NavigationTree {
    var builder: some PathBuilder {
      Screen(
        content: { (screen: DetailScreen) in
          DetailView(train: screen.train)
        },
        nesting: {
          CapacityScreen.Builder()
            DetailScreen.Builder()
        }
      )
    }
  }
}

I forked the example to modify it and show the issue here: https://github.com/andrewjmeier/swift-composable-navigator/blob/main/Example/Vanilla%20SwiftUI%20Example/Vanilla%20SwiftUI%20Example/DetailView.swift#L16

Dear users of The Composable Navigator, Unfortunately, I must inform you that I will no longer continue to maintain this project. This has several reasons, first of all taking care of my mental health.

Over the last year, like many of you, I have been working from home and the boundaries of work and life have blurred over time. This led to my mind not being able to shut down, even after I closed the lid of my laptop in the evening. While changing jobs in May last year has definitely improved the situation, I noticed that being the single maintainer of an open source project created a lot of extra pressure to deliver and perform with an invisible set of eyes watching. This project is one of the few reasons I developed a minor case of burnout and fell into a depression over the course of the year.

To take back my life and enjoy every second of it, I have taken some steps to reduce the amount of stress I am exposed to and part of these steps is stepping back as a maintainer of this project. This allows me to let go of the negative feelings attached to it.

I am grateful that so many of you have used or at least tried this framework. There are not many alternatives out there, but I would recommend checking out Stinsen (rundfunk47/stinsen: Coordinators in SwiftUI. Simple, powerful and elegant.) and the PointFree episodes on navigation in SwiftUI.

Have a great 2022 and stay safe. If you ever feel like you’re running out of energy and that nothing in life has a purpose, get help and talk to people. Life is way too precious to be miserable.

_ Daniel

Resolves #58.

Problem

Currently, ComposableNavigator is very TCA focused and assumes that people "hand-down" their view models into the NavigationTree. Flutter solves this by wrapping Widgets in ProviderWidgets that take care of initialising the Widget's dependencies and handing it down the WidgetTree through the context.

As NavigationTrees and View Hierarchies are regenerated whenever the path changes, NavigationTree/Views cannot retain ViewModels / ObservableObjects themselves as they would be reinitialised on every redraw.

Solution

Provider takes care of initialising and retaining screen dependencies. Dependencies are stored in a screen scope in a global DependencyStore. When a path builder builds its content, the Provider view is built and initialises the dependency once. Whenever a screen is removed from the navigation path, the dependency is removed from the store.

Draft

This PR is currently marked as draft as I want to add an example of provider usage to the Readme and Example app.

Resolves #49.

Problem

ResultBuilder are now officially introduced in Swift 5.4. Using PathBuilders.name feels a bit clunky especially comparing it to 'native' SwiftUI. The idea was to come up with a DSL-like language that would allow PathBuilder composition.

Solution

I wanted to give ResultBuilders a try and came up with a NavigationTree builder. A NavigationTree is composed of PathBuilders and exposes a 'builder' attribute. The builder attribute is marked with @NavigationTreeBuilder which takes care of PathBuilder composition. As PathBuilders are now always 're-initialized' when they're used, I had to move over to a more functional approach in which a PathBuilder builds a single PathUpdate into a View that makes sure to build the path's tail. Because of this approach, I had to ensure that .build(path:) is only called once per PathUpdate, as any PathBuilders with side effects like onDismiss would retrigger their side effects on each build.

As part of this PR, the Routed view gets renamed to NavigationNode. I was looking for a better name for Routed for quite a while now and I think NavigationNode is quite fitting: NavigationNode displays the content of a PathElement and builds its successor whenever the path changes. This also means that conditions in the PathBuilder are only evaluated whenever the path changes. We'll have to come up with Trigger system that allows to 'force-rebuild' the path when a condition changes. Or we might just wrap the outcome of conditional builders in another view that checks the condition and forces a rebuild when the condition value changes? We should address this in a separate issue.

Question

How to ensure that ViewModel would be initialized once?

Problem description

I am wondering what should I do to be sure that ViewModel object would be initialized once, because in my current implementation it doesn't work as I expect.

Here is my Screen:

struct TestScreen: Screen {
    var presentationStyle: ScreenPresentationStyle = .push
    
    struct Builder: NavigationTree {
        var builder: some PathBuilder {
            Screen(
                TestScreen.self,
                content: {
                    TestView(viewModel: .init()) // <- called multiple times.
                },
                nesting: {
                    TestSecondScreen.Builder()
                }
            )
        }
    }
}

So I changed implementation of Screen to:

struct TestScreen: Screen {
    var presentationStyle: ScreenPresentationStyle = .push
    
    struct Builder: NavigationTree {
        let viewModel: TestViewModel = .init()

        var builder: some PathBuilder {
            Screen(
                TestScreen.self,
                content: {
                    TestView(viewModel: viewModel) // <- called multiple times, but ViewModel is the same.
                },
                nesting: {
                    TestSecondScreen.Builder()
                }
            )
        }
    }
}

But when it comes to initialize ViewModel that expects data previous implementation won't work. Here is the example of what I have in that case:

struct TestSecondScreen: Screen {
    let title: String
    let id: String
    
    var presentationStyle: ScreenPresentationStyle = .push
    
    struct Builder: NavigationTree {
        var builder: some PathBuilder {
            Screen(
                content: { (screen: TestSecondScreen) in
                    TestSecondView(viewModel: .init(id: screen.id), title: screen.title)
                }
            )
        }
    }
}

Problem

Danger fails on PRs from forks.

Solution

According to https://github.com/danger/danger/issues/1103, setting the fetch-depth to 0, i.e. fetching all branches and tags, should fix this.

Problem

We are currently lacking a CODEOWNERS, MAINTAINERS and CONTRIBUTING files, which are common practice in open source projects. Also, our contribution process is not defined in the README.

Solution

Add the mentioned files. Outline the contribution process.

• Fix typo in main README
• Add Example README with installation steps

Problem

The Example app was missing installation steps

Solution

Add a minimal Example/README.md

Bug description

The main Xcode project file is not committed into the repo. When cloning and opening the Example workspace there is a missing Xcode project file reference.

Steps to reproduce

Clone open the workspace in Example folder. Hit run.

Expected behavior

Example should build and run.

Environment

• Xcode 12.4 / 12.5 beta 3
• Swift Xcode version.

Resolves #62.

Problem

As described in #62, circular navigation paths currently lead to failing builds as the compiler is not able to resolve recursive content types.

Solution

Allow erasing circular navigation paths to AnyView. This has a performance impact as SwiftUI will no longer be able to use the View type to perform its diffing for all erased successors. As circular paths are the exception and not the rule, I think this is fine for now.

Bug description

Basically on startup the app will show AScreen with a variable value of nil to display a loading screen. The deeplinker will parse the link into the following path [AScreen(value: 20), BScreen()]. Since the deeplinker uses replace(path:) it will successfully replace AScreen but fails at presenting BScreen. Parsing the link so that the value of AScreen is nil will present BScreen fine. So it seems the issue is with the value changing.

Steps to reproduce

Example App

Using the code below seems to solve the issue

extension Screen {
    static func == (lhs: Self, rhs: Self) -> Bool {
        lhs.presentationStyle == rhs.presentationStyle && type(of: lhs) == type(of: rhs)
    }
}

public extension AnyScreen {
    static func == (lhs: Self, rhs: Self) -> Bool {
        lhs.screen == rhs.screen
    }
}

Expected behavior

App should navigate to BScreen even when the value in AScreen changes

Environment

• Xcode 13
• Swift 5.3
• OS: iOS 15
• Package v0.2.0

Additional context

Related: https://github.com/Bahn-X/swift-composable-navigator/issues/74#issuecomment-979748812

Question

Is it possible to find out when the screen for a particular ScreenID is permanently dismissed? By "permanently" I mean that if the same screen is presented again, it would have a different ScreenID?

Problem description

I'm wrapping an analytics library that has strong ties to UIKit. In particular, it has the concept of a "page" object that is tied to the lifecycle of a UIViewController in memory. I'm trying to replicate this behavior with SwiftUI Views. I can't use onDisappear because that is triggered if a view is covered by a nav push, and in UIKit, views don't get deallocated when they're covered by navigation.

I tried attaching a @StateObject to my views, and having it notify on deinit, but @StateObject seems not to make guarantees about when or if it will deallocate things.

My current thinking is to keep a dictionary that maps ScreenIDs to my analytics page objects, and remove them from the array when a ScreenID becomes invalid. But I would need the composable navigator to tell me when that happens, and I'm not sure if that's possible. I'm thinking something like:

// naming subject to discussion
Navigator.Datasource(root: someRoot, screenIDDidBecomeInvalid: { screenID in
})

I'm not super familiar with the composable navigator's API surface, so maybe there's a better place to put it, but that's the gist of what I'm looking for.

Bug description

[//]: # Using goBack to navigate back to a previous screen doesn't dismiss all of the views when each view is presented modally.

Steps to reproduce

[//]: # Open a series of at least 3 modal views and then try to navigate back to the original view. One modal view will remain.

struct RootView: View {
    
    var body: some View {
        let dataSource = Navigator.Datasource(root: MainScreen())
        let navigator = Navigator(dataSource: dataSource)
        
        return Root(dataSource: dataSource, navigator: navigator, pathBuilder: MainScreen.Builder())
    }
    
}

struct MainScreen: Screen {
    
    var presentationStyle: ScreenPresentationStyle = .push
    
    struct Builder: NavigationTree {
        var builder: some PathBuilder {
            Screen(
                content: { (_: MainScreen) in MainView() },
                nesting: { ModalScreen.Builder().eraseCircularNavigationPath() }
            )
        }
    }
}

struct MainView: View {
    @Environment(\.navigator) private var navigator
    @Environment(\.currentScreenID) private var currentScreenID
    
    var body: some View {
        VStack {
            Button {
                navigator.go(to: ModalScreen(viewCount: 1, onDismiss: {
                    print(currentScreenID)
                    navigator.goBack(to: currentScreenID)
                }), on: currentScreenID)
            } label: {
                Text("Show new view")
            }
        }
    }
}

struct ModalScreen: Screen {
    
    var presentationStyle: ScreenPresentationStyle = .sheet(allowsPush: true)
    var viewCount: Int
    var onDismiss: () -> Void
    
    struct Builder: NavigationTree {
        var builder: some PathBuilder {
            Screen(
                content: { (screen: ModalScreen) in ModalView(viewCount: screen.viewCount, onDismiss: screen.onDismiss) },
                nesting: { ModalScreen.Builder().eraseCircularNavigationPath() }
            )
        }
    }
}

extension ModalScreen: Equatable {
    
    static func == (lhs: ModalScreen, rhs: ModalScreen) -> Bool {
        return lhs.viewCount == rhs.viewCount
    }
    
}

extension ModalScreen: Hashable {
    func hash(into hasher: inout Hasher) {
        hasher.combine(viewCount)
    }
}

struct ModalView: View {
    @Environment(\.navigator) private var navigator
    @Environment(\.currentScreenID) private var currentScreenID
    
    var viewCount: Int
    var onDismiss: () -> Void
    
    var body: some View {
        VStack {
            Text("View \(viewCount)")
            Button {
                navigator.go(to: ModalScreen(viewCount: viewCount + 1, onDismiss: onDismiss), on: currentScreenID)
            } label: {
                Text("Show new view")
            }
            Button {
                onDismiss()
            } label: {
                Text("dismiss all views")
            }
        }
    }
    
}

Expected behavior

[//]: I would expect the original screen to be fully visible and all of the modal views to be dismissed.

Screenshots

[//]:

Environment

• Xcode 12.5
• Swift 5.4
• iOS 14

Helps with #19.

Problem

To enable Tab bar supports, we need to refactor all Navigation path mutations.

• [x] path

• [x] lastOccurenceOf(screen) -> ScreenID

• [x] goTo(id:)

• [x] goTo(screen:)

• [x] go(to newPath: [AnyScreen], on: id)

• [x] go(to newPath: [AnyScreen], on: id)

• [x] goBack(to: id)

• [x] goBack(to: screen)

• [x] replacePath

• [x] dismiss(id)

• [x] dismiss(screen)

• [x] dismissSuccessorOf(id)

• [x] dismissSuccessorOf(screen)

• [x] replaceContent(of: id)

• [x] replaceContent(of: screen)

• [x] setActive(id)

• [x] setActive(screen)

• [x] didAppear(id)

• [x] View layer for native tab bar

• [x] initialiseDefaultContents(for screenID:, contents)

• [ ] check onDismiss and see if adjustments are needed

• [ ] add tab bar to example app, write UI tests

• [ ] pushing content onto the tab view

Solution

Do it. And write tests for it, to make sure nothing breaks. 🚀

Bug description

GITHUB_TOKEN does not have write permission, i.e. cannot comment on issues, in PRs triggered from forks.

Steps to reproduce

Open a pull request from a fork. Danger fails.

Expected behavior

Danger succeeds and posts a comment.

Solution

Add a bot user with write permission on issues / PRs and expose a personal access token of said user to the PR workflows. (See Danger docs)