[FEATURE]: Favorite brews

[HeruAsatru]

Original idea can be found HERE.

Posted here for your convenience:

One thing that has bothered me since ever is that every time someone shares a cool homebrew, people have to save the link and bookmark it somewhere else instead of in homebrewery.naturalcrit.com.

Therefore my request is that while you signed in and you access a shared homebrew, logged in users should be able to mark it as "favourite". hen on the users are, there should be a link that opens a page with the list of all homebrews marked as favorite.

I believe it's a very simple feature but some needed and useful.

Many thanks, and if you need UI direction for the feature, please let me know and I will help :)

[G-Ambatte]

As I see it, this needs to be is a array of shareIds stored against the user account (e.g. favorites: []), with a MongoDB query to return the query { shareId: { $in: ${favorites} }} to the User Page. Probably can give it it's own Route /favorites, /liked, etc.

[dbolack-ab]

Beginning backend work here, It is a pseudo-blocker for PR #3321

[ericscheid]

This crosses paths with the folders idea too.

Considerable planning has gone in to that to be compatible with an extensible favouriting system. Like, being able to have more than one collection of faves, of being able to mark a fave as public (vs keeping that bookmarking a secret), etc.

See also issues #758 and #3390.

[5e-Cleric]

We have also talked about the fact that faves and folders could share the same structure, with a difference in display.

[ericscheid]

I believe basic favourites functionality can be implemented using the bones of folders functionality.

A simplified faves-only roadmap:

MVP:

• [ ] create the folders mongoDB collection
• [ ] add UI function to "add to faves", which creates a folders document keyed to the user, and inserts the sharedId of the viewed brew into the brewIds property
• [ ] extend userpage functionality to check for saved faves and if so display in a new block on the user page (i.e. a 3rd group, alongside "published brews" and "unpublished brews". This should only appear when a user views their own /users/ page

Later:

• [ ] add widget to the faves group on user page to allow for renaming the collection (renames the folder)
• [ ] enable "remove from faves" option on the displayed fave brewcards — avoid confusion with "delete my access" function already on brewcards
• [ ] toggle isPublished on the faves folder (and subsequent effect on visibility on userpage)
• [ ] (more to come)

[5e-Cleric]

I am inclined on building this functionality on its own, as G-ambatte suggested, if only because it is an easy structure to follow, and the folder idea is still on diapers.

As I see it, this needs to be is a array of shareIds stored against the user account (e.g. favorites: []), with a MongoDB query to return the query { shareId: { $in: ${favorites} }} to the User Page. Probably can give it it's own Route /favorites, /liked, etc.

Following this, i'd say we create a favorites field in the user schema when a brew is first favorited, then add to that the share id of the favorited brew (should be straightforward). Once that is done, display them without edit or delete button for obvious reason, only to the own user.

How does that sound? And specially, if i did it this way would it really truncate the idea of folders? They would just be two separate functions, which could even avoid bugs breaking folders too.

[ericscheid]

How does that sound? And specially, if i did it this way would it really truncate the idea of folders? They would just be two separate functions, which could even avoid bugs breaking folders too.

If faves are built first, being simpler, then this does not block building folders later. Folders, once built, could wholly overlap the faves functionality, so the only (slight) risk is of duplicative/wasted effort, and any effort cost of refactoring faves into being simply members of a "Faves" folder.

The only intriguing aspect is the idea of displaying faves as a top-level category alongside "Published Brews" and "Unpublished Brews" (vs. displaying a card for the folder, and then click-thru to display the folder contents).

(It's also tempting to add a flag to folder meta data for a folder to be displayed in that way too, as yet-more-creeping-doom another feature).

[5e-Cleric]

If faves are built first, being simpler, then this does not block building folders later. Folders, once built, could wholly overlap the faves functionality, so the only (slight) risk is of duplicative/wasted effort, and any effort cost of refactoring faves into being simply members of a "Faves" folder.

I was thinking that that way we could build the two features in two, medium sized PRs that could be worked on and merged independently.

The only intriguing aspect is the idea of displaying faves as a top-level category alongside "Published Brews" and "Unpublished Brews" (vs. displaying a card for the folder, and then click-thru to display the folder contents).

Would Only be displayed to the owner of the userpage, would it not?

(It's also tempting to add a flag to folder meta data for a folder to be displayed in that way too, as yet-more-creeping-doom another feature).

[ericscheid]

The only intriguing aspect is the idea of displaying faves as a top-level category alongside "Published Brews" and "Unpublished Brews" (vs. displaying a card for the folder, and then click-thru to display the folder contents).

Would only be displayed to the owner of the userpage, would it not?

Faves, sure.

In the Folders spec there is a flag for whether the existence and contents of a folder are revealed to visitors who are not the owner of the folder. For a Faves folder, that would be set to Unpublished (or whatever). A user might conceivably curate a collection of 3rd party brews that they want to be visible to others, like a folder of "Best brews of 2023".

This visibility attribute would be different from the how-it-is-displayed quality.