Best way to initalize a store with data?

[reftonull]

Hi,

I've been using Boutique for a few days now, and have been able to (mostly) rip Core Data out of my app. I was, however, struggling with figuring out how to initialize a store with data on first load. This is useful to me to initialize a default category for items in my app, and it feels like it would also be useful for things like testing.

My question is likely borne out of my limited understanding of Swift Concurrency, so I'd really appreciate any help.

Thanks,
Laksh.

[mergesort]

Hey @reftonull. Glad to hear you're using Boutique and seem to be able to rid yourself of Core Data.

A simple way approach to provide data for tests would be similar to how I provide data for tests, loading items in manually from a hardcoded array.

But in version 2.0 I'll be adding a new property wrapper, @StoredValue, which seems suited to the task of providing a default category for your apps. Even though 2.0 isn't yet released it's stable, I'm mostly making small additive changes and focusing on providing a lot of documentation for exactly the kinds of problems you're running into before releasing it fully. I would recommend using 2.0, the pull request for it is pretty rich with quite a few new features, and very few changes. #25

Hope that helps, and if not, let me know and we can try to dig into what I may have missed.

[mergesort]

A small amendment to my suggestion, I tried writing a test for items, and realized that for items to be available immediately the Store initializer would need to be marked async. In the implementation I posted above the Task is unstructured, which means that it will run whenever the system deems it fit to be run, but instead we need to await the items being loading, and the initializer has to be marked async for that to happen.

There aren't many downsides but there are two notable ones that may matter to you.

1. You can't use an async property in a property wrapper, so you can't use this Store in the @Stored property wrapper.
2. You can't use this in a global context, so static let wouldn't work either.

But it should still be useful for tests, which I tested by, well, writing a test. This is how the initializer would look.

@MainActor
public init(storage: StorageEngine, items: [Item], cacheIdentifier: KeyPath<Item, String>) async {
    self.storageEngine = storage
    self.cacheIdentifier = cacheIdentifier

    do {
        try await self.removeAll()
            .add(items)
            .run()

        self.items = items
    } catch {
        self.items = []
    }
}

And here's how my test looks.

@MainActor
func testStoreWithItemsInitializer() async {
    let store = await Store<BoutiqueItem>(
        storage: DiskStorageEngine(directory: .documents(appendingPath: "Items")),
        items: [.belt, .sweater, .purse],
        cacheIdentifier: \.merchantID
    )

    XCTAssertEqual(store.items.count, 3)
    XCTAssertEqual(store.items[0], .belt)
    XCTAssertEqual(store.items[1], .sweater)
    XCTAssertEqual(store.items[2], .purse)
}

@reftonull Same question but with different code, would this approach work for you?

[mergesort]

@reftonull Thanks for the idea, I've added this initializer in #25 and it's been merged onto main! I'm still open to making changes so I was curious if you had any thoughts, otherwise I'll close out this discussion in the coming days.

[reftonull]

Hi again, I'm sorry for not replying sooner, this past week has been super busy!

This is indeed very convenient for testing! I'd have liked to have this be able to be used in @Stored, but having done some digging into the specifics of structured and unstructured concurrency, that doesn't seem possible, which is somewhat unfortunate.

This, perhaps, is the time for me to take a step back and explain why this is something I'd have liked.

Throughout my move away from Core Data and towards Boutique, one thing I have tried to keep in the codebase is the, quite frankly, amazing support for plug and play persistence containers in Core Data.

Concretely, this means that I am able to use placeholder data in previews very easily through the use of a single modifier (this snippet is similar to that found in the default Core Data enabled project in Xcode):

struct MainView_Previews: PreviewProvider {
    static var previews: some View {
        MainView()
            .environment(\.managedObjectContext, PersistenceController.preview.container.viewContext)
    }
}

Further, I am able to simply switch from an empty container to a container with placeholder data:

// for production
let persistentController = PersistentController.shared

// for placeholder data 
let persistenceController = PersistenceController.preview

