1

I'm creating an app with a "Card stack" similar to Tinder, with a Firebase Realtime DB backend. Each card will be a new unread post, if the user runs out of new posts they will run out of cards. However I don't know the best way to structure the data for this. Could I store the ID of the read posts under the user, then as I watch the Posts feed I could filter out read posts client side?

That seems a bit messy and not a very good option performance wise. Are there better options?

EDIT: Rough code of what I'm thinking:

Data Example

posts:
     "-KibasdkjbSAdASd": {
          title: 'New Post',
          body: {
              ...
          }
     },
     "-KisadBVsdadSd": {
          title: 'New Post 2',
          body: {
               ..
          }
     }
     "-KibaFNQsicaASd": {
          title: 'New Post 3',
          body: {
              ...
          }
     }

users :      
     "-KisadBVsdadSd": {
          name: 'Tom',
          readPosts: {
              "-KibasdkjbSAdASd": {
                   title: 'New Post',
                   body: {
                        ...
                   }
              },
              "-KisadBVsdadSd": {
                  title: 'New Post 2',
                  body: {
                       ..
                 }
             }
        }
     }

Code

const rootRef = firebase.database.ref();
const postRef = rootRef.child("posts");
const readPostRef = rootRef.child("users/"+uid+"/readPosts");

let readPosts= [];

//Get initial list of read posts
readPostRef.once("value", function(snapshot) {
  readPosts = Object.keys(snapshot);
});
//Update read posts when added
readPostRef.on("child_added", function(snapshot) {
  readPosts = Object.keys(snapshot);
});

 //Get list of posts, filtered on read post array
urlRef.on("value", function(snapshot) {
  snapshot.forEach(function(child) {
    if(!readPosts.includes(child.key)){
       //Unread post
    }
  });
});
Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
DasBeasto
  • 2,082
  • 5
  • 25
  • 65

2 Answers2

0

It depends on the order in which you show the cards to the user.

If you show them in a predictable order (e.g. from newest to oldest) you can just remember the ID of the last card the user saw.

If you show them in a random or personalized order you might indeed have to track precisely what cards each user has already seen.

I'm not sure why that would be messy or perform badly. So if you want a better option, you'll have to show how you'd implement the messy/slow option.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thanks! I may try to order it by date but I think it would work better in my situation to have it random. I think it may just be messy from my lack of experience with Firebase, I've included code now to show roughly what I was thinking (probably a bit of psuedocode, I wrote it on the fly). – DasBeasto Aug 24 '17 at 15:00
  • I'm still not sure what's messy about that. I'd probably not duplicate the entire posts for each user, but that depends on your use-case. There's reasons for many levels of duplicating. If you're new to NoSQL and cringe at the data duplication, I recommend reading [NoSQL data modeling](https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/) and watching [Firebase for SQL developers](https://www.youtube.com/playlist?list=PLl-K7zZEsYLlP-k-RKFa7RyNPa9_wCH2s). – Frank van Puffelen Aug 24 '17 at 16:10
-1

I'm running into this same design problem. I only see two options, perhaps there are others!

1) Download every post and ignore the ones that have been read. Expensive when you have a lot of posts.

2) Save a copy of every post to every user account and allow them to delete them once they have been read. Expensive when you have a lot of users.

Luke Pighetti
  • 4,541
  • 7
  • 32
  • 57