Name spacing conventions

[kdeda]

I'm asking for recommendations on Swift name spacing.
For example do we follow something like this ?

// option 1
struct Root {
    struct State: Equatable {
    }
    
    enum Action: Equatable {
    }

    struct Environment {
    }
}

or this

// option 2
struct RootState: Equatable {
}
    
enum RootAction: Equatable {
}

struct RootEnvironment {
}

Coming from java I find the swift name spacing kind of odd.

[tgrapperon]

I think it's up to you!

I'm personally using the second approach for my TCA features, because I'm starting to get confused once everyone is a State! This can also be problematic in SwiftUI because it can interfere with @State or @Environment if you're hosting a View inside Root.

If you're not using generics in Root, I don't see any other limitation right now between the two configurations. Otherwise, you will be prevented to conform your inner types (like State) to some protocols (like Equatable) in extensions, that it, you will need to conform to protocols in place, where the types are defined.

In other words, the first option has a few caveats, whereas the second has none I can think of, so I'd keep using the second approach, but this is mostly a personal taste (or a style-guide convention if you're following any!).

I would bet most TCA users are using the second approach for their features.

[kdeda]

I can see how the following (kept short for brevity)

struct RootDomain {
    struct State: Equatable {
    }
    
    enum Action: Equatable {
    }

    struct Environment {
    }
}

Could be fairly clean.
Thanks.

[siejkowski]

Caseless enums are usually used for namespacing both by the community and by Apple (e.g. https://developer.apple.com/documentation/combine/publishers). So you can use:

enum RootDomain {
    struct State: Equatable {
    }
    
    enum Action: Equatable {
    }

    struct Environment {
    }
}

I've used that style in one project but I've abandoned it because it was causing Xcode to lose the code completion and syntax highlighting all the time. With the recent fixes to Xcode 12.5 it might be a right time to try this structure again.

[kdeda]

Indeed, I left things empty for brevity.
The whole name spacing in swift is odd, it seems like half objc half java

[tgrapperon]

@siejkowski You're perfectly right! I misread the question and thought it was related to TCA features only. I've updated my response to make it clearer it concerned TCA features.

I'm using the nested namespacing in many places in my code, generally for semantically related types. For example, I'm defining many internal types (mostly enums) when they're used only by internal properties, like Configuration, DisplayMode, etc.

I also have a few data structures where I'm nesting wrappers. I don't think there's something wrong with nested namespacing in general Swift, other than a few limitations I've mentioned above (and maybe others I'm not aware of).

For TCA features however, I'm using the flat approach, mostly because I find it easier to refactor as I'm iterating while building the app. I don't really see the point in namespacing the feature's TCA types without namespacing the view, and I had a very bad experience while nesting the View alongside State, Action and Environment, with SwiftUI's @Environment/@State being shadowed by my feature's types, so I dropped the idea and went with the flat approach.
I guess SPM modularization can also defer the role of the RootDomain enum/struct to the module's name. It should look very similar for clients at call-site.

I'm also defining very concise fileprivate (or nested) typealiases for all my TCA states and actions (namely S and A), and I usually only have to write the full type names for exposed initializers. It is very convenient in views and reducers when scoping/pulling-back.

[AlexisQapa]

I use the flat approach but use Screen instead or View for the main view of the feature. State and Environment are only used in specific situations with TCA so I don't mind using @swiftui.State in those cases. I find really nice to use MyFeature.State outside of the feature but inside juste plain State. SPM made it very convenient to create modules without configuration or merge issues.

[maximkrouk]

I use this template for creating new modules (each module is a spm target, see isowords repo)
TCAModuleTemplate.zip

Also, at my spare time, I develop a cool code-generator, hopefully, mvp will be released at the end of July 🙂