React-Gutenberg Bridge の紹介: ヘッドレス ブロックのサポートにより、さらに優れた編集エクスペリエンスを実現

公開: 2023-04-09

あなたはヘッドレス WordPress が提供する機会に興奮していますが、クライアントのマーケティング チームは WYSIWYG Gutenberg エディターに縛られています。

ヘッドレス プロジェクトに対する Faust の新しい Gutenberg ブロックのサポートにより、この 2 つがどのように統合され、マーケティング担当者に力を与えながら開発をモダナイズするかをご覧ください。

ビデオ: React-Gutenberg Bridge の紹介: ヘッドレス ブロックのサポートにより、編集エクスペリエンスがさらに向上

スピーカー:

  • Teresa Gobble 氏、WP Engine のソフトウェア エンジニア
  • Blake Wilson 氏、WP Engine のシニア ソフトウェア エンジニア

セッションのスライド:

React-Gutenberg-Bridge-Headless-block-support-for-an-best-ed-editing-experienceの紹介ダウンロード

転写:

TERESA GOBBLE: こんにちは。 私の名前はテレサ・ゴブルです。 私は WP Engine のソフトウェア エンジニアで、Faust チームで働いています。

そして、シニア ソフトウェア エンジニアの Blake Wilson と一緒に、React-Gutenberg Bridge を紹介します。これは、さらに優れた編集エクスペリエンスのためのヘッドレス ブロック サポートです。 いらっしゃいませ。 始めましょう。

というわけで、今日はカバーすることがたくさんあります。 まず最初に、React-Gutenberg Bridge の価値と同様に、問題と解決策に関連するいくつかのことを説明します。 それから、React-Gutenberg Bridge の動作のデモを提供してくれる Blake に行きます。 その後、いくつかの技術的な詳細について説明します。 また、今後のロードマップについても説明します。

ここで問題です。 Gutenberg ブロックを WordPress からヘッドレス フロント エンドに変換する効率的な方法はありません。 実際に存在するソリューションは、ヘッドレス開発者が期待できる開発者エクスペリエンスを提供するには、スケーラブルでも直感的でもありません。

デカップリングは、エディターで Gutenberg ブロック コンテンツを使用する機能を自然に破壊します。 そしてエージェンシーは、どのように独自の方法で、またはほとんどガイダンスなしでゼロから作成するのか疑問に思っています. そして、多くの未回答の質問が人々に残っています.

スタイリングは? 再利用性、動的ブロック、InnerBlocks はどうですか? ここで、React-Gutenberg Bridge の出番です。これは 2 つの部分からなるソリューションです。1 つ目は、Gutenberg ブロックをプログラムで公開して、ヘッドレス フロント エンドで解析および読み取りできるようにする方法です。 この部分は WPGraphQL コンテンツ ブロックと呼ばれます。

次に、ヘッドレス フロント エンドでこれらのブロックのセットアップとレンダリングを容易にするためのコネクタがあります。 そしてこれが Faust WP Blocks というパッケージです。 ここでは、これらの両方のソリューションでどのように機能するかについてのチュートリアルを示します。

Web サイトの React ベースのバックエンドには、WPGraphQL コンテンツ ブロック プラグインによって公開される Gutenberg ブロックがあります。 block.json コンテンツを WPGraphQL に公開します。 WPGraphQL と呼ばれるプラグインにそれを提供します。

そして、ブロックのカスタマイズ、検出、およびレンダリングを可能にするコネクタ パッケージに行き着きます。 そして、これについては、今日の技術的な議論とデモに進むにつれて、実際にはもっと議論されるでしょう. では、これはあなたのチームにどのような価値をもたらしますか?

まあ、それはエンドツーエンドの独断的なソリューションであり、複雑さとあいまいさを軽減します. 特定の規則に従うことで、開発時間を節約できます。 ブロックとブロックパターンを組み合わせて使用​​できます。 しかも何度でも再利用できます。 React-Gutenberg Bridge がどのように機能するかがわかったので、Blake に行って実際のデモを見てみましょう。

ブレイク・ウィルソン: ありがとう、テレサ。 やあみんな。 私はブレイク・ウィルソンです。 私はここ WP Engine のシニア ソフトウェア エンジニアです。

