Another subject from my previous posts

• Basics
• Reducer and Actions
• Unidirectional flow
• Side effects
• Usage
• State normalization
• State composition
• Reducer composition
• Derived stores

which plays very nice in conjunction with a Redux-like state container, and this is Container Views. Container Views help us to keep our SwiftUI views simple and responsible for only one job.

The main idea is dividing your views into two types: Container Views and Rendering Views. The Rendering View is responsible for drawing the content, and that’s all. So basically it should not store the state or handle any lifecycle event. It usually renders the data which you pass via the init method.

Container View, on another hand, is responsible for handling data-flow and lifecycle events by providing the functions/closures to a Rendering View.

Let’s take a look at a simple example.

import SwiftUI

struct SearchContainerView: View {
    @EnvironmentObject var store: ReposStore
    @State private var query: String = "Swift"

    var body: some View {
        SearchView(query: $query, repos: store.repos, onCommit: fetch)
            .onAppear(perform: fetch)
    }

    private func fetch() {
        store.fetch(matching: 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)
        }
    }
}

struct ReposView: View {
    let repos: [Repo]

    var body: some View {
        ForEach(repos) { repo in
            HStack(alignment: .top) {
                VStack(alignment: .leading) {
                    Text(repo.name)
                        .font(.headline)
                    Text(repo.description ?? "")
                        .font(.subheadline)
                }
            }
        }
    }
}

You can see how we build a connection between Container and Rendering views. Container View provides the data to Rendering Views. By doing this, we can easily reuse our ReposView anywhere across the app. ReposView doesn’t have any dependency on some state or datastore and gets all the needed data via the init method.

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