投稿者: itmaroon

ChatGPTにも意見を聞いてみました。

formの送信に関するイベントリスナを設定する場合、onSubmitをform要素に設定することが一般的に推奨されます。以下は、その理由を示すいくつかのポイントです：
全体性: onSubmitはフォーム全体の送信に関するイベントです。ユーザーがsubmitボタンをクリックするだけでなく、例えばフォームのテキストフィールド内でEnterキーを押すことによってもフォームが送信されることがあります。onSubmitは、これらすべての送信方法をカバーします。
バリデーション: フォームのデータバリデーションは一般的に送信前に行われます。onSubmitを使用すると、送信が行われる前にバリデーションを行い、必要に応じて送信を中止することが簡単にできます（event.preventDefault()を使用）。
セマンティクス: formのonSubmitは、フォームが送信されるというセマンティクス（意味）を持っています。このため、その目的に合わせてこのイベントを使用するのは自然です。
柔軟性: 複数のsubmitボタンが1つのフォーム内に存在する場合、それぞれのボタンにonClickリスナーを追加するよりも、フォーム全体にonSubmitリスナーを1つ追加する方が管理が簡単です。

しかし、Form内にsubmitボタンが２つあったらどうするのでしょうか？
入力内容を確認するようなFormがあるとすると、OKかキャンセルを選択するために２つのsubmitボタンがあるというのが一般的です。
この場合どちらのボタンがクリックされたか峻別する必要があります。
FormのonSubmitリスナーは１つしか設定できません。
では、それぞれのボタンにイベントリスナーを設定するしかないのでしょうか？

そんなことはありません。

FormのonSubmitリスナーでコールバックされるイベントハンドラは引数を渡してくれます。
この引数はオブジェクトになっていて、クリックされたボタンの情報も持っているのです。
そのため、これを利用すれば、次のようにボタンを制御できます。
Reactコンポーネントであれば、次のようになります。

const handleSubmit = (e) => {//⓵
    e.preventDefault();//⓶
    const click_id = e.nativeEvent.submitter.id;//⓷
    if (click_id === send_id) {
            console.log('ok');
        } else if (click_id === cancel_id) {
            console.log('cancel')
        }
};
return(
    <form onSubmit={handleSubmit}>
        <input type="submit" id="btn_id_ok" value="ok">
        <input type="submit" id="btn_id_cancel" value="cancel">
    </form>
)

⓵の行のeが、その引数です。
まず、⓶でpreventDefaultメソッドを使ってonSubmitのデフォルトの挙動を止めます。
そして、③ではクリックされたボタンについているidを取り出すことができます。
これが取得できれば、ハンドラの中で条件分岐による制御が可能になります。
nativeEvent.submitterというオブジェクトが利用できるということを覚えておきましょう

先に示した例はReactコンポーネントをjsxの記法でjsファイルに記述しました。
では、これをjQueryで書くとどうなるでしょうか。

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/3.6.0/jquery.min.js"></script>
<form>
  <input type="submit" id="btn_id_ok" value="ok">
  <input type="submit" id="btn_id_cancel" value="cancel">
</form>

<script>
  const send_id = "btn_id_ok";
  const cancel_id = "btn_id_cancel";

  $('form').on('submit', function (e) {
    e.preventDefault();
    const click_id = e.nativeEvent.submitter.id;//⓵
    if (click_id === send_id) {
      console.log('ok');
    } else if (click_id === cancel_id) {
      console.log('cancel');
    }
  });
</script>

これで同じ動きになるかと思いきや、そうなりません。なぜなら、イベントハンドラに渡ったeがReactの場合と違うからです。
結論から言うとe.nativeEvent.submitter.id;ではなくe.originalEvent.submitter.id;となります。
なぜ、こんな違いが生じるのか、ChatGPTに聞いてみました。

jQuery:
jQueryは既存のJavaScriptイベントを包括する独自のイベントオブジェクトを作成します。このオブジェクトはネイティブのイベントオブジェクトを包含していて、それにアクセスするためにはe.originalEventプロパティを使用します。このようにして、jQueryはクロスブラウザの互換性を提供しています。

