Beginner - Modeling a basic todo list application.

[ghost]

Hi,

I'm just getting started with TCA and I'm struggling a little.

Just for context, I've been an iOS developer for several years, and I've got an OK amount of experience building UIKit apps in Objective-C & Swift.
I've played with SwiftUI, but nothing too fancy, just a very simple app with only screens.

I've watched the TCA collection on pointfree.co, and went through the case studies & examples.

So, I'm trying to model a "simple" todo list application, such as the one in the repo's example.
On the page of a project (aka a group of todos), I'd like to split them into sections, and allow the user to reorder them.
Here is a screenshot of how it looks like in the preview right now. (Simple enough, right 😅?)

So, in order to represent this, I've got two features, the TodoRow and the Project (simplified) :

struct TodoRow: ReducerProtocol {
    struct State: Equatable, Identifiable {
        let id: UUID
        let title: String
        var isCompleted: Bool
    }
    // ...
}
struct Project {
    struct State: Equatable {
        var title: String
        var todos: IdentifiedArrayOf<TodoRow.State>
        var focusedTodos: IdentifiedArrayOf<TodoRow.State> { IdentifiedArrayOf(todos.prefix(3)) }
        var blurredTodos: IdentifiedArrayOf<TodoRow.State> { IdentifiedArrayOf(todos.dropFirst(3)) }
    }
    // ...
}

First, please bear with me, maybe my questions are overthinking everything and it's just my "old" way of building UIKit apps with MVVM that are clouding my mind.

Question 1:
Let's say that in order to keep the todos ordered in the database, I want to add a position: Int a Todo.
My two first thoughts were :

1. Add it to TodoRow.State
   But this feels wrong because TodoRow.State doesn't need this information.
2. Add it to TodoRow.State, and have a custom TodoRowView.State that doesn't contain the position and therefore doesn't reload the view when the row's position changes.
   Better than the first idea, yet it still feels weird that my whole application would be relying on a specific "leaf" state.
   If I introduced a detailed view, like TodoDetail, would it also rely on TodoRow? Why not the other way around?
3. Create a SomeHigherLevelTodoModel that Project.State holds onto instead of holding to TodoRow.State, and have a computed property to transform SomeHigerLevelTodoModel into TodoRow.State
   This feels cleaner IMO, but it also adds a lot of boilerplate.

Question 2:
Let's say that I want to remove the completed todos from the project list, adding a 1 second delay, as shown in the Todo list example of the TCA workspace.

struct TodoRow {
    // ...
    enum Action: Equatable {
        case checkboxToggled
    }
    func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
        switch action {
        case .checkboxToggled:
            state.isCompleted.toggle()
            return .none
        }
    }
}

In my architecture, I thought it made sense to implement it like that - kinda like the Fitler in the Todo TCA workspace example:

struct Project {
    struct State: Equatable {
        // ...
        var todos: IdentifiedArrayOf<TodoRow.State>
        var ongoingTodos: IdentifiedArrayOf<TodoRow.State> { todos.filter { !$0.isCompleted } }
        var focusedTodos: IdentifiedArrayOf<TodoRow.State> { IdentifiedArrayOf(ongoingTodos.prefix(3)) }
        var blurredTodos: IdentifiedArrayOf<TodoRow.State> { IdentifiedArrayOf(ongoingTodos.dropFirst(3)) }
    }
}

Doing this, I can't add the 1 second delay because TodoRow is setting the isCompleted property directly, causing todos to change, and the view to be reloaded directly.
So instead of using a computed property I can hold on to a second array that I would mutate only one second after :

struct Project {
    struct State: Equatable {
        // ...
        var todos: IdentifiedArrayOf<TodoRow.State>
        var ongoingTodos: IdentifiedArrayOf<TodoRow.State>
        var focusedTodos: IdentifiedArrayOf<TodoRow.State> { IdentifiedArrayOf(ongoingTodos.prefix(3)) }
        var blurredTodos: IdentifiedArrayOf<TodoRow.State> { IdentifiedArrayOf(ongoingTodos.dropFirst(3)) }
    }

