undefined | Better HN

0 pointsmonocularvision3y ago0 comments

1. I can’t say I have found any real downsides yet. We have had to make improvements to support new capabilities, but it has been surprisingly easy to do so. Our most recent improvement was to formalize the concept of MVVM so that our ViewModels essentially acted in the same way as our Feature types. It allows us to continue using almost the same pattern at individual screen that we have been using at the feature level.

Our next big effort will be fitting the architecture into SwiftUI, which I think will actually be also straightforward since SwiftUI is extremely functional.

2. Onboarding is probably the biggest “downside”. I would say there is absolutely a learning curve that requires some investment but everyone I speak to about it has been pretty positive after getting over that hurdle. And it feels like our productivity is very high.

3. Android does not follow the same pattern. I am planning on sharing your article with the team though. :-)

0 comments

2 comments · 1 top-level

kodroid3y ago· 1 in thread

Thanks. I love to see a description of that formalisation, if you ever get round to publishing it.

monocularvisionOP3y ago

It’s really as simple as this:

1. Create a struct (value type in Swift) that implements a protocol (interface) to serve as your ViewModel 2. The main methods to implement are both called “update”. One is called automatically by our infrastructure when Feature state (state that exists across screens) changes. The other is called by the developer in their view controllers to pass along user actions (or other UIKit events). 3. The developer subscribed to all VM changes and updates the view in response. This subscription is done via Combine which is Apple’s FRP framework.

I am planning on writing more about this and the rest of our architecture in the future, hopefully.

j / k navigate · click thread line to collapse