React:
Reactは仮想DOMという概念を導入しており、実際のDOMとは異なるレベルの抽象化を提供しています。Reactも独自のイベントシステムを持っており、これはSyntheticEventシステムと呼ばれます。しかし、Reactはネイティブのイベントオブジェクトにアクセスするための方法も提供しており、それがe.nativeEventプロパティを使用する方法です。

これを読んで思い出しました。
“The React Way”という言葉です。
この言葉の意味を短く要約すると、
jQueryはDOMを直接操作してレンダリングするのに対し、Reactは状態変数を介して仮想DOMを生成し、実態のDOMとの差分をレンダリングすることを原則としつつもDOMの直接操作の方法も残しているということです（この話題については、こちらのブログで解説してますので、興味のある方はご覧ください。）。
つまり、jQueryにとっては.オリジナルな手法、すなわちoriginalEventなのですが、Reactにとっては、もとからあったネイティブな手法、すなわちnativeEventというわけなんだと理解しました。
こんなところにも”The React Way”という考え方が反映されているということが非常に興味深いと思いませんか。

それはさておき、今回の結論をまとめておきます。

1. submitはそれ自体にイベントリスナを設定するのではなく、formのonSubmitイベントリスナでクリック時の処理をすることが推奨される。
2. ReactコンポーネントでonSubmitイベントリスナを設定したとき、イベントハンドラに渡される引数からは
3. jQeryでは$(‘form’).on(‘submit’,function(e){・・・})としたときのイベントハンドラに渡される引数からは

とりあえず、この３つを覚えておくとFormの操作に迷うことがなくなりそうです。

npmの基本的な使用方法については、他のブログに譲ります。
ここでは、１目のプラグインを@wordpress/create-blockでプロジェクト生成してから、どのようにして２つ目のプラグインのプロジェクトを生成していくかということに焦点を絞ります。
npx @wordpress/create-blockプロジェクトを生成すると、そこにはWeb Packによるトランスパイル環境が整います。それで基本的なnpmの利用環境が整うといっていいと思います。
我々開発者はその環境が整ったうえでedit.jsやsave.jsといったJavaScriptファイルを加工していくのですが、複数のプラグインを作成するとすれば、その度にnpx @wordpress/create-blockを実行して別々の開発環境を作ってきました。
そして、複数のプラグインで共通に利用したいモジュールはnpmパッケージにまとめ、それぞれインストールしていました。
しかし、これだとnpmパッケージをバージョンアップする度に、すべてのプラグインでnpm installを実行しなければなりません。npmパッケージが１つならまだいいですが、複数になると手間が大変です。そもそも、他に依存しているnpmパッケージもあるはずで、@wordpress/scriptsという依存関係にかかわる根幹のパッケージは必ず使っているはずです。このパッケージもバージョンアップしているんです。
これを何とかする方法はないかと色々調べました。そもそも、モジュールはプラグイン内のimport文でインポートします。自分で作ったモジュールをimportするときは、そのモジュールが含まれるjsファイルのパスを指定するのですが、npm installでインストールしたパッケージにはパスがありません。
まったく基本的な話でしょうが、パッケージ名にパスがない場合はnode_modulesフォルダ内を探しにいくのです。
では、このnode_modulesフォルダはどこのフォルダ内のnode_modulesフォルダでしょうか？
Claude３が回答をくれました

edit.jsファイル内でimport { useBlockProps } from ‘@wordpress/block-editor’;と記述した場合、ビルドプロセスは以下の手順でuseBlockPropsモジュールを探します。

1. まず、プラグインフォルダ（/my-project/plugins/my-plugin/）内のnode_modulesフォルダを探します。
2. プラグインフォルダ内にnode_modulesフォルダが見つからない場合、ビルドプロセスは親ディレクトリを順番に遡ります。この例では、プロジェクトのルートディレクトリ（/my-project/）まで遡ります。
3. プロジェクトのルートディレクトリにあるnode_modulesフォルダ内で@wordpress/block-editorパッケージを探します。
4. パッケージが見つかったら、そのパッケージ内でuseBlockPropsモジュールを探します。
5. モジュールが見つかったら、そのコードを含むファイルを特定し、バンドルプロセスに含めます。

