<p></p>
<h2 id="elm-pages-in-action">
<a class="header-anchor-link" href="#elm-pages-in-action" aria-hidden="true"></a> Elm-pages in Action</h2>
<p>...あるいは、elm-pagesの概念的ポイント解説</p>
<p>By <a href="https://zenn.dev/ymtszw" target="_blank">ymtszw</a><br>
@<a href="https://elm-jp.connpass.com/event/280401/" target="_blank" rel="nofollow noopener noreferrer">Elm-jp 2023</a> (2023/05/20) <sup class="footnote-ref"><a href="#fn-b09a-1" id="fnref-b09a-1">[1]</a></sup></p>
<hr>
<h2 id="%E5%89%8D%E5%9B%9E%EF%BC%9F%E3%81%BE%E3%81%A7%E3%81%AE%E3%81%82%E3%82%89%E3%81%99%E3%81%98">
<a class="header-anchor-link" href="#%E5%89%8D%E5%9B%9E%EF%BC%9F%E3%81%BE%E3%81%A7%E3%81%AE%E3%81%82%E3%82%89%E3%81%99%E3%81%98" aria-hidden="true"></a> 前回？までのあらすじ</h2>
<ul>
<li>昨年、<a href="https://ymtszw.github.io/articles/elm-pages-and-headless-cms" target="_blank" rel="nofollow noopener noreferrer">elm-pages (v2)とHeadless CMSに入門し、好印象を抱いた</a>
<ul>
<li>せっかくなので<a href="https://ymtszw.github.io/" target="_blank" rel="nofollow noopener noreferrer">personal website</a>として成果物を整備し、その後継続的に記事更新したり、サイト改良したりしている</li>
<li><a href="https://github.com/ymtszw/ymtszw.github.io" target="_blank" rel="nofollow noopener noreferrer">ソース</a></li>
</ul>
</li>
<li>昨年後半の<a href="https://zenn.dev/siiibo_tech/articles/elm-meetup-202211?redirected=1#%F0%9F%93%9Aelm-pages-(v2)-by-dillonkearns" target="_blank">Elm Meetup (online)でコミュニティ製フレームワークの一つとして紹介</a>
</li>
</ul>
<hr>
<h2 id="%E4%BB%8A%E5%9B%9E%E3%81%AF%E2%80%A6">
<a class="header-anchor-link" href="#%E4%BB%8A%E5%9B%9E%E3%81%AF%E2%80%A6" aria-hidden="true"></a> 今回は…</h2>
<ul>
<li>elm-pages v2の概念的なポイントを紹介</li>
<li>elm-pages v3で新たに取り組まれているところと現状の共有</li>
</ul>
<hr>
<h2 id="%E3%81%9D%E3%82%82%E3%81%9D%E3%82%82elm-pages%E3%81%A8%E3%81%AF">
<a class="header-anchor-link" href="#%E3%81%9D%E3%82%82%E3%81%9D%E3%82%82elm-pages%E3%81%A8%E3%81%AF" aria-hidden="true"></a> そもそもelm-pagesとは</h2>
<p><a href="https://elm-pages.com/docs" target="_blank" rel="nofollow noopener noreferrer">elm-pages</a></p>
<ul>
<li>基本的には静的サイトジェネレータ(SSG)である</li>
<li>主要な部分はすべてElmで記述できる</li>
<li>以下、v2のAPIの概念的なポイントを紹介</li>
</ul>
<hr>
<h2 id="build-time%E3%81%A8run-time%2C-2%E3%81%A4%E3%81%AEelm-app%E5%AE%9F%E8%A1%8C">
<a class="header-anchor-link" href="#build-time%E3%81%A8run-time%2C-2%E3%81%A4%E3%81%AEelm-app%E5%AE%9F%E8%A1%8C" aria-hidden="true"></a> Build-timeとRun-time, 2つのElm App実行</h2>
<ul>
<li>SSGである以上、事前にコンテンツを静的なHTMLとして生成し、配信したい</li>
<li>しかし、Elmは<strong>クライアントでの実行時にコンテンツが動的生成される</strong>SPAに特化した言語だったはず…</li>
</ul>
<p>=&gt; elm-pagesは、<strong>2つのタイミングでのElm App実行</strong>によってこのギャップを埋める</p>
<hr>
<h2 id="build-time-app">
<a class="header-anchor-link" href="#build-time-app" aria-hidden="true"></a> Build-time App</h2>
<ul>
<li>
<code>elm-pages build</code>を実行したとき、elm-pages CLIはまずボイラープレートコード生成を行う
<ul>
<li>elm-pagesはFile-based Routingを採用</li>
<li>ファイル名(=モジュール名)規則を元に対応するroutingコード等が生成され、root appの<code>main</code>関数に結線するあたりは自動</li>
</ul>
</li>
</ul>
<div class="code-block-container"><pre class="language-elm"><code class="language-elm"><span class="token keyword">module</span> <span class="token constant">Page.Index</span> <span class="token keyword">exposing</span> <span class="token punctuation">(</span><span class="token operator">..</span><span class="token punctuation">)</span>
</code></pre></div><div class="code-block-container"><pre class="language-elm"><code class="language-elm"><span class="token keyword">module</span> <span class="token constant">Page.Articles.ArticleId_</span> <span class="token keyword">exposing</span> <span class="token punctuation">(</span><span class="token operator">..</span><span class="token punctuation">)</span>
</code></pre></div><hr>
<ul>
<li>生成されたElm Appは<strong>実際にpre-rendering機構によって実行され</strong>、結果としてのHTMLがrouteごとに得られる</li>
<li>これらのHTMLがSSGとしての<strong>第一の</strong>成果物
<ul>
<li>適当なWebサーバから配信すれば、クローラーフレンドリーなWebサイトとして機能する</li>
<li>JavaScriptが無効化されていても、prerenderされたwebサイトは正常に表示される</li>
</ul>
</li>
</ul>
<hr>
<h2 id="run-time-app">
<a class="header-anchor-link" href="#run-time-app" aria-hidden="true"></a> Run-time App</h2>
<ul>
<li>一方、生成されたElm Appそれ自体も、<strong>第二</strong>の成果物となる</li>
<li>第二の成果物は、以下の要素から成る：
<ul>
<li>みなさんが想像する<strong>Elm SPAそのもの</strong>
</li>
<li>routeごとに事前生成されたHTMLを表示後、上記のElm SPAをクライアントwebブラウザで実行し、以後の処理をSPAに移譲するためのグルーコード</li>
</ul>
</li>
</ul>
<hr>
<ul>
<li>この構成によって、静的サイトの事前生成も、webブラウザでのサイト読み込み後の動作もいずれもElmで記述する、という世界観が成立する</li>
<li>…さて御存知の通り、Elm 0.19のVDom実装にはいわゆる<strong>hydration機能(VDomを元にSSRされた結果から、ブラウザ内でVDomを再構築する機能)がない</strong>
</li>
</ul>
<p>=&gt; それではどのようにして、「以後の処理をSPAに委譲」するのか？</p>
<hr>
<h2 id="%E6%B1%BA%E5%AE%9A%E8%AB%96%E7%9A%84rendering">
<a class="header-anchor-link" href="#%E6%B1%BA%E5%AE%9A%E8%AB%96%E7%9A%84rendering" aria-hidden="true"></a> 決定論的rendering</h2>
<ul>
<li>予め結論を述べると、意外に特別なことはやってない</li>
<li>
<code>DOMContentLoaded</code>イベント契機で第二の成果物であるElm Appを起動しているだけ</li>
</ul>
<div class="code-block-container"><pre class="language-js"><code class="language-js"><span class="token comment">// 成果物HTMLで実質的に実行されるPromise</span>
<span class="token keyword">const</span> appPromise <span class="token operator">=</span> <span class="token keyword">new</span> <span class="token class-name">Promise</span><span class="token punctuation">(</span><span class="token keyword">function</span><span class="token punctuation">(</span><span class="token parameter">a</span><span class="token punctuation">)</span><span class="token punctuation">{</span>
  <span class="token dom variable">document</span><span class="token punctuation">.</span><span class="token method function property-access">addEventListener</span><span class="token punctuation">(</span><span class="token string">"DOMContentLoaded"</span><span class="token punctuation">,</span> <span class="token punctuation">(</span><span class="token punctuation">)</span> <span class="token arrow operator">=&gt;</span> <span class="token punctuation">{</span>
    <span class="token function">a</span><span class="token punctuation">(</span><span class="token function">loadContentAndInitializeApp</span><span class="token punctuation">(</span><span class="token punctuation">)</span><span class="token punctuation">)</span>
  <span class="token punctuation">}</span><span class="token punctuation">)</span>
<span class="token punctuation">}</span><span class="token punctuation">)</span><span class="token punctuation">;</span>
</code></pre></div><hr>
<ul>
<li>
<ol>
<li>Build-timeのpre-rendering</li>
</ol>
</li>
<li>
<ol start="2">
<li>ブラウザ内でのclient-side rendering</li>
</ol>
</li>
</ul>
<p>=&gt; この2つが(少なくともrender完了直後のフレームにおいて)<strong>寸分違わず一致するならば</strong>、第一の成果物由来のHTML表示そのままに、第二の成果物由来のSPAによる処理に間断なく移行できる、という理屈</p>
<hr>
<ul>
<li>「寸分違わず一致」させるために、elm-pagesはこれら<strong>二種類のrendering結果が決定論的に定まる</strong>よう設計されている</li>
<li>具体的には、
<ul>
<li>ページがrendering時に依存するデータの<code>DataSource</code>による抽象化</li>
<li>Flagsの分離</li>
</ul>
</li>
<li>（注: 多分ほかにも工夫はあるけど、概念的にポイントとなるのはこのへんだと理解している）</li>
</ul>
<hr>
<h2 id="datasource">
<a class="header-anchor-link" href="#datasource" aria-hidden="true"></a> <code>DataSource</code>
</h2>
<ul>
<li>
<strong>Build-timeに解決</strong>されるデータ
<ul>
<li>由来はCMS等の外部APIでもいいし、ローカルファイルでもいい</li>
</ul>
</li>
<li>elm-pagesの各ページモジュールは、<code>init</code>時には基本的に<code>DataSource</code>にのみ依存できる</li>
<li>ポイントは、解決された<code>DataSource</code>の内容は、<strong>JSONとしてシリアライズされてHTML(第一の成果物)に埋め込まれる</strong>こと</li>
</ul>
<hr>
<ul>
<li>Run-timeに実行されたElm App(第二の成果物)も、Build-timeから持ち越された<code>DataSource</code>をそのまま読み込んでページモジュールを<code>init</code>する</li>
<li>これによって両者の評価結果が一致する仕組み
<ul>
<li>たとえば、CMS APIの返す値がbuild-timeとrun-timeで変化していても影響を受けない</li>
</ul>
</li>
</ul>
<hr>
<h2 id="flags%E3%81%AE%E5%88%86%E9%9B%A2">
<a class="header-anchor-link" href="#flags%E3%81%AE%E5%88%86%E9%9B%A2" aria-hidden="true"></a> Flagsの分離</h2>
<ul>
<li>通常、Elm App起動時のもう一つの依存データはFlags</li>
<li>elm-pagesでは、</li>
</ul>
<div class="code-block-container"><pre class="language-elm"><code class="language-elm"><span class="token keyword">type</span> <span class="token constant">Flags</span>
    <span class="token operator">=</span> <span class="token constant">BrowserFlags</span> <span class="token constant">Json.Decode.Value</span>
    <span class="token operator">|</span> <span class="token constant">PreRenderFlags</span>
