SwiftUI/TCA Bindings and derived/computed optional state and mapping actions

[rurza]

Hey folks!
Some background first. 1,5 year ago I've committed to the TCA, I wrote real-world-non-trivial app with it, the app works, everything is great. I'd like to step up in the game and modularize the app and move it to the new TCA API. I started with both tasks together, but I've failed and I'm trying again: first with moving to the ReducerProtocol and then to modularize it (so please keep this in mind).
At the same time I'm trying to improve some ergonomics of how things are divided: how I deal with reducers, state etc. (mostly because it'll be easier to modularize it).

Now, what's specific about my app (especially compared to examples or things I saw on pointfree) is that my app has features (with and without UI), that require access to the state of different sibling substates (and sending actions). In my previous implementation I dealt with this problem by making ad-hoc reducers, that dealt with AppState/AppAction, switch on actions that I was interested and do things there.
For example: some of the events that happen in my app on feature X should result in notifications sent to the user (in form of system notifications and custom ones). But, the user can mute notifications (in the app settings) and limit them to the most important ones. So, where the feature X is composed with the AppReducer, I'm switching on actions of the feature X that should notify the user, check the app settings state if notifications are muted and if there are not, then I'm returning an action that will trigger the UI notification (that will be executed by some other reducer).
Obviously there are drawbacks to this approach, but I can test it and it works.

Anyway, we can model the app state as (I'll mix both new and old API):

|      App State      |
|    SettingState     |
|     LastFmState     |
|     ThemesState     |
| PreferencesUIState? |  <- optional state
|    etc.             |

From it we can derive SettingsUI state, which is basically an optional state that composes some of the substates from the AppState that contains non-optional PreferencesUIState and some other substates:

extension AppState {
    var settingsUI.State: SettingsUI.State? {
        get {
            guard let preferencesUIState else { return nil }
            (…)
        }
        set { (…) }
    }
}

Now, it makes total sense to use BindableAction and BindableState in the SettingsUI's State and Action (or even their substates), right?
For example some settings view with a lot of toggles can use it.
But how map actions that contain binding to the parent State/Action? I know that I could add BindableAction to the parent action and then use the pullback operator, but it can deal only with "honest" non-optional state.

Any ideas?

[importRyan]

Perhaps this is personal taste, not suited for others, but I try to avoid "tiger mom" parents where possible. Too much observation and reaction leads to "context"-like redux pattern, which has downsides for scaling and verbose test assertions.

The logic and mechanics of (a) delivering notifications and (b) persisting which notifications should be emitted sound like side effects housed in one or more closure-based clients that deal with concrete Apple or third-party services. Both the notification-generating feature and your settings screen would reach out to this client for user intents, current preferences (if any), and subscribe to state changes.

[rurza]

I agree and the new dependency management will solve some of the problems I had :)

[rurza]

I think I've found a solution and it's quite simple. I can scope store of my derived state even further to the substate that actually uses bindings. This way I don't have to support bindings on all parent states/actions. I'm not sure how this will affect performance though.