私は Faust JS チームの一員で、Faust を構築しています。 今日は、この React-Gutenberg Bridge のオーケストレーションを支援するために構築した 2 つのコンポーネントを紹介する、非常に優れたデモを用意しました。 それでは、すぐに始めましょう。

まず始めに、セットアップのためにここにあるものをお見せします。 そして、実際のコードに入り、そこにあるものを確認できます。 手始めに、ローカルで実行されている WordPress サイトをここに持っています。

いくつかのプラグインをインストールしました。 だから私はFaustプラグインを手に入れました。 これは、Faust JS サイトでのプレビューやその他の優れた機能を容易にするのに役立ちます。 WordPress サイトを GraphQL エンドポイントに変換するために必要な WPGraphQL があります。

そして、WPGraphQL コンテンツ ブロックを取得しました。 これは、React-Gutenberg Bridge を容易にするために作成したプラグインの 1 つです。 このソリューションは、2 つの主要部分に分かれています。

つまり、WPGraphQL を介してプログラムでグーテンベルク ブロック データを実際に公開するためのピースの 1 つと、Faust JS フロント エンドでそれを使用するための別の部分があります。 WPGraphQL コンテンツ ブロックとその仕組みを見てみましょう。

では、グラフィカル IDE を開きます。 そして、ページのデータを取得するために、このクエリをここに設定しました。 したがって、この場合、ページのタイトルを取得しているだけです。

つまり、GraphQL コンテンツ ブロックが行うことは、GraphQL スキーマでコンテンツ ブロック タイプを公開することです。 したがって、コンテンツ ブロックを入力すると、ここで確認できるように、この特定のページとこのページのすべてのブロックに関する情報が取得されます。 このページを編集してコンテンツを追加してみましょう。

サンプルページに飛びます。 そして、ここに白紙の状態があることがわかります。 それでは、いくつかのブロックを作成してみましょう。 ここでいくつかの列を作成しましょう。

そして、50/50 列を作成します。 この半分に段落を追加してから、この半分に画像を追加しましょう。 メディアライブラリに画像があります。 では、これをドロップしてみましょう。

ご覧のとおり、2 つの列があります。 ここでも、左側に段落、右側に画像があります。 それでは、これを更新しましょう。 WPGraphQL コンテンツ ブロックに戻り、結果として何が得られるか見てみましょう。

ご覧のとおり、コンテンツ ブロックが 2 つあります。 一つ目はコアコラム、コアコラムです。 そして、その中にレンダリングされた HTML を取得します。

したがって、WPGraphQL コンテンツ ブロックの優れた点は、InnerBlocks も処理していることです。 ここで、flat true というコンテンツ ブロックにパラメータを追加すると、これらの列にあるすべてのブロックが実際に取得されることがわかります。 そのため、私たちはあなたのためにそのケースも処理しています.

コア コラム、コア コラム、コア パラグラフ、コア イメージを取得します。 したがって、これらはすべてプログラムによって行われます。 これで、このブロック データをフロント エンドで使用できます。 それでは、ここでもう少し掘り下げてみましょう。

その上にいくつかの属性が必要だとしましょう。 GraphQL でユニオンを使用してそれを使用できます。 コア画像で行い、属性を取得します。 たとえば、キャプションが必要だとしましょう。

ここにキャプションがないことがわかります。 サンプルページに戻りましょう。 ここにキャプションを追加します。 私のキャプション。 それを更新します。

このクエリを更新すると、キャプションが WPGraphQL コンテンツ ブロックの適切な属性として取得されていることがわかります。 これがソリューションのパート 1 です。 これで、実際にすべての Gutenberg Block データを取得し、これを使用してフロントエンドで使用できます。

それでは、VS Code に目を向けてみましょう。その部分にどのように取り組むかを見ていきます。 これは私がまとめた Faust JS サンプル プロジェクトです。 とても簡単です。 これは Faust Scaffold ブループリントに基づいていますが、これらのブロックを処理するための追加の構成がいくつかあります。

したがって、JSON パッケージを見ると、いくつかの依存関係があることがわかります。core や CLI など、通常の Faust パッケージの一部です。 ファウスト VP ブロックもあります。 したがって、これはすべてのヘルパー関数を提供するパッケージの 1 つです。