そうすると複数のプラグインで共通のnpmパッケージを利用したいのであれば、wp-contentフォルダにnode_modulesをつくり、そこでnpmインストールでパッケージをインストールすれば、それぞれのプラグインは共通の上位フォルダであるwp-contentフォルダのnode_modulesを見に行ってくれるということになります。
具体的にはwp-contentフォルダに移動して、ターミナルから

npm install @wordpress/scripts

を実行します。そうすると、wp-contentフォルダ内にpackage.jsonが生成されるとともに、node_modulesフォルダも生成され、そこにブロック作成に必要なモジュールが詰め込まれます。
さらに、すべてのプラグインで使用するnpmパッケージをnpm installでインストールすれば、そのモジュールも、wp-contentフォルダ内のnode_modulesフォルダに格納されます。
そうしておけば、各プラグインでは共通のnpmパッケージをインストールする必要はないのです。

これも相当苦労しましたが、一般的なニーズがあるものと思い、頑張って作りました。
是非お役に立てていただければありがたいです。

まず、ブロックの監視って何をするのということの説明をします。一言でいうと、あるブロックがページ内に存在する場合は、配置しようとしているブロックの配置ができないようにするという制御です。
何のために必要かというと、私が作っているオープニングブロックは現在３種類あって、それぞれ同じ名前のIDをもつDOM要素を内包しています。それによって共通するアニメーションの制御を一つの関数で実行できるようにしているのです。ですから、この３つのブロックがWebページに同居するとIDが重なることになるし、仮にそれが許されたとしても思わぬ動きになってしまうでしょう。オープニングは一つのWebページに一つで十分でしょうから、２つ以上配置できないようにしたいというわけです。
同じブロックが２つ以上にならないようにするのは簡単で、block.jsonに次のように書き込みます。

"supports": {
        "multiple": false,
        ・・・他の設定
    },

これでそのブロックは同一ページに２つ存在することができなくなります。
問題は違うブロックだけれども、そのブロックがすでに存在するときは配置できないようにするという制御です。
先に完成したコードを示します。

//初めのブロックの状態を取得
let blocksInEditor = select('core/block-editor').getBlocks();・・・①
let noticeCreated = false;  //エラーメッセージ表示フラグ

subscribe(() => {
  //状態変更時のブロックの状態を取得
  const newBlocksInEditor = select('core/block-editor').getBlocks();・・・②

  if (newBlocksInEditor.length > blocksInEditor.length) {・・・③
    //オープニングブロックがあるかの検証
    const disabledBlocks = ['itmar/logo-anime', 'itmar/tea-time', 'itmar/welcome'];
    const isDisabledBlockPresent = blocksInEditor.some(block => disabledBlocks.includes(block.name));・・・④
    // 追加しようとするブロックの取得
    const newBlock = newBlocksInEditor.find(
      block => !blocksInEditor.some(existingBlock => existingBlock.clientId === block.clientId)
    );・・・⑤
    const isNewBlockDisabled = disabledBlocks.includes(newBlock.name)
    //オープニングブロックがあり追加しようとするブロックもオープニングブロックの場合
    if (isDisabledBlockPresent && isNewBlockDisabled) {
      //noticeCreatedがfalseならエラー通知
      if (!noticeCreated) {
        noticeCreated = true;
        dispatch('core/notices').createNotice(
          'error',
          'オープニングブロックは一つしか配置できません。',
          { type: 'snackbar' }
        );
      }・・・⑥
      noticeCreated = false;
      // 追加されたブロックを削除する
      dispatch('core/block-editor').removeBlock(newBlock.clientId, false);

    }・・・⑦
  }
  // ブロックリストを更新する
  blocksInEditor = newBlocksInEditor;・・・⑧
});

