コピペコードで快適生活

明日使えるソースを自分のために

サーバサイドとクライアントサイドのJavascriptが混在しているリポジトリ

表題の件の構成について社内チャットで説明したのを、再構成してみました。

ディレクトリ構成

- build
- src
- gulpfile.js
- package.json
- node_modules

buildには、ブラウザが読み込んでいるjs, css, html 一式、
そしてnodeサーバが動かしているjsが入ります。

srcの中に色々と置いてありますが、これはnodejs(サーバサイドjs) やブラウザでは実行できないES6仕様のJSで書かれてて、それを実行できる形に変換して、buildの中に突っ込んでいる感じです。SCSSも同様です。

その辺の変換のロジックはgulpfile.jsに書いてあります。

gulpfile.jsの中でやっているのは
1) sassの場所を見て、cssに変換してbuildに突っ込む
2) es6のjsを見て、js(es5)に変換してbuildに突っ込む
3) その他のファイル(画像とか)をコピーして、buildに突っ込む
4) sassのファイルに変更があったら、1)を実行する
5) es6のjsに変更があったら、2)を実行する
6) 開発用のWebサーバ立ち上げつつ、3)を実行して、4)と5)を常駐させる。
みたいなのです。

そのうち6だけが、npm run スクリプトで動かせるようになっています。
package.json の "start:server": "gulp serve" みたいに書いてあるところです。

npm run start ってやると、gulp serve が実行される。
で、gulp serve が 6) なわけです。

Javascriptの用途

あとjsの用途は基本的に3つあって混同しないように注意が必要です。

1) es6とかsassとかをビルドする用
npm run なんちゃら とかコマンド叩いて動かすやつ。
nodejsで動いています。

2) サーバサイドJS
PHPRailsみたいに、サーバ側で動かすJSです。htmlレンダリングしたりAPIの口になったりします。
build/*の中に入ったjsを nodejsが読み込んで動かしています。

3) クライアントサイドJS
ブラウザで動かすJSです。build/*の中に入っているjsをブラウザが読み込んで実行します。

静的HTML → SPA → SSR+SPA

静的HTMLから、現在の構成までの進化を追っていきましょう。

まず静的ファイルだけで作られたサイトがあります。

そのページ内の一部分だけReactJSとかでで動的に変えたいとなりました。
そのときは 1) と 3) だけでいけますね。

少し進んでシングルページアプリケーションになると、
htmlファイルは1つだけ。
その中でリンク(らしきもの)を踏むと、ページ遷移するかのようにhtmlの内容をjsが書き換えます。
これも 1) と 3) だけで実現できます。

さてここでですね。
URL直だたきでページを表示したときは、普通のwebアプリとして動かしたい。というのがあるとします。
これは、1) と 2) だけでやる感じですね。
でもでも、URL直だたきして、そのあとページ内のリンクをクリックしたときは、シングルページアプリケーションとして、JSでhtmlの内容を書き換えたいとします。
(なんでそんなことしたいかというと、サイト表示のレスポンスあげるためだったり、ページ遷移のUIをイケてる感じにしたかったり、サーバサイドの負荷を下げるためだったりします。)
で、シングルページアプリケーションとしてページ遷移っぽい動きをした時に アドレスバーの URL を書き換えちゃいます。
で、その書き換わったURLに直にアクセスすると、今度はサーバサイドのjsがページをレンダリングして、ブラウザに表示させます。
この仕組を作るために 1), 2), 3) の 3つが必要になってくるんです。

で、そこでふと気づくんです。
2) と 3) でプログラムが重複しない?っと。
同じhtmlレンダリングするのに、クライアント用とサーバサイド用でそれぞれ必要になっちゃうじゃないですか。

そこで Reactの出番なわけです。実は ReactってサーバサイドJSでも使えるんですよ。
srcに入っている React のコンポーネントって、
1) の JSによって、
2) 用と 3) 用にそれぞれビルドされるんですよ。

ルーティングも同様ですね。
どのURLで、どのコンポーネントを使うかは
サーバサイド、クライアントサイドで同じjsから情報を取得しています。

という感じです。