種別: Webサイト

Gutenbergのブロック開発をしていて、おかしな現象に見舞われました。次の画像をご覧ください。

これはブロックにニューモフィズムというシャドーをつけたものです。
上がブロックエディタの表示で、下がフロントエンドの表示です。
ご覧のとおり下は高さが狭く、ニューモフィズムの浮き出た感じが出し切れていません。
なぜ、こんな現象が起こるのかをブログにしたいと思います。

まず、この画像のHTMLとCSSを示します。
まず、HTMLです。

<div>
     <ul>
         <li>情報入力</li>
        <li>確認</li>
        <li>処理完了</li>
    </ul>
</div>

次にCSS(SCSS)です。

div{
    ul{
        margin: 1em 2em 1em 2em;
        padding: 1em 2em 1em 2em;
        box-shadow: 5px 5px 5px #ecd4d4,-5px -5px 5px #fcf8f8;
    }
}

簡単なコードです。div要素でul要素をラップし、ul要素にはmarginとpaddingをつけました。
その上でbox-shadowをつければ、marginとpaddingの間にシャドーが落ちてくれると思ったわけです。
しかし、ブロックエディタは思惑どおりでしたが、肝心のフロントエンドは変な表示になってしまいました。

調べてみるとこんなことがわかってきました。
margin-topとmargin-bottomというのは、上下に接触する要素同士においては、折り重なるという性質があります。
次のようなコードでは、要素Aの margin-bottom と要素Bの margin-top が折り重ねられ、実際のマージンは30px（大きい方の値）となります。

<div style="margin-bottom: 20px;">要素A</div>
<div style="margin-top: 30px;">要素B</div>

この事例は隣接する兄弟要素の場合ですが、この現象は、親要素とその最初または最後の子要素の間でも発生します。

<div style="margin-bottom: 20px;">
    要素A
    <div style="margin-top: 30px;">要素B</div>
</div>

この図のように子要素の上側・下側のマージンは親要素の外に「押し出される」ことになり、親要素の縦幅を広げるわけではないのです。
これが「マージンの折り重ね（マージンの重複）」です。

では、なぜブロックエディタの方は、期待どおりの動きをしてくれるのかということです。
実はGutenbergのブロック開発ではブロックエディタ側には、ブロックに１pxの破線のボーダーが付いています。
これのおかげで子要素のマージンは親要素のボーダーの内側に回るのです。
コードと図解は次のようになります。

<div style="
    margin-bottom: 20px;
    border: 1px dotted #f00;
">
    要素A
    <div style="margin-top: 30px;">要素B</div>
</div>

これは親要素にパディングがある場合でも同じです。
その他にも「マージンの折り重ね」が起きない場合があるので、箇条書きにしてまとめます。

1. borderやpaddingの追加：親要素に少なくとも1pxの border や padding がある。
2. overflowプロパティの使用：親要素に overflow: auto または overflow: hidden を設定する。
3. flexboxやgridの使用：FlexboxやGridレイアウトを使用する。

ちなみに、水平方向のマージン（margin-left および margin-right）には、マージンの折り重ね（マージンの重複）という現象は存在しません。
そもそも、水平方向のマージンというのは、要素を親要素のどの位置に配置されるかを決定するためのもので、親要素の全体の幅そのものを広げるという効果はありません。
仮に、水平方向のマージン（margin-left および margin-right）が自らの幅とあわせて、親要素の幅を超えるとオーバーフローを起こします。

親要素の幅に影響を与えるのは子要素のwidthやpadding, borderなどのプロパティです。子要素の幅やパディング、ボーダーが親要素の利用可能な幅を超える場合、通常、親要素は子要素を収容するために拡張されます。
ただし、親要素に固定の幅が設定されている、あるいは他のスタイルが適用されている場合はそうならないこともあります。

CSSの基本中の基本とも言えるmarginプロパティですが、実はこんなに奥が深かったということを今更のように知りました。

皆さんはいかがでしょう。

もし、私が経験したような現象でお悩みの方がいれば、是非参考にしていただきたいと思います。

いつものようにブロック開発をしていました。何気なく以前作ったブロックに文字入れをしようと思ってTextControlに日本語を入れようと思うと次の画像のような現象が起きました。

この画像でおわかりでしょうか？
この画像はブロックエディタのサイドバーです。
母音はローマ字変換されているけど子音は母音の入力を待たず入力が確定しているという状態です。これまで見たことがない怪現象です。
IMEの設定がおかしくなったかと思い確認しましたが特に問題はありません。そもそも他のTextControlではこんな現象は起きていません。
よくみると漢字変換もできない状態です。つまり、一文字入力するごとにEnterキーを押したような状態です。
TextControlに何か変なPropsでも渡したかなと思って確認しても特に何もありません。
こんな時はChatGPTかと思って現象を説明しましたしたがReactの非同期処理の問題というような回答でイマイチ的を得ていませんでした。

