DEV Community

Cover image for Using Container Views with Redux-like state container
Sergey Leschev
Sergey Leschev

Posted on • Updated on

Using Container Views with Redux-like state container

During my transition from multiple 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)
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
germanxp profile image
German

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.result

Collapse
 
sergeyleschev profile image
Sergey Leschev

Selectors and middleware are 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 - selectors and middleware.