Hi lucaquerella. I've been working on a similar bit (minus the React-inspired UI) here (combining ReSwift with app coordinators): https://github.com/willowtreeapps/cordux
We've also found reproducing the UI via state to be a huge win. We're using FBSnapshotTestCase to generate snapshots of our app across different controllers with different states, automated to take snapshots on different devices and in different orientations.
Glad to see other people are pursuing these ideas!
I've been working on an app that's more or less using ReSwift (I've hacked on it a bit). Can you elaborate on what you ran into that was complex/horrible?
I couldn't fix a lot of UI problems because when trying to trace what was happening through this system of actions and states I could only find when these bugs occurred when stepping between lines of machine code.
I can't offer a fair point of view because I don't think the project I was working on made proper use of ReSwift. It was very difficult to follow the flow of data and understand why certain things wouldn't work.
What you're describing doesn't really make any sense... the whole point of these frameworks is to make your application more predictable. If your layout isn't right for a particular state, you can rewind back to that exact state again and again. It sounds like you were using ReSwift wrong, to be honest. There's not a lot of magic going on in it that would make it hard to debug.
I've been working with and on a project that uses a similar architecture. At least, it's using a Redux-like dataflow borrowed from ReSwift; views are standard iOS.
The benefits I've seen so far:
- Swift's type safety means you can validate at the type level that your app state is correct. As in, you could have an enum with separate cases for your authenticated and unauthenticated states, instead of optional values to indicate what state you're in. This makes your state stronger, in that the types hold only valid states rather than some possible states being invalid (e.g. unauthenticated with non-nil user info).
- State transitions -- reducer methods, (state,action) -> state -- are purely functional which makes (IMHO) feature work straightforward, testing trivial, and debugging fairly easy.
- Your view controllers become super dumb. All they have to do is render the data and relay input events. This is a nice clean separation of concerns.
- If your navigation route is managed in state, you get deep linking "for free". This is especially helpful in one of our apps for handling global errors that could occur on any network request (update state, route to error).
- Every bit of code has an easily identifiable home.
- Communicating between view controllers is simple. Rather than "passing the baton" as state is accumulated (say a multistep form), state accumulates naturally in the store.
All that said, I still consider this an experiment. We've written about 40-50k lines of Swift across two apps with 8 developers so far, and opinions are mixed between considering it excellent and considering it burdensome.
WillowTree, Inc - Mobile and Web Apps
ONSITE in Charlottesville, VA or Durham, NC (Research Triangle)
Roles: iOS Engineer, Android Engineer, Web Developer, General Engineer
We're an apps agency that works with brand name clients. We're ranked one of the best places to work by GlassDoor [0] and Fortune [1]. I can confirm that it's a pretty sweet gig if you like the locations (I do).
https://en.wikipedia.org/wiki/Contraposition