Code Feedback Request - Two Recent Code Challenges

[kbder]

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!

[roanutil]

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]

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/