During my transition from multiple stores
- Basics
- Reducer and Actions
- Unidirectional flow
- Side effects
- Usage
- State normalization
- State composition
- Reducer composition
- Derived stores
to a single source of truth, I realize that Container Views play a significant role in this approach. I mainly use them for sending actions to the store and mapping the global app state to Rendering View properties. Container Views perfectly fit into my current app architecture.
Let’s take a look at the example.
import SwiftUI
struct SearchContainerView: View {
@EnvironmentObject var store: AppStore
@State private var query: String = "Swift"
var body: some View {
SearchView(
query: $query,
repos: store.state.search.result,
onCommit: fetch
).onAppear(perform: fetch)
}
private func fetch() {
store.send(SideEffect.search(query))
}
}
struct SearchView: View {
@Binding var query: String
let repos: [Repo]
let onCommit: () -> Void
var body: some View {
List {
TextField("Type something", text: $query, onCommit: onCommit)
ReposView(repos: repos)
}
}
}
As you can see in the example above, Container View helps us to keep Rendering Views small and independent.
Contacts
I have a clear focus on time-to-market and don't prioritize technical debt. And I took part in the Pre-Sale/RFX activity as a System Architect, assessment efforts for Mobile (iOS-Swift, Android-Kotlin), Frontend (React-TypeScript) and Backend (NodeJS-.NET-PHP-Kafka-SQL-NoSQL). And I also formed the work of Pre-Sale as a CTO from Opportunity to Proposal via knowledge transfer to Successful Delivery.
🛩️ #startups #management #cto #swift #typescript #database
📧 Email: sergey.leschev@gmail.com
👋 LinkedIn: https://linkedin.com/in/sergeyleschev/
👋 LeetCode: https://leetcode.com/sergeyleschev/
👋 Twitter: https://twitter.com/sergeyleschev
👋 Github: https://github.com/sergeyleschev
🌎 Website: https://sergeyleschev.github.io
🌎 Reddit: https://reddit.com/user/sergeyleschev
🌎 Quora: https://quora.com/sergey-leschev
🌎 Medium: https://medium.com/@sergeyleschev
Top comments (2)
This example is great @sergeyleschev !
Have you explored alternatives to all scopes being publicly available in all views that use the Store?
i.e:
store.state.search.resultSelectorsandmiddlewareare two possible solutions.Store holds the entire state of the application, and each view can access the Store and subscribe to changes in the state. However, in large-scale applications, it's not always desirable to expose all scopes of the state to all views.
One solution to this is to use selectors. Selectors are functions that take the entire state as input and return a specific subset of the state that a particular view needs. By using selectors, views only have access to the parts of the state they need, and not the entire state.
Another approach is to use middleware. Middleware intercepts actions before they reach the Store and can modify them or dispatch additional actions based on the existing state. This approach can be used to transform the state before it reaches the views, thereby limiting the scope of the state visible to the views.
While all scopes of the state are publicly available in all views that use the Store, there are ways to limit the scope of the state visible to each view -
selectorsandmiddleware.