</code></pre></div><ul>
<li>このように2つのElm Appが受け取るFlagsが分離される</li>
</ul>
<hr>
<ul>
<li>見て分かる通り、<strong>pre-render時にはFlagsは存在できない！</strong>
<ul>
<li>例えば、Elm App起動時のブラウザの画面サイズや現在時刻を取得する、といったことはpre-render時にはできないよう型で保証されている</li>
</ul>
</li>
<li>2つのElm Appは、どちらの起動タイミングでも最初はpre-render状態(Flagsなし)で起動する</li>
<li>Webブラウザ上で起動したとき、<code>BrowserFlags Json.Decode.Value</code>がElm App起動後の処理で遅れて利用可能となる</li>
</ul>
<hr>
<h2 id="elm-pages-v2%E3%81%AE%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88%E3%81%BE%E3%81%A8%E3%82%81">
<a class="header-anchor-link" href="#elm-pages-v2%E3%81%AE%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88%E3%81%BE%E3%81%A8%E3%82%81" aria-hidden="true"></a> elm-pages v2のポイントまとめ</h2>
<ul>
<li>Built-timeとRun-time, 同じElm Appを2つのタイミングで実行</li>
<li>かつ両者の結果が一致するよう設計することで、できないはずだったSSG→SPA委譲を可能にする</li>
<li>そのための工夫
<ul>
<li><code>DataSource</code></li>
<li>Flagsの分離</li>
</ul>
</li>
</ul>
<hr>
<h2 id="elm-pages-v3%E3%81%A7%E3%81%AF%E4%BD%95%E3%81%8C%E8%B5%B7%E3%81%8D%E3%82%88%E3%81%86%E3%81%A8%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%8B%EF%BC%9F">
<a class="header-anchor-link" href="#elm-pages-v3%E3%81%A7%E3%81%AF%E4%BD%95%E3%81%8C%E8%B5%B7%E3%81%8D%E3%82%88%E3%81%86%E3%81%A8%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%8B%EF%BC%9F" aria-hidden="true"></a> elm-pages v3では何が起きようとしているか？</h2>
<ul>
<li>v2までで、いわゆるJAMStackにおけるSSG→SPAという部分についてはElmだけで実現可能になっている
<ul>
<li>事前にページ生成して検索インデックスに乗るようにし、ページ表示後はCSRで動的コンテンツ提供</li>
</ul>
</li>
<li>が、御存知の通りこの構成には<strong>中間地点</strong>が欲しくなる
<ul>
<li>特に事前に生成したいページが大量にあったり、頻繁に更新されるようなwebサイト/webサービス</li>
<li>最たるものはECサイトや、ユーザ生成コンテンツからなるサービスなど</li>
</ul>
</li>
</ul>
<hr>
<ul>
<li>その中間地点を満たすのが<strong>SSRの諸形態</strong>
<ul>
<li>特にNext.jsの<strong>ISG; Incremental Static Generation</strong>や<strong>ISR; Incremental Static Regeneration</strong>, <strong>On-demand ISR</strong>あたり</li>
<li>参考
<ul>
<li><a href="https://blog.microcms.io/on-demand-isr/" target="_blank" rel="nofollow noopener noreferrer">Next.jsのOn-demand ISRで、ビルド不要の高速配信を実現する | microCMSブログ</a></li>
<li><a href="https://engineerblog.mynavi.jp/technology/on-demand_isr_introduction/" target="_blank" rel="nofollow noopener noreferrer">【Next.js】On-Demand ISRが安定版になったよ！ | マイナビエンジニアブログ</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<hr>
<ul>
<li>アプローチ
<ul>
<li>ISG: <strong>リクエストがあったとき</strong>に初めて静的生成を行い、それをエッジキャッシュに載せる</li>
<li>ISR: <code>stale-while-revalidate</code>戦略で、キャッシュデータを高速に表示しつつ再生成も行う</li>
<li>On-Demand ISR: 更に、イベントドリブンな適時再生成にも対応して、stale表示を最小化する</li>
</ul>
</li>
<li>elm-pages v3では、端的に言うとISG相当のアプローチに対応しようとしている
<ul>
<li><a href="https://github.com/dillonkearns/elm-pages-v3-beta/blob/master/docs/FAQ.md#is-elm-pages-full-stack-can-i-use-it-for-pure-static-sites-without-a-server-can-i-use-it-for-server-rendered-pages-with-dynamic-user-content" target="_blank" rel="nofollow noopener noreferrer">Server-rendered route</a></li>
<li>リファレンス実装はNetlify Functionsを使用</li>
<li>Adapter層を導入することで、他のプラットフォームにも対応</li>
</ul>
</li>
</ul>
<hr>
<h2 id="v3-status">
<a class="header-anchor-link" href="#v3-status" aria-hidden="true"></a> v3 status</h2>
<ul>
<li>ほかにも、webサイトで頻出の要求であるフォーム送信機能もサポートするため、設計・実装中</li>
<li>更に、<code>DataSource</code>等の内部実装を効率化するためにLamdera compilerを採用</li>
<li>...and more!</li>
</ul>
<p>=&gt; という状況のため、v3-betaとそのstarter repoはまだまだ流動的。一方v2のAPIはそこそこ <strong>「枯れている」と言っていいくらいに整っている</strong>ので、23年5月現在ならv2でまずはデビューしてみてください</p>
<hr>
<h2 id="%E3%81%82%E3%81%A8%E3%81%8C%E3%81%8D">
<a class="header-anchor-link" href="#%E3%81%82%E3%81%A8%E3%81%8C%E3%81%8D" aria-hidden="true"></a> あとがき</h2>
<ul>
<li>elm-pagesの中心概念はどっかで自分の言葉で書いておきたいと思ったのでこのような内容になった</li>
<li>ホントはタイトルの"in action"にもっと寄せて、
<ul>
<li>v2でのパフォーマンスチューニングとか、</li>
<li>自前サイトでの具体的なコードの話とか、</li>
<li>いくつか裏技小技とか、</li>
<li>その辺も書きたいのだが、また別の機会に</li>
</ul>
</li>
<li>
<a href="https://docs.google.com/presentation/d/e/2PACX-1vRuIA2ocDafLRJUn6nWScZmOq6YwpqXba7x5RG72yzT3X7FB-JcET33QMGsBidHsAdbnVF9KYCOa00R/embed?start=false&amp;loop=false&amp;delayms=3000&amp;slide=id.g155be708576_0_55" target="_blank" rel="nofollow noopener noreferrer">著者紹介</a>（tokyo.ex#20のスライド）</li>
</ul>
<hr>
<h2 id="q.-elm-pages%E3%81%AFpre-render%E6%99%82%E3%81%AB%E3%81%A9%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%9F%E3%83%B3%E3%82%B0%E3%81%A7%E7%94%9F%E6%88%90%E3%81%95%E3%82%8C%E3%81%9Fhtml%E3%82%92%E7%A2%BA%E5%AE%9A%E3%81%99%E3%82%8B%E3%81%AE%EF%BC%9F">
<a class="header-anchor-link" href="#q.-elm-pages%E3%81%AFpre-render%E6%99%82%E3%81%AB%E3%81%A9%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%9F%E3%83%B3%E3%82%B0%E3%81%A7%E7%94%9F%E6%88%90%E3%81%95%E3%82%8C%E3%81%9Fhtml%E3%82%92%E7%A2%BA%E5%AE%9A%E3%81%99%E3%82%8B%E3%81%AE%EF%BC%9F" aria-hidden="true"></a> Q. elm-pagesはpre-render時にどのタイミングで生成されたHTMLを確定するの？</h2>
<p><strong>A. いい質問ですね。</strong> 個人的にあまり深追いしていなかった部分です。</p>
<ul>
<li>例えばページのsubscription関数で<code>onAnimationFrame</code>を使ったりして、次フレームからいきなりページ内容が連続的に変化するような実装をした場合、pre-renderとbrowser-renderの2つのアプリの一致点を取りにくいんではないか。</li>
</ul>
<hr>
<ul>
<li>pre-renderに使ってるライブラリがよしなにやってくれてるのかもしれない。
<ul>
<li>最初のフレームで止めるとか？そんなことできるんだろうか</li>
<li>v1のときはprerender.ioを使ってたような記憶があるけど今どうなってるんだろう。</li>
<li>読者への課題とします。個人的にも追って調査します。</li>
</ul>
</li>
</ul>
<span class="embed-block zenn-embedded zenn-embedded-tweet"><iframe id="zenn-embedded__1d0f72854e52c" src="https://embed.zenn.studio/tweet#zenn-embedded__1d0f72854e52c" data-content="https%3A%2F%2Ftwitter.com%2Fgada_twt%2Fstatus%2F1661010522651910146" frameborder="0" scrolling="no" loading="lazy"></iframe></span>
<section class="footnotes">
<span class="footnotes-title">脚注</span>
<ol class="footnotes-list">
<li id="fn-b09a-1" class="footnote-item">
<p>この発表資料はZennで公開しつつ、<a href="https://marp.app/" target="_blank" rel="nofollow noopener noreferrer">Marp</a>スライドとして作成しているので水平線がいっぱい入っています <a href="#fnref-b09a-1" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>


Elm-pages in Action

Build-timeとRun-time, 2つのElm App実行

elm-pages v3では何が起きようとしているか？

Q. elm-pagesはpre-render時にどのタイミングで生成されたHTMLを確定するの？

Discussion