また、スタイルなどを処理するための WordPress 依存関係もいくつかあります。 また、この WP Blocks ディレクトリがあることにも気付くでしょう。 これは、フロントエンドのすべてのブロックが存在する場所であり、フロントエンドで使用するすべてのブロックのレジストリとして機能します。

index.js ファイルがあることがわかります。 これは基本的に、フロントエンドで使用しているすべてのブロックを決定するオブジェクトです。 ご覧のとおり、コア段落、コア列、コア列、コア画像があります。

これを設定するという点では、これからお話しする 2 つの主要な部分があります。 その 1 つは、WordPress ブロック プロバイダーと WordPress ブロック ビューアーです。 それでは、実際にどのように動作するかを見てみましょう。 まず、WordPress Blocks プロバイダーを見てみましょう。

これは pages_app で利用できるようになります。 ここに、このコンポーネント、このプロバイダー、WordPress Blocks プロバイダーがあることがわかります。 そして、ブロックを受け入れる config prop を受け入れます。 ここでは、このディレクトリのインデックスである WP Blocks からブロックをインポートし、それを構成オブジェクトに渡していることがわかります。

基本的に、これが言っているのは、WordPress Blocks プロバイダーがアプリ全体をラップし、これらすべてのブロックのコンテキストをアプリ全体に提供するということです。 それでは、WP Templates を使用して、単一のテンプレートに進みましょう。 ここで、コンテンツ ブロックの props を使用して WordPress Blocks ビューアーを呼び出していることがわかります。 これが WPGraphQL から返されるブロック データです。

さて、セットアップについてはこれで十分です。 これを回転させて、実際にどのように見えるか見てみましょう。 NPM run dev を実行すると、localhost 3000 に開発環境がセットアップされます。前に取り組んでいたページはスラッシュのサンプル ページだったので、localhost 3000 のスラッシュのサンプル ページにアクセスしてそれらの Gutenberg を確認します。以前に設定したブロック。

ここでわかるように、Gutenberg エディターで同じブロックを使用しています。 それでは、サンプル ページの Gutenberg エディタに戻りましょう。 ご覧のとおり、ここに 2 つの列があります。これが私の段落です。次に、フロント エンドにあるものに対応する画像です。

見栄えはいいですが、スタイルを変更できますか? フォントサイズを変更できますか? きっとできます。

それでは、Gutenberg エディターに戻って、これらのブロックにいくつかの変更を加えてみましょう。 では、段落に背景色を追加しましょう。 サイズも大きく変えてみましょう。 この画像では、丸みをつけてみましょう。

字幕を出しましょう。 そして、それを更新します。 ここで、これらのスタイルが適用されることがわかります。 そして、それらをフロントエンドで見ることができます。

そのため、WordPress では期待されていないパブリッシャーのエクスペリエンスを、ヘッドレス WordPress サイトに提供しています。 これに関するもう 1 つの優れた点は、これらのブロックのプログラム データを取得できるようになったことです。次の画像のように、フレームワーク固有の機能を備えた React コンポーネントを作成できます。 WPGraphQL から返された HTML をレンダリングするだけでなく、そのプログラム データを使用して、Gutenberg ですべての画像を次の画像でレンダリングするコンポーネントを作成できるようになり、遅延読み込み、パフォーマンスの向上、画像の最適化が可能になります。全体として、ユーザーのユーザー エクスペリエンスを向上させます。

だからこれは素晴らしいです。 Gutenberg エディターで期待どおりの結果が得られますが、まだサポートされていないか、Faust サイトで構成していないコンポーネントを追加するとします。 それでは、ここで新しいコンポーネントを作成しましょう。 テーブルを使用します。

行 1、行 2 の 2 つの行を作成します。移動して更新します。 ここでコードを振り返ると、コア段落、コア列、コア列、コア画像の 4 つのブロックが定義されていることがわかります。 ここにはコア テーブルがありません。

では、このページを表示するとどうなるでしょうか。 見てみましょう。 それでは、Faust フロント エンドのサンプル ページに戻ります。 そして、行 1 と行 2 を持つテーブルがまだここにあることがわかります。