ここで主役になるのはsubscribeです。これは、WordPressが提供する関数で、データストア（編集画面に配置したブロック等の内容物）の状態が変わるたびにコールバック関数を呼び出すことで、状態の変更をサブスクライブ（購読）します。
さらに詳しく説明します。
①でこの関数が実行された最初の編集画面内の状態をblocksInEditorという変数にキープします。このステートメントはリロードされるまで実行されることはありません。
②でsubscribeで呼び出されたときの編集画面内の状態をnewBlocksInEditorという変数キープします。これと①でキープしたblocksInEditorを比べるわけです。
newBlocksInEditor.length、blocksInEditor.lengthはそれぞれブロックの数を取得します。③の比較はブロックの数がnewBlocksInEditor内の方が多いとき、つまり、ブロックが新たに挿入されたことを検出するための比較です。
④でdisabledBlocks配列に設定した名前をもつブロックが subscribeが呼び出される前からあったかどうかを調べて、isDisabledBlockPresentフラグにセットします。
⑤ではnewBlocksInEditor内でblocksInEditor内のブロックにないものを探します。つまり、それが追加しようとしているブロックということです。そして、そのブロックもdisabledBlocks配列に設定した名前をもつブロックであれば、そのブロックは追加させないようにする処理に回るわけです。
⑥はエラーメッセージを表示するステートメントです。ここで最大の落とし穴があります。このステートメントが実行されると次のようなティップスが表示されます。

これは「データストア（編集画面に配置したブロック等の内容物）の状態が変わる」ということになるようで、処理が中断されそれ、subscribeのコールバックに制御が戻ってしまいます。したがって、以降のdispatch(‘core/block-editor’).removeBlock処理は行われないようです。そこでdispatch(‘core/notices’).createNoticeの実行前にnoticeCreated = true;を実行してフラグを書き換え、次にsubscribeのコールバックでif (!noticeCreated)の条件が成就しないようにしています。その後、noticeCreated = false;でフラグを戻してやれば、もう一度同じ操作が行われてもdispatch(‘core/notices’).createNoticeは実行されるという仕組みです。
この動きを確認するのに何度も何度もデバックツールでトレースしました。
このdispatch(‘core/notices’).createNoticeの仕組みを知らないと無限ループに入ってしまします。このステートメントは様々な場面で使うことがあると思うので気をつけてください。
⑦にはdispatch(‘core/notices’).createNoticeが実行されないときにようやくたどり着けます。ここで追加したブロックを削除します
⑧の処理も重要です。ブロックの数の変化以外でもsubscribeのコールバック内で常に実行されるようにしました。これはWordpressがブロックがまったくなくなったとき自動的にcore/paragraphブロックを追加するような動きをすることから if (newBlocksInEditor.length > blocksInEditor.length)での状態管理が完全にならないことがあるためです。また、ブロックの追加操作以外でもブロックのclientIdが変化してしまい、newBlock に元あったブロックが設定されてしまうことがありました。

それほど難しいロジックではないと思ったんですが、dispatch(‘core/notices’).createNoticeの作用がネックでした。これで何度も無限ループに入ってしまって、それを制御するのが大変でした。
でも、一度作ってしまえばいろんなところで応用が効きそうなので是非ご利用ください。

ちなみにこのコードはブロックのコンポーネントに含めることは相当ではないと思います。それをするとブロックがマウントされないと監視が効かないからです。したがって、このスクリプトは@wordpress/create-blockのwebpackの設定にエントリポイントを加えてトランスパイルし、それで出来上がったjsファイルをブロックコンポーネントのエントリポイントであるPHPファイルでエンキューしてWebページ全体で働くようにする必要があります。
PHPファイルには

function itmar_opening_block_add_plugin() {
//ブロックの２重登録の監視
    wp_enqueue_script(
        'itmar-check-script',
        plugins_url( 'build/check-blocks.js?'.date('YmdHis'), __FILE__ ),
        array( 'wp-blocks', 'wp-element', 'wp-data', 'wp-hooks' ),
        true
  );
    
    //他のエンキューなど
}
add_action('enqueue_block_assets', 'itmar_opening_block_add_plugin');

