開発者向け
Gatsbyサイトを世界最速にする
By Ondrej Polesny
あなたのウェブサイトはギャツビーで構築されていますか? Kontentのソースプラグインの新しいバージョンは、すべての競合他社の中で最速です。ある週末がアップグレードするのに十分であるかどうか見てみましょう!
Gatsby用のKontentソースプラグインの新しいバージョンが今年初めにリリースされました。これについては、 Gatsbyのブログですでに説明しました。この記事では、最も重要な変更点、プロジェクトでそれらを解決する方法、およびすべてにかかる時間について説明します。
改築ではありません
まず第一に、新しいソースプラグインは真新しいです。古い実装では、パフォーマンスを適切に最適化し、GatsbyCloudとプレビュー機能に関連する新しい機能を追加することができませんでした。したがって、新しい実装には、次のような多くの利点があります。
- パフォーマンス。これは現在、すべてのヘッドレスCMSの中で最速のソースプラグインです。
- インクリメンタルビルドのサポート。
- GatsbyCloudのサポート。無料枠も含まれるようになりました。
しかし、コードごとに何が変更され、プロジェクトで何を修正する必要があるかを見てみましょう。
- 要素のプロパティ名で、pascalCaseの代わりにsnake_caseが使用されるようになりました
- タイプリゾルバが削除されました
- GraphQLノードの構造がわずかに変更されました
- タイプのリレーションシップとcontentItemsプロパティが削除されました
完全な移行リファレンスガイドはGitHubにあります。ここでは、いくつかの変更点について説明し、何を行う必要があるかを詳しく説明します。また、これらの変更をGatsbyソースプラグインv2で構築されたKenticoAdvantageプロジェクトに適用するYouTubeストリームへのリンクも含めます。
要素のプロパティ名で、pascalCaseの代わりにsnake_caseが使用されるようになりました
この変更は、リッチテキストフィールドに使用されるimageId
やurlSlug
などの一部のプロパティ名に影響します。ただし、他のすべてのプロパティもチェックして、名前がsnake_caseに変更されているかどうかを確認してください。これは、http:// localhost:8000 / ___ graphiqlにあるGraphiQLエクスプローラーを使用して行うことができます。
タイプリゾルバが削除されました
これには、リッチテキストとURLスラッグの両方の解像度が含まれます。以前のバージョンのプラグインは、これまでに使用された解決済みデータに関係なく、ビルド中にすべてのタイプの解像度を設定しました。 .resolvedHTML
プロパティは削除されました。現在のベストプラクティスは、新しいRichTextElementコンポーネントを使用することです。
まず、コンポーネントを含む次のnpmパッケージをインストールする必要があります。
npm install @kentico/gatsby-kontent-components
次に、 RichTextElementをページ、テンプレート、またはコンポーネントにインポートします。
import { RichTextElement } from '@kentico/gatsby-kontent-components'
そして最後に、それを使用します:
さて、これは複雑に見えるので、詳しく見てみましょう。 .resolvedHTML
プロパティを使用していた場合、GraphQLクエリはおそらく次のようになります。
{
...
content {
resolvedHTML
}
}
画像、リンク、その他のコンポーネントの実際の解像度は現在RichTextElementコンポーネント内で行われているため、必要なすべてのデータを提供する必要があります。 GraphQLクエリは次のようになります。
{
...
content {
value
images {
image_id,
name,
url,
description
}
links {
}
modular_content {
}
}
}
ご覧のとおり、すべてのデータはGatsbyノードから提供されます。追加の作業はありません。自分で使用していない場合でも、GraphQLクエリには*_id
データを含めるようにしてください。これらにより、リッチテキストリゾルバーは特定の画像、リンク、およびリンクされたアイテムを適切に識別できます。
リゾルバー関数には、上記で概説したデフォルトの実装がありますが、ニーズに合わせて自由に調整してください。
最後のステップとして、 gatsby-config.js
ファイルのdeliveryClientConfig
オブジェクトTypeResolver
定義を削除します。
私は個人的にクリーンなコードと分離された責任が好きであり、これは間違いなくそれに向けた大きな一歩です。コンポーネントレベルでの解像度を持つことはちょうどいい感じです。
GraphQLノード構造がわずかに変更されました
GraphQLノード構造が変更され、生のDeliveryAPIと統合されました。これにより、Kontentドキュメントでソリューションを見つけて適用するのが簡単になります。
リンクされたアイテムまたはリッチテキストを使用するすべてのGraphQLクエリを調整する必要があります。
'value'プロパティの背後にあるリンクされたアイテム
リンクされたアイテムはネストされ、新しいvalue
プロパティを介してアクセスできるようになりました。
リンクされたアイテムにはタイプが必要になりました
また、リンクされたアイテムの特定のデータを使用するすべてのGraphQLクエリを変更する必要があります。この例を見てください:
{
...
elements {
content_item {
elements {
subphases {
elements {
title {
value
}
}
}
}
}
}
}
調整されたGraphQLクエリは、リンクされた要素のタイプを指定する必要があります。
{
...
elements {
content_item {
value {
... on kontent_item_phase {
elements {
title {
value
}
}
}
}
}
}
}
システム要素からのデータが必要な場合はタイプを省略できますが、とにかく指定することを強くお勧めします。この変更により、リンクされたアイテム間で予期しないタイプと一致しないため、コードのエラーが防止されます。
タイプのリレーションシップとcontentItemsプロパティが削除されました
タイプのリレーションシップとcontentItemsプロパティは、ビルドごとに発生する計算が必要になるため、パフォーマンスを向上させるために削除されました。これらの関係が必要な場合は、GitHubでこの例で説明されているように、Gatsbyスキーマ定義を拡張するか、サブクエリからクエリを作成できます。プロジェクトの初心者にとって理解しやすいので、最初のアプローチをお勧めします。 Gatsby Schemaが何かわからない場合は、このビデオをご覧ください。
これにはどれくらい時間がかかりますか?
この記事では、KenticoKontent用のGatsbyソースプラグインのv2とv6の間の主な変更点について概説しました。 Kentico Advantageプロジェクトを新しいバージョンに移行するには、約6〜8時間かかりました。あなたはそれをすべてYouTubeでリアルタイムで見ることができます:-)。ほとんどの場合、小さな名前の変更を修正し、GraphQLクエリを調整することでした。機能はほとんど手つかずのままでした。
同様のアップグレードに直面している場合は、サポートが必要な場合、または自慢したい場合は、より早く完了したことをお知らせください:-)