I have tried to replicate this to the best of my ability in Boutique, but it has been harder than I'd have hoped and feels a little hacky. Here I will detail what I did, what issues I ran into, and how I tried to get around them.

First, I tried to keep stores small, and scoped to specific models, as you recommend in your blog post. My app has three models, and so I had a store for each of them. However, when it came to placeholder data, I realized that they are all linked, and must be instantiated one after the other with relationships in between. Instantiating this data in each store, therefore, was not possible.

So instead, I had to resort to making an AppState observable object that contained, well, all my app state (i.e, all 3 stores). I used the @Republished wrapper written by @adam_zethraeus that you mentioned in your blog post. Here, my stores became coupled and any update to any of them would trigger a refresh of the entire app. However, one upside is that I could pass it around to views through making it an EnvironmentObject (even though this is sub-optimal).

To actually be able to instantiate placeholder data, I went to the dark side. This is what I did:

@MainActor
class Persistence: ObservableObject {
    // declaring stores
    @Republished var peopleStore: Store<BTPerson>
    @Republished var groupStore: Store<BTGroup>
    @Republished var eventStore: Store<BTEvent>

    // initializer taking a boolean representing whether it should be in test mode
    init(isTemp: Bool = false) {
        if isTemp {
            let pStore: Store<BTPerson> = Store(storage: SQLiteStorageEngine.default(appendingPath: "Test"))
            let gStore: Store<BTGroup> = Store(storage: SQLiteStorageEngine.default(appendingPath: "Test"))
            let eStore: Store<BTEvent> = Store(storage: SQLiteStorageEngine.default(appendingPath: "Test"))

            // ugly hack: waiting for first event from publisher to then insert placeholder data
            let cancellable =
            pStore.$items
                .first()
                .sink { items in
                    Task {
                    // insert data
                    }
                }
            
            cancellables.insert(cancellable)
            }

            _peopleStore = .init(wrappedValue: pStore)
            _groupStore = .init(wrappedValue: gStore)
            _eventStore = .init(wrappedValue: eStore)
        } else {
            let pStore: Store<BTPerson> = Store(storage: SQLiteStorageEngine.default)
            let gStore: Store<BTGroup> = Store(storage: SQLiteStorageEngine.default)
            let eStore: Store<BTEvent> = Store(storage: SQLiteStorageEngine.default)

            // even uglier hack to insert default group; uses a debounce for unfortunate reasons that I can explain if necessary. 
            let cancellable = gStore.$items
                .debounce(for: .seconds(0.5), scheduler: RunLoop.main)
                .sink { groups in
                    Task {
                        // insert default group
                    }
                }
            
            cancellables.insert(cancellable)
            
            _peopleStore = .init(wrappedValue: pStore)
            _groupStore = .init(wrappedValue: gStore)
            _eventStore = .init(wrappedValue: eStore)
        }
    }
}

This is... bad... but it works.

Now, it is entirely possible that my reasons for going through all of this are bad and I should just like, write more unit tests instead. But for me, I think that the developer experience boost you get from going through all of this (for previews) might be worth it.

