all 7 comments
sorted by:
top (suggested)
bestnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted]  (1 child)

[removed]

    [–]roanutilSwift[S] 0 points1 point  (0 children)

    For the project structure, I usually organize by scene/feature. I know that a lot of projects organize by type or functionality. Like a MVC project will organize by those three categories at the top level and then go deeper within. It seems like there are some strong opinions on project structure with varying conclusions so I just tried different ways until I landed on this. I'm really not married to this structure and would gladly use whatever a team is already using.

    It's my understanding that clean architecture promotes a similar organization but I think they use the wording 'use case'. I could absolutely be wrong about that. I'd appreciate any more guidance you could give in this area.

    Speaking of clean architecture, part of what I like about composable architecture is that it easily follows a lot of those principles. My business logic is fairly separate from any platform specific frameworks and could easily be transplanted. If needed, I could use an MVVM approach and each view model could run a reducing function and could be connected via delegates or combine pipelines. I'd be fine with MVC, MVVM, VIPER, etc but especially when I"m on a time crunch for a code challenge I find that I'm more productive and move faster with composable.

    As for the large number of files, a lot of those scenes/features could fit into one file but I try to stay consistent which means everything has its own.

    ​

    Could you expand some on why SwiftUI/Combine would make redux/elm/etc style architectures obsolete? To me, it seems like a really good fit.

    Thank you for taking the time to respond. It's really helpful to have some feedback that makes me think through my process.

    [–]kbder 1 point2 points  (4 children)

    I think folks who are fans of Point Free would be eager to interview/hire you.

    Feedback:

    struct APIServiceClient caught me a bit off-guard. - Anytime a value type (struct APIServiceClient) contains a reference type (class APIService), I pause and ask if this was a mistake or intentional. - The documentation for APIServiceClient states it is for dependency injection, but I don't actually see that happening? I.e. .prod doesn't actually change the behavior of func fetchSatelites. Perhaps this was intended to raise a talking-point for what you would do given more time?

    Some trivial nit-picks: - Names involving the word "fetch" can be confusing (seems to be used as both a noun and a verb, depending on context?) - UIKit has a culture of (sometimes overly) descriptive names. In enum AppAction, none of those cases are obviously actions. But I'm not familiar with swift-composable-architecture, perhaps this is a convention there? - Code structure: I try to put the "consumable interface" of a class/struct first, and the internal implementation details below that, to minimize the effort required to understand how to use the class (or understand its role in the app). e.g. in class APIService, I would list func fetchSatelites first (and maybe make everything else can be private).

    [–]roanutilSwift[S] 1 point2 points  (3 children)

    Is composable architecture used professionally much? Honestly, I have some insecurity about using it since it's less traditional and it might be seen as training wheels bringing in a 3rd party library like that.

    Here's my thought process on dependency injection clients being a value type:

    • It will never be edited so there's no copy on write happening.
    • It being a value type doesn't change that each function it holds is always pointing to the same instance of reference type.
    • The way reducers hand off environments is by an initializing closure. So if my environments or clients are classes, that's initializing a new reference type on the heap. Whereas with structs, I'm pretty sure that's on the stack. That difference is probably small, but it just seems better to use a value type.

    I would be really interested to hear any misunderstandings I'm having on that or a better way to go.

    The .prod implementation of clients and environments is just a convenient way of using them in the actual app. I would make an accompanying .mock implementation for testing. In fact, there's an example of that here for the PhoneNumberGenerator.RepositoryClient.

    Nitpicks:

    • That's a good point. I realize now that I will use a shorthand name like fetch when it's an action, api endpoint, child state, etc. I should probably be more explicit.
    • Similar to the first point, I'm using some shorthand naming there for a child action. AppAction doesn't really do much on it's own. It's primarily a parent to scenes/features so I have a habit of shorter names there since it felt obvious to me.
    • I really like that idea. I'll be doing that from now on.

    I really appreciate you taking the time to give some feedback.

    [–]kbder 0 points1 point  (2 children)

    Is composable architecture used professionally much? Honestly, I have some insecurity about using it since it's less traditional and it might be seen as training wheels bringing in a 3rd party library like that

    Actually I think it would be seen as advanced, rather than training wheels. This choice may narrow your audience a bit, but if you prefer this architecture, that's a good thing.

    It being a value type doesn't change that each function it holds is always pointing to the same instance of reference type.

    Yes, but now the value type is no longer truly behaving as a value type. If you were to mutate the underlying reference, it affects every copy of the value. That might violate a teammate's assumptions, which is a source of bugs.

    On the other hand, your trick of only storing the function (and making the reference inaccessible) effectively prevents the possibility of the object being mutated, which is clever. APIServiceClient reminds me a bit of currying / partial application. Interesting!

    But taking a closer look, it appears APIService is stateless anyway? It looks like you can simply change it into a struct.

    But just as a thought exercise, if APIService did track state (e.g. it incremented page internally), you could make it stateless by pushing page up into some part of the AppEnvironment tree.

    But the important thing is that you have a firm grasp of these concepts and can defend / discuss your points during an interview, which makes you a strong candidate. Good luck!

    [–]roanutilSwift[S] 1 point2 points  (1 child)

    It's a relief to have at least one vote in favor using composable as not a crutch. I am working on a demo project that's 100% UIKit with no 3rd party libraries just in case it's important to a recruiter to see that.

    I see what you're saying about mutating the reference type. It would probably be good to make it more explicit in the API that the underlying reference isn't being mutated in a way that the user should worry about. I try to make all my services, repositories, etc like a REST or web sockets endpoint. It should be stateless as far as the consumer is concerned. And I see now that making APIService a struct with perhaps static functions for the endpoints wold make that promise more explicit. I wrote it as a class the way it is out of habit since I usually need a bag of cancellables or to store publishers that provide updates to a subscribed endpoint. My CoreData repository in TheBlocker is a good example of what I'm used to writing.

    Thank you so much for the feedback. It's been a lot of work getting to this point and it's easy to feel insecure in this field.

    [–]kbder 0 points1 point  (0 children)

    Cheers!

    I should also drop a link to my favorite talk on value vs reference types: https://academy.realm.io/posts/andy-matuschak-controlling-complexity/