今までビルド毎に全ての記事を再生成していたのに対して更新があった差分だけビルドする機能で現在βテスト中の機能だ。
前回の記事ではエラーが出ていたため利用できなかった。
以前は次のエラーが出ていてインクリメンタルビルドができなかった。
WebpackError: TypeError: Cannot read property 'childImageSharp' of nullこれは画像のパスが解決できていないということだが、どうやらMarkdownから参照している画像がstaticにあると発生する模様。
もしstaticに直接画像を保存してMarkdownから参照している場合は、全ての画像ファイルをBLOG記事とおなじsrc/pages内部に変更すること。
実際に私の環境ではmdファイルが保存されているフォルダの中にimgフォルダを作ったので実際はsrc/pages/blog/imgとなった。
この変更によりインクリメンタルビルドが正しく動作するようになった。
もしまたエラーが再発した場合は次のコマンドでキャッシュを削除し全体ビルドをやり直してやれば治る可能性がある。
gatsby cleanNetlify側でインクリメンタルビルドするには前回は失敗したが、基本的に前回の記事と同様の作業をしてもらえば正常に動作するはずだ。
ぜひとも試してみて欲しい。
コンテンツメインは以上でここからはエラー原因を探し当てた方法であるので興味があれば読んで貰えればと思う。
そもそもHTMLのパスについて特別詳しくない私だがパスにスラッシュがないと画像が読めないという動きを調査していた。
./img/画像やimg/画像だとstaticの画像がうまく読めない。/img/画像でなければならない。ここに疑問があった。
はじめはgatsby-imageのバグだろうと思っていたのだが何気にHTML上では一切パスの変換が行われておらず画像が表示されるかどうかはブラウザ側のパスの解釈によるものだと分かった。
そもそも/img/画像はultra-noob.com/img/画像を指し、./img/画像はultra-noob.com/blog/記事名/img/にアクセスしている。これはこれで勉強になった。
まずはこの動作の違いに気づいたのでなにかオカシイと思った。
staticフォルダの画像は変換後にコピーされるものstaticに入れたデータはたしかにそのままURLで公開されるが、BLOG記事の画像に関してはsrc(開発専用フォルダ)からサイズやプレースホルダ等の処理されて変換されたものがstaticにコピーされて自動的にパスが付与される、というのが本来の仕組みであることに気づいた。
だとすると、上の画像URLが記述したそのままになっているのはオカシイ。
本来ビルド時に変換されなければならないのだ。
srcの中に必要つまりsrcに画像を入れておいてビルド時に処理をさせて自動でstaticに保存されるわけだ。
staticに保存した画像を直接Markdownから指定していたのが間違いだった。
というわけで、これが記事を更新したときに画像のプラグインで発生するエラーの原因だった。
またBLOG記事内の画像のプレースホルダ(ロード中の仮画像)が正しく表示されない不具合も解消された。
