ViewStore binding not working when used with a search bar

[wltrup]

Hello,

I'm on iOS 16.4, using prerelease/1.0, and I'm having a problem with the .searchable(text:) modifier where

.searchable(text: viewStore.binding(
	get: \.searchText, 
	send: Action.searchTextChanged
))

sort of "freezes" the search bar and the action is never fired. Please see the attached sample project.

The sample project has an AppRootScene (some code ommitted for brevity)

struct AppRootScene: Reducer {
    struct State: Equatable {
        var itemsA = ItemsArray(uniqueElements: Mocks.items)
        var items: ItemsListScene.State {
            get { .init(items: itemsA) }
            set { /* empty - the items tab does not change the array of items */ }
        }
    }

    enum Action: Equatable, Sendable {
        case items(ItemsListScene.Action)
    }

    var body: some ReducerOf<Self> {
        Scope(state: \.items, action: /Action.items) {
            ItemsListScene()
        }        
        Reduce { state, action in
            switch action {
                case let .items(action):
                    print("AppRootScene :: .items(\(action))")
                    return .none
            }
        }
    }

    struct View: SwiftUI.View {
        private let store: StoreOf<AppRootScene>
        init(store: StoreOf<AppRootScene>) {
            self.store = store
        }
        var body: some SwiftUI.View {
            NavigationStack {
                ItemsListScene.View(store: store.scope(
                    state: \.items,
                    action: Action.items
                ))
                .navigationTitle("Items")
            }
        }
    }
}

and an ItemsListScene (some code ommitted for brevity):

struct ItemsListScene: Reducer {
    struct State: Equatable, Sendable {
        var items: ItemsArray
        var searchText = ""
        init(items: ItemsArray = []) {
            self.items = items
        }
        var searchResults: ItemsArray {
            let sortedItems = items
                .filter { $0.name.lowercased().starts(with: searchText.lowercased()) }
                .sorted()
            return .init(uniqueElements: sortedItems)
        }
    }

    enum Action: Equatable, Sendable {
        case searchTextChanged(String)
    }

    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
                case let .searchTextChanged(searchText):
                    print("ItemsListScene :: .searchTextChanged(\(searchText))")
                    state.searchText = searchText
                    return .none
            }
        }
    }

    struct View: SwiftUI.View {
        private let store: StoreOf<ItemsListScene>
        init(store: StoreOf<ItemsListScene>) {
            self.store = store
        }
        var body: some SwiftUI.View {
            // Comment each of these in or out to see what I've tried so far.
            View1(store: store)
            // View2(store: store)
            // View3(store: store)
        }
    }
}

View1 is how I originally implemented the ItemsListScene view but, to my surprise, it didn't work:

    // The TCA way. The search bar is "frozen" and the binding action never gets sent.
    struct View1: SwiftUI.View {
        private let store: StoreOf<ItemsListScene>
        init(store: StoreOf<ItemsListScene>) {
            self.store = store
        }
        var body: some SwiftUI.View {
            WithViewStore(store, observe: { $0 }) { vs in
                List {
                    Section {
                        ForEach(vs.searchResults) { item in
                            Text(item.name)
                        }
                    }
                }
                .searchable(text: vs.binding(get: \.searchText, send: Action.searchTextChanged))
            }
        }
    }

In attempting to debug the problem, I tried to create and manage the binding explicitly, but it still shows the same problem. Also, neither of the two print statements gets executed.

    // An attempt to explicitly create and manage a binding to the search text fails.
    // The search bar is still "frozen".
    struct View2: SwiftUI.View {
        private let store: StoreOf<ItemsListScene>
        @ObservedObject var vs: ViewStoreOf<ItemsListScene>
        @Binding var searchText: String
        init(store: StoreOf<ItemsListScene>) {
            self.store = store
            let vs = ViewStoreOf<ItemsListScene>(store, observe: { $0 })
            self._searchText = .init(
                get: {
                    print("getter called")
                    return vs.searchText
                },
                set: {
                    print("setter called: \($0)")
                    vs.send(.searchTextChanged($0))
                }
            )
            self._vs = .init(initialValue: vs)
        }
        var body: some SwiftUI.View {
            List {
                Section {
                    ForEach(vs.searchResults) { item in
                        Text(item.name)
                    }
                }
            }
            .searchable(text: $searchText)
        }
    }

