I see that #3 has disposed of RIBs as something that would unnecessary complicate the tutorial / example project and even obscure the subject matter. Nonetheless, it is my sincere desire to learn more about the best-practice workflows that exist when using Needle to manage RIBs components.

This command line parameter prints out the static dependency tree starting at RootComponent.

Command: needle generate NeedleGenerated.swift apps/freight/ -print-dep

Example Output:

Root
	LoggedIn
		Active
	LoggedOut
		EntryCore

Reason

Issues with Needle on Xcode 12.5 using SPM for integration.

Changes

• Updated swift-syntax to 0.50400.0 to fix _InternalSwiftSyntaxParser issue;
• Bumped Xcode on Travic CI to 12.5.

Testing

• Verified manually using SPM install and Xcode 12.5

Hi there!

I faced with the following issue using 0.16.2 version that I installed via Homebrew.

The error output looks like: error: 💩 Unknown error: SwiftSyntax parser library isn't compatible

Seems like there is a missed detail for distribution of the latest version via Homebrew.

There is no issue if I'm using the binary with the provided version of lib_InternalSwiftSyntaxParser.dylib from the repository.

The CocoaPods Specs repo does not have the most recent NeedleFoundation.podspec (v0.9.1)

This creates a discrepancy on the autogenerated code since Needle Generator will add a reference to NeedleFoundation but CocoaPods will generate Needle.framework

I would love to give it a try and maybe contribute to this project.

How am I suppose to use it? Is there some wiki page or should I look at the code?

Btw, thanks guys, highly appreciated for these efforts.

I struggle to wrap my head around memory management in Needle and I'm looking for guidance, or maybe just confirmation that I understand things well.

Non-Pluginized Components

class ParentComponent: Component<EmptyDependency> {
    var viewController: ParentVC {
        shared {
            ParentVC(childVCBuilder: childComponent)
        }
    }

    var childComponent: ChildComponent {
        ChildComponent(parent: self)
    }
}

class ParentVC: UIViewController {
    let childVCBuilder: ChildVCBuilding

    init(childVCBuilder: ChildVCBuilding) {
        self.childVCBuilder = childVCBuilder
    }
}

protocol ChildVCBuilding {
    var viewController: ChildVC { get }
}

class ChildComponent: Component<EmptyDependency>, ChildVCBuilding {
    var viewController: ChildVC {
        ChildVC()
    }
}

I expect this code to create a memory cycle (ParentComponent -> ParentVC -> ChildComponent -> ParentComponent), hence my first question: is it correct to say that a component that has children components should not use shared when creating their associated VC?

Pluginized Components

I actually have less problems with pluginized components. I understand that the plugin extension weakly (with unowned) reference the non-core component so the only potential cycle is if a developer doesn't properly bind the pluginized component to the VC.

Though, I guess it doesn't make much sense to bind a component with multiple VC, hence my second question: is it correct to say that pluginized components must always used shared when creating their associated VC?

Combining the two

Combining the two first observations, assuming they are correct, is it correct to say that a PluginizedComponent should not have children components (apart from its non-core component), otherwise we're stuck in a contradiction where the VC both must be wrapped in shared (as a pluginized component) and not wrapped in shared (as a component with children components).

As I start using Needle in my project, I frequently face the dilemna of having to heavily rely on "dynamic" dependency injection in order to avoid infinite loops. As a result, the code feels like it's not fully embracing the Needle approach.

