Favorite renaming

[Lyinlyon]

Favorites can now be renamed inline. The favorite search now searches by the favorite id and name rather than the insertable. The changes to packages and the addition of the coverage folder were done automatically and I have no idea what they do.

[AlexKempen]

|| -> ??

[AlexKempen]

I think for the create endpoint we can simplify the sortOrder logic to:

    const existingFavorites = await db.$count(
        favorites,
        and(eq(favorites.userId, userId), eq(favorites.libraryId, libraryId))
    );

    await db
        .insert(favorites)
        .values({
            id: favoriteId,
            userId,
            libraryId,
            insertableId,
            sortOrder: existingFavorites + 1
        })
        .onConflictDoNothing();

Which just sets the sortOrder to the number of existing favorites+1 more directly

[AlexKempen]

It's looking good, you can see my comments above.

I also realized our search logic was pretty scuffed and/or scattered, so I added a typed SearchResultDocument helper and renamed/re-organized our existing search implementation so the organization is a bit clearer, so make sure you run git pull the next time you work on it so you get my changes/don't run into conflicts

[AlexKempen]

Here's an existing pattern we use for updating a row

    const body = await c.req.json<{ theme?: Theme; libraryId?: LibraryId }>();

    const db = getDb(c.env.DB);

    await db.insert(users).values({ id: userId }).onConflictDoNothing();

    if (Object.keys(body).length > 0) {
        await db.update(users).set(body).where(eq(users.id, userId));
    }

[AlexKempen]

&& is already a boolean, so Boolean() is redundant

[AlexKempen]

Double checking searchHit (already checked in isSearchActive)

[AlexKempen]

This TextInput (and related hooks and whatnot) feels like a separate EditTitle component that takes an onEditComplete callback

[AlexKempen]

I really like how this is a seperate custom hook to encapsulate the mutation logic!

[AlexKempen]

It would probably be best to rename this component CardTitleGroup and have it wrap a different CardTitle component that composes a standard title, SearchHitTitle, and EditTitle components. See https://react.dev/learn/passing-props-to-a-component#passing-jsx-as-children for info on how you can type/use the component, the end pattern you're looking for is:

<CardTitleGroup thumbnailUrls={thumbnailUrls} buildStatusBadge={badge}>
    <CardTitle title={title} searchHit={searchHit} isEditing={isEditing} />
<CardTitleGroup />

The EditTitle component can come from your editable title logic below.

[AlexKempen]

I think it would be good to also include vendors: Vendors[] in here so we can easily display the number of favorites filtered out (the pattern should match the existing pattern). I also added a filter block to the search function you can use to implement

[AlexKempen]

Favorite name should be nullable and null by default, meaning "use the name of the insertable since the user hasn't set one", since otherwise admin renames won't update people's favorites by default

[AlexKempen]

Shouldn't need to index fields other than name (and vendors if you add it)

[AlexKempen]

We do need the insertable name in the searchDb when favorite name is undefined, which probably means passing in insertables. You could also probably write a helper like getInsertableName(favorite, insertable) which returns "" if the insertable doesn't exist