Social Media Feed Clone

A social feed usually shows the same post in several places: the main feed, a user profile, a saved posts view, notifications, and a single post page. A common mistake is storing separate copies of the same post in each view. This works at the beginning, but it quickly creates bugs: the user likes a post in the feed, then opens the profile page and sees the old like count.

Problematic approach:

          const [feedPosts, setFeedPosts] = useState([]);
          const [profilePosts, setProfilePosts] = useState([]);
          const [postDetails, setPostDetails] = useState(null);
          function likePost(postId) {
            setFeedPosts(feedPosts.map((post) =>
            post.id === postId ? { ...post, liked: true } : post
            ));
          }

In this version, only feedPosts changes. The profile page and post detail page may still contain the previous version of the same post.

Better approach:

          const [postsById, setPostsById] = useState({});
          const [feedIds, setFeedIds] = useState([]);
          const [profilePostIds, setProfilePostIds] = useState([]);
          function likePost(postId) {
          setPostsById((posts) => ({
          ...posts,
          [postId]: {
            ...posts[postId],
            liked: true,
            likesCount: posts[postId].likesCount + 1
          }
          }));
          }

Pay attention to: Keep one source of truth for posts and let different routes render by ID. This makes likes, comments, reposts, and edited content stay consistent across the entire application.

Infinite scrolling looks simple, but it can easily overload your app if every scroll event starts a new request. Without a loading guard, fast scrolling may trigger several identical API calls before the first one finishes. The result is duplicated posts, unstable ordering, unnecessary network usage, and confusing loading states.

Problematic code:

          window.addEventListener("scroll", () => {
            const nearBottom = window.innerHeight + window.scrollY >= document.body.offsetHeight - 300;
            if (nearBottom) {
            fetchMorePosts();
            }
          });

This code does not know whether a request is already running. If the user stays near the bottom, the same function can fire repeatedly.

Recommended solution:

          let isLoading = false;
          let hasMorePosts = true;
          async function loadMorePosts() {
          if (isLoading || !hasMorePosts) return;
          isLoading = true;
          try {
            const nextPosts = await fetchPosts({ page: currentPage + 1 });
            appendPosts(nextPosts);
            hasMorePosts = nextPosts.length > 0;
            currentPage += 1;
          } finally {
            isLoading = false;
          }
          }

Pay attention to: Use loading flags, page cursors, and clear end-of-feed logic. For a more advanced solution, use IntersectionObserver instead of listening to every scroll event manually.

Social feeds are constantly changing. New posts appear, comments are added, older items are loaded, and users can delete or edit content. If you use array indexes as keys, the UI can reuse the wrong DOM nodes after the list changes. This may cause visual glitches, incorrect focus behavior, or reactions appearing on the wrong item.

Problematic code:

          {posts.map((post, index) => (
          <PostCard key={index} post={post} />
          ))}

Better approach:

          {posts.map((post) => (
          <PostCard key={post.id} post={post} />
          ))}

The same rule applies to comments, notifications, messages, and user lists. Every item that can be added, removed, or reordered should have a stable unique identifier.

Pay attention to:

• Use database IDs or generated IDs that remain stable between renders.
• Do not use indexes for feeds, comments, notifications, or search results.
• Keep IDs consistent across feed, profile, and post detail routes.
• Use stable keys before adding animations or optimistic updates.

Instant UI feedback makes a social app feel fast, so optimistic updates are useful. The mistake is updating the interface immediately but never handling failed requests. If the API rejects the action, the user may see a like that was never saved, a comment that disappears after refresh, or a counter that no longer matches the backend.

Problematic approach:

          async function handleLike(postId) {
          updatePost(postId, { liked: true, likesCount: likesCount + 1 });
          await api.likePost(postId);
          }

This version assumes the request will always succeed. It also does not protect against rapid double-clicks.

Better approach:

          async function handleLike(postId) {
          if (pendingLikes[postId]) return;
          const previousPost = postsById[postId];
          setPendingLikes((state) => ({ ...state, [postId]: true }));
          updatePost(postId, {
          liked: !previousPost.liked,
          likesCount: previousPost.liked
          ? previousPost.likesCount - 1
          : previousPost.likesCount + 1
          });
          try {
          await api.toggleLike(postId);
          } catch (error) {
          updatePost(postId, previousPost);
          showToast("Could not update like. Please try again.");
          } finally {
          setPendingLikes((state) => ({ ...state, [postId]: false }));
          }
          }

Pay attention to: Optimistic updates are not just about making the interface faster. They also require rollback, pending states, disabled repeated actions, and clear error feedback.

A realistic feed should not punish users for opening a post. If someone scrolls through 80 posts, opens one item, and then returns to the feed, they should land close to the same position. Beginners often rebuild the feed from scratch on every route change, which makes the application feel unstable and frustrating.

Problematic code:

          function openPost(postId) {
          navigate(`/posts/${postId}`);
          setFeedPosts([]);
          setCurrentPage(1);
          window.scrollTo(0, 0);
          }

Improved approach:

          const scrollPositions = new Map();
          function leaveFeed(routeKey) {
          scrollPositions.set(routeKey, window.scrollY);
          }
          function restoreFeed(routeKey) {
          const position = scrollPositions.get(routeKey) || 0;
          requestAnimationFrame(() => {
          window.scrollTo(0, position);
          });
          }

Pay attention to: Preserve loaded posts, pagination state, active filters, and scroll position when moving between feed, profile, and post detail routes. This is one of the details that makes the project feel closer to a real product.

Like buttons, comment buttons, repost buttons, profile links, and message actions are not decorative. They are interactive controls. A common mistake is building them with clickable <div> or <span> elements and ignoring keyboard users, screen readers, focus states, and disabled states.

Less accessible:

          <div class="like-icon active" onclick="likePost(post.id)">
          ♥
          </div>

Better structure:

          <button
          type="button"
          class="like-button"
          aria-pressed="true"
          aria-label="Unlike this post"
          onclick="toggleLike(post.id)"
          >
          ♥
          </button>

Pay attention to: Use real buttons for actions, real links for navigation, visible focus styles for keyboard navigation, and meaningful labels for icon-only controls. Dynamic feeds should be usable, not only visually impressive.