というふうにenqueue_block_assetsフックでエンキューさせます。
ここで問題となるのはbuild/check-blocks.jsがトランスパイルされたファイルでなけれならないということです。それをWebpackのカスタマイズで実行する必要があるのですが、それはまた別のブログでお話しします。

Reactを始めると仮想DOMという言葉を耳にするようになります。
ChatGPTの説明です。

生成: Reactコンポーネントがレンダリングされるとき、仮想DOMツリーが生成されます。これは実際のDOMツリーの軽量な表現です。
差分検出: 状態やpropsの変更によりコンポーネントが再レンダリングされると、新しい仮想DOMツリーが生成され、前回のツリーと比較されます。
再調整 (Reconciliation): 2つの仮想DOMツリーの差分を検出し、変更が必要な部分だけを特定します。
実際のDOM更新: 差分検出を通じて得られた変更のみが、効率的に実際のDOMに適用されます。
この仕組みにより、Reactは不必要なDOM操作を避け、高速なUI更新を実現しています。

文書で表現するとわかりにくいです。
ちょっと図式化してみましょう。

これでなんとなくわかった気になります。
実際、この程度の説明で十分なことが多いと思います。
しかし、この程度の説明だと実際に起きた不具合が、その仕組みを十分に理解していないことが原因だと気が付かず、時に相当深い奈落に落ちていくことになります。
そうならないように、この際、私の体験を材料にして、Reactの仮想DOMによるレンダリングの仕組みを深堀して徹底理解しましょう。

皆さんはGoogle Code Prettifyというライブラリをご存じでしょうか？
ブログなどでコードを紹介するとき、ハイライト表示するために使います。
コードをハイライト表示させるライブラリは他にもあると思いますが、これはかなりメジャーなライブラリで使い勝手がいいのです。

そこで、これを使ったWordpressのブロックを作ろうと思い制作にかかりました。
このサイトでも紹介されていた

しかし、非表示にはならず、何度かトグルボタンをクリックすると、行番号がどんどん重なっていきます。

なぜ、このような現象が起きるのかは、Google Code Prettifyの仕様を調べたらすぐにわかりました。
今回の説明のためにGoogle Code Prettifyについて、ごく簡単に、このライブラリの仕組みを説明します。
ライブラリを使用する側は次のようなHTMLを用意します。

<pre class="prettyprint linenums" >
    code Hilight
</pre>

そして、このHTMLをReactコンポーネントとしてレンダリングした後、useEffectで

useEffect(() => {
    PR.prettyPrint();
}, []);

としてやれば、先ほど用意したHTMLから自動的に次のようなDOMツリーを生成してくれます。

<pre class="prettyprint linenums prettyprinted">
    <span class="pln">code </span>
    <span class="typ">Hilight</span>
</pre>

このようにクラス付きのDOMツリーを生成することで、別に用意されたCSSが当たって、きれいなハイライトが表示されるわけです。
（今回の説明ではライブラリを読み込む部分の説明は省略しています。一からライブラリを読み込んで実装したい方は、このブログが参考になると思います。）

ところが、このようにきれいにラッピングしてくれるのは、pre要素の中味がテキストになっている状態で

PR.prettyPrint();

が実行される必要があります。
しかし、すでにpre要素の中味がDOMツリーになっていると、そのDOMツリーの最初のDOM要素の下に新たなツリーを作ってしまいます。
これが、今回起きた不具合の原因です。

だったら、最初に用意したHTMLを再レンダリングさせればいいんじゃないのか思いますよね。
ある程度Reactを習熟した方なら誰しもそう思うのではないでしょうか。
では、実際にコードにしてみましょう。

export default function Component() {
    const [isLine, setIsLine] = useState('');//⓵
    const code = 'line 1\nline 2'//⓶
    useEffect(() => {//⓷
        PR.prettyPrint();
    }, [isLine]);
    
    return(
        <button onClick={() => setIsLine('linenums')}>//⓸
            render
        </button>
        <pre class="prettyprint {isLine}" >//⓹
            {code}//⓺
        </pre>
    )
}

