create-react-appを使ったReactアプリの作り方とNext.jsへの期待
Reactでアプリケーションを作る場合「create-react-app」を利用することで、簡単に環境を用意することができるのでオススメです。
今回は「create-react-app」に関する説明と使い方、さらにこれから使ってみようと考えている「Next.js」についての情報を書きます。
Reactを使ってSPAを作ってみたいという人にぜひ読んでほしいです。create-react-appを使って得た経験から、簡単にできること、逆に出来ないことを紹介します。
その上でこれから時間を見つけてNext.jsを使ってみようと考えています。そのことへの期待も書いておきます。実際に使ってみた感想はまた今度書く予定です。
create-react-app
https://github.com/facebook/create-react-app
Reactを開発しているFacebookが公式に用意している、コマンドツールです。 ReactやJSXを利用するためにはいくつかの依存するツールが必要なのですが、それらを1コマンドで用意してくれるものです。
とても簡単なので勉強とかに利用するのであればオススメです。
使ってみる
npmなら以下のコマンドでインストールした後
npm install create-react-app
以下のコマンドを実行することで、「my-app」という名前でディレクトリ構成が作成されます。
npm init react-app my-app
Reactを動かすのに必要なものが一式揃っており、babelとかWebpackとかを自前で用意しなくても良いです。 package.jsonの用意や運用管理はややこしくなりがちですので、任せることができるとスムーズに出来て良いです。
開発時にローカルで動作を確認することも簡単に出来ます。必要な設定は自動で作成されます。
npm start
静的ファイルとしてのビルドも出来ます。こちらも必要最低限の設定は自動でされているので、すぐに試すことが出来ます。
npm run build
/build
ディレクトリに出力されたファイルをサーバにデプロイすれば公開です。簡単ですね。Netlifyとかならホスティングサービス側でビルドすることもできるので、とても便利です。
SPAを構築するなら十分
とりあえずSPAを作る上で最低限のものは入っています。簡単なSPAやReactの勉強に使うのであれば十分な内容になってます。依存関係なんかも用意してくれるので、とても便利。
避けたほうがいい場合
- バックエンドのフレームワークと合わせて利用したい場合はもっと柔軟なものを利用したほうがいいそうです。RailsやDjangoとかでサーバサイドを実装する場合ですね。SPAで作る必要がない場合も、特に利用する必要はなさそうです。
- SSRを実装したい場合はNext.jsなどの利用が推薦されています。create-react-appはあくまでも静的なJS・HTML・CSSを用意するだけになっており、そのことでバックエンドの心配をなくしました。
- ブログなどのコンテンツであれば、Gatsbyの利用を進められています。このブログもGatsbyで生成しています。動的に要素が変わるとかユーザーが投稿するとかであれば無理ですが、管理人が更新するだけのブログなのでGatsbyで大丈夫ということです。
- もっとカスタマイズしたい場合は「Neutrino」を参考に上げています。これについてはよくわかってません。時間があったら使ってみます。
SEOのことを考えるとSSRしたい
SPAの弱点だと思うので仕方無いとも思いますが、できるならSSRを実装したいです。 OGPやSEO関連の懸念が払拭できればとても便利なのですが。
create-react-appではSSRについてのフォローはありません。公式Githubに書いてあるとおりNext.jsなどのフレームワークを利用するのがオススメらしいので、ちょっと調べてみました。
Next.js
Next.jsとは
Reactを使ったフレームワークです。 純粋なReactだけでは実装が難しかったことについて、いくつか簡単に実装できるようになります。 上記にも書きましたがSSRを実装したいという場合に、Next.jsの使用を推奨されています。ですのでSSRに対してどのくらい便利なのかという期待をもっています。
ちなみにVue.jsのフレームワークはNuxt.jsです。名前が似ているのはNext.jsを参考に作られたからだそうです。ややこしいのでやめてほしいですが仕方ないですね。
できること
Next.jsを使うことで以下のことが簡単にできるそうです。
-
ファイルのディレクトリ構造によるルーティング
ルーティングのルールをディレクトリ構造で指定できるということです。ややこしいですが、pagesディレクトリ以下に設置したファイル構造がそのままURLの定義として反映されるみたいなことです。
-
import の最適化
宣言したimport文が解釈され、必要なページに配信されるようになるようです。不要なimportとかが解決されるので便利だとは思います。
-
Server Side Rendering
SSRも簡単に実装できるようです。サーバ側でnode.jsを動かす必要があがます。となるとNetlifyやFirebaseでは実現できなさそうです。
-
Static Exporting
静的なコンテンツとしてエクスポート出来ます。これを使ってエクスポートしたページを設置すれば、SSRを実現できるという考え方がある?様子です。それはSSRなのか?とは思いましたが、SEOとかOGPとかは確かに意図したものにできそうなので、良しとしましょう。よく考えればGatsbyはこれに該当するものですね。
SSRについて
というわけで、Next.jsでSSRを実装する場合、サーバ側にNode.jsを立ち上げて動かす・または静的なHTMLとしてサイトをエクスポートして設置するの2パターンあるようです。
FirebaseやNetlifyではサーバ上でnode.jsを動かしてリクエストに答えるのは難しいので、後者の手段になります。 まあサーバーレスをイメージしたサービスかと思いますので、SSRを実現しようとすることはそもそも矛盾しているのかもしれません。静的コンテンツをCDNで配信するくらいで実現できる要件に抑えることのが大切に思います。
Node.js動かすサーバがあるなら、最初からrailsとかLaravelとかでサイトを実装しそうですがどうなんでしょうか。やっぱりSPAとかサーバレスな環境では、SEOなどの問題は大きく残っている印象です。
サーバレスでさくっと作る! → SEO観点からSSRをしたい → サーバが必要!
というような流れになる気がします。それなら最初からサーバサイドをPHPやRubyで作るところから始めるよな。と思いました。
思い切ってSSRを諦めるという決断が必要なのかもしれません。もしかすると。
おわりに
create-react-appはとても簡単で便利です。ただし、SPAなこともありOGPやSEO関連の要素については実装が難しいです。それが許容できる簡単なWebサービスを作る、サーバレスなアプケーションを作るということであれば十分です。
SSRを実装しようとした場合はNext.jsなどを利用する必要があります。結局rubyやphpをサーバに入れてバックエンドを作った方がいいような気もします。どうなんでしょうか。どういう場合に選択されるのかイマイチわからないままです。
静的要素としてExportするなどSSRの実装方法はいくつか方法がありました。静的なコンテンツとしてSSRを実現することができるので、その点で差異はあるとも思います。
何より全部jsで作るというのが嬉しいことなのかもしれません。 動的なサイトか静的なサイトかの要件が変わってしまった場合でも柔軟に対応できる、と公式にも書いてありました。そんなことあるのか?と思いますけど。