I think the best way to explain this problem is with the following example. MyChildVC is a child VC of MyVC. The MyChildVC instance is created in MyVC.init (it could probably be done differently but it's off-topic). MyChildVC depends on a property built by MyVC itself.

I wonder if I'm missing something obvious to solve this problem and/or if there's a recommended approach to workaround this for a codebase that must scale.

// MARK: Parent component

protocol MyDependency: Dependency {}

class MyComponent: Component<MyDependency>, MyVCBuilder {
    var myVC: MyVC {
        shared {
            MyVC(
                aStreamInitialValue: 0,
                aChildVCBuilder: myChildComponent
            )
        }
    }

    var myChildComponent: MyChildComponent {
        MyChildComponent(parent: self)
    }

    var aStreamInitialValueSetupByParent: Int {
        // Refers to `myVC` before init finishes, leading to and infinite loop
        myVC.aStreamSource
    }

    var aStreamSetupByParent: AnyPublisher<Int, Never> {
        // Refers to `myVC` before init finishes, leading to and infinite loop
        myVC.$aStreamSource
    }
}

protocol MyVCBuilder {
    var myVC: MyVC { get }
}

class MyVC: UIViewController {
    @Published var aStreamSource: Int

    let childVC: MyChildVC

    init(
        aStreamInitialValue: Int,
        aChildVCBuilder: MyChildVCBuilder
    ) {
        aStreamSource = aStreamInitialValue
        
        // The "problem" illustrated with this example comes from the facts that:
        // - this builder is called in `MyVC.init` (but even if it wasn't, I'd expect the external code to be defensive)
        // - `aStream`, dependency needed by the child, is setup inside MyVC
        //
        // In a non-Needle world, I would pass `aStreamSource` and `$aStreamSource` directly into the builder here.
        // (eventually relying on "dynamic" dependency if I understand your nomenclature properly).
        // But it doesn't feel very Needle-y. Eventually, it means passing an heavy amount of dependencies "manually",
        // somewhat defeating the Needle system, and it's only to workaround an infinite loop.
        childVC = aChildVCBuilder.myChildVC

        super.init(nibName: nil, bundle: nil)
    }
}

// MARK: Child component

protocol MyChildDependency: Dependency {
    var aStreamInitialValueSetupByParent: Int
    var aStreamSetupByParent: AnyPublisher<Int, Never>
}

class MyChildComponent: MyChildVCBuilder {
    var myChildVC: MyChildVC {
        MyChildVC(
            aStreamInitialValue: dependency.aStreamInitialValueSetupByParent
            aStream: dependency.aStreamSetupByParent
        )
    }
}

protocol MyChildVCBuilder {
    var myChildVC: MyChildVC { get }
}

class MyChildVC: UIViewController {
    let aStreamInitialValue: Int
    let aStream: AnyPublisher<Int, Never>

    init(aStreamInitialValue: Int, aStream: aStream) {
        self.aStreamInitialValue = aStreamInitialValue
        self.aStream = aStream

        super.init(nibName: nil, bundle: nil)
    }
}

EDIT: I corrected the aStreamSetupByParent type issue that you mentioned in your first comment @rudro. Thanks for pointing that out.

Needle generator expects framework with name NeedleFoundation to exist. Current podspec has name Needle therefore code fails to build since there is no such pod with name NeedleFoundation.

When trying to run needle's latest release 0.16.0 we see an error that it can't find the SwiftSyntaxParser.dylib. The same was happening with mockolo at some point and mockolo is shipping the dylib with its release. The solution is probably to ship the dylib with the releases inside the Generator/bin folder. Or do you have another solution in mind?

We are looking forward to using the SwiftSyntaxParser implementation but this currently blocks updating for us.

Mockolo issue: https://github.com/uber/mockolo/issues/108

Needle codebases will end up with dependencies coming from both the component and the component's dependency protocol:

let interactor = LoggedInInteractor(loggedInStream: component.dependency.loggedInStream,
                                    networkClient: component.networkClient,
                                    appUpdater: component.dependency.appUpdater,
                                    modelProvider: component.modelProvider,
                                    modelRefresher: component.dependency.modelRefresher)

We can leverage Swift 5.1's dynamicMemberLookup keypath support to make property access consistent for all component dependencies and avoid developers the slight pain of typing component. or component.dependency. to find their dependency, and unnecessary updates during dependency refactor.

let interactor = LoggedInInteractor(loggedInStream: component.loggedInStream,
                                    networkClient: component.networkClient,
                                    appUpdater: component.appUpdater,
                                    modelProvider: component.modelProvider,
                                    modelRefresher: component.modelRefresher)

It's unclear if this issue has been around for a while or it's new in Swift 5.7/Xcode 14. We only just noticed this issue.

For our latest app, the Uber rides app, the needle generated code take over an hour to compile in Release (i.e. -Osize) mode. The issue is demonstrated in a toy project and reported here : https://github.com/apple/swift/issues/62124

The workaround for this is to add a @inline(never) to some of the functions. Until the compiler performance issue is fixed, we should use this workaround in the needle generated code.

I am going through migrating a legacy codebase onto using Needle and encountered circular dependencies. Some of my scopes have children scopes that in turn declare one of the great great parent components as their dependency, hence the dependency cycle.

The scenario I'm dealing with isn't necessarily an error - the UI I have is for users browsing through folders which means the user can open one folder and then another subfolder and then another infinitively showing the same UI/component as a child of the previous one. Think dropbox file browsing.

The issue I'm experiencing won't be a problem at runtime but since Needle is trying to resolve the dependency tree before compile time so that it can be deterministic and correct at compile time it can't really process it.

How can this be resolved? Some sort of a "break" at some point with BootstrapComponent creating a second parallel dependency tree for the part of the app I want to circularly depend on?

Seems like I'm getting double results when Needle identifies missing dependencies.

ios % needle generate upkeep/NeedleGenerated.swift Source
warning: ❗️ Could not find a provider for (userDefaults: UserDefaults) which was required by NotificationHubMenuDependency, along the DI branch of ^->AppDependencies->NotificationHubComponent->NotificationHubMenuComponent.
warning: ❗️ Could not find a provider for (userDefaults: UserDefaults) which was required by NotificationHubMenuDependency, along the DI branch of ^->AppDependencies->NotificationHubComponent->NotificationHubMenuComponent.
warning: ❗️ Missing one or more dependencies at scope.
error: 💩 Some dependencies are missing, please look at the warnings above for the list.

Is this expected or am I configuring something wrong?

I have a multi-module configuration, but if I specify a package with RootComponent, NeedleGenerated is not generated correctly.

I'll show you an example below. If you remove the HogeModule designation, it works fine.

Example

import HogeModule
final class RootComponent: BootstrapComponent {
    var hogeComponent: HogeBuilder {
        HogeModule.HogeComponent(parent: self)
    }
}

public func registerProviderFactories() {
    __DependencyProviderRegistry.instance.registerDependencyProviderFactory(for: "^->RootComponent") { component in
        return EmptyDependencyProvider(component: component)
    }   
}

The total volume of code needle produces is O(average_number_of_items_in_the_dependency_protocols x total_number_of_paths_in_the_component_tree). At Uber, the first one is slightly high maybe, but the second part is really high in our flagship apps. This is due to the total number of unique components being high and some nodes being repeated in many places.

Instead of such explicit code that we can rely on the Swift compiler to perform a second layer of safety checks for us with, we could create dictionaries at each component. Then we could rely on dynamic member lookup and then, at runtime, walk up the tree of components (to ancestors) and check on these dictionaries and check if the dictionary has the item we are looking for.