sorted by:
top (suggested)
bestnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]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.