Verge — Start “store-pattern” state management before beginning Flux in UIKit iOS app development — preparation starting SwiftUI
In the development of the app that is kind of SNS or large application, it can often grow in complexity due to display a massive number of a state(data) correctly that scattered across many UI components.
Primarily, UIKit applications differ with Data-driven UI frameworks such as React and Vue, it functions as Event-driven, and each component(e.g., UIView) has a state itself. This means the number of the state that we should handle is so much larger than Data-driven application.
In this article, I introduce this framework Verge in iOS app development and what it allows us.
Manages the state with Store-pattern
Lately, Flux state management strategy has been started to be used in mainly web-application.
As my thought, what the point of Flux is to manage the application state into one or more storage/store(less is better). It clears where the source of truth is.
It does not mean using “dispatch” “action” “mutation” something else. These keywords are used to update the managed state.
So we could say using the Flux if we manage the state in a store and using some way to update the state whatever.
However, Vue uses another word “Store-pattern” to be clear that meaning manages the state into storage.
If you’re not familiar with Flux, you can get the detail of that from Vue/Vuex documentation site. They good describe flux architecture with many small examples.
(As an iOS Engineer, it’s not easy to understand Vue immediately, but you can get things to step by step.)
Start Store-pattern in iOS with vanilla Swift and then convert to Verge
Let’s take a look at how we could do this in Swift.
In the example, it uses UIView as a component and how they manage a state and display.
Firstly, we have a UIView that includes UILabel and a single value (name) to display to the label.
name property updates nameLabel.text when itself updated.
We can say name is source of truth except for using nameLabel.text directly.
Next, add another UILabel and regarding value property.
It seems fine. However, it seems it would be complex with getting more child components and properties.
In this case, we can integrate these states into a single struct.
It’s simplified looks. and we can find all of the states what ViewA has from State struct.
Next, I’ll show you the large code snippet but it’s not so complicated, I just added another UIView component.
Because it’s for sharing the state between each view.
If the state changed, each view must display the latest value quickly.
ViewA and ViewB are almost the same, just like copied.
And I created a Store object to share the state with each view.
It uses class-type (reference type) to implement, manages the current state inside, when receive updates for the state, update the current value and then notify the event for updates to subscribers.
If you’re familiar with RxSwift or Combine else, you can imagine with Variable, BehaviorSubject, BehaviorRelay, CurrentValueSubject.
Store object implementations are mock for example, so it does not work.
Please take a look at only their interface.
By the way, you should care about the event of the state update, you will get the event every time when the state updated even if it does not need that state for the component.
That is the difficult point of the implementation in UIKit based application.
You should exactly update the value of a component when there is a difference.
It means like this,
Firstly Store becomes to emits update events contains an old and current value.
We got this the UI updates their value performantly.
It checks the target value has been changed before assign that to the component. It helps to avoid the component performs with the same value.
(Same text rendering, something else performs inside a component (UILabel UIImage, etc))
Although this checking approach is necessary, it would grow in complexity and verbosity.
Next section, we refine these codes with Verge.
Refine with Verge
Verge is a library for iOS applications due to manage the state from the store.
About Verge — Verge supports performance issues in Flux architecture
Verge has much stuff to solve some issues in using Flux architecture. Mainly performance issues by using a single large state.
However, we don’t need to know that exactly from the beginning.
It would be helpful when the application has scaled up.
I can also say we can’t avoid using this stuff because of performance issues might be serious frequently.
If you have faced some issues in flux, please check the stuff in Verge.
For example Derived and VergeORM
Verge has Store object that differs from one in the previous example.
Functions are almost the same and it supports thread-safety.
As this code shows, we can get a changes object inside call-back closure.
This object provides several functions to perform any operations regarding the state changes.
In this code, it uses ifChanged method that performs specified closure if the specified state updated. Now no needs to type the same property name twice.
Call commit method to Store to update its state.
This method performs well in multi-threading. however, we should take care about update callback closure will be called on the thread that commit fired.
Start using Flux with Verge and prepare for SwiftUI
This article showed a part of Verge’s functions.
Actually, Verge supports more technical cases, you should check the detail of Verge from the link below if you like it.
And now iOS engineers waiting for starting to use SwiftUI in all cases application.
In SwiftUI, the state management strategy thing would be more important than UIKit world, because SwiftUI runs Data-driven such as React / Vue.
To prepare using SwiftUI, we can start to refine our state management in the current project that still uses UIKit.
I work for a large application, we started preparing for that with Verge.
Thanks.
If you enjoyed this article follow me on Twitter or GitHub.
I post more content and works in OSS that focus on real-world large application.
Here is the list of OSS what I created
