Infinite loading and pagination

[juanpprieto]

This is a clean PR replacing #59 which became too difficult to merge back to main.

Quick demo:

https://screenshot.click/13-23-iwnci-10qow.mp4

Completed:

• Adds infinite loading & pagination (optional) to /products & /collections/$handle
• Adds infinite loading /collections

Todo:

• Extend MoreGridItems to add infinite on /journal
• Add orders pagination on /account
• Sync with @brophdawg11 about leveraging Link.state in the pagination.

---

@brophdawg11's comment

One nuance here that Ryan and I chatted about after the huddles - this location state will work great for client-side back/forward navigations, but won't available during SSR if the user does a hard reload - and then will be available client side so could result in hydration issues or flickers of SSR-ing only the "trailing" pages and then client-side rendering the prepended pages from location state.

To avoid this, hard reloads should ignore the client side state and should effectively be treated as if you shared the URL to a new browser. Probably requires some form of isHydrated check to see if we got SSR'd without the previous pages and then we know not to prepend them.

---

@benjaminsehl @cartogram @brophdawg11

[cartogram]

Suggested change

	{new Array(pageBy).fill('').map((_, i) => {
	Array.from({ length: pageBy }, (_, i) => {

[cartogram]

What do you think about breaking this out into a small helper.

function normalizeResultForResource(resource: ResourceType, data: any) {
  let result;
  switch (resource) {
    case "product":
      result = data?.products;
      break;
   case "collection/handle":
      result = data?.collection?.product
      break;
    case "collection":
      result = data?.collection
      break;
    case "blog":
      // TODO
    case "article":
      // TODO
  }

  return {
    hasNextPage: result?.pageInfo?.hasNextPage || false,
    endCursor: result?.pageInfo?.endCursor || null,
    nodes: result?.nodes || [],
  };
}

[brophdawg11]

Looking good! Hit me up in slack if you wanna chat about the location state approach 👍

[brophdawg11]

These loading states will go into Loading... on any navigation, including clicking "load previous" (unlikely to be in viewport) or clicking through to a product (more likely to be in viewport). We can narrow the condition a bit, maybe:

transition.state === 'loading' && new URLSearchParams(transition.location.search).get('direction') === 'next'

[brophdawg11]

Using a fetcher works here but won't provide URL updates, so if the user is scrolled down a few pages and shares the link or reloads the page they'll lose their spot. I was envisioning this being the same type of flow as the Load More but automatically triggering the navigations when the button of the current "page" scrolled into view. You could either omit/hide the load more button or leave it as an indicator to the user that more products are loading (but skeleton tiles may be a more seamless UX)

Happy to chat on a meet but the way that would work in my head (using Load More clicks for the time being) would be something like this (for the simple scroll forward case):

// The route would get the current page products from loader data 
let currentPageProducts = useLoaderData().products;
// And if it found products from prior pages in location state...
let locationProducts = useLocation().state;
// It would prepend them and show the full set
let currentlyShownProducts = [...locationProducts || [], ...loaderProducts];

// Then the Load More link would pass current products through in location 
// state for the next page to prepend
<ProductGrid products={currentlyShownProducts}
<Link to="?cursor=abc&direction=next" state="currentlyShownProducts">

That way, assuming we show 4 products per page:

• On initial load location.state is empty and we just render the first 4 products from the loader
• Clicking load more sends 1-4 through location.state, loads 5-8 from the loader, and renders all 8 products
• Clicking load more again sends 1-8 through location.state, loads 9-12 from the loader, and renders all 12 products
• ...and so on

I think @ryanflorence and @developit looked into browser limits on the size of location state in SF and 640kb sticks in my head, but we thought it plenty large to hold product metadata.

Then, if you want to enable automatic infinite scrolling, you would just trigger the navigations automatically via useNavigation, sending the same to URL and location state

[brophdawg11]

This also introduces the nuance mentioned in the description, so we'll need to figure out a good solve for that

[benjaminsehl]

@cartogram @juanpprieto

The goal for Pagination should be to provide a generic enough abstraction where you can pass any paginated Storefront API query to it, and easily configure the pagination style.

This could also be applied to something like a product carousel where you only want to load the first four products unless the shopper starts scrolling to the end; or clicking a "next" arrow.

[juanpprieto]

The goal for Pagination should be to provide a generic enough abstraction where you can pass any paginated Storefront API query to it, and easily configure the pagination style.

This could also be applied to something like a product carousel where you only want to load the first four products unless the shopper starts scrolling to the end; or clicking a "next" arrow.

I have a local commit with a reusable <Paginated /> component based on this approach.

There are still some important nuances and caveats that I'd love to show/discuss in a video-call before pushing for review

More info here: https://shopify.slack.com/archives/C02A5S8LNP9/p1666022331264459?thread_ts=1665775151.336469&cid=C02A5S8LNP9

[benjaminsehl]

From link to Slack above:

Spent a Friday trying to fix the hydration issues and refactoring with the goal of creating a reusable <Paginated /> component. Here are some points/downsides I'd like to share:

• Hydration issues — Mostly fixed but it's added additional boilerplate to avoid it
• Scroll position issues — When navigating to a new page the scroll resets to the top. It appears the feature to prevent reset is not yet available in Remix's Link
• Complexity. Are we using too much platform history.state? Worried the common dev will struggle to understand this caching + pagination mechanism (I did)
• Navigating back to the root of a fully fetched collection does not show the fully cached collection because the root link doesn’t have the cursor in the url when going to a collection via the menu or a link on the site
• Paginated urls are really long due to the cursor. Worried how they will end up once utm params kick in
• Unsure how well this approach will work with Modal based grids like search results displayed in a modal

[cartogram]

Moved to #207