Key path value type with IdentifiableArrayOf<> #874
-
Xcode 13.1, Monterey, project targetting iOS 15, Swift 5 I'm new to TCA, fairly new to SwiftUI, and exploring the example projects and putting my own spin on them to explore TCA. I'm currently working through the Todos example, and wondered about why the AppState and AppView's View State seem to be conflated. That lead me to building up the example from scratch, which gave me a state structure with only one member - the list of items.
It occured to me that I could create just a typealias to the underlying list, so used:
which allows me to be more consise in my reducer:
The problem is a compile error, when trying to use a keypath to self (not supported in Swift 4). In my ItemListView, I have:
which produces a compile error of:
So,
which gives the same compiler error, and changing it to:
Also produces the same error. Being more explicit/direct with the typing of the keypath seems to be even more contradictory:
gives:
The motivation here was to remove the redundant level of enclosure (items property in ItemList) as it seems to compile ok elsewhere by using .self as the keypath. This seems like something that 'should' work, and in fact I did find a workaround, which seems a bit esoteric, but gives this:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
@dmeehan1968 The following, for example, are equivalent: users.map { $0.name }
users.map(\.name) I think the problem you're encountering is this bug (or rather, a bug related to this bug): https://bugs.swift.org/browse/SR-12422 Hopefully it will be fixed some day, but in the meantime, you should be able to get by with an identity closure instead: self.store.scope(state: { $0 }, action: ItemListAction.item(id:action:)), |
Beta Was this translation helpful? Give feedback.
@dmeehan1968
Store.scope
actually takes a transform function and not a key path. When you see the key path it's because key path literals can often be used as a shorthand for a function.The following, for example, are equivalent:
I think the problem you're encountering is this bug (or rather, a bug related to this bug):
https://bugs.swift.org/browse/SR-12422
Hopefully it will be fixed some day, but in the meantime, you should be able to get by with an identity closure instead: