如何实现前后端下拉刷新场景下的分页适配？

Hey there! Let's walk through some alternative approaches for managing your infinite scroll feed state—beyond the hash map + ID list setup you’re currently using. All these work seamlessly with Redux (or any front-end state manager) and cater to different needs like better cache control, granular loading states, or handling real-time post updates:

If your app has multiple feeds (e.g., home feed, user-specific feed, trending feed), this approach lets you isolate pagination state per feed while keeping your post cache centralized. Here’s what the state might look like:

{
  postsById: { /* Your existing normalized post hash map */ },
  pagination: {
    'feed:home': {
      slices: [
        { ids: ['a', 'b', 'c', ..., 'j'], cursor: 'post-j-123', isLoading: false, hasMore: true },
        { ids: ['k', 'l', ..., 't'], cursor: 'post-t-456', isLoading: false, hasMore: false }
      ],
      currentCursor: 'post-t-456'
    },
    'feed:user:123': { /* Same structure for a user's personal feed */ }
  }
}

• Why it works: Each feed’s pagination slices are tracked independently, so loading the next page of the home feed doesn’t interfere with a user’s profile feed. You can also easily invalidate or refresh individual feeds without touching others.
• Best for: Apps with multiple distinct feeds or where you need granular control over cache invalidation.

Offset-based pagination can get messy if posts are deleted or reordered (you might skip duplicates or miss content). Switching to a cursor-based system (using the last post’s ID/timestamp as a marker) fixes this, and you can structure state to track your current "window" of content:

{
  postsById: {},
  activeFeed: {
    ids: ['a', 'b', ..., 'j'],
    previousCursor: null, // For infinite scroll up (if needed)
    nextCursor: 'post-j-123',
    isLoadingNext: false,
    hasMoreNext: true
  },
  invalidatedFeeds: ['feed:home'] // Track feeds that need a full refresh
}

• Why it works: When you scroll to the bottom, you pass nextCursor to your API instead of an offset, ensuring you always get the next set of posts relative to the last one you loaded. If a post is updated, you can mark its feed as invalidated to trigger a refresh on the next load.
• Best for: Real-time feeds where content is frequently added/removed, or where you want to avoid offset-related bugs.

If you’re building a smaller app with only one feed and don’t need complex normalization, you can store posts directly in a list alongside pagination state. This keeps your state structure simple and easy to reason about:

{
  homeFeed: {
    items: [
      { id: 'a', content: 'Some content', points: 100 },
      { id: 'b', content: 'Other content', points: 98 },
      // ...
    ],
    nextOffset: 10,
    isLoading: false,
    hasMore: true
  }
}

• Tradeoffs: Updating a single post requires searching the array, which can be slower than a hash map. But with libraries like Immer, you can optimize updates without much hassle.
• Best for: Small apps with a single feed and minimal post updates.

This is an extension of your current approach, aligned with Redux’s official normalized state recommendations. You keep your centralized postsById hash map, but create dedicated "views" to track ID lists for different pagination scenarios:

{
  entities: {
    posts: { /* Your normalized post cache */ }
  },
  views: {
    homeFeed: {
      pageIdGroups: [['a','b',...], ['k','l',...]], // Array of page ID arrays
      currentPage: 1,
      isLoading: false,
      hasMore: true
    },
    trendingFeed: {
      pageIdGroups: [['m','n',...]],
      currentPage: 0,
      isLoading: false,
      hasMore: false
    }
  }
}

• Why it works: The entities section is the single source of truth for all post data—updating a post here automatically reflects in every view that uses it. Views let you quickly switch between different feeds without reloading data.
• Best for: Complex apps where posts are used across multiple components/feeds.

To boost user experience, you can implement optimistic loading where you show placeholder content while fetching the next page. Track these pending requests in your state to avoid duplicate calls and handle failures gracefully:

{
  postsById: {},
  homeFeedIds: ['a','b',...,'j'],
  loadingQueue: [
    { offset: 10, status: 'pending', tempIds: ['temp-1','temp-2',...,'temp-10'] }
  ],
  hasMore: true
}

• How it works: When the user scrolls to the bottom, you immediately add temporary IDs to your feed list (rendered as loading placeholders) and fire the API request. On success, replace the temp IDs with real post IDs; on failure, remove the placeholders and show an error.
• Best for: Apps where perceived performance is a top priority, and you want to avoid empty loading states.

The right approach depends on your app’s complexity, how many feeds you support, and how often posts are updated. Start simple and iterate as your app grows!

内容的提问来源于stack exchange，提问作者JamesR