Clarification on Utilizing @Preference in TCA

[BakrIOS91]

Hello TCA Team,

I hope this message finds you well. I am reaching out to seek clarification and guidance on the potential integration of the @preference property wrapper with the Swift Composable Architecture (TCA)

import SwiftUI
import Combine

@propertyWrapper
struct Preference<Value>: DynamicProperty {
    @ObservedObject private var preferencesObserver: PublisherObservableObject
    private let keyPath: ReferenceWritableKeyPath<Preferences, Value>
    private let preferences: Preferences = .shared
    
    init(
        _ keyPath: ReferenceWritableKeyPath<Preferences, Value>
    ) {
        self.keyPath = keyPath
        let publisher = preferences
            .preferencesChangedSubject
            .filter { changedKeyPath in
                changedKeyPath == keyPath
            }
            .mapToVoid()
            .eraseToAnyPublisher()
        self.preferencesObserver = .init(publisher: publisher)
    }
    
    var wrappedValue: Value {
        get {
            preferences[keyPath: keyPath]
        }
        nonmutating set {
            preferences[keyPath: keyPath] = newValue
            preferences.preferencesChangedSubject.send(keyPath)
        }
    }
    
    var projectedValue: Binding<Value> {
        Binding(
            get: { wrappedValue },
            set: { wrappedValue = $0 }
        )
    }
}

final class Preferences {
    
    static let shared = Preferences()
    private init() {}
    
    /// Sends through the changed key path whenever a change occurs.
    fileprivate var preferencesChangedSubject = PassthroughSubject<AnyKeyPath, Never>()
    
    @UserDefault(kAppLanguage)
    var locale: Locale? = .bestMatching
    
    @UserDefault(kAppIsNetworkReachable)
    var isNetworkReachable: Bool = true
    
    @UserDefault(kAppIsLoggedIn)
    var isLoggedIn: Bool = false
    
    @UserDefault(kAppTabBarHidden)
    var tabBarHidden: Bool = false
    
    @UserDefault(kAppProfile)
    var profile: Profile? = .mock
    
    @UserDefault(kAppNotificationEnabled)
    var notificationEnabled: Bool = false
    
    @UserDefault(kAppTopicRegistered)
    var isTopicRegistered: Bool = false
    
    @UserDefault(kAppRootView)
    var rootView: AppRootView = .root
    
    @UserDefault(kIsAppDarkMode)
    var isAppDarkMode: Bool = false
    
    @UserDefault(kIsFirstLaunch)
    var isFirstLaunch: Bool = true
    
    @UserDefault(kAppCred)
    var userCred: UserCred?
    
    var isForceLogout: Bool = false
    
    var didUserPressLogOut: Bool = false
    
    var selectedTabViewContent: TabViewContents = .pharmacy
    
    var popToRoot: Bool = false
    var isNavigating: Bool = false
    
    var navigationRedirectionView: NavigateRedirectionView?
    
    var notificationTargetURLPath: String?
}

usage

struct PharmacyView: View {
    @ObservedObject var viewModel: PharmacyViewModel
    @Preference(\.popToRoot) var popToRoot
    @Preference(\.isForceLogout) var isForceLogout
    
    .........

I am particularly interested in understanding whether this approach aligns with TCA principles and if there are any considerations or enhancements that could further improve its compatibility within the architecture.

Furthermore, I'm open to exploring alternative strategies that maintain a high level of reactivity without compromising app performance. If there are recommended practices or approaches to leverage UserDefaults while efficiently listening to changes without adversely affecting the app's responsiveness, I would greatly appreciate your insights.

The goal is to ensure that user preferences can be seamlessly integrated into TCA-driven applications, contributing to a more streamlined and maintainable architecture.

I appreciate your time and expertise on this matter and look forward to hearing your valuable feedback.

[mbrandonw]

Hi @BakrIOS91, as written now the @Preference property wrapper cannot be used directly in a TCA reducer, or really anywhere besides a SwiftUI view. Dynamic properties can only be used in SwiftUI views. So that also means that @Preference cannot be used in @Observable objects either.

Next week we will be releasing 1.7 of the library that includes the observation tools we have been working on for the past 2 months, and with those tools in place it greatly enhances our ability to add things like user defaults directly to reducers. That will be the next topic we discuss on Point-Free, and the next public beta.

[BakrIOS91]

Thank you so much, @mbrandonw Your assistance means a lot, and I'm genuinely looking forward to the upcoming episodes that meet these criteria. Your dedication, along with the efforts of @stephencelis and the entire team, has truly brought something incredible to the iOS world. The impact of your work is nothing short of amazing, and I can't express enough gratitude for the contributions you've all made. Excited for what's to come! 🚀 #TCA

[BakrIOS91]

@mbrandonw, my apologies for the repeated inquiry, but do you have any updates on when the observation tools will be shared? I've noticed that version 1.7 has already been published. Additionally, I'm curious if the release will include episodes or just use cases. Thank you for your assistance.

[mbrandonw]

Hi @BakrIOS91, the tools I alluded to were not apart of the 1.7 release but will be in a future release. We will give a preview of them in our livestream next week, and then release a beta of the tools shortly after.