How to support my own Property Wrapper(s) inside ObservableState?

[danthorpe]

Apologies if this has already been announced during the observation or shared state beta, I've been going round in circles a bit trying to adopt observation with my TCA projects...

I have a micro-library to support "loading" in TCA based applications. It has a custom property wrapper, @LoadableState and an associated reducer, to support "loading" child features inside parent features. I've open sourced the library here: https://github.com/danthorpe/swift-composable-loadable

The challenge I am facing, is how to make this play nicely with ObservableState. Essentially how can a parent feature compose a property wrapper while also adopting ObservableState?

Looking at recent sources of the ObservableState macro, it seems to have hardcoded handling for TCA property wrappers or macros, including PresentationState and Shared etc.

I can think of a couple of possible ways forward

1. Write my own @Loads macro similar to @Presents
2. Update ObserableState macro to "handle" arbitrary property wrappers.

Let's start with option 1, in theory this is totally possible, I've looked at the @Presents macro, and I need something very similar. The TCA framework actually has a bunch of code to make it all happen, which I could liberally copy into my project, but it would be amazing if some of these APIs were exposed behind a SPI import, so that they could be reused.

Indeed, what I want to achieve is the same as what any other developer would want to support their own custom property wrapper inside ObservableState. In general though - this solution does not scale very well, and it makes writing a custom property wrapper (or even macro) which plays nicely with @ObservableState quite a challenge.

For option 2, in many cases, I don't actually need to actively support observation - instead I just want to be ignored by the ObservationState macro. Perhaps @ObservationStateIgnored macro could also have an extension role to apply a ObservableStateIgnored protocol - allowing it to be used to opt-out of the observation state macro.

Keen to know what others think about this, or perhaps there is another solution out there. 😀

[lukeredpath]

I had to tackle this problem - we also have a @Loadable property wrapper that does a very similar thing to yours.

I solved this by introducing a separate property wrapper called @ObservedLoadable that supports observation - both property wrappers use the same underlying LoadableState type and supporting reducers/APIs, but the @ObservedLoadable does its own observation tracking internally.

The only catch is because @ObservableState does not know about this macro, you need to also explicitly mark the property as @ObservationStateIgnored - it would be nice if the macro supported a way of declaring other macros to be ignored.

Making @ObservedLoadable work was actually quite straightforward - you need to conform to the Perceptible protocol (I'm still supporting < iOS 17) and add the registration boilerplate:

    private let _$perceptionRegistrar = Perception.PerceptionRegistrar()

    internal nonisolated func access<Member>(
        keyPath: KeyPath<Self, Member>,
        file: StaticString = #file,
        line: UInt = #line
    ) {
        _$perceptionRegistrar.access(self, keyPath: keyPath, file: file, line: line)
    }

    internal nonisolated func withMutation<Member, MutationResult>(
        keyPath: KeyPath<Self, Member>,
        _ mutation: () throws -> MutationResult
    ) rethrows -> MutationResult {
        try _$perceptionRegistrar.withMutation(of: self, keyPath: keyPath, mutation)
    }

Then add a stored property to store the internal state for your property wrapper and make wrappedValue a computed property - in this example my wrapper's internal state property is called var state:

public var wrappedValue: Value? {
    get {
        access(keyPath: \.state)
        return state.currentValue
    }
    set {
        withMutation(keyPath: \.state) {
            state = .loaded(newValue)
        }
    }
}

You can also do the same thing for var projectedValue if you need it - my wrapper exposes the actual state property as the projected value.

[danthorpe]

Ah! I see, I can add the @ObservationStateIgnored macro to the property where I've used my custom property wrapper - oh, it's so obvious when it's pointed out 😂🤦‍♂️

Thanks @lukeredpath