I wonder if there might be a better way of doing all of this that I might be missing. Of course, I understand that this is not a priority for the library and expect nothing to be put into place for this functionality specifically (it likely doesn't mesh with library goals).

But I did want to put this out there anyway just in case, if you had some guidance for something I might be doing wrong.

Thanks for being so receptive, and I'm sorry again for the long overdue (and long) reply.

[mergesort]

@reftonull This is great context and I agree, developer experience does matter! Now that I know what problem you're trying to solve that gives me some better insight, and I can consider some ways to address it I may not have considered before.

For example I was originally shy about performance considerations, but maybe the answer is creating a synchronous way to load a Store with a semaphore (and making it a static function like previewStore(...) rather than an initializer) which would be a no-go in a production environment, but ok for a preview with only a few items. I may even consider making the function have a special constraint such as capping out at 100 or 1,000 and throwing some sort of failure if you initialize it with more. If I can get that working the solution should end up looking a lot simpler, just passing in a different Store to the @Stored property wrapper.

And of course the solution should end up looking a lot simpler, you shouldn't need to do all of this, hopefully I can get to a point where.

---

I don't want to speak definitively since I don't know the context of your code, but I did notice the solution was a little complex and there a couple of things that seem a little off.

All of these paths are the same ("Test"), which would create a Store that writes different types of objects to the same database, which will to be read when it tries to decode them into one type of object at read-time.

let pStore: Store<BTPerson> = Store(storage: SQLiteStorageEngine.default(appendingPath: "Test"))
let gStore: Store<BTGroup> = Store(storage: SQLiteStorageEngine.default(appendingPath: "Test"))
let eStore: Store<BTEvent> = Store(storage: SQLiteStorageEngine.default(appendingPath: "Test"))

The manual usage of @Republished shouldn't be necessary, @Stores have the same functionality in them as the @Republished property wrapper I mentioned in the blog post, so everything should republish automatically. I pushed a change to main a few days ago to address situations where that may not be the case, if you're not using that it may be worth considering.

---

Now I'll go try to see if I can make something that works for you. 🙂

[mergesort]

Good news! I've managed to get this working, and in a way that isn't hacky at all. Since the goal is to fulfill an accurate SwiftUI Preview rather than having a synchronous initializer, I'm actually able to take another approach. This is the solution I came up with, creating a previewStore that intentionally only works in debug and comes with strongly worded documentation to explain that it should only be used for Previews.

Added is a static function you can use in SwiftUI previews

#if DEBUG
    /// A ``Store`` to be used for SwiftUI Previews and only SwiftUI Previews!
    ///
    /// This version of a ``Store`` allows you to pass in the ``items`` you would like to render
    /// in a SwiftUI Preview. It will create a a ``Store`` that **only** holds items in memory
    /// so it should not be used in production, nor will it compile for Release builds.
    ///
    /// - Parameters:
    ///   - items: The items that the ``Store`` will be initialized with.
    ///   - cacheIdentifier: A `KeyPath` from the `Item` pointing to a `String`, which the ``Store``
    ///   will use to create a unique identifier for the item when it's saved.
    /// - Returns: A ``Store`` that populates items in memory so you can pass a ``Store`` to @``Stored`` in SwiftUI Previews.
    public static func previewStore(items: [Item], cacheIdentifier: KeyPath<Item, String>) -> Store<Item> {
        let store = Store(
            storage: SQLiteStorageEngine(directory: .temporary(appendingPath: "Previews"))!, // No files are written to disk
            cacheIdentifier: cacheIdentifier
        )

        Task.detached { @MainActor in
            store.items = items
        }

        return store
    }
#endif

And here's an example of how to create a SwiftUI Preview using this new function.

struct SimpleNote: Codable, Equatable, Identifiable {
    var id: String
    var text: String
}

final class SimpleNotesController: ObservableObject {

    @Stored var notes: [SimpleNote]

    init(store: Store<SimpleNote>) {
        self._notes = Stored(in: store)
    }

}

private struct PreviewStoreView: View {

    @StateObject var simpleNotesController: SimpleNotesController

    var body: some View {
        VStack {
            ForEach(simpleNotesController.$notes.items) { note in
                Text(note.text)
            }
        }
    }

}

struct PreviewStoreViewPreview: PreviewProvider {

    static var previews: some View {
        PreviewStoreView(
            simpleNotesController: SimpleNotesController(
                store: .previewStore(
                    items: [
                        SimpleNote(id: "1", text: "1"),
                        SimpleNote(id: "2", text: "2"),
                        SimpleNote(id: "3", text: "3"),
                        SimpleNote(id: "4", text: "4"),
                        SimpleNote(id: "5", text: "6"),
                    ],
                    cacheIdentifier: \.id
                )
            )
        )
        .frame(width: 320, height: 320)
        .previewLayout(.sizeThatFits)
    }

}

@reftonull Can you try out this solution and let me know if it works for your use cases?