これは、Faust JS プロジェクトでブロックがまだ定義されていない場合、レンダリングされた HTML に対して賢明なスマート フォールバックを行うためです。 そうすれば、未定義、null、またはまったくコンテンツが表示されなくなります。 少なくとも、レンダリングされた元の HTML が返されます。

これらすべてを念頭に置いて、実際にブロックを作成するために必要なこと、つまり実際にどのように見えるかを見てみましょう。 ここで VS Code に戻ります。 たとえば、コア イメージを選択してみましょう。

ご覧のとおり、これは単なる従来の React コンポーネントです。 私たちはそれをコアイメージと呼んでいます。 また、他の React コンポーネントと同様に props を受け入れます。

ここでは基本的に 1 つのブロックに 2 つのピースがあります。 これで、プレゼンテーション層である実際の React コンポーネントができました。 そして、このブロックを実行するために必要なデータである block.fragments を取得します。

ここで、コア イメージにフラグメント、コア イメージ フラグメントを作成していることがわかります。 そして、これらの属性を取得しています。これは、このブロックをレンダリングするために必要な属性です。 代替テキスト、ソース、キャプション、クラス名、幅、高さなどを取得していることがわかります。

そして、これらの属性を実際の React ロジックに適用することができます。 したがって、ここで要求されたすべてのフィールドは、小道具で利用できます。 props.attributes が表示されます。これは、ここで要求した属性、attributes.alt、attributes.source などです。 したがって、これは、ブロックのすべてのデータ要件を同じファイル内に配置する優れた方法です。

これは、必要なデータのみをリクエストしていることを確認し、リクエストが適切でパフォーマンスが高いことを確認することです。 このサンプル プロジェクトには、いくつかのヘルパー関数もあります。 スタイルを取得し、画像サイズの小道具を取得します。

したがって、これらは基本的に WordPress からこれらのスタイルを取得し、React が使用できる実際のスタイル オブジェクトにそれらを組み合わせているだけです。 現在、スタイルはインライン スタイルでサポートされています。 グローバル スタイル シートも取得できますが、現在、theme.json のサポートの提供に取り組んでいます。

Teresa は、今後のロードマップでこれについて少し説明します。 しかし、理想的には、すべてのスタイル、パディング、マージンなどを theme.json から取得して、ヘッドレス フロント エンドに適用できるようになるでしょう。 これらすべてを念頭に置いて、Teresa と私との簡単な技術的な議論に飛び込んで、この機能に関する現在の状況と、将来の計画について話しましょう。

TERESA GOBBLE: デモをありがとう、ブレイク。 それは素晴らしかった。 それでは、技術的な詳細について説明し、これがどのように機能するかについて話しましょう。 最初に、WPGraphQL コンテンツ ブロックを使用するための要件を教えてください。

ブレイク・ウィルソン: ええ、ええ。 素晴らしい質問です、テレサ。 したがって、プラグインを使用するための唯一の要件は、WPGraphQL もインストールすることです。 明らかに、サイトを Faust JS と連携させたい場合は、Faust JS blocks パッケージをインストールできます。これにより、ヘッドレス フロント エンドでのレンダリングやすべての優れた機能が容易になります。 しかし、実際にブロック データを公開するには、WPGraphQL と WP GraphQL Content Blocks プラグインだけが必要です。

TERESA GOBBLE: 素晴らしい。 ブロックデータもどのように収集されますか?

BLAKE WILSON: ええ、すべてのブロック データは、レジスタ ブロック タイプ関数を使用する WordPress の任意のブロックによって収集されます。 したがって、その関数とのインターフェースを使用しているほとんどすべてのブロックが、コンテンツ ブロックに表示されます。 これの素晴らしい点は、block.json ファイルを中継し、それらすべてのフィールドを自動的に自己記述および自己文書化することです。 したがって、すべてのドキュメントが 1 つにまとめられます。

TERESA GOBBLE: すごいね。 なんと時間の節約になります。 もう 1 つお話ししていただきたいのは、サポートされていないブロックがどうなるかということです。 サポートされていないブロックがクエリされるとどうなりますか?

