GRDB and concurrency

[seanmrich]

Bottom line up top: I'm looking for a way to have a Shared value report it isLoading while fetching values in a subscription.

This week's episode on building a SharedReaderKey that supports GRDB was terrific. The FetchKey rightly focuses on synchronous fetches on the main thread. This is the vast majority of what I need, but there are occasions when I have a long-running operation that needs to be off the main thread. Tweaking the scheduler gets me most of the way, but I can't use isLoading to give feedback on the load state.

The AnimatedScheduler is a clever way to inject animations into automatic database observation. To support my async needs, I added a property to the scheduler:

private struct AnimatedScheduler: ValueObservationScheduler {
  let animation: Animation?
  let async: Bool
  
  func immediateInitialValue() -> Bool { !async }
  …
}

Then I added a parameter to the FetchKey initializer that configures the scheduler:

init(
  request: some FetchKeyRequest<Value>,
  database: (any DatabaseReader)? = nil,
  async isAsync: Bool,
  animation: Animation? = nil
) {
  self.scheduler = .animation(animation, async: isAsync)
  …
}

This correctly moves the work to a background thread while still delivering the data when it's available on the main thread (and animated!). However, I want to show a spinner or something when the data is being loaded. I created a detail view for your GRDBDemo that shows the name and injured status for a single player. I use this key:

struct PlayerKey: FetchKeyRequest {
  let id: Int64
  
  func fetch(_ db: Database) throws -> Player? {
    Thread.sleep(forTimeInterval: 2) // simulate long-running operation
    return try Player.fetchOne(db, key: id)
  }
}

I converted the demo app to TCA and declared the player property in a reducer:

@Reducer
struct PlayerDetail {
  @ObservableState
  struct State {
    @SharedReader var player: Player?
    
    init(id: Int64) {
      self._player = SharedReader(
        .fetch(PlayerKey(id: id), default: nil, async: true, animation: .default)
      )
    }
  }
}

Then in the view I want to show a spinner if the data is still loading:

var body: some View {
  if let player = store.player {
    List {
      Text(player.name)
      LabeledContent("Injured", value: player.isInjured ? "Yup" : "Nope")
    }
  } else if store.$player.isLoading {
    ProgressView()
  } else {
    ContentUnavailableView("Player Not Found", systemImage: "questionmark.app")
  }
}

Unfortunately the spinner is never shown. I'm probably misunderstanding the isLoading property, but I'd like to be able to set it while a fetch is in progress. There's the ValueObservation.handleEvents method that can hook me into GRDB's change tracking mechanism, but I don't know how to notify the Shared value that a load is in progress. Is this possible?

[stephencelis]

Currently, isLoading is tied to the load endpoint of Shared/SharedReader and SharedReaderKey, not subscribe. Since subscribe is a long-living operation that delivers updates, it's not clear to me how/why isLoading should toggle true for this operation.

If you want a loading indicator during the initial load operation and explicit loads like the refreshable view modifier, you can use the LoadContinuation to feed the results in asynchronously using database.asyncRead instead of database.read.

[seanmrich]

Thanks, @stephencelis. For the benefit of anyone thinking through similar issues, here's what I settled on for my project.

As is usually the case, most of the time spent in the query was processing the data rather than fetching it. SQLite queries are wicked fast so even reasonably large datasets can be fetched pretty quick. Even so, I use the async modification of the AnimatedScheduler as I described above to avoid blocking the main thread if the data is likely to be large. Then, I listen for changes to that shared data in the TCA Reducer in a for await loop:

struct State {
  @Shared var fetched: FetchedValue
  var processed: ProcessedValue
  var isProcessing = false
}

…

var body: some ReducerOf<Self> {
  Reduce { state, action in 
    switch action {
    case .task:
      let sharedFetched = state.$fetched
      return .run { send in
        for await new in sharedFetched.publisher.values {
          await send(.fetchedValueDidChange)
        }
      }

    case .fetchedValueDidChange:
      state.isProcessing = true
      let fetched = state.fetched
      return .run { send in
        let processed = try fetched.map(\.processed)
        await send(.receiveProcessed(processed))
      }

    case .receiveProcessed(let new):
      state.processed = new
      state.isProcessing = false
      return .none
    }
  }
}

This approach lets me control whether fetches happen on the main thread or not and keeps the database work separate from the processing that is now inside the Reducer where it's testable.