【问题标题】:Gatsby useStaticQuery with localeGatsby 使用带有语言环境的静态查询
【发布时间】:2021-10-04 15:27:44
【问题描述】:

我正在使用具有内容数据源和 gatsby-plugin-react-int 的 gatsby。

在我网站的每个页面上显示最新消息的块,因此我使用 useStaticQuery 挂钩来获取“新闻”组件的数据

export const useStaticNewsQuery = () => useStaticQuery(graphql`
query StaticNews {
  allContentfulNews {
    nodes {
      node_locale
      gatsbyPath(filePath: "/news/{contentfulNews.slug}")
      slug
      title
      body {
        body
      }
      publishDate
    }
  }
}
`)

但由于我的网站是多语言的 - 我需要获取与当前语言环境相关的本地化新闻。

据我所知 - staticQuery 不允许传递变量。

但是如何才能在组件中只请求与当前语言环境相关的新闻呢?

如果我将使用 pageQuery - 我将必须对我的应用程序中包含“新闻”组件的每个页面发出相同的请求,并将结果通过道具/上下文传递给我的“新闻”组件

也许我应该在 gatsby-node.js 中使用一些魔法来查询与当前语言环境相关的数据并将其传递给一些全局上下文? 此外 - 页眉、页脚和页面的其他部分也将使用相同的内容,这些内容将由单独的组件呈现并放置在几乎所有页面上,但应取决于当前的语言环境

【问题讨论】:

    标签: graph internationalization gatsby contentful gatsby-plugin


    【解决方案1】:

    鉴于您的场景和您的要求,我只能想象:

    1. 为每个语言环境创建一个静态查询 (useStaticQuery) 以获取新闻:然后您只需要获取当前语言环境并触发所需的查询,例如:
      let news;
      if (currentLocale = 'en') news = useStaticNewsQueryEn();
      els if (currentLocale = 'es') news = useStaticNewsQueryEs();
      
    2. 正如您所指出的,使用带有页面当前区域设置值的过滤页面查询
    3. 调整您的 gatsby-node.js 以获取数据并将其共享到所需的组件(应始终是模板或动态创建的页面)并通过上下文共享。

    关于您的共享组件(页脚、页眉等),您始终可以根据语言环境(条件渲染)渲染所需的组件,这应该不是问题。

    您应该看到在您的特定用例中性能更好、可扩展性/灵活性更高。

    【讨论】:

    • 谢谢你,费兰。我怀疑第 1 点(每个语言环境的静态查询)在语言环境集是动态的第 2 点时是否适用 - 我在模板页面上获取本地化数据没有问题,只是我必须对包含的每个页面使用查询,例如,一个页脚,然后通过道具传递结果?第 3 点 - 渲染通用(非页面)组件时是否可以调整 gatsby-node.js?和/或如何将数据传递给上下文?对于共享组件,数据也应该从 API 中获取,语言环境的数量 - 也将取决于 api。如何使用 cond.re
    • 1- 这取决于实现。大多数库使用上下文 API 在内部设置语言环境,因此您可以基于此挂钩静态查询。 2-是的,就是这样。如果您有 3 层以上的嵌套,您可能希望使用上下文而不是 props。 3-不,您只能设置顶级组件(页面/模板)。对于上下文,只需将其包装在 context 对象中。您的数据将存储在props.pageContext 中(更多参考请参见gatsbyjs.com/docs/creating-and-modifying-pages
    • 1 我们知道 - 静态查询不允许使用变量,那么如何将语言环境的上下文传递给静态查询? 2这里的问题是我不想请求页脚数据,对于使用页脚的每个页面,我想为整个应用程序执行 1 次 3 然后这种方法不适合我通过传输数据到页脚gatsby-node.js 所以,现在 - 任何变体都不适合我
    • 1- 我不是说将 1 staticQuery 与变量一起使用(你不能),我是说从钩子中获取语言并触发所需的 staticQuery (每个区域设置 1 个)手动设置。 2-如果页脚在每个语言环境中发生变化,则不是最佳选择。有条件地渲染每个场景所需的页脚是最佳性能。 3-我认为最简单的实现是第一个。
    • 是的,如果我确定所有可用语言环境的列表,那么第一点是有意义的,但是如果 API 也请求语言环境呢?
    猜你喜欢
    • 1970-01-01
    • 2019-06-12
    • 2018-03-07
    • 1970-01-01
    • 2020-07-29
    • 2015-10-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多