BLAKE WILSON: ええ、それはまた素晴らしい質問です。 ここで発生する可能性がある実際のシナリオは 2 つあります。 そのため、WordPress から削除された投稿データにブロックがあるとしましょう。

サードパーティのブロックが削除された可能性があります。 これは、Faust フロント エンドと WordPress レジストリの両方でサポートされていない、サポートされていないブロックの 1 つのケースです。 その場合、未定義ブロックまたは不明ブロックと呼ばれるコンテンツ ブロックに実際にブロックを返し、ヘッドレス フロント エンドで適切に入力できるようにします。 次に、WordPress レジストリのブロックがサポートされているが、Faust JS フロント エンドでまだサポートされていない場合は、レンダリングされた HTML にフォールバックします。 そうすれば、少なくとも、null、未定義、またはそのような値ではなく、表示される HTML をレンダリングできます。

TERESA GOBBLE: すごいね。 そして、これは実際に次の質問につながります。 ヘッドレス分離 Web サイトのサード パーティ プラグインに関しては、WPGraphQL コンテンツ ブロック プラグインを使用してサード パーティ プラグインを使用できますか? それらすべてがどのように連携するのですか?

ブレイク・ウィルソン: ええ、ええ。 したがって、サードパーティのプラグインについては、最初または 2 番目の質問に戻ると、それらが WordPress に登録されたブロック タイプ関数と連携している限り、そのブロックは自動的に WPGraphQL コンテンツ ブロックに公開されます。 そのデータがレンダリングされている限り、Faust JS フロントエンドでブロックを作成できます。 そして、それの素晴らしいところは、カルーセル用のサードパーティ ブロックがあるとしましょう。 Faust JS フロントエンドで一度作成したら、それを他のプロジェクトで再利用できます。

TERESA GOBBLE: すばらしい。 そこで、再利用性のピースの出番です。このプラグインを使用すると、分離された Web サイトでそのままでは機能しないサードパーティのプラグインとのギャップを実際に埋めることができます。

また、今チャットを見ると、サードパーティのプラグインからブロックを作成するのに役立つチュートリアルが実際に作成されています. 今すぐチャットを見てください。それを見て、クリックすることができます。 ブックマークしてください。

では、ブロック内のブロックをどのように処理するのでしょうか? それは本当に難しいことです。 それがどのようなものになるか、少しお話しいただけますか?

ブレイク・ウィルソン: はい、そうです。 つまり、フラットと呼ばれるコンテンツ ブロックをクエリするときに、このフラグまたはこのパラメーターがあります。 そして、それは真または偽の値を受け入れます。 したがって、これが true として提供されると、実際には、そのページ上のすべてのブロック (列、画像、または段落) のフラットな配列またはフラットなリストを取得します。

そのページでクエリされたすべてのブロックの完全なリストと、2 つの追加プロパティが表示されます。 1 つはノード ID です。 これがその特定のブロックの実際の ID です。 そして、そのブロックの親である親 ID も取得します。 それでできることは、それをフロントエンドで実際の階層リストに再構築することで、以前にグーテンベルクで見た内部ブロックの難問をほぼ解決します。

TERESA GOBBLE: 素晴らしい。 実際には、コンテンツ ブロックをフェッチするときに、適切な親子 ID 内のブロックのフラット リストを返すように指定できるオプションがありますか?

ブレイク・ウィルソン: ええ、ええ、まさに。

TERESA GOBBLE: すばらしい。 また、WPGraphQL コンテンツ ブロックがその特定の機能を確認するための別のチュートリアルも、チャットの下にあります。 そこで、スタイリングの部分についてもう 1 つ質問したいと思います。では、グローバル スタイル シートをインラインで使用してスタイリングしますが、そこでのアプローチはどのようなものですか? スタイリングはどのように行われますか?

ブレイク・ウィルソン: ええ、ええ。 そのため、スタイリングはおそらく、私たちが現在研究しようとしている最大のプッシュの 1 つです。 先ほど示した例では、インライン スタイルを使用しています。

グローバル スタイル、グローバル スタイル シートもサポートされています。 これについては、ロードマップの次の部分で触れると思います。 しかし、理想的には、theme.json からマージン、パディング、色、およびすべての適切な情報を取得して適用できるように、theme.json のサポートもサポートしたいと考えています。 そのため、次の開発段階でそれに取り組んでいきます。

