バーテンダーに尋ねる：ブロックマークアップが変更されるとどうなりますか？
公開: 2021-02-27私は最近グーテンベルクで開発を始めた開発者です。 驚くべき利点と機能がたくさんありますが、欠点、矛盾、そして絶対にひどく時代遅れのドキュメントもたくさんあります。
開発者の観点から見たグーテンベルクの最悪の側面の1つは、ブロックの検証です。 次のシナリオを考えてみましょう。 カスタム（非動的）JavaScriptベースのブロックを作成すると、CMSエディターがそのブロックを数千ページに追加します。 ブロックのマークアップを更新する必要がある場合、または更新する必要がある場合はどうなりますか？
デフォルトでは、すべてのブロックが無効の状態になり、サイトのフロントエンドに反映されません。 CMSエディターは、何千ものページに移動し、ブロックを復元できるボタンを手動でクリックする必要があります。
これを解決する方法としてブロックの非推奨が提案されていますが、APIは十分に文書化されておらず、混乱を招き、いくつかの非推奨を超えると長期的には保守できなくなるようです。
ブロック開発者が検証プロセスをオプトアウトする方法、またはブロックを回復するグローバルな方法のいずれかがあるべきではありませんか？
PJ
あなたは確かに何も妨げていません、PJ。 これの多くは、ここ居酒屋で通常取り上げるよりも少し技術的ですが、状況についての洞察を深めるために、グーテンベルクの主要な開発者の1人であるRiadBenguellaに連絡することにしました。
彼の回答に飛び込む前に、私はあなたの質問の1つの側面についていくつか考えました。 開発者が古いマークアップを廃止し、新しいものに移行する必要がある場合があります。 ただし、これは頻繁には発生しないはずです。 一般に、HTMLを定期的にオーバーホールする必要がある場合は、アーキテクチャが不十分であることを示しています。 これは、サードパーティがスタイルの変更を維持できないなど、他の問題にもつながります。
ブロックやフロントエンドコードを出力するあらゆる種類のアプリケーションを開発するときは、現在および10年後にどのようになるかを考える必要があります。 ユーザーがカスタムCSSを追加してブロックのスタイルを設定し、ブロックのHTML構造が変更された場合はどうなりますか？ 彼らの観点から、あなたのブロックの更新は彼らのサイトを壊しました。 プラグインを何らかの方法で拡張する別のプラグインについても同じことが言えます。
Gutenberg / WordPressがブロック出力を変更するときはいつでも、テーマの作成者にどれほどイライラするか尋ねてください。 ここ数年で改善されましたが、エディターとフロントエンドのスタイリングブロックはメンテナンスの悪夢でした。
開発者として、私は常に、ユーザーの視点からこれらの変更を行うことの実際の結果について考えようとしました。 これは、プロジェクトをリリースした後ではなく、1日目から発生するはずです。
これを行うと、プロジェクトをドアから出してユーザーの手に渡そうとしている初期のプロジェクトに時間が追加されます。 これは、プレリリースのステップを取り戻すことが役立つところです。 コンピューターから離れてください。 散歩に行きます。 プロジェクトのアーキテクチャと、それが長期的に理想的かどうかを考えてください。
「ブロックのバージョン管理/更新については、アーキテクチャのトレードオフを行う必要があったGutenberg APIの領域の1つであり、開発者よりもユーザーエクスペリエンスを優先することにしました」とBenguella氏は述べています。
開発方法に関係なく、プロジェクトのユーザーファーストエクスペリエンスのアプローチに従うことは、長期的には役立ちます。
「問題を正しく理解するには、ブロックがどのように機能し、編集されるかを理解する必要があります」とベンゲラ氏は述べています。 「ブロックインスタンスはJSONオブジェクトであり、エディターUIはそのJSONを操作しますが、下位互換性を維持し、ユーザーのコンテンツを最も読みやすい形式で保持し、Web標準を可能な限り採用するために、ブロックエディターJSONオブジェクトを保存しませんが、 post_contentにそのHTMLシリアル化を保存します。」
そのシリアル化は、エディターがコンテンツをリロードして再度編集するときに解析され、JSONに変換されます。 解析の最終段階では、オブジェクトを保存して解析する方法を決定するのはブロックの作成者次第です。
「ここで、ユーザーが保存されたHTML（シリアル化）を変更し、そこにランダムなコンテンツを配置した場合を想像してみてください」とベンゲラ氏は述べています。 「ブロックは、期待（ブロック作成者によって定義されたもの）と一致しないため、HTMLを適切に解析できない可能性があります。つまり、操作するためにそのJSONオブジェクトを再作成することは現時点では不可能です。 。」
これが発生すると、ブロックエディタは、情報に基づいた決定を行うためのインターフェイスをユーザーに提供します。 ブロックJSONを「強制解析」したり、HTMLまたはClassicブロックに変換したりすることができます。
これと同じタイプの無効化は、プラグイン開発者がブロックを更新するときに発生する可能性があります。 ただし、保存されたHTMLを変更する代わりに、開発者はブロックの「期待」を変更しました。つまり、ブロックの保存方法と解析方法を変更しました。
「これが、同じブロックの古いマークアップを表すブロックの非推奨を提供するようにブロック開発者に依頼する理由です」とベンゲラ氏は述べています。 「非推奨は、同じブロックの有効な代替ソースと考えることもできます。 これにより、エディターはロード時に古いマークアップを解析し、ブロックが更新された場合に新しいマークアップを保存し直すことができます。」
WordPressにはブロック非推奨のドキュメントがあります。 しかし、それは完全ではありません。 現実世界での非推奨を確認するための最良の情報源は、グーテンベルクのブロックライブラリを調べることです。 非推奨のブロックにはdeprecated.jsファイルがあります。
ベンゲラ氏は、このシステムはブロック作成者にとって苛立たしいものになる可能性があると述べました。 これは、開発環境で変更を加える場合に特に顕著です。 これにより、開発者は検証アルゴリズムを無効にする方法を求めるようになりました。
「上記で説明したように、別の理由（外部編集、別のエディターなど）でマークアップが変更された場合にも検証が重要であるため、現時点では提供したくないものです」と彼は言いました。 「そのため、ユーザーが何も知らずにコンテンツが失われる可能性があります。 現在のところ、ユーザーの認識が優先されます。」
チームは時間の経過とともに検証システムを改善し、ブロック状態を壊さない小さな変更を可能にしました。 将来の改善のためのオープンチケットもあります。