aeharding
feat: Favourite communities
In Apollo, you can favourite a community and it will add it to a more accessible section on top of the default communities list. This PR adds similar functionality. #67
- Favourite communities are stored in localStorage, similar to how appearance settings are stored.
- Favourites are segregated by accounts the user has stored. Each user has its own set of favourite communities that do not merge or interfere.
Demo:
https://github.com/aeharding/wefwef/assets/51917118/b75e0662-e4a6-4ca1-ac9f-b40f3e4d648e
This looks good! My only concern is that if you favorite a community that you aren't subscribed to, it won't appear in your favorites.
In apollo, your favorites are independent of subscriptions.
Also, unfortunately Apollo doesn't have a bulk get communities by ID endpoint. So it would require a separate request per favorite (that you aren't already subscribed to) unless I'm missing something.
We could also just say in wefwef you can only favorite communities that you're subscribed to... and unfavorite on unsubscribe.
Thoughts? My priority is to make a consistent user experience, but it's OK if it's missing some functionality.
You're right about Lemmy's API not having a bulk retrieval endpoint. I think we could do separate requests and it wouldn't be a huge deal, but the easiest way is to link it with subscriptions.
I think it's rare that people will favourite unsubscribed communities in any event. If they want to have it in their list so bad, they could create a new account in the switcher specifically for it. Afterall, Lemmy account creation is way faster than on Reddit.
Yeah... Thinking about this a bit more, favorites on Apollo are irrespective of account (global to the app). Like here. Which is nice, but... switching between accounts on wefwef, you might be subscribed to different communities and then your favorites disappear.
I still think favorites should be irrespective of lemmy account, but I'm still not sure the best way around this...
perhaps we could limit faves to 10 and then fetch whatever is missing from subscriptions?
does apollo have a fave limit?
Personally, I'd prefer to have different favourites per account. If we do it globally, then we could make use of IndexedDB to cache the metadata about the community and update it only when the account is signed back in. Apollo doesn't have a limit.
Different favorites per account makes sense to me.
I have multiple accounts so that I can make things different on the other accounts 😊
I'm down with per account.
Oh and another idea, if the user isn't subscribed, just don't render an icon. The community handle is all we should need for rendering and navigating :)
I've just added your idea. When favouriting a non-subscribed community, it will still show up, but with a FakeIcon using its ID as a seed.
Favourites are now stored as their actor ID and ID.
Awesome. Looks like some conflicts, I can resolve later if you don't get to it.
Hope you don't mind if I chime in since the linked issue was assigned the Apollo Parity tag. FWIW, Apollo would allow users to add/remove subreddits to the app's list of Favorites. This meant that a user did not need to have subscribed to that subreddit, nor would said favorite only be available for a particular user.
I personally found this functionality to be especially useful for subreddits that would otherwise spam my main feed with inane or undesired posts. For instance, I favorited r/3dprinting but intentionally didn't subscribe; while I want to help others determine what kind of printer fits their requirements, I don't want to see pictures of everyone's first 3d print and/or why it didn't well.
(And yes, I'm well aware other redditors would use it to keep "NSFW" subreddits out of their feed.)
I would love to see the same functionality implemented for Lemmy communities as well.
@dcpesses If you look at the commit history, that was already implemented in this PR.
@aeharding Oh crap, my apologies! I must have been browsing the wrong commit. Carry on with the good work, @httpjamesm!
This is the next feature priority. @burakcan, perhaps your work with Dexie for the db would be ideal for storing favorites? What do you think?
Ideally we would get the data storage nailed before merging this, so people don't loose their favorites and we don't have to do extra work to migrate to Dexie later.
@aeharding yes I think it would be good to store these in the db. We can still store small things in localstorage. But I think in general moving more complex use cases to the db will be better because of better structured migrations, better perceived performance (async db requests vs sync localstorage gets) etc.
@httpjamesm Indexeddb storage branch has been merged in! Are you able to update this branch for those changes today or tomorrow?
Thanks!
@httpjamesm Sorry, I just pushed some changes! Everything looks good to me, I just integrated with the new storage API we have and cleaned up the stored data (just storing the handle now).