TERESA GOBBLE: 素晴らしい。 説明していただきありがとうございます。 多くの人がそれについて本当に興奮していることを私は知っています。 では、サポートされていないブロックの使用をパブリッシャーに制限するにはどうすればよいでしょうか?

ブレイク・ウィルソン: ええ、ええ。 そこで、プラグインがあります。 場合によります。 サード パーティのブロックを使用している場合、これらのブロックの一部には既にこの機能が組み込まれています。

そうでない場合は、ブロックの可視性と呼ばれるプラグインがあり、実際にパブリッシャーの観点から特定のブロックを切り替えることができます. ファウスト サイトにまだ実装されていないカルーセル ブロックがあるとします。 ブロックの可視性をインストールし、それをオフにして、まだサポートされていないか開発中の間、パブリッシャーがそれを使用しないようにすることができます。

TERESA GOBBLE: すごいね。 プラグイン ブロックの可視性は、特定のブロックを実際に切り替えたり、非表示にしたり、表示したりできますか?

ブレイク・ウィルソン: ええ、ええ、まさに。 そうすれば、WordPress 側とヘッドレス サイトの両方で、サポートするブロックの数を制限することができます。フロントエンド。

TERESA GOBBLE: ああ、それは確かにクリーンな配信のようですね。 うんいいね。 最後の質問です。 これらのフロント エンド ブロックは、出版社の編集者に対応していますか?

BLAKE WILSON: ええ、素晴らしいコールアウトです。 まだです。 これは将来的に取り組む予定ですが、現時点では、これらのブロックはヘッドレス フロント エンドでサポートされています。

WordPress で作成したカスタム ブロックがある場合、NPX create block コマンドを使用している場合でも、WordPress 側でそのビューをサポートする必要があります。 しかし、それは私たちが取り組んでいるものです。 私たちはロードマップにそれを持っています。

TERESA GOBBLE: すごいね。 OK。 ブレイクさん、これらの点についてお話しいただきありがとうございます。 それは本当に役に立ちましたし、デモも同様です。

話は変わりますが、プロジェクトのロードマップについてもう少しお話しましょう。 実際には 5 つのフェーズがあり、そのうちの 2 つ (フェーズ 1 とフェーズ 2) は既に完了しています。フェーズ 1 では、ブロックを効率的に分解して再構築する方法の実装を見ました。

その後、フェーズ 2 に移行しました。これは、Faust と Gutenberg Blocks とのより緊密な統合に焦点を当て、そこにあるさまざまなユーティリティとヘルパー機能にすべての人々がアクセスできるようにすることでした。 現在進行中の次のフェーズであるフェーズ 3 では、Blake が技術的な議論で述べたように、theme.json のサポートと再利用可能なブロック ライブラリの提供に焦点を当てています。

それが完了したら、フェーズ 4 と 5 が発生します。 フェーズ 4 は既存の開発と編集の経験を強化することに焦点を当てており、フェーズ 5 はコア WordPress を超えたより広いエコシステムをサポートすることに焦点を当てています。 今後のこれらのフェーズに非常に興奮しています。ロードマップがどこにあるかを最新の状態に保つために、私たちと一緒にベースに触れ、ブログ投稿もご覧ください.

下のチャットで、ブログ投稿へのリンクを確認できます。 それらをブックマークしてください。 皆さん、React-Gutenberg Bridge の議論に参加していただきありがとうございます。 ここでブレイクを画面に戻したいので、彼も感謝の意を表し、この後も長引く質問がある場合はどこに行けばよいかについてもう少し情報を提供してくれます.

BLAKE WILSON: うん、ありがとう、テレサ、今日このセッションに参加して見てくれたみんなありがとう。 この機能を試してみるために、この機能に関するコミュニティからのフィードバックをお待ちしております。

よろしければ、チャットのリンクにサンプル プロジェクトがあります。 チャットにはヘッドレス Discord のリンクもあります。これは、あなたや他の志を同じくするヘッドレス開発者が参加して、ヘッドレス スペースでの今後の機能やリリースについてチャットできる場所です。 それでは皆様、あらためてありがとうございました。 本当に感謝しています。