Tests

[andybezaire]

Have you considered adding tests?

Great helper. This should be in SwiftUI IMO.
It works great and also preserves the testability of your system.

Let me know if you would be interested to add tests and I'd love to help.

[SwiftedMind]

Thanks for the kind words, I'm really glad you like it 😃

It's on my todo list but to be entirely honest, I need to think about how to actually do it. Adding unit tests to the QueryableManager should be easy, but adding "end-to-end" tests of the Queryable property wrapper might be hard, since it relies on SwiftUI states that are "empty" outside the SwiftUI environment (as far as I know). Maybe full blown UI tests might be the way to go there. I don't really have much experience in this area, unfortunately, but I'd love to learn.

If you have ideas, suggestions or want to help, that would be greatly appreciated 👍 😄

[andybezaire]

I have not paired before using GitHub discussions. 😀 So let's see if this works.
I think the code is structured well with good abstractions.

I think maybe a first step would be to make the Queryable's job just to provide the property wrapper.
So maybe move the Trigger into the manager?

Then maybe the trigger would change a bit. Maybe the Trigger could even be a protocol implemented by the manager. Then you might not need to keep the reference to the manager class inside the trigger struct.

Maybe pulling things together and creating boundaries so it would be easier to test.

But it is a bit risky as there currently are no tests. So not sure what the first step should be

[SwiftedMind]

I like the idea. That could separate the core logic from the property wrapper, making QueryableManager properly testable without needing the SwiftUI environment 🤔

The tricky thing is that Trigger is a public type (it's the wrappedValue type), whereas QueryableManager is not. So it would need to be replaced by something else.

Right now, I am kind of misusing Trigger as a payload type for stuff that the view modifiers need to be able to access. Improving that could actually be a good first step I guess, before turning Trigger into a protocol or something.

In any way, that's going to be a challenge 😅 But I think you're right, there might actually be a way to implement proper unit testing for this.

[andybezaire]

It's hard for me to suggest what to do because I usu do TDD and the architecture decisions are much easier to see that way.
The trigger exposes the manager to the swiftUI view. So there is a bit of coupling there.
Perhaps the start would be to specify the desired API that swiftUI will see, and then try to move things around so that the manager is not exposed to swiftUI.
to me, it would be nice if the queryable handled all of the swiftUI stuff and the manager was only accessed int he queryable. this might mean reworking the trigger which is given as the wrapped value. I wonder what the ideal API for that would be.

[SwiftedMind]

Yeah I agree. The problem is that SwiftUI has to have access to the manager in some capacity but, for example, a protocol would makes things slightly less coupled I would say.
I need to wrap my head around this for a bit, this is going to be tricky 😅. Starting with the API and then working around that is a nice idea.

[SwiftedMind]

Hey @andybezaire, I wanted to quickly give an update about what's going on. Sorry for the long silence 😅. I haven't abandoned this topic, I'm currently just swamped with some other projects that are close to a 1.0.0 release. That has taken almost all my free time in the past few weeks and will continue to do so over the next few weeks, unfortunately.

But I have not forgotten! :D I do have some ideas in mind on how to tackle this.

Sorry for the delay

[SwiftedMind]

Hey @andybezaire, it's been quite a while. I'm really sorry about that. My other project, a new SwiftUI app architecture has pretty much consumed all of my free time for the past few months.

But now I have finally had the time to work on the problem again and I think I have come up with something that might work and I'm curious what you think about it :)

---

The key to making unit tests work (and a lot more, as it turns out!) was, unfortunately, introducing a breaking change (meaning this will require a 2.0.0 release).

I pulled out the inner guts of the Queryable property wrapper and made them a public type that can live and work inside but also outside the SwiftUI environment. That new type has replaced the property wrapper. It's a simple class conforming to ObservableObject. You can find it on the develop branch, here: Queryable.swift

In practice, this changes the following:

Previously, you would use Queryable like this, in a SwiftUI view:

struct MyView: View {
  @Queryable<Void, Bool> var deletionConfirmation
  var body: some View { /* ... */ }
}

Now, there's no custom property wrapper anymore, just a plain old ObservableObject:

struct MyView: View {
  @StateObject var deletionConfirmation = Queryable<String, Bool>()
  var body: some View { /* ... */ }
}

(With iOS 17 and the Observable Macro, this can even be simplified down to a @State, which is neat)

All the .queryable[...] view modifiers still work the same as before.

---

What's new is that you can now define that Queryable anywhere:

// A view model or other observable object:
class SomeObservableObject: ObservableObject {
  let var deletionConfirmation = Queryable<String, Bool>()
}

// A globally shared object, reachable from anywhere in the app:
class SomeSingleton {
  static let shared: SomeSingleton = .init()
  let var deletionConfirmation = Queryable<String, Bool>()
}

As long as you have the reference to it, you can pass it to one of the .queryable[...] view modifiers and it will just work.

---

Additionally, this allowed me to actually add support for unit testing, which was the whole point of this. You can find a first draft of these here: QueryableTests.swift

I got this working by building a small query observer helper class gives you control over the asynchronous queries: QueryableObserver.swift

For example:

func testBasic() async throws {
    let queryable = Queryable<Void, Bool>()
    _ = QueryableObserver(queryable: queryable) { queryId, resolver in
      if queryId == "0" {
        resolver.answer(with: true)
      } else if queryId == "1" {
        resolver.answer(with: false)
      }
    }

    do {
      let trueResult = try await queryable.query(id: "0")
      XCTAssertTrue(trueResult)

      let falseResult = try await queryable.query(id: "1")
      XCTAssertFalse(falseResult)
    } catch {
      XCTFail()
    }
  }

It's still rough around the edges, but it's a start. What do you think?