OmやOm-next、Reagent、Rumなどの現状についてお話します。

1. Clojureの各種React系ラッパーライブラリの
サーバーサイドレンダリングの現状について
SPAとSSR、現実解について考えてみる
2016/09/28
Lisp Meet Up presented by Shibuya.lisp #44

2. 登壇者
{:company “Greative.GK”
:name “Kazuhiro Hara”
:twitter “@kara_d”}

3. Clojure / ClojureScript でElectronアプリケーションを
作るためのスターターキット / プラットホーム
● オープンソースにてGitHubにて公開
● MITライセンス
● 現在のスター数 : 230 http://descjop.org/

4. アジェンダ
● なぜSSRなのか? 他言語環境での難しさについて
● ClojureのReactラッパー系ライブラリでの実装について
● おれたちにはcljcがある!

5. なぜSSRなのか?について

6. SSR(サーバーサイドレンダリング)について
(Reactベースのアプリケーションの文脈で)
● Webアプリケーションに用意されているURLにアクセスした時に、
DOMの構築をフロントエンド側で行うと、一瞬表示されていない状態になる
● 初期表示状態が決まっているなら、
サーバー側で初期状態のDOMレンダリングを完了した状態で返せばいい
● 共通の半描画状態の画面を出したりローディング画像を出すアプローチもある

7. そもそもSSRする必要があるのか?
ある
ない
Reactで複雑な状態遷移を扱うようなことが前提のWebアプリケーションなら、
Accessible Rich Internet Applications(WEI-ARIA)を全力で頑張る方向に
倒したほうが良くないか?
☞ 今回こっちの場合の話

8. なぜSSRなのか?について
● URLに対する情報のアクセシビリティ・セマンティック性を確保しておく
○ ブラウザを通したURLに対するアクセシビリティ・セマンティック性とは少し別
○ SEOの問題はあまり心配しなくていいらしい (自分で実験したわけではない )
● パフォーマンスの問題
○ ブラウザでURLを直接アクセスした時に表示が完了するまでの時間の短縮化

9. SSRと一口に言っても?
● React標準のスタイルでサポートされているやり方
○ react-dom/serverを使う
■ https://facebook.github.io/react/docs/environments.html
● 上記と同じことを他言語環境でエミュレートする
● せめてJSON部分だけHTMLに埋め込む
○ TwitterやFacebookなど
● 原始的に出力するdivを切り分けて読み込み後は元のdivを消すとか...
<div id=”ssr”> ここにサーバーで出力した結果を埋め込む </div>
<div id=”react-app”> ここはReactが使う</div>

10. なぜClojureでのSSRは難しいか
Clojureに限らず難しい問題(react-rails, React.NET, react-python, react-php-v8jsな
どは公式に出ている...)
● Reactのレンダリングは、同一のものをHTMLに埋め込んで返せばいい訳ではない
○ data-reactidの指定と、data-react-checksumの指定が必要
○ data-reactidを埋め込んだHTMLに対してadler32でチェックサムを作成
○ ただ、0.14.0 -> 15.0で少し変更があった (data-reactidベースからdata-reactrootベースへ)
■ https://facebook.github.io/react/blog/2016/04/07/react-v15.html
● Reactと違うエコシステム、違うテンプレートスタイル

11. Clojureでの実装方法
大きく分けて2種類
● 独自にReactのdomを再実装
○ Rum
○ foam
○ cellophane
○ デメリットについて
● Javaのnashornを利用
○ ReactのJavaScriptコードを呼び出す
○ デメリットについて
● 別の道... ClojureScriptでNode.jsサーバーを立てる

12. ClojureのReactラッパー系の
ライブラリの現状について

13. Om
Omのバージョン0.9.0
バージョン1.0となる予定のOm-nextが開発中
● Omに対しては.cljc内でClojure用にfoamというライブラリを使う
○ https://github.com/arohner/foam
(:require #?(:clj [foam.core :as om]
:cljs [om.core :as om])
#?(:clj [foam.dom :as dom]
:cljs [om.dom :as dom]))

14. Om-next
Om-nextは、1.0.0-alpha 45にてサーバーサイドレンダリングが搭載されたが、
試したもののまだうまく動かせなかった
● 今すぐ使いたいならCellophaneが吉
○ https://github.com/ladderlife/cellophane
(:require #?@(:cljs [[om.next :as om :refer-macros [defui]]
[om.dom :as h]]
:clj [[cellophane.next :as om :refer [defui]]
[cellophane.dom :as h]]))

15. Reagent / Re-frame
Reagentでは、nashornを使った仕組みが提案されている
● Reagent Cook Book
○ https://github.com/reagent-project/reagent-cookbook/tree/master/recipes/reagent-server-rende
ring
○ プラクティスとして提供
○ たぶん公式の機構はまだない ?

16. Clojureのテンプレート系ライブラリについて
● sablono (hiccup系)
○ Issueとしてはある
■ Server-side rendering · Issue #111 · r0man/sablono
https://github.com/r0man/sablono/issues/111
● kioo (enlive系)
○ こちら、未調査(詳しい人教えてください )

17. Rum
Rumはもともと、Client / Serverを考慮して作られている
他のClojureライブラリでSSRの話が出るとき、Rumのようにしたいと
話題にあがったりする
他のReact再実装系コードの参考になっているのでは
親和性としては最高かもしれない
● server_render.cljに実装がある
○ https://github.com/tonsky/rum/blob/gh-pages/src/rum/server_render.clj

18. その他のReactラッパー系ライブラリ
● Quiescent
○ https://github.com/levand/quiescent
○ 特に公式サポートはなし ?
● Brutha
○ https://github.com/weavejester/brutha
○ 特に公式サポートはなし

19. おれたちにはcljcがある!

20. UIコンポーネントには、.cljcを使おう
● cljcを使うことでUIコンポーネントがClojure、ClojureScript共通の部品となる
● (js/console.log “HOGE”)とかJS独自の処理を書くと、
コンパイルエラーになるので良い
● コンポーネントにブラウザ独自のロジックなどが入らないように気をつける必要
あり
● ClojureのSSR込みなWebアプリケーションはどうcljcを使うか大事

21. まとめ

22. まとめ
● Om-nextは大いに期待できそうだ
● Reagent / Re-frameはエコシステムによって改善されそうな気がする
● Rumは偉大。 ただ、事例がよくわからなくて未知数感ある