⓵では状態変数isLineを用意します。
⓶ではレンダリングするコードをcodeという変数内にセットして⓺でレンダリングさせるようにします。
⓷はコンポーネントマウント時とisLineの更新時に発火するuseEffectです。
⓸でボタンを押せばisLineが更新され、再レンダリングが起き、その後⓷のuseEffectが実行されます。

これでpre要素にはlinenumsクラスが付加されて行番号付きのシンタックスハイライトが現れるというシナリオを期待しているのですが、このシナリオは実現しません。
その理由は⓺の再レンダリングが実行されないからです。
⓺は'line 1\nline 2という文字列でした。しかし、コンポーネントがマウントされたとき⓷のuseEffectが発火してPR.prettyPrint();が実行されたため、DOMツリーに変容しています（useEffectは依存配列の更新時だけでなく、コンポーネントのマウント時にも実行される。）。
だから、isLineを更新することで、もう一度DOMツリーがもとのテキストに戻った上で、PR.prettyPrint();が実行されると考えたのです。
しかし、そうはならないのです。
なぜなら、そこにはReactの仮想DOMによる比較に基づいた変更内容の決定というプロセスが働くためです（これを”reconciliation”（調整）と呼ぶそうです。）。
⓺の部分は外見上変化していますが、それはReactが知らないところで外部のライブラリ（Google Code Prettify）がDOM要素を直接更新したものであって、React側から見れば、テキストのままのはずなのです。
したがって、仮想DOMには差分が生じておらず、再レンダリングの対象から除外されてしまいます。
その結果、pre要素にはisLineという状態変数が変化したことによってクラスが追加されるというレンダリングは起きますが、⓺の部分は外部ライブラリによって更新されたままの状態になります。
この状態でPR.prettyPrint();が実行されると、先に示した奇妙な現象が起きるわけです。

では、どうするのか？
結論としては手動で元に戻すしかありません。
Google Code PrettifyにはDOMツリーを元のテキストに戻すという機能はないでしょう。
手動といっても、それほど手間がかかるわけではありません。
コードを示します。

export default function Edit() {
    const [isLine, setIsLine] = useState('');
    const preRef = useRef(null);//⓵
    const code = 'line 1\nline 2'
    useEffect(() => {
        if (!preRef.current.classList.contains('prettyprinted')) {
            preRef.current.innerText = code;//⓶
        }
        PR.prettyPrint();
    }, [isLine]);

    return (
        <>
            <button onClick={() => setIsLine('linenums')}>
                render
            </button>
            <pre ref={preRef} class={`prettyprint ${isLine}`} >//⓷
                {code}
            </pre>
        </>

    )
}

⓵でuseRefを宣言し、⓷でpre要素を参照しておきます。
⓶でその参照を使用してinnerTextプロパティをもとにもどしてやります。
その後、PR.prettyPrint()が実行されることになるので、期待どおりのレンダリングが実行されます。

今回は仮想DOMの仕組みを理解していないと、再レンダリングされるはずなのになぜ再レンダリングがおこならないのか、見当がつかないという状況になるということをお伝えすることに焦点を絞りました。
そのため、Google Code Prettifyの使い方や、useRefの利用のところは、それほど説明を加えませんでした。useRefは非常に重要なReactのフックスですので、他のブログで詳しく説明したいと思います。

Reactには仮想DOMによるレンダリングという仕組みがあることは、多くの技術者が意識していることだと思いますが、その実態を目の当たりにすることは少ないのではないでしょうか。
レンダリング後のDOM要素を開発者ツールで確認しても、それが再レンダリングされた結果なのか、再レンダリングされなかったのか見分けがつかないし、確認する必要性に迫られることが少ないからです（本当はプラグイン等で不要なレンダリングが起きていないかチェックすべきなんでしょうね。）。
しかし、今回のような不具合が起きるとそうはいきません。
外部ライブラリの利用は実践的なコンポーネントを作る上で欠かせない存在です。それとReactをうまく組み合わせるためには、基本の徹底理解がいかに大事か身につまされました。

このブログが少しでもお役に立てば光栄です。