Of course, I also looked at what a vanilla SwiftUI implementation would do and, in that case, the search bar works fine but then I don't know how to connect the @State property with TCA other than by doing what I did just above, which doesn't work.

    // This makes the search bar "usable" but then how do I connect the
    // @State searchText property to the view store?
    struct View3: SwiftUI.View {
        private let store: StoreOf<ItemsListScene>
        @SwiftUI.State private var searchText = ""
        init(store: StoreOf<ItemsListScene>) {
            self.store = store
        }
        var body: some SwiftUI.View {
            WithViewStore(store, observe: \.searchResults) { vs in
                List {
                    Section {
                        ForEach(vs.state) { item in
                            Text(item.name)
                        }
                    }
                }
            }
            .searchable(text: $searchText)
        }
    }

Is it something that I am doing wrong or is it a bug in either TCA or SwiftUI? I can't tell so any help would be greatly appreciated.

SearchText-forum.zip

[tgrapperon]

Hey @wltrup!
The problem comes from here:

struct State: Equatable {
    var itemsA = ItemsArray(uniqueElements: Mocks.items)
    var items: ItemsListScene.State {
        get { .init(items: itemsA) }
        set { /* empty - the items tab does not change the array of items */ }
    }
}

The set shouldn't be noop: the searchText value you just set in the child feature is discarded, and you return a brand new ItemsListScene.State with this field empty for the next round. It means that the search field is empty, so SwiftUI deletes the character you just entered and you get the impression that the field is stuck.
When deriving states with internal properties (like searchText), you need to make sure to preserve the value somewhere. For example using a private property:

struct State: Equatable {
    var itemsA = ItemsArray(uniqueElements: Mocks.items)
    private var _items: ItemListScene.State = .init(items: [])
    var items: ItemsListScene.State {
        get { 
          var state = _items
          state.items = self.itemsA
          return state
		}
        set { 
          self._items = newValue
        }
    }
}

I hope it'll help solving your issue!

[wltrup]

Hi @tgrapperon. Thank you so much for the quick reply and, wow, what a subtle issue. May I suggest adding this comment

When deriving states with internal properties (like searchText), you need to make sure to preserve the value somewhere

to your thread on TCA tips, possibly with some elaboration?

Once again, many thanks!

[tgrapperon]

Maybe indeed, but in general, when you're bending the rules, like setting an empty set , implementing partial Equatable to a type, etc., it'll always bite you at some point, so you can use that as a signal that something is maybe wrong somewhere.

Scope reducer notoriously expects a WritableKeyPath (or a CasePath) for a reason. Otherwise it would have been only a KeyPath. So I imagine that you started with a read-only computed property and the compiler complained that it expected a writable one, so you implemented the empty set and created a bug.

But this is an interesting occasion to reflect about what's effectively going on when the app is running because this lies at the core of features' composability: the parent store extracts a child state to run the child reducer, but it needs to store the modified state somewhere back once finished. The empty setter only allowed side effects. You can ask yourself "where does the searchText is stored from the AppState's standpoint?", because this data needs to be somewhere, and if this is nowhere, then you need to make room for it. You can apply this way of thinking to model and optimize your domains in situations where the "all-in" approach is not possible.

[wltrup]

So I imagine that you started with a read-only computed property and the compiler complained that it expected a writable one, so you implemented the empty set and created a bug.

Actually, no. The motivation for the empty setter was that I have a few TabView tabs and I didn't want to hold the full state of all of them in the app state, at all times. Thus, I wanted the tab states to be derived from a computed property in the app state. Moreover, and more importantly, the source of truth for the initial state in those tabs (itemsA in the sample project) isn't expected to change much or often and is definitely something the tabs can't change, hence the empty setter.

But, as you pointed out, I wasn't holding on to "live" states for the tabs and every time a tab needed to be rendered, it was getting a freshly created state that didn't include any "internal" state that the app state isn't aware of.

You can ask yourself "where does the searchText is stored from the AppState's standpoint?"

In my view, that's an odd question to ask because the app state shouldn't have to know or care that its "child" state has some internal/transient data that it can/should manage entirely on its own. From the app state's perspective, I would expect it to say "well, my child needs an identified array of items so that's what I'll provide it with when it asks me for its state".

In fact, my ultimate solution, once I understood the problem (thanks to you!), was to bite the bullet and store the full state of the child, as one usually does, and not the source of truth (the itemsA in the sample project). When the app starts, the source of truth is downloaded and then the child state is set with it. The child state is kept "in full" by the parent, at all times, and the parent never needs to know, care, or handle what might be inside that state.