Небольшие запросы API в Gatsby с GraphQL и React

#reactjs #graphql #gatsby #airtable

#reactjs #graphql #gatsby #airtable

Вопрос:

Я пытаюсь импортировать элементы из Airtable в Gatsby. В моей таблице около 800 записей. Это не большая нагрузка сама по себе, но я хотел бы отображать несколько элементов за раз, нажимая кнопку «Еще» для вызова следующего пакета. В Gatsby это не очевидно, поскольку, похоже, оно направлено на запросы к базам данных меньшего размера.

Каков наилучший способ действий здесь? Я попытался добавить к кнопке функцию, которая обновляет переменные startIndex и endIndex, но страница больше не будет отображаться, и простое прикрепление forceUpdate к кнопке не сработает. Я также пытался переместить список элементов в компонент, но размещение кнопки рядом с ним всегда выдает ошибку. Должен ли я сначала сохранить запрос в const? Кто-нибудь пробовал это раньше?

 
import { graphql } from "gatsby"

export const query = graphql`
  {
    allAirtable(sort: {order: ASC, fields: id}, limit: 100) {
      nodes {
        id
        data {
          Name
          Area
          Year
        }
      }
    }
  }
 ` 

let startIndex = 0;
let endIndex = 10;

const IndexPage = ({ data }) => {

  return(
  <div>
    <h1>Item list</h1>
    <p>Page count: {data.allAirtable.pageInfo.pageCount}</p>
    <ul>
      {data.allAirtable.nodes.slice([startIndex], [endIndex]).map(node => (

        <li key={node.id}>
          {node.data.Name} <br />
          {node.data.Area} <br />
          {node.data.Year} <br />
        </li>

      ))}
    </ul>
    <button>More</button>
  </div>
 )}

 export default IndexPage
  

Ответ №1:

Поиск 'load more in gatsby'

«Начальный» запрос gatsby предназначен для создания статического содержимого (позже «сервер» gatsby не будет существовать) — «загрузить больше» является динамическим, не может быть сделано таким образом, возможен только разбиение на страницы — см. Документы gatsby. Также прочитайте о 'fetch build and run time' .

Динамику можно выполнить с помощью «обычного» (для времени выполнения react) клиента graphql (например, apollo)… или загрузка некоторых подготовленных, сгенерированных gatsby статических файлов json с помощью fetch / axios.

Комментарии:

1. Спасибо! Я посмотрю на разбивку по страницам. Я думаю, что это то же самое, за исключением того, что мне не нужно переходить на фактическую страницу, мне просто нужно загрузить следующую партию элементов.

Ответ №2:

Есть несколько способов сделать это. Для некоторых вариантов использования имеет смысл запустить сервер GraphQL, к которому вы запрашиваете клиентскую часть (например, с помощью Apollo), и использовать сшивание GraphQL в Gatsby для отображения исходного содержимого на стороне сервера. Для чего-то более простого, например, для загрузки большего количества сообщений в ленту, вам будут полезны предварительно скомпилированные ответы на каждый из этих ожидаемых запросов. Я делал это в прошлом, запрашивая нужные мне данные в gatsby-node.js и выписывание файлов JSON с фрагментированными данными (в public ) и выдача обычных HTTP-запросов для этих файлов по мере необходимости со стороны клиента. Это должно быть относительно просто, но если вам нужна дополнительная помощь или пример реализации, дайте мне знать в комментариях.

Комментарии:

1. Спасибо. В первой версии проекта (базовый html / js) списку 800 записей предшествовала панель опций, содержащая различные кнопки фильтрации. Каждый фильтр фактически обновлял бы параметры и выполнял новый вызов API. Это обременительно, поэтому, возможно, во время сборки Gatsby можно выполнить один вызов, сохраняя данные. После этого, может быть, это все базовый react для сортировки элементов или скрытия их с помощью определенных ключей? Я хотел бы знать, как вы использовали gatsby-node, но я не уверен, что смогу предварительно разделить все на куски.

2. @east1999 разделять или не разделять … кодируйте весь набор в одном json (фильтруйте в apollo / array во время выполнения), если он небольшой — файл данных размером в несколько МБ сегодня не так уж много

3. @xadm Если вы фильтруете, вы находитесь в немного менее оптимальном месте. Если вы создаете предварительно отфильтрованные списки данных, вы рискуете, что пользователь загрузит лишние данные при переключении между ними. И наоборот, если вы вообще не выполняете фильтрацию, вы рискуете снизить производительность на более медленных устройствах и подключениях. Возможно, вы обнаружите, что что-то вроде Sanity , позволяющее выполнять запросы со стороны клиента, является лучшим решением без головы, чем пытаться использовать Airtable, где использование API является запоздалой мыслью.