Another question about using SQLiteData with TCA

[gerfarfel]

This is a follow-up to #260 (and #47) on the topic of using SQLiteData with TCA. My question has to do with how to bridge between parent and child reducers. I know that this is essentially the same question that was asked in #260, but I'd like to revisit it in a more generalized context. Actually, I'm hoping that I've misunderstood something about the answer to that question, because it seems to imply that one of TCA's core features (composition) isn't fully compatible with SQLiteData.

In the simple example below, the parent reducer (RemindersDetail) is fetching an array of Reminders from the database. The child reducer (ReminderRow) holds mutable transient variables in addition to data from the database. The question is how to generate the array of child states (reminderRows) in the parent state. It can't be generated via a custom database fetch, because it contains mutable transient data, and generating it through a computed property means that new child state will be created every time it's accessed, which can also be highly problematic.

@Reducer
struct RemindersDetail {
  @FetchAll(Reminder.all) var reminders
  var reminderRows: [ReminderRow.State] // HOW TO BRIDGE FROM reminders TO THIS?
}

@Reducer
struct ReminderRow {
  struct State {
    var reminder: Reminder
    var isSelected: Bool   // mutable transient state not stored in the database
    init(reminder: Reminder) { … }
  }
}

The advice for the specific case discussed in #260 (as I understand it) was to subsume the child state directly into the parent. This approach can work, but it takes TCA's primary superpower – composition – off the table. If SQLiteData imposes significant restrictions on how data can be modeled with TCA, then that's a significant downside to using the two libraries together.

My current approach (which also has obvious downsides) has been to not hold @Fetch data directly in my reducer state, but rather to use SQLiteData as a back-end for handling database transactions. I'd love to know if I've misunderstood something here, or if anyone has come up with a better approach.

As a final comment, I'd love to see more examples and discussion of how to use SQLiteData and TCA together. Thanks!

[mbrandonw]

Hi @gerfarfel, there just is no good way to achieve what you want when using value types, regardless of using TCA/SQLiteData or not. What you want is the ability to have data stored externally, for the data to be fetched for a feature in a collection, and then to have rows in a list hold each element from the collection and have their mutations be connected to the parent feature and external data source. There's no way to package up all that magic in value types. That's something reference types can do of course, but then that comes with a bunch of other downsides.

But also, we feel that it is rarely ever needed to actually break features down along the boundaries of elements in a collection. We do provide the tools for this (forEach and ForEach that works with stores), but we find it's hardly ever necessary to use them. The vast majority of the time rows in a list are static views with no logic or behavior. And even when they do have logic and behavior, it's so simple that you can typically just use action closures to delegate that work to the parent feature.

[gerfarfel]

Thanks for the reply @mbrandonw. I take your point that one can generally work around the issue in the scenario described in my example. The problem I was trying to get at (poorly articulated, unfortunately) pertains for any parent/child reducers, not just collections at the edges. If the parent state contains fetched data and also holds child state, what are the possible mechanisms for updating the child state when the parent's fetched data changes (e.g., after a CloudKit sync event)? Those updates happen outside the scope of the TCA reducers. I've experimented with database triggers, but that approach can get complicated pretty quickly.

[mbrandonw]

Ah, for that kind of parent-child relationship, things are simpler. And really it works exactly as it does in vanilla SwiftUI. Some of our demos in the repo demonstrate this too.

For example, in the SyncUps app, the SyncUpsListModel (this would be a reducer in TCA) uses @FetchAll to grab all sync ups:

sqlite-data/Examples/SyncUps/SyncUpsList.swift

Lines 11 to 18 in 57274d5

	@FetchAll(
	SyncUp
	.group(by: \.id)
	.leftJoin(Attendee.all) { $0.id.eq($1.syncUpID) }
	.select { Row.Columns(attendeeCount: $1.count(), syncUp: $0) },
	animation: .default
	)
	var syncUps: [Row]

And then that screen can navigate to a detail screen for a sync up, which is powered by SyncUpDetailModel (again, a reducer in TCA) that uses @FetchOne to fetch the most current details of the sync up:

sqlite-data/Examples/SyncUps/SyncUpDetail.swift

Line 12 in 57274d5

@ObservationIgnored @FetchOne var syncUp: SyncUp

This means the SyncUpDetailModel can make whatever edits it wants to the database and can rest assured that it's local syncUp will always have the freshest data, and the root list of sync ups will also always be refreshed.

[gerfarfel]

Thanks (again!) @mbrandonw. That's helpful. I've been working with TCA for quite a while now, and integrating SQLiteData is requiring me to rethink some of the patterns I've developed. But that's actually a good thing!