TextControlをレンダリングしているコードは次のようになっています。

<TextControl
    label="コピーテキスト"
    labelPosition="top"
    value={optionStyle.copy_content}
    onChange={(newValue) => {
        setLocalOptionStyle(prev => ({ ...prev, copy_content: newValue }));
    }}
/>

上記のコードのonChange={(newValue) => {setLocalOptionStyle(prev => ({ ...prev, copy_content: newValue }));でこのブロックコンポーネントが持つoptionStyleオブジェクト内のcopy_content オブジェクトの値を書き換えています。
そして、

const [localOptionStyle, setLocalOptionStyle] = useState(optionStyle);

// localOptionStyle の変更があるたびに setAttributes を呼び出す
useEffect(() => {
    setAttributes({ optionStyle: localOptionStyle });
}, [localOptionStyle]);

としてあって、setLocalOptionStyleでlocalOptionStyleに変更があれば、optionStyleというブロックの属性が書き換わるという仕組みです。
特別特殊なことは何もしてないし、何か問題が起こるなどとは全く思っていませんでした。
ところが、このコードには重大な欠陥があるのです。おわかりでしょうか？

ヒントはこの表題の中にあります。
答えに至るポイントは

value={optionStyle.copy_content}

にありました。
どうしても

onChange={(newValue) => {
    setLocalOptionStyle(prev => ({ ...prev, copy_content: newValue }));
}}

の方に目が行きがちでChatGPTもonChangeでなくonBlurで処理すれば、入力の確定を遅らせることができるなんていう説明をしていました。
しかし、そこではないのです。

TextControlに表示されている文字列はvalueに渡された値です。そして、次のようなコードがより一般的だと思います。

<TextControl
    value={copyInputValue}
    onChange={(newValue) => {
        setCopyInputValue(newValue);
    }}
/>

このコードと問題のコードの違いがおわかりでしょうか。
そう、一般的なコードはvalueにnewValueが何も加工されずに渡っています。ところが、問題のコードはvalueに{ optionStyle.copy_content }というnewValueを加工したものを表示させています。
そうするとTextControlは入力途中で未返還の状態を維持することができず、確定した文字列を表示してしまうのです。
「TextControlのonChangeは一文字入力ごとに発火する」ということを意識していれば、そのたびにsetLocalOptionStyle(prev => ({ ...prev, copy_content: newValue }));が働いて一文字一文字確定させていくんだというイメージが湧いたのではないでしょうか。
たとえば次のようなコードならわかりやすいでしょう。

<TextControl
    value={copyInputValue}
    onChange={(newValue) => {
        setCopyInputValue(`${newValue}.`);
    }}
/>

こんなコードを書くことはないでしょうが、テンプレートリテラルでnewValueに’.’をつけるような加工をしています。これがTextControl内にレンダリングされたら、その後は日本語変換はできなくなるだろうなということは想像がつくと思います。

この問題を解消するコードを示します。

//TextControlの表示用変数
const [copyInputValue, setCopyInputValue] = useState(optionStyle.copy_content);

<TextControl
    label="コピーテキスト"
    labelPosition="top"
    value={copyInputValue}
    onChange={(newValue) => {
        setCopyInputValue(newValue);
        setLocalOptionStyle(prev => ({ ...prev, copy_content: newValue }));
    }}
/>

このコードではTextControlの表示用として状態変数を一つ用意して、それをvalueに渡しています。そうすることでTextControlの表示として加工していないnewValueを渡すことができます。setLocalOptionStyleはこれまでどおり行えばよいのです。ブロックにレンダリングされるのはそれによって書き換えられたoptionStyle.copy_contentです。それ自身は正解で、何もonBlurのイベント発生を待つ必要はありません。それを待っているとブロックへのレンダリングが遅れ、TextControlの入力内容がリアルタイムにブロックの表示に反映されなくなります。

TextControlは非常に一般的で基本的なUIだと思っていましたが、他の入力コントロールと違い入力途中の状態を表示するという特殊性があります。そのため入力コントロールの表示とブロックのレンダリングが必ずしも一致しないということを意識しないといけないのかということに気付きました。もちろん、ほとんど場合は一致するので気が付きにくいです。日本語入力でなく、英数字を入力していればこんな現象は起こらず欠陥には気づきません。
そういう意味でなかなか、良い勉強になったと思いました。
参考にしていただけると光栄です。