GoodDAPP
GoodDAPP copied to clipboard
Implement like feature
- [ ] RealmDB: create x collection
likes
(user_id
,content_id
), add uniq index foruser_id
+content_id
- [ ] ThreadDB: create collection
likes
(content_id
,count
) - [ ] RealmDB: add method queryLikes(contentId, userId = null) querying likes count by specific filters from realm
- [ ] RealmDB: add method addLike(contentId, userId) which inserts document to likes collection
- [ ] UserStorage: add method addLike(contentId) a) calls queryLikes(contentId, this.user.id) b) if result is - calls addLike(contentId, this.user.id)
- [ ] UserStorage: add method getLikes(contentId). reads data from threaddb, returns null or false if no data cached, likes count otherwise
- [ ] UserStorage: add method getLikesAndSync(contentId). reads and aggregates remove data from realm by content id, updates local cache, returns likes count
- [ ] add hook
useContentLike(contentId)
: a) calls getLikes(contentId) b) if found - updates likes count in state var c) calls getLikesAndSync(contentId), updates likes count in state var d) declares addLike fn, which recallsaddLike(contentId)
, then getLikesAndSync(contentId) and returns its result e) exports [likes, addLike] - [ ] add component
<Likes contentId={contentId}>
. a) reuses hook b) renders button once likes are loaded (likes !== null
orfalse
) c) calls addLike fn on button push d) displays likes count got from hook
@johnsmith-gooddollar @patpedrosa what is this?
Option to add "Like" to the feed post. Ceramic won't be a good option to keep likes due to the slow performance So we'll use realm + local caching of aggregated data (with likes counted) in thread db
This is an optional task, not planned for the initial feed release
As the alternative we could also find for some ready solution but it won't be decentralized and also we would need to find some like widget working on both web and RN
Did @patpedrosa define the requirements for this feature? where are they? this should not be in "sprint"
This is in sprint because we may do it if we will have time
This is a generic "like" feature. Like on any social media. There're no any "requirements" possible, everything is clear.
There's no such thing as "like on any social media", Do you have an idea what's happening behind the scenes in all those social media platforms when user presses "like"? so obviously its not "like any social media" Plus you raised important issue that you would have to use mongodb to store it, now that makes things even more complicated. All features should be defined by @patpedrosa first and then evaluate what are the technological and architectural implications
This feature is so simple that I wonder why you want to discuss something)
I know what happening on like press. I had experience implementing such things. I've been working on hi-load social media project in 2011 and 2013-2015
I'm also doesn't like the realm db solution. I'd prefer to use custom backend and store likes data onto myisam MySQL table with the proper indexes configuration. And use separate table to store aggregated data. But you suggested to use decentralized solutions so realm is only option here as a) ceramic is really slow b) we've defined that we will have r/o ceramic access from client side
The solution described contains many points just because I decomposed it well. So it will be simple to implement by our team. Personally if would do it in a half of day with testing. There's really nothing to do - one realm table one local cache schema. Simple logic to get data, simple document insert on "voting"
@patpedrosa need to discuss this next week
@sirpy @patpedrosa Does it still relevant or could be closed / moved to the IceBox ?