    enum Action: Equatable {
        case removeCompletedTodos
        case todoAction(id: UUID, action: TodoRow.Action)
    }

    var body: some ReducerProtocol<State, Action> {
        Reduce { state, action in
            switch action {

            case .removeCompletedTodos:
                state.ongoingTodos = state.todos.filter { !$0.isCompleted }
                return .none

            case .todoAction(_, action: .checkboxToggled):
            enum CancelID { }
            return Effect
                .run { send in
                    try await mainQueue.sleep(for: .seconds(1))
                    await send(.removeCompletedTodos, animation: .default)
                }
                .cancellable(id: CancelID.self)

            case .todoAction:
                return .none
            }
        }
        .forEach(\.todos, action: /Action.todoAction(id:action:)) { TodoRow() }
    }

But then I need to send a copy of both todos and ongoingTodos when I create a Project.State, which feels wrong, because I'm filtering the array in multiple places.

Am I missing something completely obvious with these two questions, or overthinking it way too much?

Feel free to refer me to a some video, case studies, or even another thread from these discussion if it's covered somewhere in there 👍🏻

Thanks everyone for your help,
Maxime.

[tgrapperon]

Hey @mdechalendar-heetch! Here are my 2 cents on the questions:
Question 1: Storing Todos in a database
The Todo's index is a property of a Todo in a "table/list" context. The way I'm making this kind of things works in CoreData for example (where we don't have ordered relations if we want NSPersistentCloudKitContainer) is to create a TodoRow (or TodoItem) that holds both index and a reference to some Todo content. The list thus contains a sequence of TodoRow, each in a "to-one" relation to Todo. So I have Todos <->> TodoRow <<-> Todo. Here the Todo ->> TodoRow is to-many because a Todo can belong to different collections, with different indexes.

In TCA, you can imagine the exact same segmentation if you want to keep things isolated: A Todo domain that is "index-agnostic"¹, that you embed (likely trivially) into a TodoRow domain that holds the index, and possibly other interesting data (for example, to mark it as important in this list's context), and then a Todos domain that handles the list.

The TodoRow approach uses the same underlying idea behind the Identifiable wrapper that ships with TCA (for now, so don't rely too much on it, as it may migrate to swift-identified-collections at some point), where you use a wrapper type to decorate a base one with additional information (here, an ID), and forward all the calls otherwise). It is also possible that property wrappers can help make the accesses less boilerplaty.

Once you have Todo, TodoRow, and Todos domains, it is easier to spot where a particular feature may branch from.

Question 2: Having several Todo lists with delays
This is more a SwiftUI modeling problem, and the second approach is likely the correct one. You want your UI to be a function of your state, but you don't want this state to be in a 1-to-1 relation on the backend's side, so you need to model your feature as an intermediary ViewModel. This indeed prevents the automatic filtering you're doing using computed properties, and it's likely better to handle the changes explicitly from the reducer as you noticed. If the Todo is marked as "done", this should be immediately propagated to the database, but you don't want the corresponding UI to reflect that automatically, so it means that at some point in time during this delay, you have a Todo that is effectively in two "different" states (completed in the backend/model, and completedAFewMsAgo for the UI) which means that you need to store this information twice. There is no real way around it given the way SwiftUI automatically reacts to state changes.

Footnotes

1. While it's not the case here because each Todo as a natural intrinsic identifier (its UUID), not having access to the index at the Todo level can be relatively tricky if you spawn long-living effects with a cancellation ID, as you would likely want a unique ID per Todo, which is sometimes too much to ask to a Todo domain that is context-agnostic (again, not the case here because we have Todo.id). There is currently nothing built-in TCA to handle this automatically, but the upcoming navigation update may lay down some infrastructure that can be repurposed to automatically manage this kind of problem. One solution in the meantime is to inject an identifier as a Dependency (or as a local property) from TodoRow into Todo. ↩

[ghost]

Thanks a lot @tgrapperon, both answers are making a lot of sense.
I'll have a bit of time over to week-end to try your suggestions, I'll let you know how it goes.

Thanks again for your time 👍🏻