このブログの使用技術（Gatsby.js、TypeScript、Emotion、Contentful）
はじめまして！
このサイト、FE-Designerは、フロントエンドとデザインの狭間で悪戦苦闘しながら仕事をしている筆者が技術的なことや、日々の仕事から得た学びを発信していくブログになる予定です。
このサイト、FE-Designerは、フロントエンドとデザインの狭間で悪戦苦闘しながら仕事をしている筆者が技術的なことや、日々の仕事から得た学びを発信していくブログになる予定です。
初回の本記事では、このブログで使用している主要な技術とその選定理由について説明していきます。
Gatsyby.js
Gatsby.jsは近年人気急上昇中のReactベースフレームワークです。
メリットや良さはたくさんあるのですが、その中で特に気に入っているポイントについてお話しします。
メリットや良さはたくさんあるのですが、その中で特に気に入っているポイントについてお話しします。
ユーザーの体感速度が爆速
WordPressのような動的ページ生成ではなく、MovableTypeのように静的ページを生成するので、ユーザーのリクエストごとの処理が軽く、レスポンスが早くなっています。
また、コンテンツの最適化を自動で実行してくれて、クリティカルな要素（「ファーストビューで必要な要素」的なニュアンスだと思っています）だけを最初に読み込んでくれます。
さらに、GatsbyのLink要素を使えば飛び先の要素をprefetchしてくれるので、２ページ目以降は「あれ？もうページ遷移した？？」というレベルです。
画像の読み込みも最適化してくれていて、ロード直後には非常に小さくした画像をBase64形式で読み込み、大きい画像の読み込み完了後に差し替えてくれます。
画像はページ読み込みのボトルネックになりがちで、読み込み後の画面がガクッとなってしまったりするとCoreWebVitals への悪影響も出やすいところなので、その対応が簡単に出来るのは非常にありがたいですね。
画像はページ読み込みのボトルネックになりがちで、読み込み後の画面がガクッとなってしまったりするとCoreWebVitals への悪影響も出やすいところなので、その対応が簡単に出来るのは非常にありがたいですね。
これらの工夫の多くは、頑張ればフレームワークを使わなくても可能ですが、実際に対応しようと思うと心が折れるものではないでしょうか（自分は確実に折れます）
Reactに慣れていれば学ぶことが少ない
Reactを触ったことがあれば新規に学ぶことは多くありません。
「いつもの感じね〜」と、ストレスなく進めていくことができます。
「いつもの感じね〜」と、ストレスなく進めていくことができます。
他のCMSだとお作法的なことを学ぶ必要があります。
それも慣れてしまえば問題ないのですが、独自な仕様やお作法に手こずる時間はないに越したことはありません。
それも慣れてしまえば問題ないのですが、独自な仕様やお作法に手こずる時間はないに越したことはありません。
ただ、Gatsby.jsの場合でもGraphQLは新規に学ぶ必要がある方も多いかもしれません。GraphQLはFacebookが開発したクエリ言語です。
GraphQLは非常に使い勝手がよく、以下のように「どんなクエリを投げると、どんなデータが返ってくるのか」をパッと確認しながら作業を進めていくことが出来ます。
大手企業での採用が増えるなど非常に伸びている言語でもあるので、この機会に学んでみるのもいいかと思います。
TypeScript
みなさんおなじみTypeScript、新規プロジェクトでは導入するケースが非常に増えていますね。
とはいえ自分のような半分デザイナーのような人種からすると、ハードルの高さもあります。
無限に湧いてくる波線エラーに対応しているだけで時間が過ぎていた、、なんてことも少なくありません。
無限に湧いてくる波線エラーに対応しているだけで時間が過ぎていた、、なんてことも少なくありません。
そんな場合は「エラーを時には無視してもいい」と自分としては思っています。
エラーが残っていることで勉強しようというモチベーションも高まりますし、もし不具合が起きた時にはエラー周辺から調査するための目印として使うことも可能です。
エラーが残っていることで勉強しようというモチベーションも高まりますし、もし不具合が起きた時にはエラー周辺から調査するための目印として使うことも可能です。
TS導入は最初は厄介にも感じますが、自身の成長にもコードの改善にも、そしてコードの情報量増加にも役立ちますので、迷うことなく導入をオススメしたいですね。
Emotion
CSS-in-JSライブラリとしてstyled-componentsの次くらいに人気がある（と思っている）Emotionです。
「そもそもCSS-in-JSを使うべきなのか？」という疑問をお持ちの方も多いと思います。
それに対する自分の回答としては「どちらでも問題ないが、大型サイトや複数人で触るサイトの場合はCSS-in-JSの方が良さそう」です。
それに対する自分の回答としては「どちらでも問題ないが、大型サイトや複数人で触るサイトの場合はCSS-in-JSの方が良さそう」です。
CSS-in-Jのメリットは数多くありますが、自分は以下の２点が大きいと思います。
- コンポーネント単位で名前空間が分割される
- 意図しないところに当たる、がなくなる
- スタイルの使っている/使っていないが100%分かる
- 使っていなさそうだけど消すのが怖いスタイル、がなくなる
この２点はCSS命名規則やファイル管理の工夫で解決することも可能ではありますが、大規模サイトで完璧にやることは非常に難しいです（少なくとも自分はうまくいったケースを見たことはありません）
HTML構造が見辛くなる、コードの補完が効きづらくなる、若干の学習コストがかかるなどのデメリットはありますが、大規模サイトではぜひ導入をオススメしたいです。
では、そのCSS-in-JSの中でどのライブラリを使うのがいいのでしょうか？
自分は特にこだわりがなければEmotionの使用が良いかなと思っています。
自分は特にこだわりがなければEmotionの使用が良いかなと思っています。
比較的後発のライブラリで、他のライブラリに出来ることはだいたいできますし、記法にも癖はありません。
日本ではあまり人気がないのか、日本語のドキュメントが少なめなので、そこが気になる方は一番メジャーなstyled-componentsを選んでおくのも良いかもしれません。
Contentful
ブログ記事のデータ管理にはContentfulを利用しています。
ContentfulはヘッドレスCMSと呼ばれる、表示面の機能のないCMSです（英語の詳細なニュアンスは分かりませんが、ヘッドレス＝顔がない＝表示機能がない、というイメージです）
WordPressなどと違い、表示面を自分で作らないといけませんが、逆にいうと表示面を非常に自由に作ることができるのがメリットです。
サイトの骨組みとコンテンツが明確に分離できるのもいいところだと感じました。
サイトの骨組みとコンテンツが明確に分離できるのもいいところだと感じました。
ヘッドレスCMSにもいろいろなものがありますが、現状では以下の二つのどちらかを選ぶのがいいかなと思います。
- Contentful
- 最もメジャーで人気のあるヘッドレスCMS
- 情報もプラグイン も豊富
- MicroCMS
- 珍しい日本製のCMS
- 資料が日本語で読みやすく、必要なサポートも多分受けやすい
自分はメジャーさを重視してContentfulを選択しました。
まとめ
このサイトで使っている主要な技術の説明は以上です。
Gatsby.js、TypeScript、Emotion、Contentful、、
改めて書いてみるとかなりメジャーなものが多く、独自性がないですね..
改めて書いてみるとかなりメジャーなものが多く、独自性がないですね..
..広く使われているものは良いものが多く、情報も得やすいので間違ってはいないと思いますが、今後は少し尖った技術にもチャレンジしていきたいです。
