開発関連技術 | Change Of Pace

ポートフォリオサイトをTanStack Startでリプレースしたので振り返ってみよう

Mon, 23 Feb 2026 00:00:00 GMT

前からリプレースしたいと言っていたポートフォリオサイトをようやくリプレースできたので、振り返りや感想などを軽くつぶやいてみます。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

{/*  */}

ポートフォリオサイトの履歴

ざっとポートフォリオサイトの履歴を振り返ってみます。

起源

はじめてポートフォリオサイトを作ったのが2020年頃。

当時、日々の勉強メモを記録する TIL リポジトリを更新していっており、その派生でポートフォリオサイトを作ったのでした。採用していた Docusaurus だとドキュメントを書くのに適していたため、TIL の記録をドキュメントのように公開してみようと思っていたのです。そうすれば勉強の状況も他者に示せたりするかなぁと考えたこともあり。

TIL の移行

TIL 活動を続けているうちに、だんだんと Notion で書いていった方が気軽に書きやすいのでは？という考えが浮かび。リポジトリで管理となるとどうしても都度コミットする必要があるので、その手間がだんだんと気になってきたのでした。

それもあって、ポートフォリオサイトからは TIL の記録を公開するのはやめていました。ちなみに現在は Obsidian で記録を書いていくようにしています。

リプレースへ

TIL の記録を公開するのをやめたことで Docusaurus を採用した意味がなくなってしまったな...と感じるようになりました。また、サイトのテーマは既存のものを使っていたこともあり、なんだかオリジナリティというか面白味も特にないなぁと。

ブログも独自デザインでリプレースしたこともあり、ポートフォリオサイトもいずれリプレースしたいと思うようになっていました。どうも 2024年振り返り～技術活動、ブログ、キャリア編～の頃にはすでにそう思っていたようです。

リプレースしたもの

レイアウト比較

大まかなレイアウト比較として、トップページとスキルページを載せてみます。

ページ構成自体はそれほど変えていないので真新しさはないですが、リプレース前より少しすっきりしたような気がしています。

デスクトップ

トップページ. <div class="layout-fixed">

Docusaurus（リプレース前）	TanStack Start（リプレース後）
<ImageWrapper src="screenshots/2026/portfolio-replace-tanstack/portfolio-docusaurus-desktop.png" alt="ポートフォリオリプレース前のトップページ - デスクトップ" />	<ImageWrapper src="screenshots/2026/portfolio-replace-tanstack/portfolio-tanstack-desktop.png" alt="ポートフォリオリプレース後のトップページ - デスクトップ" />

</div>

スキルページ. （リプレース前は経歴も載せていましたが、全公開するのはやめたのでスクショも経歴の前までにしてます。本来はフッターまであります） <div class="layout-fixed">

Docusaurus（リプレース前）	TanStack Start（リプレース後）
<ImageWrapper src="screenshots/2026/portfolio-replace-tanstack/portfolio-skill-docusaurus-desktop.png" alt="ポートフォリオリプレース前のスキルページ - デスクトップ" />	<ImageWrapper src="screenshots/2026/portfolio-replace-tanstack/portfolio-skill-tanstack-desktop.png" alt="ポートフォリオリプレース後のスキルページ - デスクトップ" />

</div>

モバイル

トップページ. <div class="layout-fixed">

Docusaurus（リプレース前）	TanStack Start（リプレース後）
<ImageWrapper src="screenshots/2026/portfolio-replace-tanstack/portfolio-docusaurus-mobile.png" alt="ポートフォリオリプレース前のトップページ - モバイル" />	<ImageWrapper src="screenshots/2026/portfolio-replace-tanstack/portfolio-tanstack-mobile.png" alt="ポートフォリオリプレース後のトップページ - モバイル" />

</div>

Docusaurus（リプレース前）	TanStack Start（リプレース後）
<ImageWrapper src="screenshots/2026/portfolio-replace-tanstack/portfolio-skill-docusaurus-mobile.png" alt="ポートフォリオリプレース前のトップページ - モバイル" />	<ImageWrapper src="screenshots/2026/portfolio-replace-tanstack/portfolio-skill-tanstack-mobile.png" alt="ポートフォリオリプレース後のトップページ - モバイル" />

</div>

リプレースで採用してみた主な技術

TanStack Start

主となるフレームワークに選定したのは TanStack Start。 <OG url="https://tanstack.com/start/latest" />

{/*  */}

Full-stack Framework powered by TanStack Router for React and Solid

Full-document SSR, Streaming, Server Functions, bundling and more, powered by TanStack Router and Vite - Ready to deploy to your favorite hosting provider.

{/*  */}

TanStack シリーズでいろんなパッケージが提供されているうち、React, TanStack Router ベースで作られているフルスタックフレームワークです。

ブログリプレースの時と同様に、ポートフォリオサイトも最初は Next.js でリプレースしようかと思い、実際に Next.js で着手していたのですが...。 Next.js だとややオーバースペック気味に感じていたのと、メジャーすぎてなんだか面白みがないなになり。

TanStack Start は比較的新しい技術なことと、React ベースなのでとっきやすいこと。SSG もできるらしいということで、今回初めて触って採用してみたのでした。まぁ、仕事だったらこんな技術選定すると怒られそうではありますが、個人開発なので自由が利くということで。

Tailwind CSS

スタイリングは Tailwind CSS を採用しました。 TanStack Start のテンプレで採用されていた流れで採用しましたね。

CSS in JS を久しぶりに書くことも考えたのですが、サッと作りやすいというと Tailwind CSS の方があるかなぁと。（そもそも TanStack Start で CSS in JS って動くのかな？）普段、仕事でよく書いていることもあり、なじみ深いです。

デザインは本ブログのリプレース時と同様に、結局作りながら雰囲気で構築していきました。モノクロ基調にしたいというのはあったので、そこから膨らませた感じでしたね。 Tailwind だとこういう雰囲気でスタイルガチャガチャするのも少し楽な気がしています。

React Bits

これは技術というかコンポーネント集ですね。 React をベースとして、アニメーションが設定されているコンポーネントが Shadcn や jsrepo 経由で提供されているものです。 Tailwind CSS 版のコードが提供されていることもちょうどよかったですね。

アニメーションは入れすぎるとくどい印象を与えるため、扱いが少し難しいものではありますが、せっかくリプレースするので遊び心的な観点で少し入れてみたいなと思ったのでした。現時点では以下の3つを採用しています。

Text Type
Circular Text
Fade Content

リプレースした感想など

今年入ってからリプレース着手しまして、主に週末細々と進めていました。かかった時間としてはざっくり30時間ほど。ブログの時は150時間くらいかかっていたので、それと比べればぱっと作れた方でしょうか（記事データの移行がないからそれはそう）

シンプルな構成ではあるので TanStack Start の機能をそれほど使えてはいませんが...。公式で Next.js からの移行ガイドが用意されていて、それを見た感じ必要十分な機能はある程度そろっているような印象を受けましたね。今後は TanStack Start の採用事例の話も流れてきたりするんだろうか。

ちなみに今回 AI は使いませんでした。小規模で使うまでもなかったというか、自分でガチャガチャしながら作りたかったので使わなかったです。

前からリプレースしたいな～と思っていたので、ようやくリプレース出来てよかったです。

元々は年を越すタイミングでリリースできたらと考えていました。着手がずれこんでしまいましたが、とりあえず無事にリリースまでいけたので一安心しています。

今度はポートフォリオの内容が充実できるよう、何か作ったり、技術の知識を深めたりしていきたいですね。

参考リンクまとめ

2025年振り返り～技術活動、ブログ、キャリア編～

Tue, 30 Dec 2025 00:00:00 GMT

{/*  */}

年末恒例の振り返りのうち、技術活動、ブログ、キャリア編やっていきます～。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

2025年の活動履歴

コミット履歴

今年の Git の Contributions 履歴から。

GitHub

今年は1279でした。

このアカウントを使った活動は個人活動のみでしたね。ほぼ土日メインの活動だったかなと思います。色がついている日こそ少ないですが、1日あたりの履歴数がそこそこあったみたいです。

案件 - GitHub

個人アカウントとは別アカウントの活動になるため、別途記載しています。

今年は1417でした。

平日はほぼ毎日何かしらコード書いてたと思うので、積み重ねでこれくらいになったようです。

例年と比較するとこんな感じ。

	2025	2024	2023	2022	2021	2020	2019
GitLab	0	0	0	0	0	0	?
GitHub(個人)	1,279	858	1,712	657	2,169	920	231
GitHub(仕事)	0	19	82	199	0	541	76
GitLab(案件)	0	179	1,699	1,448	-	-	-
GitHub(案件)	1,417	1,707	124	-	-	-	-
合計	2,696	2,763	3,617	2,304	2,169	1,461	307 + ?

昨年と比べるとビミョーに減っていたようです。個人活動は増えていたようですが、案件活動が少し減っていました。

ブログ

アクセス履歴

今年の履歴はこんな感じです。例年通り、Google Analytics のデータ部分のみ抜粋。（12月に関しては、執筆時点でのものです）

月	記事数	月のアクセスユーザ数	月のページビュー数
1月	93	142	216
2月	93	187	250
3月	93	242	294
4月	93	165	223
5月	93	164	214
6月	93	252	292
7月	93	175	202
8月	93	196	223
9月	93	188	234
10月	93	234	281
11月	95	269	329
12月	97	217	253

アクセスユーザ数計：2,431
ページビュー数計：3,011

昨年との比較.

アクセスユーザ数：2,868 -> 437減
ページビュー数：4,006 -> 995減

昨年からさらに記事書けなかったこともあり、今年もまぁ減るよね...という感じでした。

記事執筆について

さらに全然書けてないですね...。脱・資料まとめの人ならず。

今年投稿した記事.

Developers Summit 2025 公開資料・Xアカウントリンクまとめ
JSConf JP 2025 公開資料・Xアカウントリンクまとめ
Windows + Git Bash環境でmiseとSafe Chainを共存させる
2025年振り返り〜精神疾患との生活編〜
2025年振り返り～技術活動、ブログ、キャリア編～ ※当記事

ブログ以外の記事執筆活動

※Zenn に投稿した記事は、基本的には当ブログでも投稿しています。

ブログ + Zenn で活動しているのは継続中。当ブログ関連以外の記事はクロス投稿しているのは変わりません。

今年 Zenn からいただいた振り返りはこんな感じでした。（12/24までのもの） <ImageWrapper className="w-[70%]" src="screenshots/2025/looking-back-2025-tech/zenn-recap.png" alt="Zenn 2025 Recap - 2025年の活動振り返りデータ - 29,923字の執筆、3記事、23,175ビュー、58Likes" />

個人開発

新規活動は特になしでした。

引き続き、ブログや過去に作ったもののメンテナンスをしていたくらいです。脆弱性対応のためのアプデとか。

個人勉強

フロントエンド

前半に devChallenges の課題を少しこなした程度ですね。 Front-end 編の課題をやる気でいたものの、結局着手できなかったな🙄 App Router の試し書きをしたかったやつ。（仕事では普段書いてますが）

バックエンド

今年は書く機会がなかったですね。書くとしたら Hono で書くような気はします。

資格試験

結局、昨年の振り返りで言っていた HTML プロフェッショナルレベル2は受験できてないです。

ただ、会社の都合で TOEIC を受験しに行きました。とりあえずスコアの登録するためというので、ほとんど勉強できずで受験したのでひどいスコアでしたが...😇 試験自体はちょっと面白かったので、ちゃんと勉強して再チャレンジしたいところ。

イベント参加

今年参加したイベントはこちら。オンライン参加のみです。

※資料まとめのみ <OG url="https://event.shoeisha.jp/devsumi/20250717" /> <OG url="https://jsconf.jp/2025/ja" />

オンライン視聴参加 <OG url="https://findy-tools.connpass.com/event/347251/" />

習慣づいてないからか、全然参加できなかったですね。業後はゆっくりしたいな...という思いが先行してしまう問題。

リードエンジニア的な立ち回り・キャリア

今年は特に目立った大きな成果がなかったような。

案件でのチーム開発や調整が多い対応などは引き続きこなしていましたが、いつもの業務という感じです。

2026年はどうしていきたいか

ブログ・技術記事

ブログ自体のメンテナンスは引き続き行うとして、記事執筆が問題ですね。なかなか昔のペースに戻せない問題。

今年の mise の記事を書いたときは、記事にするモチベが湧いて書いてたのでそういうモチベが戻ってくれるといいのですが。小ネタ記事からでいいのでリハビリしたいところ。

個人開発

ポートフォリオサイトのリプレースをいい加減やりたいですね。 Next.js(App Router) でのリプレースを考えていたものの、静的サイトで使うにはオーバースペックな気もするので、他の技術を使うかな～と考えています。

個人勉強

フロントエンド

devChallenges の課題の Front-end Developer 編やあるいは他の個人活動で何か作りたいですね。

今年は npm にランサムウェアの攻撃があったり、React, Next.js に深刻な脆弱性が見つかったりなど色々波乱だったこともあり、脆弱性にも気を付けておきたいところ。

バックエンド

そろそろ Hono 使ってみたいですね。 Kotlin を書く機会もあると良さそうですが、気軽に試せそうなのって Kotlin のフレームワークよりは Hono かなぁと。

ドキュメント活動

いい加減、DocDD を試さねば。新しい仕事の環境で何か関われる機会があるといいのですが。

資格試験

今年もテクニカルライティング試験の教本の第4版出なかったなぁ...。出版されるのを待っていたのですが、いい加減第3版で勉強して受験した方がいいかも？

それと情報処理試験が CBT 形式に変わることで、受験しやすくなるようなので、チャレンジするのもありですね。いつも会場が遠くて起床試験が大変だったのです...。応用情報のリベンジするかなぁ。

それ以外でチャレンジするとしたら、HTML プロフェッショナルレベル2や期限が切れてしまった AWS SAA の更新もしくは SAP かなと思います。

イベント参加

フロントエンド、ドキュメント系はできれば参加したいところです。業後に参加するモチベが湧くかがちょっと微妙なところですが...。

リードエンジニア的な立ち回り・キャリア

来年は仕事の環境の変化が本格的に始まるので、それ次第なところがあります。変わった先で求められるレベル感にうまく適応できるといいのですが、どうなるかがちょっと読めないですね。

以上、今年の技術活動、ブログ、キャリア編の振り返りでした。

年々書くことが抽象的でふわっとしている気がする...。精神疾患との生活編でも書いたのですが、環境の変化に伴い来年はどうなるのか読めないところがあるので、プラスに働いてくれるといいなと思うばかりです。

皆様よいお年をお迎えください～。

{/*  */}

Windows + Git Bash環境でmiseとSafe Chainを共存させる

Sun, 30 Nov 2025 00:00:00 GMT

めちゃ久しぶりの小ネタ記事です。

import OG from "@/components/OG.astro"

背景

筆者の個人の開発では Windows + Git Bash 環境を使っています。 Node.js のバージョン管理ではしばらく Volta を使っていました。

この Volta をより汎用性の高い mise に移行したかったのですが、Safe Chain と共存させるのに少しだけ工夫が必要だったので、備忘録として残しておきます。

mise は言語や CLI ツールのバージョン管理、環境変数やタスク管理の機能を提供するツールです。 <OG url="https://github.com/jdx/mise" />

Safe Chain は、マルウェアに汚染されているパッケージをブロックしてくれるツールで、最近流行っている Shai Hulud による攻撃に対する防御策の1つです。 <OG url="https://github.com/AikidoSec/safe-chain" />

詳細は各公式情報を参照してください。

環境のつくり方

mise のインストール

mise の公式ドキュメントにもある通り、winget での導入に対応しています。

winget install jdx.mise

winget で導入した場合は、パスを通す部分も自動で行ってくれるので楽ちんですね。

Node.js のインストール

mise 経由で任意のバージョンの Node.js をインストールして、とりあえずグローバル使用設定にしておきます。

mise install node@24.11.1
mise use --global node@24.11.1

Safe Chain のインストール

mise 経由で Safe Chain を導入します。

mise exec node -- npm install -g @aikidosec/safe-chain
mise exec node -- safe-chain setup

この後にターミナルを再起動することで、Safe Chain が使えるようになるのですが... 以下の動作確認用パッケージをインストールしようとしても、ブロックしてくれず🙄

mise exec node -- npm install safe-chain-test

また、nodeやnpmコマンドを使うにあたり、毎回mise exec nodeを書くのがめんどくさいという課題もありました。 Volta では直接nodeやnpmコマンドを使っても、カレントディレクトリにおける設定バージョンを自動的に適用してくれていたため、これを mise でもやりたかったのです。

エイリアスの活用

mise 経由でインストールした Safe Chain のマルウェア検知がうまく動作しない
mise でバージョン管理しているnodeやnpmコマンドを実行するには、mise exec nodeをつける必要がある

この2つの課題に対して、筆者の場合はエイリアスで解決しました。

Bash の環境で読み込まれるファイルにエイリアスを設定しておきます。筆者の場合は、エイリアス用の別ファイルを用意して、それを.bashrcから読み込むようにしました。

# mise
# 本来は mise activate を実行すれば、直接 node や npm コマンドが実行できるようになるが
# Windows + Git Bash で mise activate すると git や vi などの PATH が通らなくなってしまう。
# 環境変数の PATH に <homedir>\AppData\Local\mise\shims 通すことでも直接 node, npm コマンドが使えるようになるが、
# Safe Chain がうまく動作してくれないため、エイリアスで対応する。
if command -v mise >/dev/null 2>&1; then
  alias node='mise exec node -- node'
  alias npm='mise exec node -- aikido-npm'
fi

if [ -f ~/.bash_aliases ]; then
  . ~/.bash_aliases
fi

これで直接nodeやnpmコマンドを書いても、実質的には mise を通したコマンド実行をしてくれるのでいい感じになりました。 npmの方はaikido-npmにしているのがポイントです。これは通常のnpmコマンドではなく、Safe Chain が提供しているnpmコマンドのラッパーにあたるものとなるため、Safe Chain が動作してくれるようになりました。今回はnpmコマンドのみの対応ですが、他のパッケージマネージャーのコマンドでも同様にエイリアスで対応できそうです（筆者は未確認です）

ちなみに直接nodeやnpmコマンドを書けるようにする方法として、mise の公式ドキュメントに記載があった方法も試しました。しかし、筆者の環境では2つの課題の解決ができなかったため、今回の方法をとりました。

その1：.bashrcにmise activate bashを実行する処理を記載しておく方法 -> vi や git などほかのコマンドのパスが通らなくなってしまった。

{/*  */}

その2：Windows の環境変数の PATH に<homedir>\AppData\Local\mise\shimsを追加する -> 直接nodeやnpmコマンドを実行できるようにはなったが、Safe Chain のマルウェア検知がうまく動作しなかった。ただし、もし Git Hook で任意の npm パッケージを動作させたい時は、この PATH 追加が必要なようだった（セキュリティ的には Lifecycle Scripts の取り扱いは要注意...！）

{/*  */}

Safe Chain のマルウェア検知の動作確認

マルウェア検知の動作確認用のパッケージをインストールしようとして、ブロックされていれば Safe Chain が動作しています。

> npm install safe-chain-test
✖ Safe-chain: Malicious changes detected:
 - safe-chain-test@0.0.1-security

Safe-chain: Exiting without installing malicious packages.

他にもよりよい方法はあるかもですが、とりあえず mise と Safe Chain の共存ができたので満足してます。 Shai Hulud による攻撃怖いですしね...。皆様もご安全に開発を～。

2024年振り返り～技術活動、ブログ、キャリア編～

Tue, 31 Dec 2024 00:00:00 GMT

{/*  */}

一人暮らし後、初めての年末年始を迎える、よしです。年末恒例の振り返りのうち、技術活動、ブログ、キャリア編やっていきます～。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

2024年の活動履歴

コミット履歴

恒例の Git の Contributions 履歴から。

GitHub

今年は 858（個人） + 19（案件外の仕事） = 877 でした。

個人活動としては、devChallenges の課題をいくつかこなしたくらいだったかな。ほぼ土日メインの活動でした。

（案件外の）仕事は、業務改善活動で作った Bot のメンテナンスを少しだけやった程度だったため少な目。

案件 - GitLab・GitHub

参加している案件では、セルフホスティングの GitLab, GitHub が共存しているため、両方載せておきます。

あくまで今のメインは GitHub 側を使っているため、ほとんど contributions 数がないですね。手動で数えたところ 179 contributions で、一番濃いところは 30 contributions でした。

GitHub の方は、ほとんどの日はコード書いてたので、平日はほぼ履歴がありますね。

合わせると、案件活動としては 179 + 1707 = 1886 でした。

例年と比較するとこんな感じ。

	2024	2023	2022	2021	2020	2019
GitLab	0	0	0	0	0	?
GitHub(個人)	858	1,712	657	2,169	920	231
GitHub(仕事)	19	82	199	0	541	76
GitLab(案件)	179	1,699	1,448	-	-	-
GitHub(案件)	1,707	124	-	-	-	-
合計	2,763	3,617	2,304	2,169	1,461	307 + ?

うーん、昨年と比べ活動量減りましたねぇ。 2022年よりは多いものの、個人活動の減少が響いていたようです。

ブログ

アクセス履歴

今年の履歴はこんな感じです。例年通り、Google Analytics のデータ部分のみ抜粋。（12月に関しては、執筆時点でのものです）

月	記事数	月のアクセスユーザ数	月のページビュー数
1月	87	250	317
2月	88	837	999
3月	89	337	542
4月	89	279	408
5月	89	218	266
6月	89	220	266
7月	89	106	134
8月	90	（計測できていない）	（計測できていない）
9月	90	113	182
10月	90	158	209
11月	91	159	201
12月	93	181	218

アクセスユーザ数計：2,858
ページビュー数計：3,742

昨年との比較.

アクセスユーザ数：3,358 -> 500減
ページビュー数：5,683 -> 1,941減

今年は全然記事書けてなかったこともあり、まぁ減るよね...という。それと GA4 での計測が正しく行えてない時もあったのでした。

2月にポーランドからのアクセスが謎に急増するという現象があり。どうもこの時期、同じ現象に遭遇した方が多数見られて不正アクセスのようでした。以下の記事を参考に WAF で IP 制限を入れて対処したのが効いたのか、一応アクセスは収まってくれたようです。 <OG url="https://note.com/taiwanwalking/n/naa162cfd47f2" />

7/16～9/7 のあたりでは、GA4 が謎に計測できてない現象が起きていました。その頃にライブラリのアプデ等はしていなかったこともあり、気づくのが遅れてしまったやつ...。もしかしたら、7月に UA が完全に廃止になった影響かもしれません。 GA4 の設定が出来ているように見えて、実は不完全なところがあり。UA 経由で計測できていただけで、UA 完全廃止に伴い計測不調がおきたみたいな。（でも、UA の計測自体は昨年の7月に停止しているはずなので、それも違うのかな...？）

記事執筆について

今年は全然記事書けてなかったですね...。ほぼ資料まとめの人になってしまっていた🙄

今年投稿した記事.

Developers Summit 2024 公開資料・Xアカウントリンクまとめ
HTML5プロフェッショナル認定試験レベル1受験レポート記事が、freelance hubで紹介されました
フロントエンドカンファレンス北海道 2024 公開資料・Xアカウントリンクまとめ
JSConf JP 2024 公開資料・Xアカウントリンクまとめ
2024年振り返り〜精神疾患との生活編〜
2024年振り返り～技術活動、ブログ、キャリア編～ ※当記事

昨年もこのままでは資料まとめの人になってまう...と嘆いていたのに、そうなってしまっているや～ん。

ただ、3月に過去記事が freelance hub 様で紹介されるという希少な体験もしたりしていました。技術記事の執筆活動復活したら、またそういう機会があったりするんだろうか...？

ブログ以外の記事執筆活動

※Zenn および Qiita に投稿した記事は、基本的には当ブログでも投稿しています。

ブログ + Zenn で活動しているのは継続中。当ブログ関連以外の記事はクロス投稿していました。

今年 Zenn からいただいた振り返りはこんな感じでした。（12/22までのものです）

Qiita, ~note~ は今年活動なしです。

※2025/09/15...note のリンクは除去しました。

個人開発

今年も新規活動は特になし。

ブログをメンテナンスしていたくらいでした。 Astro の画像最適化に対応するとかもやってましたね。

個人勉強

フロントエンド

昨年、React と Next.js の最新バージョンのキャッチアップしなきゃと言っていた気がしますが...。今年は React 19, Next.js 15 まで来ましたね。やべー追いつけてねぇよぉ...になってます😇

まぁ、案件では Next.js の App Router 使っているので自然と触れる機会は増えてはいます。ただ、個人で使うまでには至ってない状態ですね。

React 19 も uhyo さんの本をチームで読み合わせたりしつつも、実際に書く機会がまだなくて慣れていない感じ。 <OG url="https://zenn.dev/uhyo/books/react-19-new" />

あとは過去に作った devChallenges の課題メンテナンス + 新規課題をいくつかこなしました。

バックエンド

案件で Kotlin を書く機会は今年もほとんどなかったですね。昨年使ってみたいと言っていた Hono も結局使えてなかったな...。

資格試験

昨年少し勉強していた HTML プロフェッショナルレベル2の試験は結局受けてなかったです。

TIL 活動

技術メモの Notion から Obsidian に移行は一段落ついていたものの、まだそこまで活用できてないかな。

イベント参加

今年参加したイベントはこちら。オンライン参加のみです。

※資料まとめのみ <OG url="https://event.shoeisha.jp/devsumi/20240215" /> <OG url="https://www.frontend-conf.jp/2024" /> <OG url="https://jsconf.jp/2024/" />

オンライン視聴参加 <OG url="https://tw-meetup.connpass.com/event/306213/" /> <OG url="https://findy.connpass.com/event/306774/" /> <OG url="https://tw-meetup.connpass.com/event/309169/"/> <OG url="https://offers.connpass.com/event/310086/" /> <OG url="https://findy.connpass.com/event/318090/" /> <OG url="https://tw-meetup.connpass.com/event/320894/" />

今年前半止まりで後半は参加できてないなぁ。ドキュメント周りにも関心があることもあり、ドキュメント系のイベントも参加していました。

リードエンジニア的な立ち回り・キャリア

年始から、案件で先方エンジニアチームに1人で先行して合流・キャッチアップし、他メンバー合流の橋渡しをする。という役割を担っていました。他のタスクとの優先度の関係で、3月にはその役割を離れることにはなってしまったのですが、ドキュメントに書いていた情報が他メンバー合流時に役に立ったとの声をもらうことができました。

なお、今回は既存案件内の別プロジェクトという感じだったので、ドメイン知識等は備えている状態ではありました。新規契約の案件で、リードが先行して入ってキャッチアップして他メンバーとの橋渡しをする。というのはリードの仕事でよくあると思いますし、今後そういう機会があった時に活かせるといいなと。

その他は、案件内の GraphQL - Fragment Colocation から派生した設計をチームで協力しながら進めたことがありました。アプリケーション全体に影響する設計だったこともあり、結構時間かけて悩んだ記憶。こういうのも自らすすんでこなせていけると強いんだろうなぁ。

2025年はどうしていきたいか

ブログ・技術記事

来年は1年で12記事書けるといいなぁ。もしくは、12記事までいかなかったとして、技術の話的な記事をまた書けるようにしたいところ。資料まとめの記事は多分まだ続けると思います。

ブログ自体のメンテナンスも合間見てやっていきます。今も Astro 5系へのアプデがまだなので、近々やらねば。

個人開発

ポートフォリオサイトの Next.js(App Router) リプレースを進めるかも？デザインどうしようかな...があるんで、結局実作業は進まない気もしつつ、まぁいずれはやりたいということで。

個人勉強

フロントエンド

案件で React 19, Next.js 15 アプデの話が出ているので、新しい機能も使える機会ありそうな気がしています。ただ、やはり個人でも素振りはしておきたいですねー。

進めていた devChallenges の課題で、次の Front-end Developer 編からはフロントエンドのフレームワークが使用可能になるため、そこで素振りしようかなと考えています。旧課題のメンテナンスで Next.js の Pages Router から App Router 移行も考えたものの、使用していた emotion 移行が少し大変そうだったので新課題でやろうかなと。スタイリング系のライブラリも新しめのやつ使ってみたい。

バックエンド

何かの機会に Hono を使ってみたいところ。そういえば、Next.js の Route Handlers を Hono に差し替えるみたいな面白い記事を見かけたので、これをちょっとやってみたい気もしました。 <OG url="https://zenn.dev/chot/articles/e109287414eb8c" />

ドキュメント活動

元々、自分が関心を持っている領域なのと。弊社内で代表自ら DocDD（ドキュメント駆動開発）を浸透させるという流れができているので、そこに何かしら関わっていけるといいのかなぁと漠然と考えていたりします。（ちなみに社内のフロントエンド職能グループ内で、ドキュメント整備・管理の役割のチームにも所属していたりします）

その過程で AI との関わり方も変わってきそう。

資格試験

HTML プロフェッショナルレベル2、いい加減挑戦するかなぁ。

あとテクニカルライティング試験も気になっているのですが、公式の教本の第4版が出そうで出ないという状態で、教本買うタイミングを悩んでいます。来年には出版されてほしいなぁ。 <OG url="https://jtca.org/learn-tc/certificate-exam/writing_b/" />

TIL 活動

Obsidian のナレッジベース構築ガシガシ進めたい。自分はテキストに起こして情報を整理して理解するタイプなので、Obsidian に書いていったら自然と良い方向に行きそうな気がします...！

イベント参加

引き続き、無理のない範囲でフロントエンド、ドキュメント、決済系のイベントは参加してみようかなと。でも、優先度としては前者2つが高いですね。

リードエンジニア的な立ち回り・キャリア

精神疾患との生活編でも以下のように書いていました。

{/*  */}

仕事面では、来年何か変化の起こりそうな気がしています。案件が1つの佳境を迎えるのと、案件外の新しい仕事にチャレンジすることがありまして。

それと占い的な話で、来年の運勢は「目立つポジションやリーダー的な立場といった、これまで避けてきた仕事を任されることがあるが、毛嫌いして断るな。」「苦手な分野で周囲から指摘されることがあるが、これまでその分野をやってこなかったツケを払う時がきたと思え。」的なことが書いてあったので、なんかそういう変化があるんだろうなぁと漠然に思っているのもあります。

{/*  */}

何かしら変化は起きるのかなと。変化に振り回されてあーだこーだ言ってる未来も予想されますが、可能な範囲で迎え撃って、自分の糧にしていきたいところです。まぁ、必要に応じて誰かに相談しながらなら、なんとかなるはず？

以上、技術活動、ブログ、キャリア編の振り返りでした。

今年の振り返りやってて、あれこれできてねぇなぁ...とややしょんぼりしつつ。仕事・プライベートともにちょっとしたチャレンジできたものもあったので、まぁよしとしようかと思います。

では、皆様よいお年をお迎えください～。

{/*  */}

2023年振り返り～技術活動、ブログ、キャリア編～

Sun, 31 Dec 2023 00:00:00 GMT

{/*  */}

今年はキャリアに伸び悩んでクヨクヨしたりが多かったなぁと思っている、よしです。今年の振り返り、技術活動・キャリア編です～。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

2023年の活動履歴

コミット履歴

恒例の Git の Contributions 履歴から。

GitHub

今年は 1712（個人） + 82（仕事） = 1794 でした。

個人活動としては、当ブログリプレースや、過去に作ったアプリや課題作品のメンテナンスをしていました。まぁ、ぼちぼち？

仕事は会社の業務改善活動で作った Bot のメンテナンスを少しやっていたくらいでした。昨年同様、案件の活動は別アカウントの方です。

案件 - GitLab・GitHub

参加している案件では、セルフホスティングの GitLab -> GitHub へ移行中のため、両方載せておきます。

GitLab の方は Contributions の合計を計算したところ 1699 でした。一番多い濃い日は、多いところで 32 contributions ほど。

GitLab の方を見てもらえるとわかるように、大体9月くらいから移行しています。 GitHub 側の9月より前の活動は重複カウントとみなしてカウントせず。（恐らくコミット数のみ重複カウントされる形になる） 9月以降の GitHub 活動からも重複カウントを除外すると、124 ほどでした。

なので、案件活動としては 1,699 + 124 = 1,823 くらいのようです。

数年比較するとこんな感じ。

	2023	2022	2021	2020	2019
GitLab	0	0	0	0	?
GitHub(個人)	1,712	657	2,169	920	231
GitHub(仕事)	82	199	0	541	76
GitLab(案件)	1,699	1,448	-	-	-
GitHub(案件)	124	-	-	-	-
合計	3,617	2,304	2,169	1,461	307 + ?

今年は個人活動がグッと活動量が増えましたね。案件活動は少しだけ。（2019年が極端に少ないのは、年始から休職〜時短勤務で復職とかだったため）

ブログ

アクセス履歴

今年の履歴はこんな感じです。例年通り、Google Analytics のデータ部分のみ抜粋。（12月に関しては、執筆時点でのものです）

月	記事数	月のアクセスユーザ数	月のページビュー数
1月	79	440	627
2月	80	305	414
3月	81	312	405
4月	81	319	410
5月	81	232	323
6月	81	296	402
7月	82	272	856
8月	82	156	214
9月	83	188	482
10月	83	241	377
11月	85	294	766
12月	87	283	407

アクセスユーザ数計：3,338
ページビュー数計：5,683

昨年との比較.

アクセスユーザ数：7,896 -> 4,558減
ページビュー数：10,644 -> 4,961減

年々減っていっていますね...🙄 7月にページビューが増えたのはリプレースしたからかなと思うのですが、そのあとはまた戻った感じでした。今年も大して技術記事書けてなかったしなぁ...という所感ではあります。

技術記事ガリガリ書いて、ブログ改善をしていけば、またアクセス数戻ったりするだろうか？

記事執筆について

今年はついに年間12記事投稿の目標を達成できなかったです...。技術記事という記事全然かけてないじゃん。

今年投稿した記事.

このままでは資料まとめ記事の人になってしまうので、エンジニアとして尊厳を復活させなければ。

リプレースについて

2021年くらいから当ブログをリプレースする構想があったけれど、なかなか手が付けられていなかったというやつ。今年はついに Astro でリプレースしました！🎉

5～7月の平日夜や休日を使ってコツコツ作業して進めました。 7月にリリースして、リプレースしました記事も書いたので、詳細はそちらで書いています。

当ブログサイトをAstroでリプレースしたので、リプレース前後を振り返ってみよう！

何より大変だったのは記事データの移行でしたね。リプレースやりきることができてよかったー。

ちなみにリプレースしました記事を書いた後に、ドメインおよびホスティング環境を Cloudflare にお引越ししていたりします。ポートフォリオサイトも同様にお引越し。ドメイン、ホスティング環境ともにまとめて管理できるの嬉しい。

ブログ以外の記事執筆活動

※Zenn および Qiita に投稿した記事は、基本的には当ブログでも投稿しています。

ブログ + Zenn で活動しているのは継続中で、年末振り返り記事以外はクロス投稿していました。ただ、ブログリプレースの記事は技術中心の内容になるように少し編集しています。（Zenn で自ブログの宣伝をしたいわけではなかったので）

今年 Zenn からいただいた振り返りはこんな感じでした。（12/20までのものです）

やはり文字数は少なめ（昨年は13万文字くらい）

Qiita, Crieit, ~note~ は今年活動なしです。

※2024/09/14追記：Crieit はサービスクローズされました。 ※2025/09/15...note のリンクは除去しました。

個人開発

新規活動は特になし。 web1week で過去に作ったアプリのメンテナンスをしていたくらい。

以前はよくお世話になっていた CRA 構成から脱却して Vite に移行する対応をしました。 eject して、こんなにいろんなパッケージを隠蔽して管理してくれていたんだなぁと思ったとともに、それゆえにメンテナンス大変だったのかな...とも思ったり。技術の栄枯盛衰を感じた出来事でしたね。

Vite の爆速環境になって快適になりました。

個人勉強

フロントエンド

昨年、React 18 とか Next.js 13 とか大きなアプデがあったわけですが、今年もそんなにドキュメント読み込めてないかも...。そうこうしているうちに Next.js 14 がリリースされたりして。

App Router のハンズオン教材や、Next.js 14 リリース時に公開された Learn Next.js はやりました。あとは App Router を実際に開発で使う機会があると、より理解が深められそうだなと。

それと、過去に作った devChallenges の課題のメンテナンスをしていました。ちなみに devChallenges は9月にリニューアルしたので、新しい課題もいくつかこなしたりしていましたね。

<blockquote class="twitter-tweet"> <p lang="en" dir="ltr">🎉 BIG ANNOUNCEMENT:<br />- <a href="https://t.co/FrvrS6Ugkr">https://t.co/FrvrS6Ugkr</a> is officially upgraded.<br />- Totally new designs and challenges.<br />- More updates to come in the future.<br />- The old version is still accessible at <a href="https://t.co/HOApmv1MeL">https://t.co/HOApmv1MeL</a><br /><br />This marks a new beginning after 2 years inactive. 🐰🎊 <a href="https://t.co/rKZ1FF3e56">pic.twitter.com/rKZ1FF3e56</a> </p>— devchallenges.io (@devchallengesio) <a href="https://twitter.com/devchallengesio/status/1706023452182790334?ref_src=twsrc%5Etfw">September 24, 2023</a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

バックエンド

今年は案件でも Kotlin を書く機会がほとんどなかったですね。

案件チームで取り組んでいた、書籍「実践 Node.js 入門」を使った Node.js 勉強会が一巡したくらい？

資格試験

HTML プロフェッショナルレベル2を受験してみようかと書籍も購入していたのですが、勉強に飽きてそのままになっています...。自分の場合、ただ本を読むだけだと飽きてしまって身につくこともない傾向があるので、何か良い勉強法を見つけたい。

TIL 活動

2021年から Notion で活動していましたが、Obsidian の方が良いのでは？と考えて移行途中です。

Obsidian はマークダウンベースのエディタで、ローカルファイルベースになっているのが特徴です。拡張性に優れていて、コミュニティプラグインなんかも多く公開されています。書いていてちょっと楽しくもあるので、今後 Obsidian でナレッジベースを作ろうかなと構想中。

イベント参加

今年参加したイベントはこちら。オンラインは気軽に参加できて、ありがたいです🙏

※資料まとめのみ <OG url="https://event.shoeisha.jp/devsumi/20230209" /> ※会社でアーカイブ視聴会に一部参加 <OG url="https://cssnite.doorkeeper.jp/events/163736" />

オンライン視聴参加 <OG url="https://offers.connpass.com/event/298939/" /> <OG url="https://front-okinawa.connpass.com/event/299738/" /> <OG url="https://jsconf.jp/2023/" /> <OG url="https://offers.connpass.com/event/302376/" /> <OG url="https://findy.connpass.com/event/302508/" />

リードエンジニア的な立ち回り・キャリア

案件業務ではエピックリードを複数担当。仕様がかなり複雑なものだったり、関係者の多い中規模程度のものもありました。

今年の前半はよかったのですが、後半くらいからキャリアに悩むことが多かったです。チームメンバーがガシガシキャリアを前に進んでいる感じで、それに対して自分は何ができるのか？と思ったり。

自分の能力向上やキャリアの悩みに対して、能力検査や研修を受けたりしました。

EQ 検査・研修

EQ とは Emotional Intelligence Quotient の略で、心の知能指数のこと。よく言われる IQ とは違い、先天的なものではなく、後天的に伸ばすことができる能力です。

まず自分の感情を理解しよう、というところから始まり。感情は自律神経（体調）と深く関係している -> 自分の感情を理解することで自分の体調を理解することにつながる。というのは、精神疾患との付き合い方にも活かせそうだなと思いました（元々、EQ 研修に関心を持った理由の1つでもある）

そのほか.

人との関係性を楽にするコツ
自分の感情を調整する
モチベーションと自己成長
他者理解と自己の大きな目的
コミュニケーションスタイル（癖）を知る
プロジェクトマネジメント、脳科学、キャリアと EQ

といった研修に参加。

自分自身のことから、リードとしてチームメンバーとの関わり方であったりと幅広く活かせそうな分野だなと。実用的なことを抜いたとしても、興味深い話が聞けて楽しいです。また研修の新期が始まったら参加してみようと思っています。

ちなみに、この研修を受ける前と後とで EQ を測る検査をしました。劇的な伸びがあったわけではないものの、最初に低かった部分が伸びて全体的に均等に。均等の方がその後の能力伸ばしやすいそうなので、よい経過だなーという話をしました。

EQ 検査の内容を踏まえた面談なんかも実施いただいて、とても良い話ができたなと思っています。

ジョブ・クラフティング

自分の仕事を再定義して認識や行動を変えることで、よりよい仕事ができるようにする。というワークショップのようなものです。

具体的には、こんな感じのことをしました。

今自分がやっている仕事を洗い出す
- どれだけ熱量やコストをかけているかで、大中小にわける
自分の価値観を洗い出す
自分の強みを洗い出す
自分が熱量を持っていることを洗い出す
洗い出した今やっている仕事をもとに、今後やっていきたい仕事を考える
洗い出した仕事・価値観・強み・熱量をグループ化する

自分自身のことを考える機会でもあるので、事前にクリフストレングスを受けてみたり、身近なメンバーに強みをヒアリングして望みました。それでもなかなか難しかったですね。皆さん、最後のグループ化のところで一番悩むらしいです。

案件業務の話も含まれているので、実際にやったもののスクショは貼らないのですが、全体の所感はこんな感じでした。

強みの調和がいろんなところに影響している感じがする
収集・整理が強い
ドキュメント業務の比率高いので、伸ばしていきたい
- ドメインエキスパートの情報をドキュメント化するみたいな動きができると良さそう
共感力がすべての統率を担っている

2024年はどうしていきたいか

ブログ・技術記事

いつもの記事を1年で12記事は掲げつつ、半分くらいは技術の話的な記事を書きたいですねー。せっかくエンジニアをやっているので。

イベント資料まとめ記事も需要があることではあって続けようとは思っていますが、技術記事執筆と両立したいよね～という話。

あとは Astro のアプデが日々行われているので、追従してメンテナンスしていきます。 Astro の新しい機能を使って改善なんかもやっていきたいですね。 Lighthouse スコア改善とか、アクセシビリティ改善とか。

個人開発

今は Docusaurus を使用しているポートフォリオサイトを、Next.js(App Router) にリプレースする構想を進めるかもしれません。記事データがない分、ブログより楽できそうではあるのですが、デザインを少し凝ってみるかなぁとかぼんやり考えていたりします。（デザインは沼なのでまた進まないかも😇）

あとは、RSS リーダーアプリを作ってみる？という構想があったりします。普段、RSS リーダーを使っているわけではないのですが...。いくつか既存のアプリを使おうとしてなんかいまいち続かなかったので、自分で作ったら活用するかなぁとかぼんやり思ったという話。

個人勉強

フロントエンド

来年こそ React と Next.js の公式ドキュメント読み込みたい...。

Next.js の App Router に関しては、案件業務で触れる予定なので自然とキャッチアップしていけそう。便利な機能ができた一方で、キャッシュの使い分けとか難しくなった部分もあるので頑張ってついていきたい。

リニューアルした devChallenges の課題は、引き続き合間を見つけて取り組もうと思っています。また、似た課題を公開しているところとして、以下のサイトも気になっています。 <OG url="https://www.frontendmentor.io/" />

フロントエンドの学習コンテンツがまとまっているサイトなので、いい感じに活用していきたい。

バックエンド

Kotlin も関心はあったのですが、直近は Node.js 周りの理解を深めていくといいのかなぁと。

Hono なんかは、何かの機会に使ってみたいですね。 <OG url="https://hono.dev/" />

資格試験

来年こそは、HTML プロフェッショナルレベル2にチャレンジしてみようかな。名前で紛らわしいですが、実質 JavaScript の試験なので業務にも活きるはず？

TIL 活動

Notion から Obsidian への移行を終わらせて、Obsidian でガシガシナレッジベースを作る方針にしたいですね。

プログラミングのことだけでなく、エンジニアとしての仕事に活きそうな知識全般を残していくイメージ。キャリアに関する深堀とかもやりやすくなる...はず。

イベント参加

フロントエンド、ドキュメント、決済系のイベントは参加してみようかなと思っています。時間が合うなら無理のない範囲で参加しようと。

ただ、オフライン参加はちょっと敷居高い感じがして踏み出せないかも。

リードエンジニア的な立ち回り・キャリア

来年の案件業務では、切り込み隊長のようなことにチャレンジする予定がありまして。自分が先行して、後からほかのメンバーが合流できるように横展開していくような感じ。

あまりやったことがない動きなので少々不安はありつつ。今年後半から停滞を感じていたキャリアへ、大きくプラスにできそうなチャレンジではあると思っています。適度に人に頼りながら向き合っていきたいですね。

また、年末にチームメンバーとの話で面白い発見がありまして。自分は、前でリードするタイプとは違って、周りに安心感を与える守護者のような印象なのだそうです。来年の切り込み隊長のような動きも守護範囲を広げる活動なんじゃないかと言われて、いい解釈だなぁと。

ドメインエキスパートの守護者のような動きを意識していこうかなーと思う出来事でした。

今年の振り返りではキャリアのことも触れてみました。会社の方でも振り返りをやっているので、同じようなことを書くことにはなるのですが、技術活動とも関わることではあるかなと思ったので。

無理はしないのが前提にありつつ、来年はチャレンジしたなーと思えるような年にしたいですね。

では、皆様よいお年をお迎えください～。

{/*  */}

StyleLintアプデ対応とご一緒にpostcss-preset-envはいかが？

Sat, 23 Sep 2023 00:00:00 GMT

こんにちは。前に作ったもののメンテナンスをしていると、いろいろ発見があるねぇとぼんやり思っている、よしです。今回は StyleLint 15系アプデ時に発見したプラグインを紹介してみます。

import OG from "@/components/OG.astro"

要約

さらっと結論だけ知りたい方向けに要約を書いておきます。

StyleLint とその基本ルールセットである stylelint-config-standard をアプデすると、fix される CSS 構文が新しくなっていく（それはそう）
おおよそ各種ブラウザ対応はされているが、場合によってもう少し古いバージョンにも対応させたいことがある
postcss-preset-env を使用すると、これ1つでほとんどの PostCSS をまとめて適用・管理できて旧構文の CSS を出力できるぞ
- 書くときは新しい構文で、出力は旧構文というのが実現できまっせ
- まだブラウザサポートが不安な新しい構文も書いていけるぞ

背景

過去に作った静的ページの課題のメンテナンスをしていまして。 StyleLint 15系へのアプデ対応をしている中で、基本ルールセットである stylelint-config-standard もアプデしました。それにより、課題を作った当時は採用を見送った比較的新しめの CSS 構文へ fix されるようになりました。その課題を作ったのは2年前とかなので、あれから各種ブラウザ対応が進んでいることを考えると、それはそう🙄

ただ、なかには一部のブラウザで少し古いバージョンだとダメそうなものがあったので、書くときは新しい構文で、出力は旧構文ということができたらいいなーと考えていました。といいつつ、PostCSS を1つずつ適用するのは少々面倒だな…と思っていたところで見つけたのが postcss-preset-env でした。

※なお、今回の使用バージョンは以下です.

StyleLint：15.10.3
stylelint-config-standard：34.0.0
PostCSS：8.4.29
postcss-preset-env：9.1.3

postcss-preset-env

コードはこちらのリポジトリの一部として管理されています。 <OG url="https://github.com/csstools/postcss-plugins" />

※元々は以下のリポジトリでしたが、2022/12/14にアーカイブされました。 <OG url="https://github.com/csstools/postcss-preset-env" />

PostCSS Preset Env lets you convert modern CSS into something most browsers can understand, determining the polyfills you need based on your targeted browsers or runtime environments.

※Google 翻訳 PostCSS Preset Env を使用すると、最新の CSS をほとんどのブラウザーが理解できるものに変換し、対象のブラウザーまたはランタイム環境に基づいて必要なポリフィルを決定できます。

postcss-preset-env は多くの PostCSS プラグインをまとめて管理できるプラグインパックです。 Can I Use、MDN から提供される、各機能のブラウザサポート情報を公開している CSS DB というものがあり。この CSS DB を参照し、各 PostCSS プラグインを適用するか制御しているとのこと。 <OG url="https://cssdb.org" />

まさに「書くときは新しい構文で、出力は旧構文」というのが、これ1つでほとんど対応できるわけです。楽ちん。

README で紹介されている変換例.

@custom-media --viewport-medium (width <= 50rem);
@custom-selector :--heading h1, h2, h3, h4, h5, h6;

:root {
  --mainColor: #12345678;
}

body {
  color: var(--mainColor);
  font-family: system-ui;
  overflow-wrap: break-word;
}

:--heading {
  background-image: image-set(url(img/heading.png) 1x, url(img/heading@2x.png) 2x);

  @media (--viewport-medium) {
    margin-block: 0;
  }
}

a {
  color: rgb(0 0 100% / 90%);

  &:hover {
    color: rebeccapurple;
  }
}

/* becomes */

:root {
  --mainColor: rgba(18, 52, 86, 0.47059);
}

body {
  color: rgba(18, 52, 86, 0.47059);
  color: var(--mainColor);
  font-family: system-ui, -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen, Ubuntu, Cantarell, Droid Sans, Helvetica Neue;
  word-wrap: break-word;
}

h1, h2, h3, h4, h5, h6 {
  background-image: url(img/heading.png);
}

@media (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) {
  h1, h2, h3, h4, h5, h6 {
    background-image: url(img/heading@2x.png)
  }
}

@media (max-width: 50rem) {
  h1, h2, h3, h4, h5, h6 {
    margin-top: 0;
    margin-bottom: 0;
  }
}

a {
  color: rgba(0, 0, 255, 0.9)
}

a:hover {
  color: #639;
}

導入方法

インストール.

npm i -D postcss postcss-preset-env

あとは PostCSS の設定ファイルで、このプラグインを使用するよう設定。基本的にはこれだけで OK。

module.exports = {
  plugins: [require('postcss-preset-env')],
};

オプションを渡して設定をカスタムすることももちろんできます。

対応している PostCSS

postcss-preset-env 配下の src/plugins/plugins-data.mjs を見てもらえると良さそうです。ざっと60個以上ありますね…！すごい。（このファイルには記載がないですが、実は autoprefixer も内包されていたりします）

このリポジトリ内で管理している PostCSS プラグインも多数参照しています。リポジトリルートからの plugins 配下とそれぞれの README も見てもらえると、よりどんなものがあるかわかりますね。

なお、postcss-preset-env には W3C に認められた CSS 標準機能のポリフィルとフォールバックのみが含まれているとのこと。そのため、非標準機能や糖衣構文にあたるものは対応していないことに注意です。もし非標準機能や糖衣構文の機能を提供する PostCSS と共存させたい場合は、PostCSS 設定にて、postcss-preset-env より先に定義する必要があります。

公式の例.

module.exports = {
	plugins: [
		"postcss-syntactic-sugar",
		"postcss-non-standard",
		// ...
		[
			"postcss-preset-env",
			{
				// plugin options
			},
		],
		// ...
		// maybe a minifier?
	],
};

また、一部の PostCSS はポリフィルを追加で導入 + それを読み込む設定を追加する必要があることも注意です。詳細は README - Plugins list - Plugins that need client library を参照ください。

オプション

ここではオプションの一部だけ紹介。

stage

各 CSS 機能が Web 標準として実装される過程における安定性を示すもの。どの stage の CSS 機能のポリフィルを有効にするかを指定。

postcssPresetEnv({ stage: 2 })

各 stage のざっくり概要.

stage	概要	説明
0	Aspirational（野心的）	非公式草案または編集者草案。まだまだ下書き段階。
1	Experimental（実験的）	編集者草案または初期作業草案。これから仕様検討が進むくらいの温度感。
2	Allowable（許容可能）	進行中草案。変更される可能性はありつつ、一部のブラウザで実装される。
3	Embraced（受け入れられる）	推奨事項候補。少なくとも2つの一般的なブラウザに実装される。ほとんど変更されることがない。
4	Standardized（標準化）	勧告。一般的なブラウザによって実装される Web 標準。

各 stage の説明や、stage ごとの CSS 機能は CSS DB を見ると一目瞭然です。 stage 2の機能多いな👀 <OG url="https://cssdb.org/#the-staging-process" />

デフォルトでは2が設定されています。大体の方は2のままでも、ほとんどの目新しい機能は試せそうですね。

minimumVendorImplementations

最小ベンダー実装数のこと。どの実装ステータスに基づいて、CSS 機能のポリフィルを有効にするか指定。

postcssPresetEnv({ minimumVendorImplementations: 0 })

目安.

0：どのベンダーも実装していない
3：すべての主要ベンダーが実装済み

デフォルト値は0。もし安定している CSS 機能のみにポリフィルを有効にしたい場合は、2が推奨されているようです。

features

各 PostCSS の id を指定することで、ポリフィルの有効無効を直接決定するもの。 id はsrc/plugins/plugins-data.mjsを直接参照したり、公式ドキュメントから確認可能です。 <OG url="https://preset-env.cssdb.org/features" />

例えば以下の設定はnesting-rulesを有効にして、それ以外は stage 3 としてポリフィル有効化判定が行われます。

postcssPresetEnv({
  /* use stage 3 features + css nesting rules */
  stage: 3,
  features: {
    'nesting-rules': true
  }
})

そのほか、毎度おなじみの browserslist に関する設定や、autoprefixer の設定などがあります。詳細は README - Options を参照ください。

これらのオプション設定を踏まえて、どの PostCSS のポリフィルを有効化するか一元管理してくれるわけです。便利。

プレイグラウンド

PostCSS をまとめて面倒見てくれることは分かったけれど、実際の出力がどうなるか検証したい！という方は、公式のプレイグラウンドを活用するとサッと検証できます。オプションもある程度カスタムできるので、stage などの設定を変更して比較なんかも簡単です。やったぜ。 <OG url="https://preset-env.cssdb.org/playground" />

ちなみに StyleLint にも公式のプレイグラウンドがあります。 <OG url="https://stylelint.io/demo" />

元構文がどう fix されるのか差分を表示してくれるので便利ですね。パッケージのバージョンも変更できるため、どのバージョンからこのルール適用されるようになったんだ？みたいな検証も楽にできます。やったぜ。

2つを組み合わせて、StyleLint で fix されるこの構文は PostCSS 対応しているのか？と試していくとよさそうです。

これまで新しい CSS 構文が登場しても、ちょっと前のブラウザバージョンで使えなかったりして、積極的に書こうとしてこれなかったんですよね。なので新しい構文を情報としては知りつつ、結局書く機会がないから習得できてない状態で。とはいえ、普段フロントエンドで仕事している人間として、ちゃんと習得できた方がいいよなーと。

今回知った postcss-preset-env のおかげで、新しい構文を書けるものがわーっと広がりました。これからは StyleLint の恩恵も受けながら、積極的に新しい構文を採用していきたいですね。

皆様の良い CSS ライフに繋がりますように～。

参考リンクまとめ

当ブログサイトをAstroでリプレースしたので、リプレース前後を振り返ってみよう！

Sun, 30 Jul 2023 00:00:00 GMT

こんにちは、今年の暑さにヘロヘロ気味のよしです。昨年、全然手を付けられていなかったブログリプレースをやり遂げたので、この機に当ブログの履歴の振り返りをしてみました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

{/*  */}

当ブログの履歴

まずはリプレースまでの当ブログの履歴を軽く振り返ってみます。

起源

当ブログサイトを Jekyll で作ったのが2018年5月。この頃の自分というと、エンジニア1年目のペーペーの新人時代。

特にブログを作りたい意欲があったわけではなく、Jekyll というものでローカルサーバ立ち上げて何か作れるらしいぞ、という謎の意欲で作っていました。 Jekyll が SSG の1つということや、そもそも SSG がなんなのかすらよくわかってなかった気がする…。（自分で振り返ってもよくわからん起源だ😇）

当時、ブログを作りたい！ってなると WordPress に行きつく人多そうなのに、自分は全然 WordPress に行き当たらなかったなぁ。駆け出しエンジニアで Jekyll 使ってた人を観測したことがないので、ちょっと変わったやつだったのかもしれない。

そんな起源ながらも、密かに記事を書いていっていました。

Web 上に公開

Web 上に公開したのが2018年の年度末。

当時、親交があった会社の先輩とブログの話をしているうちに「公開しちゃいなよ」的なことを言われて。「Netlify で公開すると楽」と教えてもらって、画面共有しながらデプロイした記憶があります。確かに楽でした。懐かしいですね。

それから独自ドメイン割り当てたり、各種アクセス解析ツールや広告を導入したり、サイトを運営していくにあたり必要なことを少しずつやっていきました。

リプレースへ

2020年末の振り返り時には、リプレースしたいなぁって言ってました。

2020年振り返り～技術活動、ブログ編～

Jekyll によるブログサイトでも特に困ったことはなかったのですが、Ruby 製というのが気になってきて。というのも、この頃は自分のキャリアに悩んだ結果、フロントエンドに転向しようかなと思っていた時期でした。フロントエンドとなると、TypeScript なり Node.js なりが身近になるなか、ここだけ Ruby というのもどうなのかなぁと。自分が関心のある言語に Ruby がなくなったのと、普段扱う技術スタックをある程度狭めたかったこともあり、リプレース構想をするようになりました。

Jekyll の時は公開されているテーマを使用していたので、リプレース時にオリジナルのデザインにしたいなー。モノクロ基調のかっこいいデザインにしたいなーとか。ただ、そこから実際に着手ができずで、これはデザインを凝りだすと当分はリプレースできないな…というのでデザインに凝るのはあきらめました。

リプレースしたもの

レイアウト比較

大まかなレイアウト比較として、トップページと記事ページを載せてみます。ちなみに、なんかえらい余白空いているところやぼかしているところは広告の箇所です。

デスクトップ

トップページ. <div class="layout-fixed">

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/changeofpace-jekyll-desktop.png" alt="リプレース前のトップページ - デスクトップ" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/changeofpace-astro-desktop.png" alt="リプレース後のトップページ - デスクトップ" />

</div>

記事ページ. <div class="layout-fixed">

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/changeofpace-post-jekyll-desktop.png" alt="リプレース前の記事ページ - デスクトップ" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/changeofpace-post-astro-desktop.png" alt="リプレース後の記事ページ - デスクトップ" />

</div>

モバイル

（リプレース前に撮っていた Jekyll の頃のスクショがバグっていたので、過去の Deploy Preview で撮りなおした結果、広告が表示されていません）

トップページ. <div class="layout-fixed">

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/changeofpace-jekyll-mobile.png" alt="リプレース前のトップページ - モバイル" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/changeofpace-astro-mobile.png" alt="リプレース後のトップページ - モバイル" />

</div>

記事ページ. <div class="layout-fixed">

{/*  */}

Jekyll（リプレース前）	Astro（リプレース後）
<img src="/screenshots/2023/blog-replace-astro/changeofpace-post-jekyll-mobile.png" alt="リプレース前の記事ページ - モバイル" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/changeofpace-post-astro-mobile.png" alt="リプレース後の記事ページ - モバイル" />

</div>

リプレースで採用してみた主な技術

リプレースにあたり、採用した主な技術を振り返ってみます。

Astro

主となるフレームワークに選定したのは Astro。 <OG url="https://astro.build" />

Astro ってどんなもの？

Astro is the all-in-one web framework designed for speed. Pull your content from anywhere and deploy everywhere, all powered by your favorite UI components and libraries.

Astro は、速度を重視して設計されたオールインワン Web フレームワークです。お気に入りの UI コンポーネントとライブラリを利用して、どこからでもコンテンツを取得し、どこにでも展開できます。

ざっくり言うと、コンテンツ重視の高速な Web サイトを構築するためのフレームワークです。ビルド時に不要な JavaScript を取り除き、プレーンな HTML に近い状態となることもあり、高速に動作してくれます。

元々は SSG に特化していましたが、2系からは特定のページだけ SSR する、なんてこともできるようになりました。あらゆる形式のデータを提供するエンドポイントという機能があるので、動的に画像や RSS を生成して返したり、API ルートとして使うこともできたりします。

それと面白い特徴の1つとして、React や Vue、Svelte などのコンポーネントも共存できることがあったりします。使い慣れたフレームワークのコンポーネントを作るもよし。 JSX ライクにも書ける Astro コンポーネントを作るもよし。

採用した背景

リプレース構想の最初の頃は Next.js でやろうかなーと思っていました。移行にあたりライブラリの調査なんかはしていたものの、実作業はなかなか手を付けられないまま2022年後半になり。いい加減、どうにか進めたいなと考えていた頃に、Astro を知りました。

Astro は元々 SSG 特化のフレームワークだったこともあってか、すでにブログで使えるような機構が備わっていたんですよね。 Next.js だと自分で機構を用意する必要があるので、Astro の方が移行楽そうだなと。また、Next.js は色々できる分、ブログにはオーバースペックなのでは？ JavaScript を必要最低限まで減らすアプローチの Astro の方がパフォーマンス良いのでは？などと思うようになり、Astro を採用することにしました。

UnoCSS

スタイリングには UnoCSS を採用しました。（グローバルスタイルや記事コンテンツ部分は Sass も併用）

UnoCSS ってどんなもの？

Instant On-demand Atomic CSS Engine Customizable · Powerful · Fast · Joyful

UnoCSS は Vue.js、Nuxt.js、Vite のコアチームメンバーである、Anthony Fu 氏による OSS です。 Anthony Fu 氏がどのような背景で UnoCSS を開発するに至ったかは、ご本人の以下の記事で語られています。 <OG url="https://antfu.me/posts/reimagine-atomic-css" />

UnoCSS はフレームワークでなくエンジンとなっており、自分でカスタムルールを定義したり、それをプリセットとして他のユーザと共有したりが可能です。一方でいくつかのプリセットが同梱されており、デフォルトのプリセットを使用すると、以下のような代表的なフレームワークのスーパーセットを提供してくれます。

Tailwind CSS
Windi CSS
Bootstrap

プリセットの中には、Iconify がベースとなった各種アイコンや Web フォントを気軽に使用できるものもあったりします。便利。ちなみにアイコンの一覧はこちら。 <OG url="https://icones.js.org" />

採用した背景

自分としては独自のカスタムルールを定義したかったわけではなく。

デザインに凝るのをあきらめた関係上、Tailwind CSS を使うと開発速度早くなるかなぁと思ったのですが。そのまま使うより UnoCSS を通して使用した方がパフォーマンス良いんじゃないかと考えて採用したのでした。（なので、デフォルトプリセットを使用しつつ、Tailwind CSS のクラスをメインで使用しています）

Anthony Fu 氏の記事に記載されていたベンチマークに衝撃を受けたのもありましたね。 <ImageWrapper src="screenshots/2023/blog-replace-astro/unocss-benchmark-2021-10.png" alt="2021/10/21のベンチマーク UnoCSSを1として、windicssが195.36倍、Tailwind CSSが251.28倍" />

（2022/10のものだと、だいぶ縮まっていましたが） <ImageWrapper src="screenshots/2023/blog-replace-astro/unocss-benchmark-2022-10.png" alt="2022/10/25のベンチマーク UnoCSSを1として、Tailwind CSSが6.08倍、windiCSSが8.38倍" />

あとはアイコン気軽に使えるのいいなーと思ったのもあります。

リプレースにあたり、機能の変遷

Jekyll からリプレースするにあたり、画面一覧や機能を洗い出してリプレース先の技術でどうやって実装できるのか？というのを調査していきました。加えて、リプレース時に新しく対応したい機能に関しても調査。

元々、Next.js でリプレース検討していたので、最初は Next.js ベースで調査していました。その後、Astro 版も調査して比較すると、やはり Astro の方が組み込み機能や Integration で手軽に実現できるものが多い印象でしたね。

基本部分.

	Jekyll（リプレース前）	Astro（リプレース後）
テンプレートエンジン	Liquid ベース	（JSX ライクな Astro 記法）
テーマ	jekyll-theme-hydeout	自作
フォント	Abril Fatface, Sawarabi Mincho, HackGen	Abril Fatface, Sawarabi Mincho, HackGen
ナビゲーションリンク	テーマベース	自作
カテゴリー	Jekyll 組み込み	Astro 組み込み機能を使って自作
タグ	Jekyll 組み込み	Astro 組み込み機能を使って自作
お問い合わせ	Google Form 埋め込み	Google Form 埋め込み
ページネーション	jekyll-paginate-v2	Astro 組み込み
記事のもっと見る	Jekyll excerpt_separator オプション	廃止

マークダウン周り.

	Jekyll（リプレース前）	Astro（リプレース後）
yaml front matter	Jekyll 組み込み	Astro 組み込み
マークダウン解析〜変換	kramdown ベース	remark, rehype ベース
MDX	（なし）	@astrojs/mdx
改行認識	kramdown の hard_wrap オプション	remark-breaks
目次	kramdaown の toc 機能	（Astro 組み込み機能を使ってメニューにした）
自動アンカーリンク生成	jekyll-anchor-headings	rehype-autolink-headings
コードブロックのタイトル	（なし）	remark-flexible-code-titles
コードブロックのコピーボタン	（なし）	自作
シンタックスハイライト	Rouge ベース	Shiki ベース

補助機能.

	Jekyll（リプレース前）	Astro（リプレース後）
リンクカード	（なし）	hiroppyさんのやり方を参考に実装
RSS	jekyll-feed	@astrojs/rss
サイトマップ	jekyll-sitemap	＠astrojs/sitemap
SNS シェアボタン	Twitter、はてブ	（一旦、廃止）
関連記事表示	（デフォルトの最新記事表示のままにしていた）	（廃止）
Google Analytics	公式のスニペットコード	公式のスニペットコード + @astrojs/partytown
Google Search Console	公式のスニペットコード	公式のスニペットコード
Google Adsence	公式のスニペットコード	公式のスニペットコードベースで遅延読み込み

基本部分

テンプレートエンジン

<OG url="https://shopify.github.io/liquid" /> Jekyll では Liquid が採用されていました。 Shopify でも採用されていたりして割とメジャーなのかなと思っていたら、そもそも Shopify が作った言語じゃん…ということを執筆中に気づいたという〜😇 自分はあまり馴染みがなかったので、多少カスタムするのに書いていたくらいでした。

Astro では JSX ライクに書ける構文となっているため、普段 React や Next.js のコードを書いている自分にとっては扱いやすく、サイトをカスタムしやすくなりました。リプレースにあたり、もしテンプレートエンジンで書くとしていたら、多分リリースまでモチベーションがもってなかったと思います。型定義がある安心感。

逆にテンプレートエンジンが慣れている人にとっては、JSX にとっつきにくさがあるかもしれませんね。といっても、Astro では素の HTML をそのまま Astro ファイルにしても割と動いてくれたりするので、React～Next.js よりは敷居が低そうな印象です。

テーマ

<OG url="https://github.com/fongandrew/hydeout" /> Jekyll の頃は公開されている Hydeout テーマを使用していました。全体的にモノクロ基調寄りでカッコいいなーと思って採用。

リプレースにあたっては、モノクロ基調寄りは維持しつつも自作でカッコいいデザインにしたいと構想。 Web 上にあるモノクロ基調のサイトのデザインを参考にしようかなと思っていた頃もありましたが、1からデザインを学ぶとすればいつまでもリプレースできなさそうな気がしまして…。

あくまでブログサイトなので、見た目に凝ったデザインというより、メインコンテンツである記事が読みやすいことを優先することにしました。それにあたり、Zenn のような技術記事のプラットフォームや、Astro で作成された技術ブログの構成を参考にさせていただきながらレイアウトを構築していきました。

自作するとなんだか愛着がわきますね。

フォント

Abril Fatface：ブログタイトルのみ
Sawarabi Mincho：テキスト全般
HackGen：インラインコード、コードブロック

Abril Fatface は元々使用していた jekyll-theme-hydeout テーマの中で、ブログタイトル部分に使われていて、なんかカッコよかったので続投。 Sawarabi Mincho は日本語フォントの中でお気に入りのフォントです。線の強弱があるので可読性に優れていたり、美しい文字のような印象を受けたので採用しています。 HackGen は VSCode のフォントにも設定しているなど、コードを書くうえでも普段使いしているフォントです。読みやすくて好きです。

前者2つは Web フォントであるため、UnoCSS の Web Fonts preset を使って利用。 HackGen はリポジトリのリリースからダウンロードして、UnoCSS のテーマに登録したうえで利用。 <OG url="https://github.com/yuru7/HackGen" />

ナビゲーションリンク

Jekyll の頃はテーマベースで、デスクトップ表示では画面左側に配置、モバイル表示ではページ上部に配置のナビゲーションリンクでした。デスクトップ表示はともかく、モバイル表示でナビゲーションリンクを使いたいときに、いちいちページ上部にスクロールしないといけないのが気になってしまい。

リプレースにあたり自作。デスクトップ表示では画面左側にサイドバーとして追従配置、モバイル表示では固定ヘッダーからメニューで使用できるようにしました。メニューを開いたときに、固定で画面右上に表示だったり、ぼかしをいれるところは Tailwind CSS の公式ドキュメントを参考にしています。

カテゴリー

Jekyll の頃は元からサポートされており、front matter でカテゴリー指定をすれば、割とスッと使えるようになっていました。（カテゴリー名の日本語化は別途一工夫したような）

Astro においては、front matter と動的ルーティングの組み合わせで実現しています。 getStaticPathsでルーティング生成時に、全記事取得から front matter に指定したカテゴリーで絞り込みをするイメージ。 Next.js の動的ルーティングに慣れている人なら、あっさり対応できると思います。

注意点として、UnoCSS はビルド時にクラスの静的抽出を使用して動作します。その関係上、動的に割り当てているクラスを検出できず、そのクラスのスタイルを生成してくれません（そのクラスが静的にどこからも使われていなければ）

各タグに応じたアイコンを動的に割り当てるにあたり、Safelist に登録して、強制的にそのクラスのスタイルを生成してくれるように対応しました。 <OG url="https://unocss.dev/guide/extracting#safelist" />

お問い合わせ

Google Form 埋め込みを継続にしました。リプレースにあたり、Google Form を利用しつつも見た目をカスタムする手もありましたが、今のところ対応していません。

フリーランスの人が仕事探しにも活用するポートフォリオサイトとかなら対応した方がよいかと思いますが、雑多なこと書いてるブログサイトなので別に優先度落としてよいかな…と。

ページネーション

Jekyll には元々Jekyll-paginate プラグインが導入されていて、ページネーション機能が備わっていたのですが、カテゴリー記事一覧ページには対応していない課題がありました。カテゴリー記事一覧ページでも利用したい場合はjekyll-paginate2を使うよう、公式からも案内されていたのでこちらを利用。

<OG url="https://docs.astro.build/ja/core-concepts/routing/#ページ分割" /> Astro では組み込みのpaginate()関数を使用することで、ページネーションを実現しています。

記事のもっと見る

記事一覧ページには冒頭文だけ表示して、もっと見るを押すと記事ページに遷移する、というあれです。 Jekyll の頃は、excerpt_separator オプションを利用することで実現が可能でした。自分の記事で冒頭挨拶文があるのは、この機能の影響ですね。

特にこだわりがあったわけではなかったのと、Astro で実現するよさそうな方法がうまく見つけられなかったので、思い切って廃止にしました。

マークダウン周り

yaml front matter

記事のメタデータを記述するところです。どちらも組み込みで機能が備わっていたので、特に困らなかったですね。 Astro では、Zod が組み込まれていて front matter の型定義ができたので、より厳密に管理できるようになりました。

マークダウン解析〜変換

Jekyll では kramdown ベースになっており、オプションを設定することでカスタムが可能になっていました。

Astro では元々組み込まれている @astrojs/markdown-remark で処理しているようで、remark と rehype がベースになっています。双方のプラグインによる拡張をサポートしているため、豊富なプラグインで割といろんなカスタムができます。ちょっと楽しい。

MDX

Jekyll の頃は特に使用しておらず、普通にマークダウンで記事を書いていました。

<OG url="https://docs.astro.build/ja/guides/integrations-guide/mdx" /> Astro では @astrojs/mdx Integration を使うことでさっくり MDX に対応できました。コンポーネントが使えるようになるので、表現の幅が広がりますね。最初はマークダウンでいいかなと思っていたのですが、後述のリンクカードのコンポーネントの都合で MDX を使うようにしています。

改行認識

マークダウンにある改行をそのまま改行として認識するか、というやつです。デフォルトでは認識されないので、半角スペース2つ等で改行させる必要があり、これが面倒だったので自分はそのまま認識してくれるようにしています。

Jekyll の頃は、kramdown の hard_wrap オプションでさっくり対応できました。

<OG url="https://github.com/remarkjs/remark-breaks" /> Astro では remark-breaks プラグインを導入して対応しています。プラグインの適用さえすれば、特に設定は不要なので楽ちんでした。

Astro では記事データにある見出しを抽出してくれる機能が備わっているため、それで実現しています。ただ、目次というよりは、ナビゲーションリンクのようにどこからでも使えるようにしたいなーと思い。デスクトップ表示では、画面左側のサイドバーでナビゲーションリンクと切り替えて利用できるように。モバイル表示では、固定ヘッダーからメニューとして利用できるようにしました。

なお、デスクトップ表示において、サイドバーの下部に配置している構成をよく見かけます。今回はナビゲーションリンクでそこそこ縦幅をとっている + 追従配置にしている関係で、画面の縦幅によっては扱いずらい感じになりそうだったので、ナビゲーションリンクと切り替えできる形をとりました。（あまり見たことがない構成なので、実はアンチパターンだったりするかもしれない？）

自動アンカーリンク生成

各見出しのところで # とかリンクアイコンで、その見出しのアンカーリンクが取得できるやつです。

<OG url="https://github.com/allejo/jekyll-anchor-headings" /> Jekyll の頃は jekyll-anchor-headings で対応していました。 Gem として導入するのではなく、最新の該当 HTML ファイルをダウンロードして導入するようになっていますが、比較的楽ちんです。

<OG url="https://github.com/rehypejs/rehype-autolink-headings" /> Astro では rehype-autolink-headings で対応しました。

注意点として、Astro は rehype プラグインが実行された後に id 属性を注入するようになっています。そのまま使うと rehype-autolink-headings 実行時に id 属性がない状態になり。うまくリンクが生成されないため、@astrojs/markdown-remarkのrehypeHeadingIdsと組み合わせて使用するようにしています。

コードブロックのタイトル

Jekyll の頃は対応していませんでしたが、よく対応しているサイトを見かけるのでリプレース時に対応したいなーと思っていました。

<OG url="https://github.com/mottox2/remark-code-titles" /> <OG url="https://github.com/ipikuka/remark-flexible-code-titles" /> リプレースにあたり、最初は remark-code-titles で対応していました。ただ、タイトルの要素が単純にコードブロックの pre 要素の前に生成されることで、後述のコピーボタンの配置と相性の悪い問題があり。

<h1>Hello World</h1>
<div class="remark-code-title">hello.js</div>
<pre><code class="language-js">console.log('js')
</code></pre>

remark-flexible-code-titles であれば、コンテナとなる要素でラップした中にタイトルの要素が生成される構造になるため、こちらを採用しました。

<div class="remark-code-container">
  <div class="remark-code-title">title.js</div>
  <pre>
    <code class="language-javascript">let me = "ipikuka";</code>
  </pre>
</div>

コードブロックのコピーボタン

これも同様に Jekyll の頃は対応していませんでしたが、リプレース時に対応したいなーと思っていました。 remark-flexible-code-titles で生成される構造に合わせて、自作スクリプトで生成するようにしています。

シンタックスハイライト

<OG url="https://github.com/rouge-ruby/rouge" /> Jekyll の頃は Rouge ベース。

<OG url="https://shiki.matsu.io" /> <OG url="https://prismjs.com" /> Astro では Shiki と Prism を組み込みサポートしていますが、Prism を使う場合は別途 CSS を用意する必要があるので注意です。自分はデフォルトの Shiki を使用しています。

補助機能

リンクカード

Zenn の記事で URL を書くと OGP カード表示に変えてくれる的なやつです。 Zenn であの表示を見てからは自分もこれやりたいなーと思うようになりました。

Jekyll の頃は対応しておらず、リンクは普通にマークダウンのリンクで記述していました。自分はブログと Zenn にクロス投稿をしている関係で記事内容を転記しているのですが、リンク部分を書き換えるの地味に面倒で…。それを解消する意味でもどうにか対応できないかなと調査。

<OG url="https://github.com/zenn-dev/zenn-editor" /> 最初に Zenn の zenn-markdown-html のコードを読んでみて、リンクカード変換の部分を参考にできないかなと思ったのですが、どうにも難しそうであきらめました。

<OG url="https://github.com/gladevise/remark-link-card" /> remark-link-card でお手軽に対応できそうではあったものの、最終更新が2年前なのと、HTML 構造をカスタムしたかったので見送り。

結果的に、hiroppy さんがやられていた方法がいいなーと思い、参考にさせていただくことにしました。（hiroppy さんも Astro でサイトをリプレースされていて、サイト構成から参考にさせていただいていました） <OG url="https://hiroppy.me/blog/migrate-blog-from-hatena" /> 具体的にどんなことをやられているかというと、ざっくりこんな感じです。

リンクカード用のコンポーネントを作成
- props で渡された URL の OGP 情報を fetch して、それで要素を構築
  - 本番ビルド時のみ、取得した OGP 情報を JSON にキャッシュ
  - キャッシュがある場合はそちらから OGP 情報を表示する
MDX でそれを利用してリンクを記述するようにする

OGP 情報をビルド時に取得するので、ビルド後の静的ファイルとして表示時には表示が早くなる。キャッシュができるので、ビルドも早くできる。というメリットがありつつ、リンクカードの内容が常に最新になるわけではないデメリットもあります。そこらへんは定期 JOB などでカバーすればよいかなと思っています。（今のところまだ作ってないです）

MDX でリンクカード用コンポーネントを使用することになるので、ブログと Zenn のリンク構文を一致させる目的は達成できていませんが…。リンクカード用コンポーネント呼出しを記述するスニペットは作ったので、それでいくらかマシにはなりました。

ファビコン取得部分に関しては、Google の非公開 API を使用するようにしました。非公開 API ということは急に使えなくなる可能性があるので、最初は meta 情報からファビコン URL を抽出するようにしていたのですが…。割といろんな URL パターンを観測して分岐処理を書くのがつらくなってきたので、あきらめました。

RSS

<OG url="https://github.com/jekyll/jekyll-feed" /> Jekyll の頃はjekyll-feedを利用。使用するプラグインに追加するだけなので楽ちん。

<OG url="https://docs.astro.build/ja/guides/rss" /> Astro では、エンドポイント機能と@astrojs/rssの組み合わせが公式で紹介されていたので、そちらで対応。このブログサイトは技術の話だけでなく雑多な話をしているので、カテゴリーごとの RSS も取得できるようにしました。

サイトマップ

<OG url="https://github.com/jekyll/jekyll-sitemap" /> Jekyll の頃はjekyll-sitemapを利用。

<OG url="https://docs.astro.build/ja/guides/integrations-guide/sitemap" /> Astro では、@astrojs/sitemapで対応。本番ビルド時にサイトマップを生成してくれます。 sitemap-0.xmlとsitemap-index.xmlを生成し、後者から前者を参照するような構造になっていたのがちょっと不思議でしたが、特に困ったことはなかったです。

SNS シェアボタン

Jekyll の頃は、Twitter とはてブのシェアボタンを設置していました。ただ、使用している人がいなさそうだったのと、最近の Twitter の動向が怪しかったので一旦廃止に。

Google Analytics

引き続き公式のスニペットコードを使用して導入しています。

<OG url="https://docs.astro.build/ja/guides/integrations-guide/partytown" /> ただ、普通に導入すると Lighthouse のスコアに影響が出るということで、Astro では@astrojs/partytownを使用して影響が出ないようにしました。

Partytown は遅延読み込みライブラリの一種で、スクリプトをメインスレッドでなく Web ワーカーの方で処理してくれるようです。

Google Search Console

google-site-verification の meta 情報埋め込みを引き続き行っています。

Google Adsense

Jekyll の頃は、公式のスニペットコードをパラメータを少し調整した上で導入していました。

Astro で導入するにあたっては、遅延読み込みで対応しました。最初は、これも Partytown が使えるかなと思っていたのですが、うまく動作してくれなかったので断念。普通に読み込むと、Adsense が生成する要素で Lighthouse の減点を食らったのでどうにかしたいが、こちらが手を加えられない箇所だしな…となり。

調査をすると、どうも遅延読み込みをしてカバーするテクニックがあるとヒットしたので、遅延読み込みで対応することにしました。主にこちらのサイト様のやり方を参考にさせていただいています。 <OG url="https://mamenaka.jp/blog/pagespeed-insights-100-astro-blog" />

この遅延読み込みの欠点としては、ファーストビューに広告があると明らかに遅延読み込みしているとわかり、あまりよくないことでしょうか。（自分がリプレースした）サイトではまさにファーストビューにも広告があったので悩ましかったのですが、まぁ元々オマケ程度につけてるくらいだしな…というので許容としました。

パフォーマンス比較

Chrome 拡張の干渉を避けるため、シークレットウィンドウの Lighthouse で検証。一部、リプレース前より悪くなったものもありつつ、全体的にはスコア向上になった印象ですね。

Astro はその特徴から、そんなに神経使って頑張らなくても高スコアが狙いやすい気はしました。じゃあ Jekyll は良くなかったのかというと、自分がリプレース前にパフォーマンスをあまり意識していなかったので、ちゃんと意識している人は高スコア出せていると思っています。

トップ（/）

デスクトップ.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-top-desktop.png" alt="リプレース前のトップページ・デスクトップスコア - パフォーマンス：98, ユーザー補助：66, おすすめの方法：100, SEO：90" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-top-desktop.png" alt="リプレース後のトップページ・デスクトップスコア - パフォーマンス：100, ユーザー補助：100, おすすめの方法：100, SEO：100" />

</div>

モバイル.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-top-mobile.png" alt="リプレース前のトップページ・モバイルスコア - パフォーマンス：84, ユーザー補助：66, おすすめの方法：92, SEO：89" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-top-mobile.png" alt="リプレース後のトップページ・モバイルスコア - パフォーマンス：100, ユーザー補助：100, おすすめの方法：100, SEO：100" />

</div>

about（/about）

デスクトップ.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-about-desktop.png" alt="リプレース前のaboutページ・デスクトップスコア - パフォーマンス：95, ユーザー補助：74, おすすめの方法：92, SEO：82" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-about-desktop.png" alt="リプレース後のaboutページ・デスクトップスコア - パフォーマンス：98, ユーザー補助：100, おすすめの方法：100, SEO：100" />

</div>

モバイル.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-about-mobile.png" alt="リプレース前のaboutページ・モバイルスコア - パフォーマンス：75, ユーザー補助：74, おすすめの方法：92, SEO：81" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-about-mobile.png" alt="リプレース後のaboutページ・モバイルスコア - パフォーマンス：96, ユーザー補助：100, おすすめの方法：100, SEO：100" />

</div>

リンク多め（/posts/2023-02-11-developers-summit-2023）

リプレース後は、リンクカード関連でいくつかコンソールエラーがでていたので、パフォーマンスに響いてるっぽい。

デスクトップ.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-link-desktop.png" alt="リプレース前のリンク多めページ・デスクトップスコア - パフォーマンス：96, ユーザー補助：66, おすすめの方法：92, SEO：100" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-link-desktop.png" alt="リプレース後のリンク多めページ・デスクトップスコア - パフォーマンス：87, ユーザー補助：100, おすすめの方法：92, SEO：100" />

</div>

モバイル.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-link-mobile.png" alt="リプレース前のリンク多めページ・モバイルスコア - パフォーマンス：57, ユーザー補助：66, おすすめの方法：100, SEO：94" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-link-mobile.png" alt="リプレース後のリンク多めページ・モバイルスコア - パフォーマンス：64, ユーザー補助：100, おすすめの方法：92, SEO：100" />

</div>

画像多め（/posts/2020-04-23-react-material-ui）

デスクトップ.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-image-desktop.png" alt="リプレース前の画像多めページ・デスクトップスコア - パフォーマンス：57, ユーザー補助：71, おすすめの方法：100, SEO：100" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-image-desktop.png" alt="リプレース後の画像多めページ・デスクトップスコア - パフォーマンス：99, ユーザー補助：100, おすすめの方法：92, SEO：100" />

</div>

モバイル.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-image-mobile.png" alt="リプレース前の画像多めページ・モバイルスコア - パフォーマンス：41, ユーザー補助：71, おすすめの方法：100, SEO：94" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-image-mobile.png" alt="リプレース後の画像多めページ・モバイルスコア - パフォーマンス：85, ユーザー補助：100, おすすめの方法：92, SEO：99" />

</div>

ツイート埋め込み多め（/posts/2020-09-20-web1week-2）

デスクトップ.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-tweet-desktop.png" alt="リプレース前のツイート埋め込み多めページ・デスクトップスコア - パフォーマンス：91, ユーザー補助：70, おすすめの方法：100, SEO：100" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-tweet-desktop.png" alt="リプレース後のツイート埋め込み多めページ・デスクトップスコア - パフォーマンス：99, ユーザー補助：100, おすすめの方法：83, SEO：100" />

</div>

モバイル.

Jekyll（リプレース前）	Astro（リプレース後）
<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-jekyll-tweet-mobile.png" alt="リプレース前のツイート埋め込み多めページ・モバイルスコア - パフォーマンス：80, ユーザー補助：70, おすすめの方法：100, SEO：95" />	<ImageWrapper src="screenshots/2023/blog-replace-astro/lighthouse-astro-tweet-mobile.png" alt="リプレース後のツイート埋め込み多めページ・モバイルスコア - パフォーマンス：100, ユーザー補助：100, おすすめの方法：83, SEO：98" />

</div>

スコアが伸びなかったところ

リンクカード周りの取得がうまくいってないところは、その分減点されてましたね。

Google の API でファビコンが取得できなかったときは、フォールバックのアイコンを返すようになるのですが、404へ行きあたる関係上コンソールにエラーが出てしまうんですよね…。あとは、OGP 画像として設定されている URL が無効になってしまっているとか。

この辺は、相手のサイト側の問題の気がしているので、今のところ特に対策等はしていません。（というか、何か対策できる...？）

一部はこちら側で改善できそうな点もあったので、今後改善していきたいですね。

ちなみにパフォーマンス改善で行われることの多い、画像最適化については今のところ対応していません。

現在、Astro で実験的サポートになっていて機能としては一応使えはします。 3系リリースで正式サポートになるっぽかったので、まぁその時に対応でもいいかなぁとなりました。 <OG url="https://astro.build/blog/images" />

その代わり、記事移行する際にすべての画像を圧縮かけたうえで移行しています。ほぼ7～8割くらいは削減してくれたので、全体としてはだいぶ軽くなっているはず。圧縮にはこちらを使わせていただきました。お手軽に圧縮できて良きです。 <OG url="https://imguma.com" />

リプレースした感想など

完全に個人活動なので休日メインで進めていました。 2023/04に本格開始して2023/07/09にリリース。かかった時間としてはざっくり150時間くらいだったので、もし仕事として平日作業していたなら1か月で終えられたようです。

数年なかなか進められていなかったものをようやく終えられたので、すっきりしましたね。 Lighthouse のスコアも全体的には改善されたので、とりあえず自己満足しています。

気になる技術を使って何かを作るのは、キャッチアップの良い機会になりますし、やはり楽しい。個人開発だと割と自由に技術選定できるので、気兼ねせず試しやすいです。 Astro や UnoCSS と少しだけ仲良くなれた気がしました。特に Astro は活発にリリースが行われているので、今後の動向が楽しみです。

ちなみにリプレースで一番大変だったのは、機能実装ではなく記事移行でした。元のマークダウンをそのまま MDX にすればよいという話ではなくて、微妙に文章調整をしたりしたので。それを約80記事でやったので、それはまぁ大変だよね…と😱

どうせ書くならリプレース前後を比較をするような方式にしたいなーというので書いていたら、すっかり長文になってしまいましたね。新機能中心にリリースしました記事を書くこともできましたが、同じく移行を考えている方の何かの参考になればいいなと思い、このスタイルにしました。リプレースにあたっての技術調査って割と大変だと思いますので…。

少しでも何かの参考になれば幸いです。

{/*  */}

参考リンクまとめ

Astro 周り.

UnoCSS 周り.

Jekyll 周り.

その他.

技術文書を書く方に送る、書籍「技術者のためのテクニカルライティング入門講座」

Sat, 25 Mar 2023 00:00:00 GMT

こんにちは、積読の消化が追いついてねぇ…とぼやいてる、よしです。今回は、読んだ書籍を紹介したい気持ちになりまして、紹介記事に挑戦してみました。

import OG from "@/components/OG.astro"

はじめに

紹介したい本

「技術者のためのテクニカルライティング入門講座」という書籍です。

以下、翔泳社のサイトより引用.

日本では、「文書は論理的かつ簡潔に記述する」という、当たり前のテクニックを学ぶ機会があまりありません。そこで本書では、忙しい技術者の方でも「テクニカルライティング」を通じて、相手に伝わる技術文書を効率よく書けるようになるテクニックを多数紹介していきます。ユーザーマニュアルや障害報告書、提案書といった実務直結の文例を多数掲載しているので、すぐに業務に役立てることが可能です。新人～中堅の技術者の方だけでなく、管理職の方も添削指導のお手本としてご利用いただける内容です。

そもそも「論理的」とはどういうことなのか？というところから始まり。ロジカルライティングとは？　テクニカルライティングとは？と基礎的な考え方を提示しつつ、具体的なテクニックを紹介。さらにそれらのテクニックを組み合わせて、実際の技術文書をどう作っていくのかという実例まで記載されている書籍です。

書籍が発売されたのは2018年11月19日。当記事の執筆時点からは約5年前になりますが、今でも十分通用する内容になっていると個人的に思いました。

※2024/12/31追記 2024/12/18に第2版が出版されました！主に生成 AI に関する章が増えているようです。 <OG url="https://www.shoeisha.co.jp/book/detail/9784798188423" />

紹介したいと思った背景

（私事なので興味ない方はすっ飛ばしてもらって大丈夫です）

自分は今の会社に来てから「ドキュメント力が高い」と評価されることが増えました。（図的なドキュメントは大して描いたことがないので、多くは文章能力のことを指して言われていたのだと思っています）

{/*  */}

それまでは特に自分の長所のような自覚は全くなく。評価されるようになったことで、これって出来てる方なんだーとやっと自覚するようになり。「技術記事書いてるから自然と伸びたのかな？」「Textlint を活用したり、ネットで聞き齧ったテクニックを取り入れたりしてたおかげ？」と思いつつ、そういえばちゃんと基礎からライティング技術を学んだことなかったなぁと。

{/*  */}

自分の長所だというなら、ちゃんと基礎から学んでより磨いていきたい。学んだことを周囲の人にも伝えられるようになれたら、より良いだろうなと思ったこともあり。それで書籍を読んでみようとまず手に取ったのが、今回の書籍でした。

読んでいて、技術文書の書き方悩んでる人、みんなこの本読んだらいいんじゃないか？と思ったのがきっかけです。基礎の基から具体的なテクニック〜実践まで記載されていたので、紹介されているテクニックを取り入れるだけでも十分役に立つと思ったのです。

書籍の内容の紹介

書籍の目次はこのようになっています。

第1章：ロジカルライティング × テクニカルライティング活用の基礎知識
第2章：わかりやすく、簡潔な文章を書くテクニック
第3章：読み手に伝わる文章を書くテクニック
第4章：読みやすさを高める文書フォーマット〜表現・表記のルール〜
第5章：実践編　ユーザーマニュアル・取扱説明書
第6章：実践編　提案書
第7章：実践編　障害報告書
第8章：実践編　社外メール文

冒頭でも触れた通り、基礎知識〜テクニック・ルール〜実践といった流れですね。テクニックの章だけでも、それぞれ before・after 例が提示されているためわかりやすいです。今回は1〜3章の内容について少し紹介してみます。

第1章 - ロジカルライティング × テクニカルライティング活用の基礎知識

第1章の目次.

1.1：技術者の書く文章がわかりにくい3つの理由
1.2：そもそも「論理的」とはどのようなことか
1.3：思考を効果的にアウトプットするための「ロジカルライティング」
1.4：「読み手」は目の前にいる人だけ？
1.5：「目的」ありき。読んだ人の行動を想定する
1.6：書き出す前にロジックを組み立てることが何より重要
1.7：情報をわかりやすく伝えるための「テクニカルライティング」

まずはよくあるアンチパターンに触れつつ、大事な基本的考え方から記載されています。これまで論理的、ロジカルライティング、テクニカルライティングという言葉はよく聞いていたものの。その意味がちゃんと説明できるか？と言われると自信がなかったため、改めて認識する良い機会になりました。

書籍の説明文をざっくり引用すると、こんな感じ。

論理的：わかりやすく伝わり、読み手の次の行動につながるほど筋道が通っていること
ロジカルシンキング：論理的で筋道の通った思考方法や説明の仕方
ロジカルライティング：ロジカルシンキングを活用して文書作成する技術
テクニカルライティング：技術的な情報を利用者にわかりやすく伝えるための文書技術

技術文書は、ロジカルライティングとテクニカルライティングを組み合わせて記述していくものと考えると良さそうですね。

まずは読み手を洗い出し、文書の目的と読み手に期待する次の行動を明確にする。 というのが、技術文書を書く上ではとても大事である旨記載されています。ここがブレてしまうと曖昧な内容になってしまい、結局何が言いたいのかよくわからないものになってしまいがち。要らぬ不安や混乱を招いてしまうこともある…とあり、心当たりある気がしました😇

その次に、いきなり文書を書き始める前に、情報を整理してロジックツリーを組み立てようとありました。主題を元に整理した情報を階層のツリーにして、全体像のイメージを作成。そこからポイントを設定。各ポイントには、ポイントを裏付けるような内容を書いていく、といった感じ。技術記事だったら、最初にタイトルを決めて見出し構成を決めた後に、それぞれの見出しの内容を書いていくといった具合ですね。

第2章 - わかりやすく、簡潔な文章を書くテクニック

第2章の目次.

2.1：1文1義で書く
2.2：文を長くしない。「〜（だ）が」、「〜ので」で文をつながない
2.3：一文を短く。50字以内で収めるように
2.4：5W2H を盛り込み、曖昧な文章にしない
2.5：メールの件名、文書のタイトルから目的が伝わるように書く
2.6：「話し言葉」と「書き言葉」を使い分ける
2.7：接続詞の使用は最小限に抑えて、効果的に使う
2.8：長くなりがちな文章を簡潔に仕上げるコツ

この章では、冗長的で曖昧な文章とならないようにするテクニックが紹介されています。なんとなく意識できていたものもあれば、ちょっと自信がないものもありましたね😓

特に「〜（だ）が」、「〜ので」って割と使いがちと言いますか。これが良くない理由としては、以下のようなことが挙げられていました。

複数の内容が1文に盛り込まれてしまい、1文1義にならない
文の中で最も伝えたいことが、文の最後にきてしまう

このせいで、内容が読み手に伝わりにくくなってしまう、というものです。

とはいえ、文章を書きながら注意するのは難しいこともあり。書き上げた後の見直しの段階で文を区切ったり、順番を変えたりすると良いとのことでした。個人的には、完全に使わないようにするというよりは、多用しないように気をつけようかなと思っています。（当記事でもいくつかは使用していたりします🙄）

それと「話し言葉」と「書き言葉」を使い分けるというのは、場合にもよりそうかなと。書き言葉の方が冗長な表現を省いており簡潔に伝わりやすい。礼節や説得力を高めるためにもビジネス上はこちらを使った方が良い、というのは確かにそうだと思いつつ。技術記事であれば、きっちり書き言葉でなくても良いかなとは思いました。きっちりだとなんだかお固い印象を与えてしまいそうな気がしまして。

ちなみに最初に目次を見た時、目次にあるタイトルだけでも何が言いたいのか率直に伝わってきました。 2.5のテクニックがまさに実施されているんだなぁとちょっと感激したものです。

第3章 - 読み手に伝わる文章を書くテクニック

第3章の目次.

3.1：最も重要な内容を先に書く
3.2：形容詞や名詞句でなく、動詞でズバリと書く
3.3：否定表現に気をつける
3.4：受動態と能動態を使い分ける
3.5：具体的に情報を盛り込んで書く
3.6：「など」を多用しない
3.7：レビューを受けて、わかりやすさを高める
3.8：最後の文でしっかりと締めくくる

この章では、より読み手に内容や目的が伝わるような文章を書くためのテクニックが紹介されています。うーん、こちらも出来ているものもあれば、自信ないものがある…。

{/*  */}

「〜しないと、〜ない」や「〜しないとは限らない」のような二重否定を使っていませんか？特に後者の方は「必ずしもそうなるわけではなくて、状況による」と曖昧な表現をしたくなった時に使いたくなったりしますよね。こういった二重否定は、パッと内容が分かりにくくなってしまって、結局何が言いたいのかストレートに伝わらない問題を抱えているとのこと。読み手に書き手の意図を考えさせてしまう、迷わせてしまうので避けましょうと。

{/*  */}

「など」を多用しない、というのは特に自信がないやつですね。「ここに挙げたのは一例で他にもあるよ」という時につい使いがち。良くない理由として、これも文章を曖昧にしてしまう要因になるためでした。

対処法としては、「など」を削除してしまう。もしくは「〜などの工具」のように、「など」の後に例示をまとめるようなものを加えること。こうすることで「など」が何を示すのかを明確にして曖昧とならないようにすると良いそうです。

読んでみてどうだった？

冒頭に述べた通り、この書籍の発売日が5年前であるため、古い情報もあるかな？と最初は思っていました。実際に読んでみると、全部がとまでは言いませんが、十分今でも通用する考え方やテクニックが記載されている印象を受けましたね。基礎知識の地盤固めにとても良く、読んで良かったなと。

テクニックがしっかり言語化されているので、これを自分の中で落とし込みつつ。周りのメンバーにも伝えていけると良いドキュメントを作成する環境にしていけそうです。

だからこそ紹介したいと思ったというのもあります。

テクニカルライティングとシステム開発は似てる？

それと読んでいてすごく思ったのは、テクニカルライティングで技術文書を作成するフローやテクニックって、システムを作る時に考えることと似ているなぁと。

フローで言うとこんな感じ。

技術文書	システム
情報収集〜整理	要件定義
ロジックツリー作成	設計
執筆	実装
レビュー	テスト

プログラミングにおいても可読性って大事ですよね。可読性向上のためのテクニックが多く存在するわけで。それらの基本的な考え方って、分かりやすい技術文書を書くテクニックと同じなんじゃないかなーと思ったのです。

じゃあ、優れた技術文書を書ける人 = 優れたシステムを作れる人なのか...？そこはどうなんだろうなぁと。

実装は得意でもドキュメント書くの苦手だと言う人もいるので、一概にそういうわけではなさそう？ただ、基本的な考え方は理解していて実装には落とし込めるけれど、ドキュメントへの落とし込み方がうまく掴めていない。ということであれば、その落とし込み方さえわかれば無双できる可能性あるのでは…？🤔 心当たりがある方は、ぜひ意識して伸ばしてみてはいかがでしょう。自分も設計〜実装力を合わせて磨いていくぞー。

さらなるテクニカルライティングの世界へ

{/*  */}

自分はこの書籍をとっかかりに、よりテクニカルライティングへの関心が高まったように思います。他にもテクニカルライティングを取り扱った文献を読んでみたいなぁと。

{/*  */}

ちなみに現在は、先日発売されたばかりのこちらの書籍を読んでいます。 <OG url="https://pub.jmam.co.jp/book/b622627.html" />

架空のサービスのドキュメントを作るような形式で話が進んでいくので、より開発寄りの書籍ですね。内容が気になる方は、翻訳者の方による紹介スライドがおすすめです。（プロダクト開発と同じ流れなんだよ、という話があって自分が思ったことは割と合ってたんだーって感激しました） <OG url="https://speakerdeck.com/iwashi86/docs-for-developers" />

サイボウズの仲田さんのスライドもおすすめです。 <OG url="https://speakerdeck.com/naohiro_nakata/technicalwriting" /> <OG url="https://speakerdeck.com/naohiro_nakata/technicalwritingfordeveloper" />

Google のテクニカルライティングのドキュメントはこれから読みたい。 <OG url="https://developers.google.com/tech-writing" />

それとテクニカルライティングの資格もあるそうなので、そちらもちょっと気になっています👀 （2023/11/25：URL が変わっていたので差し替え） <OG url="https://jtca.org/learn-tc/certificate-exam/" /> <OG url="https://speakerdeck.com/line_developers/my-story-about-taking-the-technical-writing-exam" />

世の中にはテクニカルライターという専門職の方もいらっしゃるので、そういった方々には敵わないかもしれませんが…。テクニカルライティングは、1エンジニアとして身につけて損はない技術だと思っているので、ぜひ伸ばしていこうと思っています。せっかく周りから評価してもらえた部分ですし、これからも自分の長所とできるようにしたいものです。

ただ、最近勢いのある AI にとって代わられる可能性のある領域かなとも思いますので、上手い付き合い方も考えていかないとですね。

今回は初めて書籍の紹介記事を書いてみました。内容を書きすぎると営業妨害になりそうで、薄すぎても何が良いのか伝わらなくなりそうで。書くの意外と難しい…。拙い文章で恐縮です。（この記事でこのテクニック活用されてないじゃんとかツッコミがやや怖いですね）

今回紹介した書籍であったり、テクニカルライティングに関心を持ってくれる方がいらっしゃれば幸いです。ドキュメントは軽視しちゃダメですぞ。

参考リンクまとめ

2022年振り返り～技術活動、ブログ編～

Sat, 31 Dec 2022 00:00:00 GMT

{/*  */}

今年は学びの多い1年だったなぁとしみじみ思っている、よしです。例年通り、体調編に引き続き技術活動の振り返りもやっていきますー。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

2022年の活動履歴

コミット履歴

恒例の Git の Contributions 履歴から。

GitHub

今年は 657（個人） + 199（仕事）= 856 でした。

2月に復職して、会社へ慣れることに重きを置いていた1年でもあったので、個人活動は正直あまりできていないですね...。頭の方に devChallenges の活動と、いくつか書籍の学習のコードを記録していたくらい。

仕事少なくね？と思われるかもしれませんが、4月から参加している案件がセルフホスティングの GitLab を使用しているので、ここには上がってきていません。案件外の業務改善活動だったり、内定者アルバイトメンバーの課題レビューとかの履歴ですね。

GitLab

では、案件での活動はどれくらいだったかというと、こんな感じでした。

GitLab って Contributions の合計出してくれないんだっけ？と思いながら計算してみたところ、1448 でした。

実装チケットやったり、レビューしたりとでこれくらいになったみたいです。色が一番濃い日は、多いところだと30 contributions ありました。

ここ数年を比較するとこんな感じ。こうしてみると、昨年や前の会社にいた頃より活動できてたんだなぁと。（2019年が極端に少ないのは、年始から休職〜時短勤務で復職とかだったため）

	2022	2021	2020	2019
GitLab	0	0	0	?
GitHub(個人)	657	2,169	920	231
GitHub(仕事)	199	0	541	76
GitLab(案件)	1,448	-	-	-
合計	2,304	2,169	1,461	307 + ?

復職活動

昨年5月からやってきた復職活動ですが、0社目もとい7社目の会社の内定が1月に出ました。その後、2月中旬に入社して今に至るので、無事にフロントエンドエンジニアとして社会復帰できました。やったーーーーー！！！🎉

この会社はメンタルヘルスに理解があるだけでなく、相談できる専門チームがあるという〜。自分もよくお世話になっています。このチームだけでなく、自分が所属しているチームだったり、案件全体のメンバーだったりと相談できる場がいくつかあって助かっています。ありがてぇ。

復職にあたり体調の波があったりもしましたが、その辺りは振り返り体調編の方に書いています。

ブログ

アクセス履歴

今年の履歴はこんな感じです。例年通り、Google Analytics のデータ部分のみ抜粋。（12月に関しては、執筆時点でのものです）

月	記事数	月のアクセスユーザ数	月のページビュー数
1月	69	692	876
2月	71	694	975
3月	72	818	1,168
4月	72	691	893
5月	73	688	1,080
6月	74	628	802
7月	74	620	769
8月	74	612	809
9月	75	659	831
10月	75	679	852
11月	77	633	927
12月	79	482	662

アクセスユーザ数計：7,896
ページビュー数計：10,644

昨年との比較.

アクセスユーザ数：12,002 → 4,106減
ページビュー数：16,512 → 5,868減

昨年と比べて減りましたね。技術記事は Zenn の方にもクロス投稿しているので、そちらで見ている人が多いのかなというのと。今年は技術の中身っぽい記事がそんなに書けてなかったのもあるのかなぁと思いました。

まぁ、アクセス数のために記事書いているわけではないので、あんまり気にしていないです。

記事執筆について

今年は復職して会社へ慣れることに重きを置いていたこともあり、個人活動はあまりできていませんでした。技術記事に関しても同様ですね。

今年投稿した記事.

あれ、12記事目標にしていたのに10記事しかなくね？と言われそうな気がしますが、一応記事としてはもう2記事書いていたりします。後述しますが、note に1記事と Zenn のみ投稿の1記事がありまして。

なので、ギリギリ目標達成？

リプレースについて

昨年の振り返りの時にも、当ブログを Jekyll から Next.js で作り直したいと言っていたやつです。結論を言うと、結局今年も手を付けないままですね😇

ただ、今の構想を言うと、Next.js でなく Astro でリプレースすると良いのでは？と思っています。 <OG url="https://astro.build" />

Astro は静的サイトに特化したもので。 Zero JavaScript Runtime で高速に動作すると言うのと。コンポーネント実装に React をはじめ既存のフロントエンドライブラリが使用できるといった、面白い特徴を持っていたりします。チュートリアルをやってみましたが、なかなか良さそうだったので試したいなぁと。

ちなみにデザインを少し凝ったものにしたい構想があったのですが、広告との共存を考えると難しいでは？という感じがしてきたので、別に質素なデザインでもええか...という気持ちです。デザインのことを考えると、いつまでもリプレースできなくね？と思ったというのもありますね。

ブログ以外の記事執筆活動

※Zenn および Qiita に投稿した記事は、基本的には当ブログでも投稿しています。

ブログ + Zenn で活動しているのは継続中。基本的にはクロス投稿していますが、一部会社に紐づくものがあったのでそれは対応していません。（ちなみに10月に会社の Publication に所属しました） ~入社エントリは note の方で書いています。~

※2025/09/15...note のリンク、会社記事のリンクは除去しました。

今年 Zenn からいただいた振り返りはこんな感じでした。（12/23までのものです） <ImageWrapper className="w-[70%]" src="screenshots/2022/looking-back-2022-tech/zenn-recap.png" alt="Zenn 2022 Recap - 2022年の活動振り返りデータ - 102,201字の執筆、9記事、2スクラップ、83,251ビュー、528Likes、2個のサポートバッジ" />

12/25投稿の記事があるので、それを足すともう少し数値が上がるかなと。文字数は13万文字くらいに。それでも昨年は20万文字くらい書いていたので減りましたが、ページビュー的には昨年より多かったです。（ページビュー的にもやっぱりブログより Zenn の方が圧倒的に見られていますね）

今年はリンク集が強かったみたいです。

ちなみに Qiita と Crieit は今年活動なしです。

※2024/09/14追記：Crieit はサービスクローズされました。

個人開発

昨年の春頃やってた OOUI - メモアプリは中断したままですね。まぁ、今続きをやるにしても諸々のバージョンがだいぶ上がった関係でコードが古くなってしまっているので、作り直した方がいいのかもしれない...。当時よりもうまく実装できるかもですし。

来年何かやれたらいいですが、devChallenges の Full-stack 編を優先するとか、なんだかんだ他の学習をやってそうな気がしますね。

個人勉強

フロントエンド

TypeScript × React × Next.js を自分のメイン技術にしていたので、その周辺にはアンテナ貼っていたかなと。今年は React 18 とか Next.js 13 とか色々ありましたねー。ただ、正直ちゃんとキャッチアップできてない部分はあります...。

デザイン、アクセシビリティについてもほとんど何もできてないですね。

テストに関しては、案件で書くようになったのでいくらか身についたと思います。とはいえ、E2E テストもわかるようになりたいと言っておきながら、結局やれてない...。（E2E は今の案件では書いていません）

あとは、ブログリプレースのところでも書きましたが、Astro が気になってチュートリアルやったりもしていました。

バックエンド

バックエンドの文脈で Kotlin を少し勉強したりもしていました。今の案件で使われていることもあり。ちょっと読み書きできるようにはしておきたいと思いまして。

自分が昔メイン技術としていた Java の後継的言語なので、気になったというのもありました。実際に勉強していると、当時の Java のつらみみたいなところが Kotlin で改善されていたりしていて、発見がありましたねー。

資格試験

昨年の振り返りで話題にしていた2つの資格については、無事に更新・取得できました。

AWS SAA 更新
HTML プロフェッショナルレベル1

AWS SAP を受験する手もありましたが、ヒヨってしまったので AWS SAA 更新にとどまりましたね。

HTML プロフェッショナルレベル1については、割とギリギリ目の合格でした...😇 来年余裕があればレベル2にチャレンジするのもいいかもしれませんね。

TIL 活動

昨年から勉強記録を Notion に移行して、今も継続中。もはや TIL 活動というより、自分用のメモを記録していっている感じですね。

非公開のページでひたすらメモを残していっているので、外部の方に内容を示すことはできませんが、まぁこの方が続けられている気がします。

その他

devChallenges の Front-end 編を年始の方に終わらせました。（最後の課題については、案内されている API が廃止されていて実質できない状態だったので、7個目まで）

Full-stack 編もやろうとしていたものの、復職して会社に慣れることを優先していたので、ほとんど進められていません。まぁ、しょうがない。

Recursion の勉強は停止したままですね...。自分が停止している間も色々更新があっているのは見かけていたので、また再開したいところではあります。

2023年はどうしていきたいか

ブログ・技術記事

いつもの1年で12記事は継続していきます。今年はあまり技術の中身的な記事が書けてなかったので、来年は何か書きたいところ。 Zenn では会社の Publication に所属しているので、会社のブランディングに良い影響を与えられるような記事も書けると良さそう？

ブログリプレースはどこかでやりたいですねー。 Astro + 質素なデザインでリプレースなら、多分やれるはず...。というかやれ。 Jekyll は悪くないですが、いい加減 Ruby とおさらばしたい気持ち。

個人開発

OOUI の課題を仕切り直すかなと思いつつ、多分やらないような気がします。

web1week のような、小規模アプリを作るような機会があれば何か作るかも。

個人勉強

フロントエンド

TypeScript × React × Next.js をメインに据えるのは継続。今年ちゃんとキャッチアップできていなかった React 18 と Next.js 13 も勉強しておきたいところ。

案件で Storybook やテストを書くようになったこともあり、個人活動でも自然と書けるくらいにはしておきたいですね。作成したストーリーをテストに流用できるの、なかなか便利でした。

バックエンド

あくまで自分の技術としてはフロントエンドを軸にしつつ。今年、Kotlin を勉強したので、せっかくならそれで何か作ってみたいですね。手頃なものでは、devChallenges の Full-stack 編のバックエンド側で使ってみるかなぁという構想があったりします。

FE、BE 両方実装が必要なため、来年だけで完走しきるのは難しそうですが。いくつか進められたらいいなぁと思います。

資格試験

余裕があれば HTML プロフェッショナルレベル2にチャレンジしてみようかと。レベル1と比べてだいぶ出題範囲が広いので、割と勉強しないとやばそうですね😇

あとは、エンジニア0〜1年目の時に3回不合格だった応用情報をリベンジしてみるのもいいかなと思いつつ。あれはまず起床試験がだるいので、受験するかは微妙です。当時よりは知識増えてる分、いくらか飲み込みが早くはなりそうなんですけどね。早起きしんどいんですよ...。

キャリアアップ的な話

プログラミング的な技術力もさることながら。仕事でキャリアアップをしていく中で、以下の能力も伸ばしていかないとなと思っています。

リードエンジニア的な立ち回り
チームのサポート力
ドキュメント力

書籍で学んだり。社内で目標となる人を見つけて。その人から話を聞いてみたり、真似をしてみたり。試行錯誤しながら、能力を伸ばしていきたいですね。

リードエンジニア的な立ち回り

この辺りは、前社時代にほとんど経験できていなかったところで苦手意識すらありました。でも、自分の経験年数的には当然求められることだよなと。

そこから今の案件でエピックの担当になり、そのエピックでリード的な立ち回りをやるようになりました。チームのリードメンバーのサポートを受けながらのチャレンジで、非常に学びが多かったですね。

この辺りを自分1人でもちゃんとできるように、自分の中で確立させていきたいなと。（何もかも1人でやればいいというわけではなくて、必要に応じて人を巻き込みながら自力で進められる程度）

チームのサポート力

リードエンジニア的な立ち回りの話をしましたが、自分の特性上、チームを前で引っ張っていくというのは向いていないようでした。どうもチームのサポート的なポジションが向いているようだったので、後方支援型のリードとして動いていけたらいいのかなと思っています。

ちなみに今の会社でのエンジニア職位としては、リードとテックリードがまた別で定義されており。その中で、テックリードを目指すといいのかなぁとぼんやり考えていたりします。

ドキュメント力

会社でドキュメント力を評価されることが増えたので、そこをさらに伸ばそうかなと。これも後方支援的な話になりそう？

今年は何より社会復帰できたことがよかったなぁと。会社に慣れることを優先していた中でも、仕事を通して非常に学びのある1年になった気がします。

ただ、リードといったチームとしての動き的な能力が伸びた一方で、実装力的な技術力がそこまで伸びなかったかなとも思います。この辺りは、来年個人勉強や活動で強化していきたいところですね。

ここまで読んでくださった方、ありがとうございました。ではでは、皆様、よいお年をお迎えくだされー。

{/*  */}

simple-git-hooksでもブランチ名からIssue番号抽出をやりたくて、わちゃわちゃした話

Mon, 21 Nov 2022 00:00:00 GMT

こんにちは、よしです。今回は記事リハビリということで、ちょっとした小ネタ記事を書いてみました。

import OG from "@/components/OG.astro"

今回やりたかったこと

簡潔に言うと「simple-git-hooks を使った Git フック設定で、ブランチ名から Issue 番号を抽出してコミットメッセージへ自動付与するようにしたい」というやつです。

背景はいいから実際の設定方法見せてくれや、という方は設定方法の結論へどうぞ。

もうちょっと背景を説明してみる

Git フック

皆さんおなじみの Git に Git フックという機能があります。

他のバージョンコントロールシステムと同じように、Git にも特定のアクションが発生した時にカスタムスクリプトを叩く方法があります。このようなフックは、クライアントサイドとサーバーサイドの二つのグループに分けられます。クライアントサイドフックはコミットやマージといったクライアントでの操作の際に、サーバーサイドフックはプッシュされたコミットの受け取りといったネットワーク操作の際に、それぞれ実行されます。これらのフックは、さまざまな目的に用いることができます。

公式にも書いてある通り、Git の特定のアクションが発生した時にカスタムスクリプトを叩く仕組みのことです。（詳細やフックの種類は当記事では説明しないので、公式ページをご参照ください）

この Git フックを使った設定としてよくあるのが...

コミット前に Linter、フォーマッターでコード整形する
ブランチ名から Issue 番号を抽出して、コミットメッセージに自動で付与する

など。

前提として、コミットメッセージに Issue 番号を書いておくと、自動的にその Issue と紐づけをしてくれるのもおなじみですね。（PR なんかでもそうですが）自分は以前から手動で Issue 番号を書いていたので、これを Git フックで自動化したいなぁと思ったのでした。

Git フックに関するパッケージ

Git フックを設定となると、多くの方はそれを扱いやすくしてくれるパッケージを利用しているのではないでしょうか。割と有名なものだと Husky とか。 <OG url="https://typicode.github.io/husky" />

自分が Git フックを活用するようになった頃、ちょうど Husky はライセンス問題でごたごたしていた時だったので、自分は simple-git-hooks の方を採用したのでした。 Husky に対して、こちらは Zero dependency かつ軽量版なやつ。 <OG url="https://github.com/toplenboren/simple-git-hooks" />

じゃあ、simple-git-hooks で今回やりたい仕組みを設定しよう！となったわけですが、ググっても Husky の記事ばかりヒットしまして。基本的な設定方法はおおよそ同じとは思いつつ、実際にやってみるといろいろハマったので、せっかくなら記事にするかとなった次第です。

前提

simple-git-hooks を初期設定済み

動作確認環境.

Windows：Git Bash × GNU sed
Mac：iTerm × BSD sed

設定方法の結論

使用する Git フック

検索でヒットした多くの記事は commit-msg フックを使用して、コミットメッセージの先頭か末尾に番号を付与しているような感じでした。ただ、自分の場合はコミットメッセージの一行目末尾に Issue 番号をつけたくて。

commit-msg フックだとちょっとめんどくさくね...？一行目だけ抽出して末尾に番号付けて、残りの行を結合するとかやらないけなくね...？

ということで、prepare-commit-msg フックを使用する方向に。あらかじめコミットメッセージテンプレに置換用の文字を入れておき、コミットメッセージ入力前にブランチ名から抽出した Issue 番号に置換する、ということをやることにしました。

このやり方は、こちらの記事を参考にさせていただきました。 <OG url="https://tech.mobilefactory.jp/entry/2021/12/06/000000" />

コミットメッセージテンプレ

使用するコミットメッセージテンプレの1行目に置換用のテキストを入れておきます。

(#Issue)

prepare-commit-msg フックのスクリプト

prepare-commit-msg はコミットメッセージを入力する前に実行されるフックです。後述しますが、sed コマンドが GNU でも BSD でも動作するように組んでます。

ブランチ名の前部分がブランチ種別/Issue番号という命名だと抽出する仕組み。ブランチ種別部分は一旦以下の3つにしました。

feature
bugfix
release

ブランチ名の例.

feature/1
feature/1-test

#!/bin/sh

## sed コマンドが GNU か BSD か確認
GNU_SED=true
sed --version 1>/dev/null 2>/dev/null || GNU_SED=false
echo $GNU_SED

## コミットメッセージ入力前に、ブランチ名から Issue 番号を抽出して置換する
COMMIT_MSG_FILE=$1
MESSAGE=$(cat "$COMMIT_MSG_FILE")

ISSUE_NUMBER=$(git rev-parse --abbrev-ref HEAD | grep -Eo "^(feature|bugfix|release)/[0-9]+" | grep -Eo "[0-9]+")
if [ -n "$ISSUE_NUMBER" ]; then
  if [ "$GNU_SED" == "true" ]; then
    sed -i "s/(#Issue)/(#$ISSUE_NUMBER)/" $COMMIT_MSG_FILE
  else
    sed -i "" "s/(#Issue)/(#$ISSUE_NUMBER)/" $COMMIT_MSG_FILE
  fi
  exit 0
fi

## Issue 番号が抽出できなかった + そのまま続行する場合は、置換用文字列を除去する
read -p "Issue 番号がブランチ名にないので置換できませんが、続行しますか？ (y/N): " YM < /dev/tty
case "$YM" in
  [yY]*)
    if [ "$GNU_SED" == "true" ]; then
      sed -i "s/(#Issue)//" $COMMIT_MSG_FILE
    else
      sed -i "" "s/(#Issue)//" $COMMIT_MSG_FILE
    fi;;
  *) echo "abort." ; exit 1 ;;
esac

Mac の場合は、ファイル作成時に実行権限がつかない？ようだったので実行権限を付与しておく必要がありました。

chmod a+x .githooks/prepare-commit-msg

simple-git-hooks の設定

前述のカスタムのフックスクリプトを実行するように書けばいいわけですが、\"$@\"で引数を渡すのを忘れずに（引数に関しては後述も参照）

// 抜粋
"simple-git-hooks": {
  "prepare-commit-msg": "./.githooks/prepare-commit-msg \"$@\""
},

これらの内容で、simple-git-hooks の設定を反映。以降は、コミットしてコミットメッセージ入力前にフックスクリプトが動作して、置換用テキストがブランチ名から抽出した Issue 番号に指し変わっているはずです。

躓いたところと補足説明

たったこれだけの設定をするだけでも、意外といろんなところに躓きました。（普段、シェル書き慣れてないのもあるかも😇）

せっかくなので、どのあたりに躓いたのかと、その補足説明も書いておこうかと。

引数が入らない？

最初、いろんな記事を読んでみたところ、フックスクリプトの引数$1にコミットメッセージファイルの情報が入ってくることがわかりました。なので、$1を使うようなシェルを書いていったわけですが、いざ実行するとなぜか値が入ってこない...。引数の数が入る$#を確認すると0。

どういうこと??? simple-git-hooks だとなんか引数の渡り方が違うんか???と混乱。原因としては、simple-git-hooks の設定定義時に引数を渡すような書き方をしていなかったせいでした。

// 誤
"prepare-commit-msg": "./.githooks/prepare-commit-msg"

// 正
"prepare-commit-msg": "./.githooks/prepare-commit-msg \"$@\""

{/*  */}

simple-git-hooks は設定したフックの種類に応じて、.git/hooks配下にフックファイルを作成します。（今回だと.git/hooks/prepare-commit-msg）そのフックファイルの中で、simple-git-hooks 設定で設定したコマンドを実行する、というような仕組みになっているのです。

{/*  */}

#!/bin/sh
./git-hook/commit-msg "$@"

そのため、元々のフックファイルへ渡されるようになっている引数をカスタムのフックの方でも使用したい場合は、そのまま引数を渡してあげれば OK。

引数渡してないんだから、そりゃあ引数ないってなるやん。

read の処理で止まってくれない

ブランチ名から Issue 番号を抽出するにあたり、もし番号が見つからなかった場合は、そのまま続行してよいか応答処理を入れるようにしました。

こちらの記事を見て、シェルで応答処理を実現するには read を使えばいいらしいぞとわかり、書いてみて動作確認。すると、本来はユーザの入力待ち状態になり止まってくれるはずなのですが、止まってくれない...。どうもユーザ入力部分が勝手に入力されて、y でも Y でもないので続行しない方の処理に進んでしまっているようでした。

この件を調べてみると、ループ処理の中で read を使っているとそういうことがあるという記事がいくつかヒット。今回はループ処理の中ではないんだけどなと思いつつ。コンソールからの入力しか受け付けないようにするには< /dev/ttyをつけるとよいとのことだったので、つけたところ止まってくれるようになりました。 <OG url="https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q12125082002" />

sed コマンドの違い

Windows（Git Bash）でも Mac でも使用できる sed コマンドですが、どうも2種類あって、微妙に挙動が違うらしいとわかり。種類としては以下の2つ。

Windows（Git Bash）or Linux：GNU sed
Mac：BSD sed

今回使用している、ファイル上書きの-iオプションも挙動が違うものの1つでして。 BSD sed の方では、-iオプションの後ろにバックアップファイルの拡張子をつける必要があるとのこと。（バックアップファイルを作りたくない場合は、空文字にすると作られません）

# GNU sed
sed -i "s/(#Issue)/(#$ISSUE_NUMBER)/" $COMMIT_MSG_FILE

# BSD sed
sed -i "" "s/(#Issue)/(#$ISSUE_NUMBER)/" $COMMIT_MSG_FILE

そのため、できればどちらでも動作するようなスクリプトにしたいなぁと試行錯誤でわちゃわちゃして。結果的に、sed --versionコマンドの実行結果でどちらの sed なのか判断するフラグ変数を作り、それで分岐させるようにしました。 BSD sed の場合は、--versionオプションが存在しないのでエラーになることを利用したものです。

それとsed --versionの実行結果を出力はしたくなかったので、1>/dev/null 2>/dev/nullで出力しないようにしています。 <OG url="https://qiita.com/harasakih/items/868a850fcdc99a2c37b0" />

以上、小ネタ記事をお送りしました。自分は普段シェルをあまり書いてない人間なので、なかなかうまくいかなくて四苦八苦...😇

とはいえ、前からやりたいと思っていた仕組みを作ることができたので、これからばっちり活用していきたいですね。

採用こそしなかったですが、Git フックってほかの言語でも書けるらしく、へーそうなんだーという発見があったり。 Git フックの理解が少し深まったので、ほかにも便利そうなスクリプト組んでみるのもよさそうです。また、何かあったら記事にするかもしれません。

参考リンクまとめ

devChallenges - Front-end 編を完走？したので、さっくり振り返ってみた

Fri, 04 Mar 2022 00:00:00 GMT

こんにちは、先日復職して現在進行形で復活中のよしです。 devChallenges の課題をさらに1コース完走？したので、また振り返ってみました。

※翻訳は Google 翻訳を使用しています。 ※2023/09/25...devChallenges が全面リニューアルしたため、旧課題は legacy サブドメインの方に移りました。リンクを修正。 ※2025/02/09...legacy サブドメインのサイトがクローズされたようでアクセスできなくなっていました。それに伴いサイトへのリンクを除去。

import OG from "@/components/OG.astro"

devChallenges のおさらい

※https://legacy.devchallenges.ioというドメインでかつてはサイトがありましたが、現在はクローズされたようです。

ざっくりいうと、Web Developer になるための学習コンテンツや課題を提供しているコミュニティです。こちらで提供されているものに、Figma のデザインデータとユーザストーリーを元に課題作品を作るというものが3コースあり。そのうちの Fron-end 編をやったので振り返るよというのが今回の趣旨です。

この辺りは Responsive Web 編の振り返りをした前回の記事でも書いたので、ちょっと端折ります。

devChallenges - Responsive Web 編を完走したので、さっくり振り返ってみた

Front-end 編の課題を振り返ってみる

Responsive Web 編が主に Web サイトのページの制作だったのに対して、Front-end 編ではモックデータや外部 API を利用した Web アプリを作るようなものが主になります。

難易度的には先に Responsive Web 編をやった方がいいかなぁといった感じですが、自分は Front-end 編を先に開始してしまったので、前半の課題はなかなか苦戦しました...。（Front-end 編折り返しくらいで Responsive Web 編を先にやってから、続きをやりました）

Use a Front-end Framework and choose any Frameworks or Libraries

訳：フロントエンドフレームワークを使用し、フレームワークまたはライブラリを選択します

Front-end 編のルールの1つにこうあるので、自分は Next.js を練習がてら採用。どの課題も TypeScript × Next.js × emotion で作成しています。

では、8課題をさっくり振り返っていきます。（あまり実装のネタバレにならないような書き方としました）

完走？

振り返ると言っておきながら、先に言っておくことがありまして。

当記事のタイトルを完走？としている件。 Front-end 編も8課題用意されてはいるのですが、実は最後の課題だけ進めることができませんでした。というのも、この課題で使用案内されていた GitHub Jobs API がすでに廃止されて使えなくなっていたためです。 <OG url="https://github.blog/changelog/2021-04-19-deprecation-notice-github-jobs-site" />

デザインデータはあるので、適当にモックデータを作ってやる手もあったのですが、そこまでしてやる価値があるかな？というのが気になってしまいまして。他に求人情報を提供する API は探せばあるでしょうが、同様にそこまでしてやらなくていいかな、というので今回は進めていません。

そのため、振り返るのは最後の課題以外の7課題になります。

1 - Button component

ユーザストーリー.

I can see different button types: default, outline and text （訳：さまざまなボタンタイプが表示されます：デフォルト、アウトライン、テキスト）
I can choose to disable box-shadow （訳：ボックスシャドウを無効にすることを選択できます）
I can choose to disable the button （訳：ボタンを無効にすることを選択できます）
I can choose to have an icon on the left or right (Use Google Icon and at least 5 variants) （訳：左側または右側にアイコンを表示するように選択できます - Googleアイコンと少なくとも5つのバリエーションを使用）
I can have different button sizes （訳：ボタンのサイズを変えることができます）
I can have different colors （訳：色を変えてもいい）
When I hover or focus, I can see visual indicators （訳：ホバーまたはフォーカスすると、視覚的なインジケーターが表示されます）
I can still access all button attributes （訳：引き続きすべてのボタン属性にアクセスできます）
(optional) Show button in a similar way like the design or use Storybook. Otherwise, showing the button in multiple states is enough （訳：デザインと同じようにボタンを表示するか、ストーリーブックを使用します。それ以外の場合は、ボタンを複数の状態で表示するだけで十分です）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-button-component" />

ボタンコンポーネントと、そのカタログページを作る課題。ボタンコンポーネントをいかに汎用的に作るか？を考えていきます。

自分が devChallenges の課題で一番最初にやった課題で、当時は HTML・CSS 基礎力もガタガタというひどい状態だったので、なかなか時間がかかりました。まだ自分のやり方があまり定まってなかった部分もありましたし。慣れてる方だったらポンポンと終わるんじゃないかなぁと。

執筆時点で、オプションの Storybook のやつはやっていません。

2 - Input component

ユーザストーリー.

I can see error state （訳：エラー状態を確認できます）
I can choose to disable input （訳：入力を無効にすることを選択できます）
I can choose to have helper text （訳：ヘルパーテキストを選択できます）
I can choose to have an icon on the left or right (Use Google Icon and at least 5 variants) （訳：左側または右側にアイコンを表示するように選択できます - Googleアイコンと少なくとも5つのバリエーションを使用）
I can have different input sizes （訳：さまざまな入力サイズを使用できます）
I can have different colors （訳：色を変えてもいい）
I can choose to have input take the width of the parent （訳：入力に親の幅を使用させることを選択できます）
I can have multiline input like a textarea （訳：テキストエリアのように複数行入力できます）
When I hover or focus, I can see visual indicators （訳：ホバーまたはフォーカスすると、視覚的なインジケーターが表示されます）
I can still access all input attributes （訳：引き続きすべての入力属性にアクセスできます）
(optional) Show input in a similar way like the design or use Storybook. Otherwise, showing the input in multiple states is enough （訳：デザインと同様の方法で入力を表示するか、ストーリーブックを使用します。それ以外の場合は、複数の状態で入力を表示するだけで十分です）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-input-component" />

インプットコンポーネントと、そのカタログページを作る課題。前回の課題の input 版ですね。同様にいかに汎用的なインプットコンポーネントを作るか、アイコンも付与できるようなコンポーネントをどう作るか、などを考えていきます。

input は button と比べて装飾の仕方が変わってくるので、まだそれに慣れてなかった当時の自分はそこそこ苦戦してた気がします。アイコン入れるのどうやんのー！？みたいな。

これも執筆時点で、オプションの Storybook のやつはやっていません。

I can still access all input attributes （訳：引き続きすべての入力属性にアクセスできます）

ユーザストーリーのこちらに関して。解釈の仕方は色々ありそうな気がするのですが、カスタムの Input コンポーネントと input タグとで競合する props を排除してたりするので、満たせてないかな？と思い下記のような補足説明を加えた状態にしています。

{/*  */}

excluded some props whose settings conflict with custom props. Also, Since it was created as a component for text input, the type of input element is limited to text format.

訳：設定がカスタム props と競合する一部の props を除外しました。また、テキスト入力のコンポーネントとして作成されたため、入力要素のタイプはテキスト形式に制限されます。

{/*  */}

3 - Windbnb

{/*  */}

ユーザストーリー.

I can see a list of properties （訳：プロパティのリストが表示されます）
I can see the property card with a name, rating, apartment type, and super host （訳：名前、評価、アパートの種類、スーパーホストが記載されたプロパティカードが表示されます）
I can open the filter drawer （訳：フィルタードロワーを開けます）
I can filter properties by location and number of guests （訳：場所とゲストの数でプロパティをフィルタリングできます）
I can see the number of filtered items （訳：フィルタリングされたアイテムの数を確認できます）
I can see pages following given designs （訳：与えられたデザインに続くページを見ることができます）

{/*  */}

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-windbnb" />

簡易的な検索機能を持つ、ミニマムな Airbnb クローンを作る課題。データについてはモックデータが用意されているので、それを使用。データの表示をどうやるか、ドロワーをどう作るか、などを考えていきます。

自分は最初、無理に React Query を使うようなやり方をしていたので余計に複雑化させてしまっていました😇 推しているライブラリだからって、何でもかんでも使うの良くない。（のちにローカル state を使うようなリファクタリングして除去しました）

それとドロワーの実装はすごい悩みました。これもまた当時は慣れてなくて。なんかアニメーションがうまくいかない！？（クローズ時のアニメーションが動作しない）とか、ドロワー開いている時のその下にあるコンテンツの操作制御のあたりとか。

Material UI のドロワーコンポーネントのスタイルを参考にしたりしつつ、操作制御に関して悩んだツイートをしていたら、フォロワーの方に inert 属性のことを教えていただきました。

<blockquote class="twitter-tweet"> <p lang="ja" dir="ltr">Material UI の実装はわからないですかが、この辺が役に立つかもしれません<a href="https://t.co/mJu19xy3Em">https://t.co/mJu19xy3Em</a><br /><br />ポリフィル<a href="https://t.co/NXV7BWLdaP">https://t.co/NXV7BWLdaP</a> </p>— ジャングル大帝 (@LEO_i7) <a href="https://twitter.com/LEO_i7/status/1406195146287321089?ref_src=twsrc%5Etfw">June 19, 2021</a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

こんな便利な属性があったのかー！と大きな発見でしたね。これ以降、ドロワーやメニューを実装する時は inert 属性を活用するようになりました。 Responsive Web 編でも活用してたやつですね。

4 - Todo app

ユーザストーリー.

I can add a new task （訳：新しいタスクを追加できます）
I can complete a task （訳：タスクを完了できます）
I can toggle between All, Active and Completed （訳：All、Active、Completedを切り替えることができます）
I can remove one or all tasks under the Completed tab （訳：タブで1つまたはすべてのタスクを削除できます）
(optional) Store the data in local storage that when I refresh the page I can still see my progress （訳：データをローカルストレージに保存します。ページを更新しても、進行状況を確認できます。）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-todo-app" />

Todo アプリを作る課題。 Todo のデータや状態をどう管理するかを考えていきます。

自分はローカルストレージによる永続化にもチャレンジしました。ローカルストレージを使ったことは何気にこれが初めてだったので、最初はちょっと戸惑いましたね。やや癖がある感じというか。慣れてさえしまえば処理の使い回しとかできるんでしょうが。他タブでのストレージ変更を検知するイベントの存在なんかも知ることができました。

5 - Random quote generator

ユーザストーリー.

I can see a random quote （訳：私はランダムな引用を見ることができます）
I generate a new random quote （訳：新しいランダムな引用を生成します）
When I select quote author, I can see a list of quotes from them （訳：引用著者を選択すると、それらからの引用のリストが表示されます）
I can see quote genre under the author （訳：著者の下で引用のジャンルを見ることができます）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-random-quote-generator" />

QuoteGarden API を使用した、名言引用アプリを作る課題。この課題から外部 API を使うような形式に。外部 API から取得したデータを活用して、どうアプリを作っていくかを考えていきます。

業務で API との連携は経験あったので、この課題はそんなに苦戦しなかった気がします。

6 - Country quiz

{/*  */}

ユーザストーリー.

I can see at least 2 types of questions: a city is the capital of.. or a flag belong to country.. （訳：私は少なくとも2つのタイプの質問を見ることができます：都市は首都です..または旗は国に属します..）
I can see select an answer （訳：私は答えを選択するのを見ることができます）
I can see if my answer is correct or incorrect （訳：答えが正しいか間違っているかがわかります）
When I answer correctly, I can move on to the next question （訳：正解したら次の質問に移ります）
When I answer incorrectly, I can see my results and try again （訳：間違って答えると、結果を確認して再試行できます）
I can try again （訳：もう一度試すことができます）

{/*  */}

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-country-quiz" />

REST COUNTRIES API を使用した、国情報クイズアプリを作る課題。外部 API から取得したデータをそのまま表示するのではなく、クイズ用に加工するのをどうするか、というのを考えていきます。

課題上で案内されていた REST COUNTRIES API はhttps://restcountries.eu/でしたが、こちらは現在サブスクリプション API になったそうで使用できませんでした。そのため、この API のオープンソース版を作られた方がいて、今回はそちらを使わせていただきました。 <OG url="https://restcountries.com" />

最初は、取得したデータをクイズ用に加工するイメージや、どの状態管理が必要であるかといったイメージがなかなかスムーズにいかなくて苦戦しました。その中でふと Responsive Web 編を先にやろうかななんて思いついてしまったので、その時点での記録を Issue に残しておいて、この課題をしばらく中断。 Responsive Web 編を終えて戻ってきた頃には、なんとなく実装のイメージが浮かんで課題を進められました。詰まった時に時間を置くのは、やはり有効ですね(笑)

ただ、ユーザストーリーを少し勘違いしていたところがあり。本来は連続何問正解できるかな？というクイズ形式のはずが、10問中いくつ正解できるかな？という仕様で実装してしまっていました。実はこの記事を書いて振り返りをしている時に気づいて、慌てて修正してたりします😅

これまで何気に使ったことがなかったコンテクストを使った実装にもチャレンジできて、その使い方がおおよそわかってよかったです。

7 - Weather app

ユーザストーリー.

I can see city weather as default, preferably my current location （訳：私はデフォルトとして都市の天気を見ることができます、できれば私の現在の場所）
I can search for city （訳：都市を検索できます）
I can see weather of today and the next 5 days （訳：今日と次の5日間の天気を見ることができます）
I can see the date and location of the weather （訳：天気の日付と場所がわかります）
I can see according to image for each type of weather （訳：天気の種類ごとに画像で見ることができます）
I can see the min and max degree each day （訳：毎日最小度と最大度を見ることができます）
I can see wind status and wind direction （訳：風の状態と風向がわかります）
I can see humidity percentage （訳：湿度のパーセンテージがわかります）
I can see a visibility indicator （訳：視界インジケーターが見えます）
I can see the air pressure number （訳：気圧数がわかります）
(optional) I can request my current location weather （訳：現在地の天気をリクエストできます）
(optional) I can convert temperature in Celcius to Fahrenheit and vice versa （訳：摂氏の温度を華氏に、またはその逆に変換できます）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-weather-app" />

MetaWeather API を使用した、天気予報アプリを作るチャレンジ。位置情報をどうやって取得するか、都市検索機能をどう実装するかなどを考えていきます。 API をフロント側から直接呼ぶと CORS に引っかかるので、その辺りの対応も必要になってきます。

※2023/11/25追記 MetaWeather API が使えなくなったため、現在は OpenWeather APIで案内されています。

Country quiz のようなデータ加工はあまり必要ないので、人によってはこちらの方が簡単かも？少しデザイン性のある課題なので、完成した時に「おー！」ってなったりするかもです。自分はちょっとそうなりました(笑) メーターを表現する要素のことを知れたりと、新しい発見もありましたね。

主な使用した技術やライブラリなどの振り返り

これを書くと若干実装のネタバレになる気もしますが、せっかくなので今回も一緒に振り返ってみました。 Responsive Web 編でも書いたやつは、サラッとだけ書いてます。（当記事の投稿時点での使用技術です）

TypeScript × Next.js × emotion

はじめの方に書いた通り、Front-end 編では全部この構成でやっています。 Next.js の勉強というのと、 CSS in JS をどれかひとつはわかるようになりたいというので emotion を採用したという経緯がありました。課題を通して理解を深められたので、実案件にも活かしていきたいところです。

静的解析 + フォーマッタ

フロントエンドでお馴染みのやつです。 VSCode 拡張として自動整形を動作させたり、GitHub Actions 上でもチェック、コミット時に自動整形したりとしてました。

Material Icons

Front-end 編でも、アイコンはこちらを使うように案内があったので使用しています。 emotion を使っているので、emotion-icons 経由で使用。

modern-css-reset

個人的にちょうどいいと思っているリセット CSS なので使ってます。

wicg-inert

Windbnb のところでも触れた、inert 属性のポリフィル。ドロワーやメニュー、モーダル UI での要素の非活性制御をやりやすくするやつ。（スクロール抑制には対応してないので、そこは別途対応が必要）

inert 属性の説明に関しては、こちらの記事がやはりとても参考になるのでまた載せておきます。 <OG url="https://standard.shiftbrain.com/blog/unavailable-inert-regions-and-inert-attribute" />

focus-visible

focus-visible 疑似クラスのポリフィル。 focus-visible 疑似クラスは Safari の対応がイマイチなので、ポリフィルを使うようにしています。

主に使用しているのは button 要素の outline 制御のあたり。

csx

CSS に関するユーティリティな関数を提供するやつ。主に色の制御に使うことが多いです。

RGB 値からでなくカラーコードを基準とした暗い色や明るい色、透明度を反映させた色を作りたいことがあったので、このライブラリを使った関数を作って活用。 Sass だったら元々関数が用意されているんですが、emotion だと使えないっぽかったので。

uuid

UUID を生成してくれるやつ。 Todo app で一意の ID をつけたかったので使用。今思えば、別に UUID じゃなくてもよかったかな...。

ky・ky-universal

fetch ベースの HTTP クライアントライブラリ。後者の方は、フロントエンド、サーバーサイド両方で使えるやつ。

外部 API を利用する課題で使用。最近は axios からこちらに移行している流れを感じているので、昨年あたりから使うようになりました。ただ、型安全な HTTP リクエストでお馴染みの Aspida が ky をサポートしていないので、今後は使わなくなっていくかも？

React Query

キャッシュ機構も含んだ状態管理ライブラリ。一部の課題で外部 API から取得したデータを保持するのに使用。

同様の機能を持つライブラリはいくつかありますが、個人的には React Query が使いやすい感じに思えたので使用しています。コンテクストやローカル state との使い分け、もしくは組み合わせの辺りをもっと追求して、いい感じにしていきたい。

{/*  */}

完走？してどうだった？

devChallenges を始めたきっかけに関しては、Responsive Web 編の記事でも書いたのでざっくりいうと、自分の HTML・CSS 基礎力弱弱じゃね？と思う出来事があったからです。ホント、トラウマになりそうな出来事がありましてね...。それを克服するために始めたわけです。 React 周りを伸ばしていきたかったので、その流れで Next.js や emotion の勉強も兼ねて。

やっぱり実際に何か作ってみるというのは、すごく勉強になりますね！自信にも繋がりますし、本当にやってよかったなぁと心から思います。

ちなみに devChallenges を始めた頃は復職活動をしていた時期でして、つい先月に復職したところです。この復職先でのコーディング試験では、devChallenges を通して学んだことがすごく活きたと思っているので、そういう意味でもやってよかったなぁと。

ただ、テストコードが全然書けていないので、テストの勉強がてらテストコードを書いてみようかなとも構想中です。

{/*  */}

今回は Front-end 編の振り返りをさっくりお送りしました。

残りは Full-stack 編となりましたが、これはバックエンドも含むので1課題作るだけでも時間かかりそうですね。仕事との兼ね合いもあるので、やるかどうかは微妙なところではありますが、勉強になることは間違いないので前向きに検討しようかなと。

devChallenges、興味を持たれた方はぜひチャレンジしてみてはいかがでしょうか。ではではー。

参考リンクまとめ

※記事系のみ.

UIにおける見えるけど利用できない非活性な領域の実装とinert属性について

TypeScript × Aspida × Zodで型安全なHTTPリクエストについて考えてみた

Sat, 12 Feb 2022 00:00:00 GMT

TypeScrpt の型定義に日々助けられているなぁ、なんて思っている、よしです。今回は型安全な HTTP リクエストについて検証してみたことを書いてみました。

import OG from "@/components/OG.astro"

検証しようと思った背景

ざっくりいうと、フロントエンドの実装をしていて、API のレスポンスチェック用に毎回自前の型ガード実装するのだるいなと思ったことがあったからです。

こういうやつ.

export type User = {
  id: number;
  name: string;
};

export type Users = User[]

const isUser = (arg: unknown): arg is User => {
  const u = arg as User;

  return (
    typeof u.id === 'number' &&
    typeof u.name === 'string'
  );
};

const isUsers = (args: unknown): args is Users => {
  const us = args as Users;

  return us.every((u) => isUser(u));
};

export { isUser, isUsers }

API のレスポンスボディの中身が少なければ、まぁさっくり実装すればいいんですが...。外部 API とかで中身がなんか多いやつだと、一個一個書くの地味につらみがありまして。

そこから、型ガード対応しているバリデーションライブラリ導入してみるかな？ ↓ せっかくならリクエスト時も型安全にしてみる？という流れで導入検証してみようという発想になりました。

使用するライブラリ

当記事ではさらっと紹介だけします。ライブラリの詳細は各リポジトリの README 等をご参照ください。

Aspida

ブラウザと node.js のための TypeScript フレンドリーな HTTP クライアントラッパー

HTTP クライアントライブラリ自体と、その HTTP クライアントライブラリのラッパーパッケージを組み合わせるような使い方をします。

作者の方の紹介記事はこちら <OG url="https://zenn.dev/solufa/articles/getting-started-with-aspida" />

型安全な HTTP リクエスト、といえば Aspida の名を前からよく聞いて気になっていました。記事などでも割と好印象な話を聞いていたイメージ。よっしゃ、使ってみようとまず改めて少し調べてみると、ちょっと気になったところが。

レスポンスの型チェックについて

Aspida の特徴の1つとして以下のようなものがあります。

パス・URL クエリ・ヘッダー・ボディ・レスポンス全てに型を指定できる

とても頼もしいライブラリであることは確かなのですが、この「レスポンスの型」について。紹介記事なんかでも、よくこのことに触れられていて「レスポンスに型がつく！」「型がつくので補完がきく！」なんて書いてあったり。でも「そもそもレスポンスがちゃんと想定した形式で返ってきているかのチェック」について書いてあるのは、ほとんど見かけなかったんですよね。

自分は最近では、HTTP リクエストで取得したデータに対して、型ガードでチェックするような実装をすることが多く。そのため、このチェックまで Aspida が面倒を見てくれるのか否かが気になってしまったのでした。結論を言うと、Aspida はさすがにそこまでは面倒を見てくれません。他のライブラリや自前の型ガードと組み合わせるなりする必要があります。

ちなみに v2 でその辺も対応しようと現在検討されていることを、メンテナの方に教えていただきました。ただ、どうも難航しているようです。

<blockquote class="twitter-tweet"> <p lang="ja" dir="ltr">現状、レスポンスデータの検証がされていないのは仕様です。aspida v2で対応したいと考えており、開発中ですが、他ライブラリとの兼ね合いなどにより難航しています。 </p>— はす (@83_hasu) <a href="https://twitter.com/83_hasu/status/1489539954904481793?ref_src=twsrc%5Etfw">February 4, 2022</a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

なかなか難しい問題ではあるでしょうが、もし対応されたら、ますます強力なものになりますね。

@aspida/ky について

個人的に最近使用している HTTP クライアントライブラリが ky であるため、Aspida は ky に対応しているのかが気になりました。紹介記事なんかでは ky に対応しているともあるものの、リポジトリの packages 配下に ky に関するパッケージが存在しない...。

調べてみたところ、どうも v1.1.0 リリース時にサポートを終了されたそうです。そんなにダウンロード数少なかったのか...。

作者の方のツイート.

<blockquote class="twitter-tweet"> <p lang="ja" dir="ltr">aspida v1.1.0 をリリースしました🎉🎉<br /><br />- 1DL/日しかない ky のサポート終了<br />- swr と swrv の型を整理<br />- パス名の@以降に number/string 以外を指定できる隠し機能を削除<br /><br />十分な利用実績が出来たのでv1に上げました<br />隠し機能を使っていなければコード修正なく更新出来ます<a href="https://t.co/bLjiq5P99w">https://t.co/bLjiq5P99w</a> </p>— Solufa (@m_mitsuhide) <a href="https://twitter.com/m_mitsuhide/status/1338257674043936769?ref_src=twsrc%5Etfw">December 13, 2020</a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

ただ、npm パッケージとしては一応残っているようです。 <OG url="https://www.npmjs.com/package/@aspida/ky" />

{/*  */}

ky は fetch API を拡張したものなので、色々と便利な機能が追加されていたりします。その1つとして、レスポンスがステータスコード 400、500番台で返ってきたときに自動で HTTPError をスローしてくれる、というものがありまして。これに関しては、@aspida/fetch（もしくは @aspida/node-fetch）のオプションで、そのような挙動へできることが分かったため、今回は @aspida/fetch を採用することにしました。

{/*  */}

Zod

Zod is a TypeScript-first schema declaration and validation library. I'm using the term "schema" to broadly refer to any data type, from a simple string to a complex nested object.

型ガードに対応しているバリデーションライブラリはどれがいいかなと調べてみると、割と結構いろんなものがありましたね。その中で、今回は Blitz.js でも採用されている Zod を採用することにしました。

あらかじめ Zod でスキーマを定義しておいて、そのスキーマに沿ってバリデーションチェックを行うような使い方をします。

型ガードは廃止？

意気揚々と導入しておいてなんですが、いざ実装する時に、Zod に存在すると思っていた型ガード機能が廃止されていることを知りました。

The .check method has been removed in Zod 3. For details see

どうも、以前はcheck()というものがあったものの、v3 リリース時に削除されたそうです。

公式のサンプル.

import * as z from 'zod';

const stringSchema = z.string();
const blob: any = 'Albuquerque';
if (stringSchema.check(blob)) {
  // blob is now of type `string`
  // within this if statement
}

じゃあ、チェックはどうする？というところですが、Zod でバリデーションチェックするものとしてparse()というものがあります。これはバリデーションチェック OK であれば通過したものを返し、NG であれば ZodError をスローする、というものです。これでもやりたいことはできるので特に問題なし。check()が削除されたのも恐らくそのためでしょう。ちなみに NG 時に ZodError をスローしないsafeParse()というものもあります。

公式のサンプル.

import { z } from "zod";

// creating a schema for strings
const mySchema = z.string();

// parsing
mySchema.parse("tuna"); // => "tuna"
mySchema.parse(12); // => throws ZodError

// "safe" parsing (doesn't throw error if validation fails)
mySchema.safeParse("tuna"); // => { success: true; data: "tuna" }
mySchema.safeParse(12); // => { success: false; error: ZodError }

これまでの型ガード実装時は、型チェック結果の boolean により if 分岐をかけて、NG 時にエラーをスローするのを自前でやっていました。それに対して、このparse()を使えば if ブロックを1つ減らせるので、よりスッキリ書けますね。

既存の型定義からスキーマを作成することについて

Zod で定義したスキーマを元に型定義を生成する方法は、README に記載がありました。 inferとtypeofの組み合わせでいけるそうです。

公式のサンプル.

const A = z.string();
type A = z.infer<typeof A>; // string

const u: A = 12; // TypeError
const u: A = "asdf"; // compiles

では、逆に既存の型定義からスキーマを生成することは出来るのか？というところが気になりました。途中から Zod を導入する場合とか、このパターンが欲しいこと割とあると思ったんですよね。

調べていたら、ちょうど試している方がいて、このやり方を使わせていただきました。 <OG url="https://zenn.dev/uttk/articles/bd264fa884e026#%E5%9E%8B%E5%BC%95%E6%95%B0%E3%81%AE%E6%B8%A1%E3%81%97%E6%96%B9" />

import * as z from "zod";

// zodに渡せる型に変換する型
type toZod<T extends Record<string, any>> = {
  [K in keyof T]-?: z.ZodType<T[K]>;
}

interface Hoge {
  hello: string;
  world: string;
}

// Hogeを型引数として渡す
const HogeSchema = z.object<toZod<IHoge>>({
  hello: z.string(),
  world: z.string()
})

上記の場合。 HogeSchema では、元の型定義にないプロパティを定義しようとしたり、違う型にしようとするとちゃんとエラーになってくれます。プロパティの入力補完も効いてくれるので便利でした。

実装例

では、今回自分がやってみた実装を書いていきます。なお、Aspida の README の内容をベースとしました。

今回の使用バージョンは以下の通りです.

TypeScript：4.5.5
Node.js：16.13.0
Next.js：12.0.9
@aspida/fetch：1.7.1
Zod：3.11.6

ディレクトリ階層（関連する部分のみ抜粋）

（ルート）
┣ src
║  ┣ api/  #Adpida 用の API 型定義置き場
║  ║  ┣ users/
║  ║  ║  ┣ _userId@number/
║  ║  ║  ║    ┗ index.ts
║  ║  ║  ┗ index.ts
║  ║  ┗ $api.ts
║  ┣ compnents/  #各種コンポーネント置き場
║  ┣ domains/  #ドメイン（HTTP リクエストロジック置き場）
║  ┣ hooks/  #カスタムフック置き場（domains のラッパー）
║  ┣ lib/  #ライブラリの設定やユーティリティなどの置き場
║  ┣ mock/  #モックデータ置き場
║  ┣ models/  #モデル型定義置き場
║  ┗ pages/
║      ┣ api
║      ┣ _app.tsx
║      ┗ index.tsx
┣ .gitignore
┣ aspida.config.js
┣ package.json
┣ tsconfig.json
┗ yarn.lock

コードはこちらのリポジトリにあるので、よろしければどうぞ。 <OG url="https://github.com/h-yoshikawa44/type-safe-request" />

API 情報

API は Next.js の API ルートでモック API を作成。

ユーザ情報一覧取得 API

パス：api/users
メソッド：GET
クエリパラメータ：
- limit?: number
レスポンスボディ：
- ユーザ情報の配列

ユーザ情報取得 API

パス：api/users/{userId}
メソッド：GET
パスパラメータ：
- userId: number
レスポンスボディ：
- ユーザ情報

ユーザ新規作成 API

パス：api/users
メソッド：POST
リクエストボディ：
- name: string
レスポンスボディ：
- ユーザ情報

前準備

インストール

Aspida と Zod のインストール。

yarn add @aspida/fetch zod

直接 Adpida と Zod には関係ありませんが、コマンド並列実行をするためにこちらもいれておきます。

yarn add -D npm-run-all

Aspida の設定

Aspida 用の API 型定義ファイルを置く場所を作る必要があるのですが、自分はsrc/apiとしました。設定ファイルでこのパスを指定しておきます。

module.exports = {
  input: 'src/api',
};

Zod の設定

tsconfig の strict モードを有効化しておく必要があります。

{
  // ...
  "compilerOptions": {
    // ...
    "strict": true
  }
}

それと、型定義からスキーマ作成する型を使いやすいように定義して、エクスポートしておきます。

import { z } from 'zod';

export type ToZod<T extends Record<string, any>> = {
  [K in keyof T]-?: z.ZodType<T[K]>;
};

モデル型定義とスキーマ定義

Aspida の API 型定義ファイルに直接書いてもいいんですが、個人的な好みとしてモデルの型定義は別ファイルとしました。より厳密な型チェックをしたかったので、strict()をつけてます。また、リクエスト時のパラメータに関するものも一緒に定義しておきました。

import { z } from 'zod';
import { ToZod } from '@/lib/zod';

export type GetListRequestQuery = {
  limit?: number;
};

export const getListRequestQuerySchema = z
  .object<ToZod<GetListRequestQuery>>({
    limit: z.number().optional(),
  })
  .strict();

export type PostRequestBody = Pick<User, 'name'>;

export const postRequestBodySchema = z
  .object<ToZod<PostRequestBody>>({
    name: z.string(),
  })
  .strict();

export type RequestPathParams = {
  userId: string;
};

// パスパラメータとしては全て文字列になるので、文字列で数字のみにする
export const requestPathParamsSchema = z.object<ToZod<RequestPathParams>>({
  userId: z.string().regex(/\d+/),
});

export type User = {
  id: number;
  name: string;
};

export const userSchema = z
  .object<ToZod<User>>({
    id: z.number(),
    name: z.string(),
  })
  .strict();

export type Users = User[];

export const usersSchema = z.array(userSchema);

エラーレスポンスの型も簡単に定義しておきました。

import { z } from 'zod';
import { ToZod } from '@/lib/zod';

export type ErrorResponse = {
  message: string;
};

export const errorResponseSchema = z.object<ToZod<ErrorResponse>>({
  message: z.string(),
});

モックデータ

さっくり User モデル一覧のモックデータを作成しておきました。

import { Users } from '@/models/User';

const users: Users = [
  {
    id: 1,
    name: 'Adam',
  },
  {
    id: 2,
    name: 'Scott',
  },
  {
    id: 3,
    name: 'Matt',
  },
  {
    id: 4,
    name: 'John',
  },
  {
    id: 5,
    name: 'Frank',
  },
  {
    id: 6,
    name: 'Nicole',
  },
  {
    id: 7,
    name: 'Katie',
  },
  {
    id: 8,
    name: 'Nina',
  },
  {
    id: 9,
    name: 'Nancy',
  },
  {
    id: 10,
    name: 'Carol',
  },
];

export { users };

Aspida での API 型定義

Aspida では API のエンドポイントに合わせたディレクトリ階層を作って、API の型を定義していきます。前述のモデル型定義を活用しながら定義しました。

エンドポイント：api/users

import {
  GetListRequestQuery,
  PostRequestBody,
  User,
  Users,
} from '@/models/User';

export type Methods = {
  get: {
    query?: GetListRequestQuery;

    resBody: Users;
  };

  post: {
    reqBody: PostRequestBody;

    resBody: User;
    /**
     * reqHeaders(?): ...
     * reqFormat: ...
     * status: ...
     * resHeaders(?): ...
     * polymorph: [...]
     */
  };
};

エンドポイント：api/users/{userId}

import { User } from '@/models/User';

export type Methods = {
  get: {
    resBody: User;
  };
};

パスパラメータが含まれるエンドポイントの場合は、このファイルのように_パラメータ名@型というような名称にします。

Aspida 監視モード

前項の API 型定義がある状態で aspida コマンドを実行すると、そのディレクトリに$api.tsというファイルが生成されます。これが、型が反映されたリクエスト関数となり、これを使うことで型安全なリクエストができるようになるというわけです。

/* eslint-disable */
// prettier-ignore
import { AspidaClient, dataToURLString } from 'aspida'
// prettier-ignore
import { Methods as Methods0 } from './users'
// prettier-ignore
import { Methods as Methods1 } from './users/_userId@number'

// prettier-ignore
const api = <T>({ baseURL, fetch }: AspidaClient<T>) => {
  const prefix = (baseURL === undefined ? '' : baseURL).replace(/\/$/, '')
  const PATH0 = '/users'
  const GET = 'GET'
  const POST = 'POST'

  return {
    users: {
      _userId: (val1: number) => {
        const prefix1 = `${PATH0}/${val1}`

        return {
          get: (option?: { config?: T }) =>
            fetch<Methods1['get']['resBody']>(prefix, prefix1, GET, option).json(),
          $get: (option?: { config?: T }) =>
            fetch<Methods1['get']['resBody']>(prefix, prefix1, GET, option).json().then(r => r.body),
          $path: () => `${prefix}${prefix1}`
        }
      },
      get: (option?: { query?: Methods0['get']['query'], config?: T }) =>
        fetch<Methods0['get']['resBody']>(prefix, PATH0, GET, option).json(),
      $get: (option?: { query?: Methods0['get']['query'], config?: T }) =>
        fetch<Methods0['get']['resBody']>(prefix, PATH0, GET, option).json().then(r => r.body),
      post: (option: { body: Methods0['post']['reqBody'], config?: T }) =>
        fetch<Methods0['post']['resBody']>(prefix, PATH0, POST, option).json(),
      $post: (option: { body: Methods0['post']['reqBody'], config?: T }) =>
        fetch<Methods0['post']['resBody']>(prefix, PATH0, POST, option).json().then(r => r.body),
      $path: (option?: { method?: 'get'; query: Methods0['get']['query'] }) =>
        `${prefix}${PATH0}${option && option.query ? `?${dataToURLString(option.query)}` : ''}`
    }
  }
}

// prettier-ignore
export type ApiInstance = ReturnType<typeof api>
// prettier-ignore
export default api

ただ、開発中に毎回 aspida コマンドを手動実行するのは手間なので、監視モードにしておくと楽です。今回は Next.js 側のローカルサーバ起動と並列実行するようにしました。

"scripts": {
    "dev": "run-p dev:*",
    "dev:next": "next dev",
    "dev:aspida": "aspida --watch",
    "build": "aspida && next build",
    ...
  },

それと、$api.tsは自動生成分なので、.gitignoreに追加しておくと良いです。

## aspida
$api.ts

Aspida でのリクエスト時の設定とクライアント作成

こちらは既定のファイルではなく、自分でsrc/lib配下に作成。 @aspida/ky の項でも書いてましたが、リクエストが400・500番台で返ってきたときに自動で HTTPError をスローしてくれるオプションを有効にしました。

import aspida, { FetchConfig } from '@aspida/fetch';
import api from '@/api/$api';

const fetchConfig: FetchConfig = {
  credentials: 'include',
  baseURL: '/api',
  throwHttpErrors: true, // throw an error on 4xx/5xx, default is false
};

export const client = api(aspida(fetch, fetchConfig));

Aspida でのリクエストクライアントをエクスポートしておき、ドメインでこのクライアントを使うようにします。

これで前準備は終わりです。

API ルート

モックの API を作成。冒頭に書いた通り、parse()でバリデーションチェックを行っています。クエリパラメータやリクエストボディのチェックをして、内容がおかしければ ZodError をキャッチから400を返す感じ。

// Next.js API route support: https://nextjs.org/docs/api-routes/introduction
import { NextApiRequest, NextApiResponse } from 'next';
import {
  getListRequestQuerySchema,
  postRequestBodySchema,
  User,
} from '@/models/User';
import { ErrorResponse } from '@/models/ErrorResponse';
import { users } from '@/mock/user';
import { ZodError } from 'zod';

export default function handler(req: NextApiRequest, res: NextApiResponse) {
  switch (req.method) {
    case 'GET':
      try {
        const query = getListRequestQuerySchema.parse(req.query);
        if (query.limit && query.limit < users.length) {
          res.status(200).json(users.slice(0, query.limit));
        } else {
          res.status(200).json(users);
        }
      } catch (e) {
        if (e instanceof ZodError) {
          const errorResponse: ErrorResponse = {
            message: '不正なクエリパラメータです。',
          };
          console.error(errorResponse, e);
          res.status(400).json(errorResponse);
        }
      }
      break;
    case 'POST':
      try {
        const body = postRequestBodySchema.parse(req.body);
        const newUser: User = {
          id: users.length + 1,
          name: body.name,
        };
        res.status(201).json(newUser);
      } catch (e) {
        if (e instanceof ZodError) {
          const errorResponse: ErrorResponse = {
            message: '不正なリクエストパラメータです。',
          };
          console.error(errorResponse, e);
          res.status(400).json(errorResponse);
        }
      }
      break;
    default:
      const errorResponse: ErrorResponse = {
        message: 'このエンドポイントで、そのメソッドは定義されていません。',
      };
      console.error(errorResponse);
      res.status(405).json(errorResponse);
  }
}

// Next.js API route support: https://nextjs.org/docs/api-routes/introduction
import { NextApiRequest, NextApiResponse } from 'next';
import { requestPathParamsSchema } from '@/models/User';
import { ErrorResponse } from '@/models/ErrorResponse';
import { users } from '@/mock/user';
import { ZodError } from 'zod';

export default function handler(req: NextApiRequest, res: NextApiResponse) {
  switch (req.method) {
    case 'GET':
      try {
        const query = requestPathParamsSchema.parse(req.query);
        const user = users.find((user) => user.id === Number(query.userId));
        if (user) {
          res.status(200).json(user);
        } else {
          const errorResponse: ErrorResponse = {
            message: '指定のIDを持つユーザは存在しません',
          };
          console.error(errorResponse);
          res.status(404).json(errorResponse);
        }
      } catch (e) {
        if (e instanceof ZodError) {
          const errorResponse: ErrorResponse = {
            message: '不正なパスパラメータです。',
          };
          console.error(errorResponse, e);
          res.status(400).json(errorResponse);
        }
      }
      break;
    default:
      const errorResponse: ErrorResponse = {
        message: 'このエンドポイントで、そのメソッドは定義されていません。',
      };
      console.error(errorResponse);
      res.status(405).json(errorResponse);
  }
}

ドメイン

src/lib/aspida.tsでエクスポートしているクライアントを使っていく感じ。このクライアントから各 API リクエストの関数（生成した$api.tsのやつ）が使えるため、API の型定義が間違ってない限り、おかしなリクエストをする心配がありません。入力補完もばっちり。これが型安全に HTTP リクエストができるという Aspida の大きな特徴ですね。

parse()でレスポンスの型チェックを実施。 NG で ZodError がスローされた時は、そのまま再スローにしていて、後述のラッパーのカスタムフック側で処理するようにしました。ちなみにメソッド部分を$をつけたものにする（例：get → $get）と、直接レスポンスボディを受け取るようにもできたりします。

※各ドメインはindex.tsで再エクスポートしてます。

ユーザ情報一覧取得.

import { HTTPError } from '@aspida/fetch';
import { GetListRequestQuery, usersSchema } from '@/models/User';
import { errorResponseSchema } from '@/models/ErrorResponse';
import { client } from '@/lib/aspida';

const getUsers = async (query?: GetListRequestQuery) => {
  try {
    const res = await client.users.get({ query });
    return usersSchema.parse(res.body);
  } catch (e) {
    if (e instanceof HTTPError) {
      errorResponseSchema.parse(await e.response.json());
    }
    throw e;
  }
};

export default getUsers;

ユーザ情報取得.

import { HTTPError } from '@aspida/fetch';
import { userSchema } from '@/models/User';
import { errorResponseSchema } from '@/models/ErrorResponse';
import { client } from '@/lib/aspida';

const getUser = async (userId: number) => {
  try {
    const res = await client.users._userId(userId).get();
    return userSchema.parse(res.body);
  } catch (e) {
    if (e instanceof HTTPError) {
      errorResponseSchema.parse(await e.response.json());
    }
    throw e;
  }
};

export default getUser;

ユーザ新規作成.

import { HTTPError } from '@aspida/fetch';
import { PostRequestBody, userSchema } from '@/models/User';
import { errorResponseSchema } from '@/models/ErrorResponse';
import { client } from '@/lib/aspida';

const postUser = async (body: PostRequestBody) => {
  try {
    const res = await client.users.post({ body });
    return userSchema.parse(res.body);
  } catch (e) {
    if (e instanceof HTTPError) {
      errorResponseSchema.parse(await e.response.json());
    }
    throw e;
  }
};

export default postUser;

カスタムフック

ドメインのラッパー的なやつで、コンポーネント側からは直接ドメインを呼ばないように。リクエスト中のフラグやエラーメッセージの管理ができるようにしてあります。リクエストに関係する処理なども併せて定義。

リクエストが正常系・異常系問わず、レスポンスの内容がおかしい場合は ZodError の所に行きつくので、そこは改善の余地がありそう...。

※各カスタムフックはindex.tsで再エクスポートしてます。

ユーザ情報一覧取得.

import { useState, useEffect, useCallback } from 'react';
import { HTTPError } from '@aspida/fetch';
import { ZodError } from 'zod';
import { Users } from '@/models/User';
import getUsers from '@/domains/getUsers';

const useUsers = () => {
  const [isLoading, setIsLoading] = useState<boolean>(false);
  const [errorMessage, setErrorMessage] = useState<string>();
  const [users, setUsers] = useState<Users>();

  useEffect(() => {
    setIsLoading(true);
    getUsers()
      .then((data) => {
        setErrorMessage('');
        setUsers(data);
      })
      .catch((err) => {
        if (err instanceof HTTPError) {
          setErrorMessage('ユーザ一覧情報の取得に失敗しました');
        } else if (err instanceof ZodError) {
          setErrorMessage('想定しないデータの取得が行われました');
        }
      })
      .finally(() => {
        setIsLoading(false);
      });
  }, []);

  return { isLoading, errorMessage, users };
};

export default useUsers;

ユーザ情報取得.

import { ChangeEvent, FormEvent, useState, useCallback } from 'react';
import { HTTPError } from '@aspida/fetch';
import { ZodError } from 'zod';
import { User } from '@/models/User';
import getUser from '@/domains/getUser';

const useSearchUser = () => {
  const [userId, setUserId] = useState<number>(1);
  const [isLoading, setIsLoading] = useState<boolean>(false);
  const [errorMessage, setErrorMessage] = useState<string>();
  const [user, setUser] = useState<User>();

  const handleChangeUserId = useCallback((e: ChangeEvent<HTMLInputElement>) => {
    setUserId(Number(e.target.value));
  }, []);

  const handleSearchUser = useCallback(
    (e: FormEvent<HTMLFormElement>) => {
      e.preventDefault();

      setIsLoading(true);
      getUser(userId)
        .then((data) => {
          setErrorMessage('');
          setUser(data);
        })
        .catch((err) => {
          if (err instanceof HTTPError) {
            err.response.status === 404
              ? setErrorMessage('指定のIDを持つユーザは存在しません')
              : setErrorMessage('ユーザ情報の取得に失敗しました');
          } else if (err instanceof ZodError) {
            setErrorMessage('想定しないデータの取得が行われました');
          }
        })
        .finally(() => {
          setIsLoading(false);
        });
    },
    [userId]
  );

  return {
    userId,
    isLoading,
    errorMessage,
    user,
    handleChangeUserId,
    handleSearchUser,
  };
};

export default useSearchUser;

ユーザ新規作成.

import { ChangeEvent, FormEvent, useState, useCallback } from 'react';
import { HTTPError } from '@aspida/fetch';
import { ZodError } from 'zod';
import postUser from '@/domains/postUser';

type FormData = {
  name: string;
};

const useCreateUser = () => {
  const [values, setValues] = useState<FormData>({
    name: '',
  });
  const [isLoading, setIsLoading] = useState<boolean>(false);
  const [errorMessage, setErrorMessage] = useState<string>();

  const clearValues = useCallback(() => {
    setValues({ name: '' });
  }, []);

  const handleChangeInput = useCallback(
    (key: keyof FormData) => (e: ChangeEvent<HTMLInputElement>) => {
      setValues({ ...values, [key]: e.target.value });
    },
    [values]
  );

  const handleCreateUser = useCallback(
    (e: FormEvent<HTMLFormElement>) => {
      e.preventDefault();

      setIsLoading(true);
      postUser(values)
        .then((data) => {
          setErrorMessage('');
          alert(
            `id: ${data.id} name: ${data.name}\nユーザを新規作成しました（モックなので実際には作成されてません）`
          );
          clearValues();
        })
        .catch((err) => {
          if (err instanceof HTTPError) {
            setErrorMessage('ユーザ新規作成に失敗しました');
          } else if (err instanceof ZodError) {
            setErrorMessage(
              'ユーザ新規作成に成功しました（モック）が、想定しないデータが返却されました'
            );
          }
        })
        .finally(() => {
          setIsLoading(false);
        });
    },
    [values, clearValues]
  );

  return {
    values,
    isLoading,
    errorMessage,
    handleChangeInput,
    handleCreateUser,
  };
};

export default useCreateUser;

これでロジックができました。あとはこれをコンポーネント側から使っていきます。

コンポーネント側

pages配下は、ルーティングと Head の責務だけにしています。

import { Fragment } from 'react';
import Head from 'next/head';
import HomePage from '@/components/page/Home';

export default function Home() {
  return (
    <Fragment>
      <Head>
        <title>Type Safe Request</title>
        <meta name="description" content="型安全なHTTPリクエスト検証" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <HomePage />
    </Fragment>
  );
}

さっくり作ったビューの実体はこちら。（index.tsで再エクスポートしてます。）

import { VFC } from 'react';
import styles from './Home.module.css';
import useUsers from '@/hooks/useUsers';
import useSearchUser from '@/hooks/useSearchUser';
import useCreateUser from '@/hooks/useCreateUser';

const Home: VFC = () => {
  const { isLoading, errorMessage, users } = useUsers();
  const {
    values,
    isLoading: createIsLoading,
    errorMessage: createErrMsg,
    handleChangeInput,
    handleCreateUser,
  } = useCreateUser();
  const {
    userId,
    isLoading: searchIsLoading,
    errorMessage: searchErrMsg,
    user,
    handleChangeUserId,
    handleSearchUser,
  } = useSearchUser();

  return (
    <div className={styles.container}>
      <div className={styles.layout}>
        <div>
          <h2>ユーザ一覧</h2>
          {(isLoading || errorMessage) && (
            <p className={errorMessage && styles.errorText}>
              {isLoading ? '読み込み中...' : errorMessage}
            </p>
          )}
          {!(isLoading || errorMessage) &&
            users?.map((user) => {
              return (
                <div key={user.id}>
                  <p>{`id: ${user.id} name: ${user.name}`}</p>
                </div>
              );
            })}
        </div>
        <div className={styles.rightBlock}>
          <div>
            <h2>ユーザ検索</h2>
            <form onSubmit={handleSearchUser}>
              <label>
                id:{' '}
                <input
                  type="search"
                  required
                  pattern="^\d+$"
                  title="数値で入力してください。"
                  value={userId}
                  onChange={handleChangeUserId}
                />
              </label>
              <button type="submit" disabled={searchIsLoading}>
                検索
              </button>
            </form>
            {!(searchIsLoading || searchErrMsg) && user && (
              <p>{`id: ${user.id} name: ${user.name}`}</p>
            )}
            {!searchIsLoading && searchErrMsg && (
              <p className={styles.errorText}>{searchErrMsg}</p>
            )}
          </div>
          <div>
            <h2>ユーザ新規作成</h2>
            <form onSubmit={handleCreateUser}>
              <label>
                name:{' '}
                <input
                  type="text"
                  required
                  value={values.name}
                  onChange={handleChangeInput('name')}
                />
              </label>
              <button type="submit" disabled={createIsLoading}>
                新規作成
              </button>
            </form>
            {createErrMsg && <p className={styles.errorText}>{createErrMsg}</p>}
          </div>
        </div>
      </div>
    </div>
  );
};

export default Home;

検証してみてどうだったか

型安全な HTTP リクエストにしたいとして、実際に自分のやり方に組み込むにはどうすればいいか？というところが、おおよそ解決したのでまぁ満足です。自前で型ガード実装するつらみから解放されたのと、より安全な HTTP リクエストができるようになったのとで、検証してみてよかったなぁと。

余談：tRPC

Zod の README を見ていたところ、同じ作者の方が作ったこのライブラリに関する記述を見かけました。まだあまり詳しくは見られていませんが、Aspida とはまた違ったアプローチの、型安全な HTTP リクエストをするためのライブラリのようです。 Zod との組み合わせをしているようなサンプルもあったので、気になる方はドキュメントをぜひ読んでみてはいかがでしょうか。

今回は Aspida と Zod を使った、型安全な HTTP リクエストについてのお話でした。当記事に書いたのは、あくまで自分のやり方ではありますが、導入を検討されている方の何かの参考になれば幸いです。

参考リンクまとめ

{/*  */}

{/*  */}

2021年振り返り～技術活動、ブログ編～

Thu, 30 Dec 2021 00:00:00 GMT

{/*  */}

今年も色々あったなぁなんで感慨深くなっている、よしです。今年も、体調編に引き続き技術活動の振り返りもやっていきますー。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

2021年の活動履歴

コミット履歴

いつものように、まずは Git の Contributions 履歴。今年は1つの GitHub アカウントしか使ってなかったので、そちらだけ。

昨年は 920（個人） + 541（仕事）= 1461 でしたが、今年はそれを超えましたね。まぁ、新しい会社がなかなか決まらなかった分、時間はあったので日中は何かしら活動してた日が多かったです。

2月～5月くらいまでが割と活動活発でしたね。 5月に復職活動を開始するまでは、個人開発をガリガリ実装したり、ハンズオン教材を進めていたり。その過程で学んだことを記事にしたりしてました。

6月からは devChallenges の課題を開始。

8月～9月は勉強をいったん中断し、過去に作った個人開発の TypeScript 化 + リファクタリングや React 関連記事の全体見直し更新をやってました。（勉強が途切れるなと思いつつ、今思えばこの判断は良かったと思っています）

10月中旬～12月から devChallenges を再開。

あとは合間で記事を書いたり、ポートフォリオサイトの更新をしたりなどしてた感じです。

復職活動

今年で一番優先度が高かったのはこれですね。身体の調子を見ながら5月に開始しました。

応募状況に関しては、おおよそこんな感じでした。

5月：
- 0社目：以前から憧れだった会社さんに問い合わせてみるも、自分では実力不足の気がしてこの時は一旦諦める
- 1社目：スカウト → カジュアル面談
6月：
- 1社目：技術試験でボロボロになり見送り
- 2社目：スカウト → カジュアル面談
7月：
- 2社目：技術試験でまたもボロボロになり見送り
- 3社目：事前面談 → 書類選考落ち
8月：
- 4社目：カジュアル面談 → 書類選考
9月：
- 4社目：1次面接 → 2次面接
- 5社目：メッセージ受信 → カジュアル面談
10月：
- 4社目：3次面接 → 4次面接落ち
- 6社目：メッセージ受信
11月：
- 5社目：書類選考 → 1次面接落ち
- 6社目：カジュアル面談
- (0社目もとい)7社目：カジュアル面談申し込み
12月：
- 7社目：カジュアル面談 → 技術試験 → 1次面接 → 2次面接 → （結果待ち）

主に、精神疾患について一定の理解がある技術面だけでなく体調面でも気軽に相談できる環境があるという会社さんを探していました。あと、楽しそうな雰囲気だとよりいいなとか。ただ、小規模の会社さんだと、自分がもしうまく立ち上がれなかった時にご迷惑をおかけしてしまう影響が大きいと判断しました。そのため、いい会社さんだと思っても、ご遠慮させていただいたりもしてました。

一度に複数社とのやり取りだとテンパりそうだったので、あまり同時に応募することはしなかったです。早い方だと、同時に何社も受けてパパっと決めちゃうんだろうな、なんて思ったり。（現に、Twitter でそういう方を見かけました）

この他にもスカウトメッセージをいただいたりしましたが、いかにもテンプレっぽいとか。自分のどこに興味を持ったのかあまり書いてないとか。ホントにプロフィール読んだのかな？と思うような内容だったとか。文面の95%くらい自社のアピールが長々と書いてあるとか。そういった会社さんはすみませんが返信してないです。

こういったメッセージでない会社さんでも、返信しきれてないものもあります（申し訳ないです...🙇‍♂️）返信しつつも、お話はお受けできなかったものもありました。

スカウトをいただきながら技術試験でボロボロの結果だというのは、なんだかスカウトしてくださった方にも申し訳なかったですね...。特に1社目に関しては、リモートで繋いで画面共有をしながらその場でやるというものだったので、すごい気まずかったです。ただ、そんなボロボロの自分にもちゃんとフィードバックをくださって、とてもありがたかったなと。自分が抱えるスキルの問題がはっきりしたので、その後それを克服すべく勉強に打ち込むことができました。

執筆時点では、7社目の2次面接（最終面接）を終えたところです。一応、技術試験と1次面接では割といい評価をいただけているような印象でしたが、こればっかりはわかりませんからね。でも、以前から憧れの会社さんなので、もし内定出たらめちゃくちゃ嬉しい。

前社を退職してから1年ちょっと経ち、だいぶ貯金が寂しい感じになってきたので、決まるといいなぁ。

ブログ

アクセス履歴

今年のブログ履歴はこんな感じ。例年通り、Google Analytics のデータ部分のみ抜粋しています。（12月に関しては、執筆時点でのものです）

月	記事数	月のアクセスユーザ数	月のページビュー数
1月	57	1,312	1,785
2月	58	1,369	1,852
3月	59	1,391	1,811
4月	60	1,081	1,395
5月	62	1,024	1,309
6月	62	1,013	1,309
7月	62	881	1,228
8月	62	807	1,185
9月	63	751	1,157
10月	64	946	1,395
11月	66	807	1,157
12月	69	628	881

アクセスユーザ数計：12,002
ページビュー数計：16,512

昨年との比較.

アクセスユーザ数：6,722 → 5,280増
ページビュー数：9,670 → 6,842増

今年はなんだか段々と減っていくような感じでした。まぁ、技術記事に関しては Zenn の方にもクロス投稿しているので、そちらで見ている人の方が多いのかなと。実際に記事タイトルで検索しても Zenn の方が先に出てくるので。また、実際にページごとのアクセス数を見ると、上位はブログでしか投稿していない記事が多かったです。

記事執筆について

6月～9月中旬は勉強や過去記事の見直し更新を優先しがちだったので、数か月の間は新規記事投稿がなかった状態。今年も月に最低1記事書こうという目標が達成できなかったわけではありますが、せめて12記事にはしたかったのでリカバリして、なんとか当記事で12記事達成にできました。

8月～9月中旬に思い切って時間をとって、React 関連記事の見直し更新をやったのは良かったなと。元々、まだ React 歴の浅い状態で書いた記事だったので、今見るとイマイチな部分とかが割と多くて気になってたんですよね。改めて検証しなおしたり公式ドキュメントを読んだりと、情報が整理できてすっきりしました。

今年も React の記事は書いていたものの、React 入門シリーズが全然書けてないので、何かそろそろ書きたいところです。

リニューアルについて

昨年末の構想として、今の Jekyll 製なのを Next.js で作り直したいなというものがありました。これの進捗としては、あまり変わっていません。

Next.js の勉強はできたのと、リニューアルする上での移行ライブラリの調査などはおおよそできたのですが...。そもそもデザインどうするの？というところで悩んだ結果、優先度が低い状態でした。

デザインの知識は正直あまりないので、デザインを学ぶとか、ギャラリーサイトなどで参考にできそうなデザインを見てみるとかをやらないとなぁといった感じです。

ブログ以外の技術記事活動

※Zenn および Qiita に投稿した記事は、すべて当ブログでも投稿しています。

昨年、Zenn がリリースされてからブログ + Zenn で活動してきたので、Qiita に新規投稿はしていません。ただ、React 関連記事の見直し更新をする際、Qiita に投稿してあった分も更新してあります。

ちなみに Zenn からいただいた振り返りはこんな感じでした。（12/23までなので、devChallenges の記事は含まれてません） <ImageWrapper className="w-[70%]" src="screenshots/2021/looking-back-2021-tech/zenn-recap.png" alt="Zenn 2021 Recap - 2021年の活動振り返りデータ - 211,651字の執筆、9記事、60,096ビュー、572Likes、3個のサポートバッジ" />

やっぱり MUI v5 記事が伸びてましたね。ああいった新機能まとめみたいな記事は、やはり需要があるんだなぁと。 v4との比較なんかも頑張ったかいがありました。

Crieit に関しては、今年は web1week に参加しなかったので新規投稿なし。 web1week の開催自体は知っていて、ネタ集めをした回なんかもありましたが、結局参加まではしませんでした。問われる発想力...🙄

※2024/09/14追記：Crieit はサービスクローズされました。

個人開発

OOUI ワークアウト - メモアプリ

昨年末くらいから OOUI のワークアウトを実際に作ってみる活動を細々と再開して。メモアプリの実装を2月～5月くらいは割とガリガリやってました。

JavaScript × React は経験ありますが、TypeScript × React は経験なかったので調べながら進めていった感じ。はじめは型定義に戸惑いつつも、その強力な型補完や入力補完を体験して、今では型定義ない方が不安になります（笑）

TypeScript × React の組み合わせを対象としている技術書典の書籍「りあクト！」には特にお世話になりました。 <OG url="https://github.com/oukayuka/Riakuto-StartingReact-ja3.1" /> 開発環境整備のことから React における概念、よく使われるライブラリのことまで網羅されていて。改めてちゃんと React を勉強できたなぁと。

コンポーネント設計やカスタムフックのことなど、だいぶ時間をかけて試行錯誤して。その結果、おおよそ自分なりのやり方のようなものが定まりました。

コツコツ進めていったメモアプリの実装ですが、復職活動の中で自分のスキルの問題が見えてきたので、そちらの克服を優先するために中断しました。

過去に作った web1week 作品

復職活動をするなかで個人開発のものとして記載するため、少しでも見栄え良くしたいなというのと。 OOUI - メモアプリで TypeScript × React の自分なりの実装方法が定まったので、それを適用したかったというので、リファクタリングを行いました。

元々、2作品ともに JavaScript × React で作ったものだったので、TypeScript 化対応。それとロジックが混在していた状態だったので、ロジックをカスタムフックに切り出し対応を実施。おかげでコードがすっきりしました。

個人勉強

今年特に勉強した技術.

TypeScript
React
Next.js
React Query
emotion
HTML・CSS・JavaScript 基礎

TypeScript × React については前述の通り、OOUI - メモアプリを実装する中で勉強。

Next.js は公式チュートリアルやハンズオン教材をやったり。 <OG url="https://tk-rabbit-house.booth.pm/items/2381995" /> <OG url="https://zenn.dev/dala/books/nextjs-firebase-service" />

現状、フロントエンドの技術スタックとして、素の React を採用するよりは Next.js として採用する方がデファクトのイメージがありました。そのため、Next.js も勉強しておきたいなということで、今年から勉強開始。もちろん TypeScript × Next.js です。

React Query も OOUI - メモアプリの中で使ってみてました。元々、「りあクト！」の中で触れられていたことで知り、とても便利そうなので使ってみた感じです。実際、すごい便利ですよね。コードがすっきり書けるの嬉しい。いくつか React Query を使った記事を書いたりもしました。

emotion は CSS in JS が流行っているので、どれか使えるようにしておきたいなというので、emotion に。知名度的には styled-components の方が上かとは思いますが、個人的には emotion の方が好みで CSS Prop でスタイルを書く練習をしていました。

復職活動をするなかで直面した自分のスキルの問題として...

デザインデータの再現実装の経験がない
HTML・CSS・JavaScript 基礎が微妙な部分あり
コーディング速度が遅い

というものがありました。フロントエンドを志望するならこの辺りができてないと絶望的だなと思ったため、これらを克服するために devChallenges という海外のコミュニティの課題を6月頃から開始。

ざっくりいうと、あらかじめ用意された Figma デザインデータとユーザストーリーを元に課題作品を作るものです。 devChallenges の詳細に関しては、先日振り返り記事を書いたのでそちらから。

devChallenges - Responsive Web 編を完走したので、さっくり振り返ってみた

最初は Front-end 編を進めていましたが、4課題くらい終えた頃に Responsive Web 編を先にすることへ切り替えて、そちらは完走しました。課題を通して、改めて基礎的な部分を考える機会になり、とても勉強になりましたね。少し自信もついた気がしますし、本当にやってよかったなーと思います。

コーディング速度の面は、Emmet を積極的に使うようになったり、スニペットを少し活用したりするようになりました。課題の数をこなす中で少しずつ早くなったかな？とも。

それと技術試験対策でアルゴリズム力も鍛えた方がいいかなというので、CS を学べるプラットフォームである Recursion の学習も少しやっていました。 <OG url="https://recursionist.io" /> 今は中断したままですが、内容がすごくいいなと思ったので少しずつでも進めたいところです。

TIL 活動

TIL（Today I Learned）という、その日学んだことを GitHub リポジトリに記録する活動のことです。

昨年では TIL リポジトリに記録 → ドキュメントとしてまとめたやつをポートフォリオサイトへ投稿みたいにやっていましたが...。復職活動や勉強と比較すると優先度が低かったので、どうしても放置になりがちで。

勉強した内容については Notion に記録していった方がよくないか？というので、Notion へ移行。ドキュメントとしてまとめる件については、一旦一からやりなおそうということで、投稿していた分は削除しました。

でも、ポートフォリオサイトではせっかく Docusaurus を使っているので、何かしらは書きたいところです。

その他

2月くらいに、各種技術アカウント ID を少し変えたい欲がわいてきたので変えました。今はh-yoshikawa44という ID を主に使用しています。 Zenn や Crieit など ID が変更できないやつは前のままです。

ポートフォリオサイトのドメインもこれに合わせて変更。

2022年はどうしていきたいか

復職活動

執筆時点（2021/12/30）で選考中の会社さんにもし決まれば、すぐ社会復帰ですね。合否の結果は年明けの楽しみにしつつ。もしそうなったとして、入社してしばらくは環境の変化で疲れやすかったりすると思うので、体調に気を付けて少しずつ馴染んでいきたいところです。

もしダメだった場合は、また改めて会社探さないとですね。精神疾患について一定の理解があることや、技術面だけでなく体調面でも気軽に相談できる環境があるというのは、なるべく妥協したくないなぁと。（会社決まっても続けられない環境なら意味ないので）それ以外の部分は、多少の妥協が必要になってくるかもしれませんね。

ブログ・技術記事

月に1記事もしくは1年で12記事書ければいいかなと。会社が決まったとして、仕事しながら記事書くのどうしようかなと悩ましいところではありますが。 Zenn のスクラップを活用して、少しずつ検証内容や文章を書いていくようにしようか、と構想してます。

ブログのリニューアルについては、デザイン面の問題ですね。デザインの基礎学習とか、少しずつギャラリーサイトを見て参考にできそうなものをストックしていくとかやろうかなと。モノクロ基調のかっこいいデザインにしたいという構想はありつつ、デザイン力がないので悩ましいところです。

個人開発

OOUI - メモアプリが中断したきりなので、いずれは再開しないとですね。ただ、devChallenges の方を優先度高くするつもりなので、あまり着手できないかも。

web1week は来年も開催されるかはわかりませんが、また参加を検討したいですね。ネタ探しするだけでも意外な収穫があったりするので、一旦は何かを作れないか考えてみるのも大事かなと。もし開催されなかったとして、自分でお題のくじなんかを作って、ひいたお題で何が作れるか構想するのも発想力の訓練になるかも？

個人勉強

TypeScript × React or Next.js はメインにしつつ。それ関連で新しい技術が出てきたら、情報を追いつつ、自分でも試してみるというのを継続。今年は、テストやデザイン、アクセシビリティ関連まではいけなかったので、その辺も勉強したいですね。そのほか、業務で必要になる技術があれば、それを自分でも学んだり。

AWS ソリューションアーキテクトアソシエイト資格の有効期限が8月で切れるので、更新の受験をする予定です。自宅でも受験できるそうになったそうですが、自宅に自習室みたいな部屋がないので、受験会場へ行くことになりそう。前回受験した時は、体調面でえらい目にあったので、ちょっと怖いですが...。それと HTML プロフェッショナル試験も受けてみようかなーと。

devChallenges の Front-end 編の続きをやらないとですね。すでに投稿済みの作品についても、今見ると微妙なところがあったりするのでリファクタリングしたり。それが終わったら Full-stack 編もやりたいところですが、バックエンドも絡んでくるので時間かかりそうだなと。でも、設計の勉強にもなりそうですし、せっかくなら全コース完走したいですし。とりあえずはやる方向で考えています。

Recursion の学習も少しずつでも進めたいところです。

TIL 活動

勉強したことのメモや記録については、引き続き Notion で行っていきます。あくまで自分用みたいなところがあるので、さすがに Notion ページを公開まではしないかなと。

内容まとめのドキュメント化 + 公開については、これもやりたいと思いつつ優先度が低くなりがちで、あまり着手できないかも。どうやって進めるかが定まってないですし、なかなか悩ましいところで...。よくやる処理なんかをいろんな言語で書けるような作りにする？という構想はありつつ。個人勉強をする中でいい案が降ってこないかなぁと思っていたりします。

今年は復職活動をしつつも、なかなか会社が決まらなかった分の時間で色々やってきましたね。残念ながら年内に社会復帰はできませんでしたが、精神疾患と向き合ったり、やりたかった勉強を集中してやれたりしたかなと。自分が勉強してきたことは決して無駄じゃなかった、と思えるような出来事もあったので、これも必要な時間だったと前向きに捉えるつもりです。来年こそは社会復帰して、仕事もしつつプライベートも両立できるようなスタイルを追求していきたいですね。

ここまで読んでくださった方、ありがとうございました。ではでは、皆様、よいお年をお迎えくださいー。

{/*  */}

devChallenges - Responsive Web 編を完走したので、さっくり振り返ってみた

Fri, 24 Dec 2021 00:00:00 GMT

こんにちは、ここ1年コツコツ勉強してよかったなぁなんて思っている、よしです。 devChallenges というコミュニティの課題を1コース完走したので、さっくりと振り返ってみました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

devChallenges とは？

※https://legacy.devchallenges.ioというドメインでかつてはサイトがありましたが、現在はクローズされたようです。

Web Development Resources and Community that help you to become a Web Developer by working with Real-life projects and practices. ↓ 訳：実際のプロジェクトやプラクティスを使用して Web Developer になるのに役立つ Web 開発リソースとコミュニティ。

おおよそ翻訳通りで、Web Developer になるための学習コンテンツや課題を提供しているコミュニティです。名称表記としては「devChallenges」だったり「DevChallenges」だったりするものの、個人的には前者を使うことが多く、当記事でもそう書いていきます。

学習コンテンツ部分は準備中になっている項目が多かったりするのですが、課題の方は結構充実していまして。課題の大カテゴリとして以下の3つがあり、それぞれで8課題ずつ用意されています。

Responsive Web Developer（難易度1～3）
Front-end Developer（難易度2～3）
Full-stack Developer（難易度3～8）

あらかじめ用意された Figma のデザインデータとユーザストーリーがあり、それに沿って課題作品を作っていくような形です。必ずしもデザインデータ通りというわけではなく、ユーザストーリーさえ満たしていれば多少のアレンジは OK。実装方法の明確な回答は用意されていませんので、自分で試行錯誤しながら作っていきます。作成した作品は自分でどこかしらのホスティングサービスに公開したのち投稿でき、他のユーザからレビューをもらうなんてことも出来たりします。逆に他の方の投稿作品を見て参考にしたりも（まだ自分で作成していない課題の他の方の投稿作品を見ることは非推奨となってはいますが）

自分は実務でやった React にハマってからフロントエンド志望になった人間で、それから React 関連の技術を主に勉強してきたのですが...。デザインデータの再現実装を実務でやったことがないとか、HTML・CSS の基礎知識に微妙なところがあったり等課題を抱えておりまして。それらを克服するために、この devChallenges の課題をはじめました。また、実際に何かを作ってみるとして自分でネタが思いつきにくいところもありまして、そういう面でもこういう課題いいなと思ったというのもあります。

最初は Front-end 編を進めていましたが、諸事情あって途中から Responsive Web 編の方を先に。この度、その8課題を完走し終えたので、ちょっと振り返ってみようかなと思った次第です。

※2022/03/04追記 Front-end 編振り返りも投稿しました。

devChallenges - Front-end 編を完走？したので、さっくり振り返ってみた

Responsive Web 編の課題を振り返ってみる

Responsive Web 編では主に Web サイトのページをレスポンシブに作る課題となっています。

最後の課題を除き、素の HTML・CSS・JavaScript を使うことが推奨とされていたので自分もそうしました。実際には Sass や TypeScript 等を使うことが多いかなという印象ですが、まずは基礎的な書き方できないとなぁということで。とはいえ、PostCSS や npm パッケージはいくつか使っています。

では、8課題をさっくりと振り返っていきます。（あまり実装のネタバレにならないような書き方としました）

1 - 404 Not Found

ユーザストーリー.

I can see a page following the given design （訳：与えられたデザインに続くページを見ることができます）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-404-not-found" />

404ページを作成する課題。最初の課題なので易しめです。 HTML・CSS 基礎がわかっている人にとっては瞬殺ものやもしれませんね。

自分の場合は、実装部分よりも、今後課題を進めていく上での環境構築やルール決め（クラスの命名規則など）で時間を使った記憶です。クラスの命名規則に関しては、BEM のやり方を取り入れてみることにしました。

2 - My team page

ユーザストーリー.

I can see a page following the given design （訳：与えられたデザインに続くページを見ることができます）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-my-team-page" />

チームメンバー一覧ページを作成する課題。縦書きテキストや交互に余白の違うものをどう実装するか？を考えていきます。

ただ単に要素を同じように並べるのと比較して、一工夫あることでちょっとおしゃれ感ありますね。

3 - Interior Consultant

ユーザストーリー.

I can see a page following the given design （訳：与えられたデザインに続くページを見ることができます）
On mobile, I can see a collapsed navigation （訳：モバイルでは、折りたたまれたナビゲーションを見ることができます）
On mobile, when I select the hamburger menu, I can see a navigation （訳：モバイルでハンバーガーメニューを選択すると、ナビゲーションが表示されます）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-interior-consultant" />

インテリアサービスサイトのトップページ + メニューを作成する課題。複数ページがあるサイトのようなデザインをしていますが、課題としてはトップページだけです。

画面幅によって、ヘッダーメニューとメニューボタンを切り替える方法。メニューの要素をどうやって実装するか、表示非表示の制御などを考えていきます。

メニューの制御をするにあたっては、意外と考えるところ多いですよね。改めて考えるいい機会になりました。

4 - Recipe page

ユーザストーリー.

I can see a recipe with ingredients and instructions （訳：材料と説明書が入ったレシピを見ることができます）
I can select a checkbox if I have the ingredients （訳：材料があればチェックボックスを選択できます）
I can see the number of servings, baking times （訳：私はサービングの数、ベーキング時間を見ることができます）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-recipe-page" />

レシピサイトのレシピページを作成する課題。テキスト中の一部分のみスタイルをあてたり、カスタムのリスト番号をどうやって実装するかを考えていきます。

テキストに使える HTML タグって意外といろんな種類ありますよねー。それらをちゃんと正しく使い分けられているか？と言われると、なかなか沼りそうな気もしました。カスタムのリスト番号は、おおよそのやり方がわかると自分でアレンジもできて、ちょっとおしゃれにできそうです。

5 - My Gallery

ユーザストーリー.

I can see a page following the given design （訳：与えられたデザインに続くページを見ることができます）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-my-gallery" />

ギャラリーページを作成する課題。ギャラリー作品の配置をどうやって実装するか？を考えていきます。

個人的には1つ前の Recipe page の方が難しかったです。

6 - Checkout Page

{/*  */}

ユーザストーリー.

I can see a page following the given design （訳：与えられたデザインに続くページを見ることができます）
I can input email, phone, full name, address, city, country, and postal code （訳：メールアドレス、電話番号、氏名、住所、都市、国、郵便番号を入力できます）
I can input the number of items （訳：アイテム数を入力できます）
I can select at least 3 countries from the dropdown （訳：ドロップダウンから少なくとも3か国を選択できます）
When I click submit button or press enter, I can see a warning if validation fails （訳：送信ボタンをクリックするか Enter キーを押すと、検証が失敗した場合に警告が表示されます）
When I click submit button or press enter, I can see a successful alert if validation succeeds （訳：送信ボタンをクリックするか Enter キーを押すと、検証が成功した場合に成功したアラートが表示されます）

{/*  */}

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-checkout-page" />

買い物フォームページを作成する課題。 input 要素の type や、バリデーションチェックをどうやって実装するか等を考えていきます。ちなみにこのバリデーションチェックに関しては、JavaScript を使わなくてもいいよとなっています。

input 要素の type 属性も割といろんな種類ありますよねー。 type によっては iOS Safari だと数字しか入力できないといった仕様もあるので、ちょっと注意が必要だなとか。郵便番号や電話番号のバリデーションは、グローバルに対応する場合、どういう正規表現になるんだろうか...と考えたり。（今回の実装では一旦日本仕様にしました）

今回はおおよそデザイン通りにしましたが、入力例を下部に書いておくとか、必須かどうかを赤ラベルで表示しておくとか。そういう配慮も本来は必要になってきますよね。フォームもなかなか考えるところ多いなーと。

7 - Edie homepage

ユーザストーリー.

I can see a page following the given design （訳：与えられたデザインに続くページを見ることができます）
I can see a page on mobile following the given design （訳：与えられたデザインに従ってモバイルでページを見ることができます）
I can go to certain locations by selecting links in navigation or footer （訳：ナビゲーションまたはフッターでリンクを選択すると、特定の場所に移動できます）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-edie-homepage" />

LP を作成する課題。単純に作成する要素が多いので、なかなかやりごたえのある課題です。ナビゲーションからの移動やレイアウトのずらし等の実装方法を考えていきます。

今までの課題でやってきたことの集大成 + レイアウトのずらしテクニックを使う感じで、個人的には割と楽しめた課題でした。 LP を作れるようになると、フロントエンド基礎はおおよそ大丈夫そう？

8 - Portfolio

ユーザストーリー.

I can see personal details （訳：個人情報を見ることができます）
I can see skills （訳：スキルが見えます）
I can see projects （訳：プロジェクトを見ることができます）
I can filter projects by tag （訳：タグでプロジェクトをフィルタリングできます）
I can see hobbies or certificates （訳：趣味や証明書が見えます）
(optional): I can see experiences （訳：私は経験を見ることができます）
(optional): I can see blogs （訳：ブログが見えます）
(optional): I can see projects on different pages （訳：別のページでプロジェクトを見ることができます）

自分の投稿作品 <OG url="https://github.com/h-yoshikawa44/ch-portfolio" />

ポートフォリオページを作成する課題。この課題では React や Vue などを使ってもいいよ、とのことだったので、自分は Next.js × emotion で作りました。これまでの課題と違って、デザインデータそのままを作るというよりは参考にする程度で、自分のデータをいれてカスタマイズする感じです。

自分は別でポートフォリオサイトを持っているので、そこまで作りこみはしませんでした。持っていない人はこの機会に作りこんでおいて、それを活用するのも1つの手ですね。

主な使用した技術やライブラリなどの振り返り

これを書くと若干実装のネタバレになる気もしますが、せっかくなので一緒に振り返ってみます。（当記事の投稿時点での使用技術です）

静的解析 + フォーマッタ

この辺はフロントエンドをやってるとおなじみですね。 VSCode 拡張として自動整形を動作させたり、GitHub Actions 上でもチェックするようにしてました。

途中から Pre Commit 設定も導入したいなということで、以下の2つを導入してコミット時フォーマットかけるようにも設定。

Vite

次世代フロントエンドツール。

課題を進めるにあたり、最初は VSCode 拡張の Live Server を使ってローカルサーバを立ててやってました。そこから JavaScript を使う課題へなった時に Vite のことを思い出し。 Web 制作でも活用できて爆速環境だよー、ということで使い始めました。導入も簡単でしたし、ホットリロードやビルドも爆速で動作するので、すごい快適でしたね。

ただ、Vite のホットリロードと VSCode 拡張として動作させていた Autoprefixer の自動整形がバッティングするという現象に遭遇して、記事を書いたりもしました。

VSCode拡張によるファイル保存時自動整形の影響で、ViteのホットリロードがバグってCSSが空になった話

以降、Autoprefixer は PostCSS として Vite 側で動作させるように。

Material Icons

課題のデザインの中で使われている各種アイコンは Material Icons を使っていると案内があったので、それを使うようにしました。 1～7の課題では CDN で。8の課題では emotion-icons 経由で使用。

modern-css-reset

リセット CSS はいろいろ種類があるわけですが、個人的にはこれがちょうどいいかなと最近使っています。

wicg-inert（+ メニューにおける制御）

inert 属性のポリフィル。そもそも inert 属性って何？って方は、以下の記事がとても参考になります。 <OG url="https://standard.shiftbrain.com/blog/unavailable-inert-regions-and-inert-attribute" />

メニューを開いた時、その下にある本コンテンツのことも考慮しないといけないんですよね。 Tab でフォーカスできないようにするとか、ポインターイベントを無効化するとか。ざっくり言うと、そういう管理を楽にできるのが inert 属性です。本実装はされていないため、このポリフィルを使用しています。

便利な inert 属性ですが、スクロール抑制には対応していないので、そこは自分で overflow: hidden をつけるなりが必要です。

フェードイン/アウト時に display が絡む時の問題

それとメニューの表示/非表示時にフェードイン/アウトのようなアニメーションをつけたい時。 display が絡む制御だと、フェードインは問題ないのにフェードアウトはうまく動作しない問題で頭抱えてましたね。フェードアウトアニメーションが終わる前に display: none へ切り替わってしまうための現象のようでした。

これについては、ほぼ同じ悩みを抱えていた方がいて、display でなく visibility を使う方向で解決しました。 visibility だと transition 制御が効くようです。 <OG url="https://medium.com/eureka-engineering/html-css-%E3%81%9F%E3%81%8B%E3%81%8C%E3%83%95%E3%82%A7%E3%83%BC%E3%83%89%E3%82%A4%E3%83%B3-%E3%83%95%E3%82%A7%E3%83%BC%E3%83%89%E3%82%A2%E3%82%A6%E3%83%88%E3%81%99%E3%82%8B%E3%81%A0%E3%81%91%E3%81%AE%E6%8C%99%E5%8B%95%E3%81%AB%E5%85%A8%E5%8A%9B%E3%81%A7%E5%8F%96%E3%82%8A%E7%B5%84%E3%82%93%E3%81%A0%E7%B5%90%E6%9E%9C-%E6%9C%80%E5%BC%B7%E3%81%AEcss%E3%81%8C%E3%81%A7%E3%81%8D%E3%81%A6%E3%81%97%E3%81%BE%E3%81%A3%E3%81%9F%E8%A9%B1-%E6%9C%80%E5%BC%B7-881152c4ff13" />

メニュー開閉時にスクロールバーの幅分ずれる問題

本コンテンツは縦スクロール出来るぐらい内容があり、スクロールバーが表示されている。それに対して、メニューを開いている時は縦スクロール出来るほど内容がないため、スクロールバーが表示されないという場合。

単純にフェードイン/アウトだけだと、スクロールバーの横幅分位置がずれてしまう現象が目立ってしまう問題がありました。（GIF をとってないのでどういうことかわかりづらいやもですが、本コンテンツとメニューの左右余白を同じにしてメニュー開閉するとわかるかなと）

スクロールバーの有無次第で余白を調整するみたいなことをやろうとしたものの、なんだかイマイチだったので、スライドイン/アウトも兼ねるようにして目立たなくするという回避策をとりました。

ページ初回読み込み時に transition が動作してしまう問題

スライドイン/アウトも兼ねるようにしたわけですが、今度はページ初回読み込み時に transition が動作してしまう問題に遭遇。本来はメニューボタンの押下で、はじめてスライドイン/アウトが動作するはずですが、それがページ初回読み込み時にも動作してしまうというものです。

こんな感じで一瞬ちらついてしまいます。

これに関しては、調べたところ Chrome のバグらしいです。本来は transition の初期状態が最初の状態になりますよね。そこが transition が反映されていない初期状態（メニューが画面内にある状態） → transition の初期状態（メニューが画面外にある状態）という感じで動作してしまっているとのことです。あらかじめ transition を無効にするクラスを付与しておき、ページ読み込み後にそのクラスを外すようにして対応しました。 <OG url="https://css-tricks.com/transitions-only-after-page-load" />

focus-visible

focus-visible 疑似クラスのポリフィル。 focus-visible 疑似クラスは Safari の対応がイマイチなので、ポリフィルを使うようにしています。

使うところとしては、ボタン要素の outline 制御です。 not と組み合わせて、キーボード操作以外の focus 時は outline を表示しないようにする感じ。

TypeScript × Next.js × emotion

8の課題の時のみ使用。元々、Front-end 編をやってた時に使ってた構成です。 TypeScript と Next.js はデファクトくらいの印象なので、実際に使いながら勉強したいなということで採用しました。

それと CSS in JS も流行っているので、どれか使えるようになりたいなというので、emotion を使うようになりました。個人的には styled-components よりも emotion の方が好みで、CSS Prop を使ってスタイルを書いています。

csx

8の課題の時のみ使用。 CSS に関するユーティリティな関数を提供するライブラリ。元々は TypeStyle というライブラリから使用されているもののようです。

RGB 値からでなくカラーコードを基準とした暗い色や明るい色、透明度を反映させた色を作りたいことがあったので、このライブラリを使った関数を作って活用しています。 Sass だったら元々関数が用意されているんですが、emotion だと使えないっぽかったので。

rss-parser

8の課題の時のみ使用。 RSS 情報を取得し、JS オブジェクトとして扱えるようにしてくれるライブラリ。

ブログの最新5記事を表示する、ということをやりたかったので活用しました。割とあっさり使えて便利でしたね。

完走してどうだった？

{/*  */}

元々、自分の業務経験としては、バックエンド寄りの方が多い身でして。フロントの業務経験としては、Web の管理システム系を React + UI コンポーネントライブラリで作ったことがある程度だったので、これまであまり素の HTML や CSS を書く機会がそんなになかったんですよね。その結果、フロントエンド志望になったのはいいが HTML・CSS 基礎が微妙なところあるってどうなの？という感じで、お恥ずかしい限りでした...。

そんな状態を克服するべく、この8課題を実際に自分で調べたり試行錯誤しながら作っていったことで、なんだか少し自信がついたといいますか。自分なりの進め方とか、スタイルのパターンとか、そういうのが定まってきた感覚がありましたね。本当に課題に取り組んでよかったなぁと。

Front-end 編が中断したままなので、次はそちらの続きもぼちぼちやろうかなと思います。

さっくりと振り返るつもりが、意外と長くなりましたね🙄 （長くなるのはもはやお家芸）

devChallenges は、現役の方が腕試しや復習をするのにも、未経験の方が勉強するにもいいコンテンツだと思います。興味がある方は、ぜひチャレンジしてみてはいかがでしょうか。

{/*  */}

参考リンクまとめ

※記事系のみ.

Windows側になるべく実行環境作りたくなかったやつが、Voltaでバージョン管理できるNode.js環境を作ってみた

Tue, 09 Nov 2021 00:00:00 GMT

こんにちは、開発環境整備って割と沼だよねと最近思っている、よしです。 Node.js 環境を改めて考える機会があり、Volta というバージョン管理ツールを使ってみました。その記録と紹介です。

※翻訳には Google 翻訳を使用しています。

import OG from "@/components/OG.astro"

Volta とは？

ざっくりいうと Node.js 関連に特化したバージョン管理ツールです。

The Hassle-Free JavaScript Tool Manager （訳：手間のかからない JavaScript ツールマネージャー）公式では、このように書かれていました。

Node.js のバージョン管理というと、nodenv とか nvm、n、Nodist とか色々有名なものがありますよね。それらに対して、Volta では Node.js だけでなく、パッケージマネージャである npm や yarn、npm パッケージも管理できます。公式では Volta の特徴として以下の3つがあげられています。

Fast

Install and run any JS tool quickly and seamlessly! Volta is built in Rust and ships as a snappy static binary. （訳：JS ツールをすばやくシームレスにインストールして実行してください！ Volta は Rust に組み込まれており、きびきびとした静的バイナリとして出荷されます。）

Volta は Rust で作られていることもあり、非常に動作が早いです。実際に Volta 経由で新しく Node.js を落としてくるときも、待ち時間はほとんどなかったです。10秒くらい。

Reliable

Ensure everyone in your project has the same tools—without interfering with their workflow. （訳：プロジェクトの全員が同じツールを使用していることを確認します。ワークフローに干渉することはありません。）

Google 翻訳だとなんかよくわからん感じになっていますが、プロジェクトメンバー全員が同じバージョンを使うようにできる、ということなのかなと。プロジェクトごとにバージョン固定ができるのは、既存のバージョン管理ツールでもおなじみですね。

Universal

No matter the package manager, Node runtime, or OS, one command is all you need: volta install. （訳：パッケージマネージャー、Node ランタイム、または OS に関係なく、必要なコマンドは1つだけです。volta install です。）

Volta は OS に関係なく動作します。これも Rust 製であることの恩恵の1つでしょうか。

既存のバージョン管理ツールの多くは Unix 系のみ対応で、Windows だと WSL 側でしか使えませんでした。 Windows 向けバージョン管理ツールとして Nodist がありましたが、（2021/11/09現在で）最終リリースが2019年で古くなっていたりと問題を抱えており...。 Volta は Windows でも動作するので、Nodist から移行したという方も見受けられましたね。

自分は個人 PC として Windows を使っていまして。これまでは Windows 側になるべく言語や実行環境を入れたくない派だったので、WSL 側や Docker で環境を作るようにして。 Node.js に関しては、WSL 側で Linuxbrew → anyenv → nodenv を使ってバージョン管理をして環境を作っており、特に困ったことはありませんでした。

そのなか、開発環境について考える機会があり、その時期にこの Volta を知り。実際に使ってみて良さそうであれば、今後は Windows 側で Node.js の管理しようかなと思ったわけです。

それでは、基本的な使い方を紹介していきます。

動作確認バージョン

Windows 10 Pro：20H2（19042.1288）
Volta：1.0.5

インストール

Windows

インストーラが用意されているので、それをダウンロードしてインストール。 GitHub リポジトリのリリースから直接ダウンロードしてもいいですし、winget でも対応しているのでそっちでも。

winget install --id Volta.Volta

インストーラを使うと、以下のパスを自動で追加してくれます。

ユーザ環境変数の Path：\Users\\{USER}\AppData\Local\Volta\bin
システム環境変数の Path：\Program Files\Volta\

システム環境変数の追加もあるので、ターミナルを起動していた場合は、ターミナルごと再起動してコマンドが使えるか確認。

補足として「Volta の機能はシンボリックリンクの作成に依存するため、次のいずれかを行う必要がある」とあります。

開発者モードを有効にする（推奨）
昇格された特権で Volta を実行する（非推奨）

開発者モード無効でもいける？

開発者モードにするのはなんだか少し抵抗があった自分は、まずは無効のままでインストールしてみました。

結論から言うと、Node.js とパッケージマネージャ（npm と yarn）のバージョン管理に関しては、特に問題なく動作した印象です。仕組みとして、〇〇env 系でおなじみの shim が使われているそうなので、問題なかったのかも？

しかし、npm パッケージに関してはシンボリックリンクが使われる仕組みのため、Volta 管理下でグローバルインストールするとエラーになりました。 Windows では、開発者モードでないと管理者権限のユーザでしかシンボリックリンクが作成できないことによるものでしょう。

volta install typescript
error: Could not create shared environment for package 'typescript'

Please ensure you have correct permissions to the Volta directory.

なので、npm パッケージのグローバルインストールを併用しないのなら、無効のまま Volta を使用しても支障はなさそう？ただ、公式では有効にすることが推奨されているので、無効のまま使用するのをおススメはしません。

ちなみに、自分が Volta をインストールした時は、ちょっとトラブりまして。

最初、インストール自体は成功しているのに volta コマンドが使えないという問題が生じてしまい...。何度かアンインストールとインストールを繰り返してもダメで。やっぱり開発者モードにしないとダメかーと思って有効にして、インストールしなおしてもダメで。

「???」という感じでしたが、Volta に関するディレクトリを削除したうえでインストールしなおしたら無事コマンドが使えるようになりました。

\Users\\{USER}\AppData\Local\Volta
\Program Files\Volta\

もしかしたら最初にインストールした時、どこかファイルが壊れていて、それが残っていたのかも？

Unix

Mac や Linux の方は curl でシェルを落としてきて、実行すれば OK。 WSL でも同様です。

curl https://get.volta.sh | bash

この方法では、使っているシェルに応じたファイル（~/.zshrcとか）にパスを自動で追加してくれるとのこと。（内部的に実行しているvolta setupコマンドによるもの）

export VOLTA_HOME="$HOME/.volta"
export PATH="$VOLTA_HOME/bin:$PATH"

ちなみに brew 経由でもインストールできます。

brew install volta

こちらではvolta setupの自動実行は行われないので、手動で実行。（もしくは自分で直接パスを追記）

volta setup

主な機能

コマンドの詳細は後述するので、さらっと書きます。

Node.js やパッケージマネージャ（npm、yarn）のバージョン管理

基本的には既存のバージョン管理ツールと同じく、指定バージョンのものを取得してきてインストール。インストールしたもののなかで、使用するバージョンを指定するという流れ。

以下は Node.js の例ですが、npm と yarn も同様です。

# 最新 LTS バージョンの Node.js を取得 + インストール + デフォルト（グローバル）バージョンに指定
volta install node
# v15.14.3の Node.js を取得 + インストール
volta fetch node@15.14.3

# そのプロジェクトでの（ローカル）バージョン指定
volta pin node@15.14.3

ローカルバージョンに指定したバージョンは、そのプロジェクトの package.json に記録されます。

{
  .
  .
  .
  "volta": {
    "node": "15.14.3",
    "yarn": "1.22.17"
  }
}

nodenv とかだと.node-versionに記録されるので、これは独自の方式ですね。 Netlify といったホスティングサービスでは、.node-versionでバージョン検知する仕組みがあったりするので、そういう恩恵は得られにくいような気もしました。

Volta 側でインストールしたバージョンを確認するとこんな感じ。 default がデフォルト（グローバル）バージョン、current がそのプロジェクトでの（ローカル）バージョン。（default と current で同バージョンの場合は、current が優先して表示される）

volta list all
⚡️ User toolchain:

    Node runtimes:
        v15.14.0 (current @ C:\Users\{USER}\XXXX\XXXX\package.json)
        v16.13.0 (default)

    Package managers:
        Yarn:
            v1.22.17 (current @ C:\Users\{USER}\XXXX\XXXX\package.json)

インストールできる各種バージョンについては、確認コマンドが見当たらなかったので、自分で Node.js 公式等を見る必要がありそうです。デフォルトでは、パブリックソースおよびレジストリ（https://nodejs.org、https://yarnpkg.com、https://www.npmjs.com）から取得するとのこと。 nodenv でいうnodenv install -lみたいな、一覧確認できるコマンドが今後追加されたらいいなぁと。

ちなみにパッケージマネージャに関しては、新しいものとしてpnpmがありますが、一応は使えるかなという感じでした。（試しにインストールしてみようとしたところ、パッケージマネージャというよりは、後述する npm パッケージとして認識されたので）

npm パッケージのバージョン管理

グローバルインストールしたものとローカルインストールしたものとで、同名の npm パッケージが存在していた場合、ローカルの方を優先して使うよ。というやつです。

例えば、普段ちょっとしたスクリプトを実行するのに TypeScript をグローバルインストールしていたとします。

# ※npm や yarn でグローバルインストールしても Volta 管理下になる
volta install typescript
# or
npm install -g typescript
# or
yarn global add typescript

tsc --version # 4.4.4

その一方で、とあるプロジェクトでは違うバージョンをローカルでインストールしていた場合。そのプロジェクトに移動した際には、ローカルバージョンが自動的に使われます。

cd /path/to/project-using-typescript-3.9.4
tsc --version # 3.9.4

また、グローバルインストールした npm パッケージは、インストール時のデフォルト（グローバル）バージョンである Node.js と関連付けられます。この npm パッケージを、グローバルバージョンとして使用する際は、この関連付けられた Node.js が使われるようになっているそうです。

volta list all
⚡️ User toolchain:
    .
    .
    .
    Packages:
        typescript@4.4.4 (default)
            binary tools: tsc, tsserver
            platform:
                runtime: node@16.13.0

その他の機能

{/*  */}

Node.js・npm・yarn をパブリックソースおよびレジストリ（https://nodejs.org、https://yarnpkg.com、https://www.npmjs.com）以外からダウンロードしたい場合の、ダウンロードプロセスへのフックを提供。

{/*  */}

1つのリポジトリに複数のプロジェクトがあり、それら全てで Volta 設定を共有したいワークスペース環境内で Volta を使用する方法を提供。（extends を使って、親 package.json の volta プロパティを参照するようなやり方）

コマンド

volta fetch

The volta fetch command will allow you to fetch a tool into the local cache, without setting it as a default or making it available, for future offline use. （訳：ツールをデフォルトとして設定したり、将来オフラインで使用できるようにすることなく、ツールをローカルキャッシュにフェッチできます。）

Fetches a tool to the local machine

USAGE:
    volta fetch [FLAGS] <tool[@version]>...

FLAGS:
        --verbose    Enables verbose diagnostics
        --quiet      Prevents unnecessary output
    -h, --help       Prints help information

ARGS:
    <tool[@version]>...    Tools to fetch, like `node`, `yarn@latest` or `your-package@^14.4.3`.

最初は、後述するinstallとかぶってるように思えて、この訳もよくわからんって感じでした。 installがツールの取得 + インストール + デフォルト（グローバル）設定であるのに対して、こちらはどうもツールの取得とインストールのみを行うもののようです。

バージョン指定についてはこんな感じ。

# v15.14.0 の Node.js を取得 + インストール
volta fetch node@15.14.0

# v15 の最新バージョンの Node.js を取得 + インストール
volta fetch node@15

# 最新 LTS バージョンの Node.js を取得 + インストール
volta fetch node

volta install

The volta install command will set your default version of a tool. It will also fetch that tool if it isn’t already cached locally （訳：volta install コマンドは、ツールのデフォルトバージョンを設定します。また、まだローカルにキャッシュされていない場合は、そのツールをフェッチします）

Installs a tool in your toolchain

USAGE:
    volta install [FLAGS] <tool[@version]>...

FLAGS:
        --verbose    Enables verbose diagnostics
        --quiet      Prevents unnecessary output
    -h, --help       Prints help information

ARGS:
    <tool[@version]>...    Tools to install, like `node`, `yarn@latest` or `your-package@^14.4.3`.

これは訳のとおりです。 nodenv なんかだと、インストール（nodenv install）とグローバルバージョン設定（nodenv global バージョン）が別コマンドだったので、ちょっと不思議な感じですね。

バージョン指定については fetch と同様です。

volta uninstall

The volta uninstall command allows you to remove any global package that has been installed with volta install. （訳：volta uninstall コマンドを使用すると、volta install でインストールされたグローバルパッケージを削除できます。）

Uninstalls a tool from your toolchain

USAGE:
    volta uninstall [FLAGS] <tool>

FLAGS:
        --verbose    Enables verbose diagnostics
        --quiet      Prevents unnecessary output
    -h, --help       Prints help information

ARGS:
    <tool>    The tool to uninstall, e.g. `node`, `npm`, `yarn`, or <package>

このコマンドでアンインストールできるらしいのですが、現状対応しているのはグローバルインストールした npm パッケージのみのようでした。自分が node と yarn で試してみた時は、エラーになってアンインストールできず。

> volta uninstall yarn
error: Uninstalling yarn is not supported yet.

> volta uninstall yarn@1.22.17
warning:  No package 'yarn@1.22.17' found to uninstall

> volta uninstall node
error: Uninstalling node is not supported yet.

> volta uninstall node@15.14.0
warning:  No package 'node@15.14.0' found to uninstall

実体としては以下のディレクトリにいるので、そこから削除してしまえば一応対応できるみたいです。

Windows：%LOCALAPPDATA%\Volta\tools\image
Unix：~/.volta/tools/image

ちなみにグローバルインストールした npm パッケージは、従来通り npm、yarn コマンドでもアンインストール可能。

volta pin

The volta pin command will update a project’s package.json file to use the selected version of a tool. （訳：volta pin コマンドは、選択したバージョンのツールを使用するようにプロジェクトの package.json ファイルを更新します。）

Pins your project's runtime or package manager

USAGE:
    volta pin [FLAGS] <tool[@version]>...

FLAGS:
        --verbose    Enables verbose diagnostics
        --quiet      Prevents unnecessary output
    -h, --help       Prints help information

ARGS:
    <tool[@version]>...    Tools to pin, like `node@lts` or `yarn@^1.14`.

そのプロジェクトでのツール（Node.js、npm、yarn のみ）のバージョンを固定する時に使用。nodenv でいうローカルバージョン指定。 package.json がないところで使ってもエラーになります。

固定したバージョンは packge.json へ記録されるようになっています。

volta list

The volta list command allows you to inspect your installed Node runtimes, package managers, and packages with binaries. （訳：volta list コマンドを使用すると、インストールされているノードランタイム、パッケージマネージャー、およびバイナリを含むパッケージを検査できます。）

Displays the current toolchain

USAGE:
    volta list [FLAGS] [OPTIONS] [tool]

FLAGS:
    -c, --current
            Show the currently-active tool(s).

            Equivalent to `volta list` when not specifying a specific tool.
    -d, --default
            Show your default tool(s).

        --verbose
            Enables verbose diagnostics

        --quiet
            Prevents unnecessary output

    -h, --help
            Prints help information


OPTIONS:
        --format <format>
            Specify the output format.

            Defaults to `human` for TTYs, `plain` otherwise. [possible values: human, plain]

ARGS:
    <tool>
            The tool to lookup: `all`, `node`, `yarn`, or the name of a package or binary.

Volta 管理下の各種バージョンを確認するのに使用。

volta completions

The volta completions command will generate command completion information for your shell. （訳：volta completions コマンドは、シェルのコマンド補完情報を生成します。）

Generates Volta completions

By default, completions will be generated for the value of your current shell,
shell, i.e. the value of `SHELL`. If you set the `<shell>` option, completions
will be generated for that shell instead.

If you specify a directory, the completions will be written to a file there;
otherwise, they will be written to `stdout`.


USAGE:
    volta completions [FLAGS] [OPTIONS] <shell>

FLAGS:
    -f, --force
            Write over an existing file, if any.

        --verbose
            Enables verbose diagnostics

        --quiet
            Prevents unnecessary output

    -h, --help
            Prints help information


OPTIONS:
    -o, --output <out_file>
            File to write generated completions to


ARGS:
    <shell>
            Shell to generate completions for [possible values: zsh, bash, fish, powershell,
            elvish]

コマンド入力補完のスクリプトを生成してくれます。使用しているシェルを指定することで、そのシェル用のスクリプトを出力してくれるので、あとはそれを読み込むようにすれば OK。

自分は bash で~/bash_completion配下にスクリプトを配置して、~/.bash_profileから読み込むようにしました。

then
  for COMPLETION in "${HOME}/bash_completion/"*
  do
    [[ -r "${COMPLETION}" ]] && source "${COMPLETION}"
  done
fi

volta which

The volta which command will unwrap Volta’s shims and locate the actual binary that will be launched by Volta. （訳：volta which コマンドは、Volta の shim をアンラップし、Volta によって起動される実際のバイナリを見つけます。）

Locates the actual binary that will be called by Volta

USAGE:
    volta which [FLAGS] <binary>

FLAGS:
        --verbose    Enables verbose diagnostics
        --quiet      Prevents unnecessary output
    -h, --help       Prints help information

ARGS:
    <binary>    The binary to find, e.g. `node` or `npm`

これは訳文のとおりです。実体のバイナリがあるパスを表示してくれます。

volta setup

The volta setup command will enable Volta by modifying the PATH for the current user (in a platform-dependent way) to include the Volta shim directory （訳：volta setup コマンドは、現在のユーザーの PATH を（プラットフォームに依存する方法で）変更して Volta shim ディレクトリを含めることにより、Volta を有効にします。）

Enables Volta for the current user

USAGE:
    volta setup [FLAGS]

FLAGS:
        --verbose    Enables verbose diagnostics
        --quiet      Prevents unnecessary output
    -h, --help       Prints help information

Volta のパスを通してくれるもの。 Volta を brew ではなく、インストーラで入れた場合は自動実行されるので、手動実行することはあまりなさそうです。

volta run

The volta run command will run the command that you give it, using versions of tools that are specified at the command line. （訳：volta run コマンドは、コマンドラインで指定されたバージョンのツールを使用して、指定されたコマンドを実行します。）

Run a command with custom Node, npm, and/or Yarn versions

USAGE:
    volta run [FLAGS] [OPTIONS] <command> [--] [args]...

FLAGS:
        --bundled-npm    Forces npm to be the version bundled with Node
        --no-yarn        Disables Yarn
        --verbose        Enables verbose diagnostics
        --quiet          Prevents unnecessary output
    -h, --help           Prints help information

OPTIONS:
        --node <version>         Set the custom Node version
        --npm <version>          Set the custom npm version
        --yarn <version>         Set the custom Yarn version
        --env <NAME=value>...    Set an environment variable (can be used multiple times)

ARGS:
    <command>    The command to run
    <args>...    Arguments to pass to the command

Volta を通して、各種コマンドを実行。オプションでコマンド実行時の使用バージョン指定ができるので、事前にバージョン切り替えをしなくていい。オプションとして各ツールのバージョンを指定しなかった場合は、そのプロジェクトの固定バージョンが。プロジェクトの固定バージョンもなければ、デフォルト（グローバル）バージョンが使われます。

バージョンごとの検証をする時などによさそうです。

volta help

Prints this message or the help of the given subcommand(s)

USAGE:
    volta help [subcommand]...

ARGS:
    <subcommand>...    The subcommand whose help message to display

Volta コマンドのヘルプを表示。

余談：asdf でのバージョン管理とその速度

今回、開発環境について考える機会があったことで Volta を使ってみたわけですが、実は元々 asdf を使おうかと思っていました。というのも、発端としては Twitter で anyenv から asdf に移行した方を見かけたことでした。

この asdf とは、言語や実行環境だけでなく CLI ツールにも対応しているバージョン管理ツールです。基本的な機構を有する asdf 本体がまずあって、そこへ各種言語・ツールに応じたプラグインを追加していくという構造になっています。プラグインの作り方は公開されており、有志の方がいろんなプラグインを作っているため、実に膨大な言語・ツールに対応しているなにやらすごいやつです。

これは anyenv の完全上位互換なのでは...！と想い、意気揚々と asdf を導入してみた自分。 Node.js もちゃんと動作しているし、大丈夫そうかなと思っていた矢先、実行速度の問題に直面しました。

同時期に導入したプロンプトの Starship。この Starship はプロジェクトディレクトリに移動すると、そのプロジェクトのファイルなどをスキャンして情報を表示してくれる機能を持っています。例えば Node.js だったら、package.json や .node-version、node_modules などの有無で Node.js のプロジェクトだと認識。 node -vでバージョンを取得して表示してくれます。

{/*  */}

ただ、このバージョン取得にやたら時間がかかってしまい、Starship のデフォルトのスキャン時間がタイムアウトしてしまう事態に...。じゃあ、一体 asdf 経由での Node.js 実行は、どのくらい時間かかっているのか？一旦タイムアウト時間を伸ばしてみてstarship explainで確認すると、1200ms～1500ms くらいかかっていました。時間かかりすぎでは...。 anyenv だと 500ms～700ms くらい（シェル起動時のスクリプトとしては、asdf の方が早いらしいです） Starship のスキャンタイムアウト時間をこれに合わせて設定すると、当然プロンプトの表示時間が遅いので微妙だなと考えるようになり。

{/*  */}

これについて調べていくと、どうも以前から速度面の問題はあったようで、こちらの記事でその Issue についての話があります。 <OG url="https://tech.buty4649.net/entry/2021/07/29/201613" />

直接バイナリを実行すると早いのに、asdf の shim 経由で実行すると遅くなるという現象。 direnv を使って対応する手もあるそうですが、プロジェクトごとに設定を書かないといけないのが気になってしまい...。また、自分の実行速度ほど遅い方は見かけなかったので asdf だけの問題ではなく、単純に自分の WSL 環境がよろしくない可能性もあるなと。そのため、WSL を初期化しなおしてみるとか、WSL2 にするとかを試す手もありました。

しかし、そんな時に Volta を知り。もう Windows 側でそこそこ早くて、ちゃんと動作するならそっちの方がよくないか？と思い、今回に至ったというわけです。ちなみに Windows 側に Volta と Starship をいれて、starship explainで Node.js のスキャン時間を計測すると 70ms～120ms くらいでした。 WSL 側の anyenv、asdf と比べると、だいぶ早くなりましたね。

今回は、紆余曲折あって行きついた Volta を紹介してみました。他の方の Volta 記事との差別化や、未来の自分が見ても納得するように書こうとしたら、だいぶ長くなりましたね🙄 まぁでも、おかげで自分の中の疑問点がおおよそ解消されました。

Volta 導入を検討している方の、何かの参考になれば幸いです。

参考リンクまとめ

余談.

VSCode拡張によるファイル保存時自動整形の影響で、ViteのホットリロードがバグってCSSが空になった話

Sun, 24 Oct 2021 00:00:00 GMT

こんにちは、よしです。先日、Vite デビューをしたところ思わぬ現象に遭遇してしまいました...。せっかくなので、その対応方法とともに記録を残します。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

要約

さらっと結論だけ知りたい方向けに、先に結論を書いておきます。

{/*  */}

VSCode 拡張の Autoprefixer を導入している + ファイル保存時にこの拡張の自動整形を動作させている ↓ Vite のローカルサーバを立ち上げてコードを書いている ↓ Vite の（CSS ファイル保存時の）ホットリロードが時折バグって、生成物の CSS の中身が空になってしまうことがある ↓ Vite と Autoprefixer を併用する場合は、Autoprefixer を VSCode 拡張として動作させるのでなく、PostCSS として Vite 側で実行してもらうようにしようね！

{/*  */}

ちなみに当記事では Vite についての説明は特にしません。

遭遇したときの状況とその現象

海外のとある課題サイトの課題を進めていたところ。微量ながら JavaScript も書くので、せっかくなら Vite を導入してみるかーと途中から導入。 <OG url="https://ja.vitejs.dev" />

導入には公式サイトともに、こちらの記事を参考にさせていただきました。 <OG url="https://ics.media/entry/210708/#contents-anchor-pitfalls" />

Vite を使ったのはこれが初めて。導入の楽さと爆速の環境を体験して、次世代のフロントエンドツールとして注目されているのもわかるなぁという気持ちでした。

そのなか、スタイリングをするために CSS ファイルを編集してホットリロードを何度かさせていると...。爆速のホットリロードで、全くスタイルがあたってない状態になってしまいました。あまりに不意のことだったので、「急にどうした！？」とテンパる自分。

そこからさらにホットリロードを何度かさせると、元に戻ることもあればそのままの状態が続いたり。たまに起こるくらいならまだしも、4、5回に1回くらいの頻度で発生するので、こりゃあ原因調査してみようということに。

原因調査

JavaScript ファイルが読み込まれてない？実行されていない？

Vite を使っている場合、CSS ファイルの読み込みに関しては、起点となる JavaScript ファイルからインポートということもできます。自分の場合もそうしていました。そのため、最初は JavaScript が読み込まれてないとか、実行されていないとかなのかな？と。

試しに JavaScript ファイルへ setInterval を仕込むと普通に動作していたので、この説はなし。また、この現象は CSS ファイル保存時のホットリロード時のみ発生していたので、CSS がなんかおかしくなっている説へ。

生成される CSS がおかしい？

正常時と現象発生時の CSS を比較して見てみることに。

起点 JavaScript ファイルから CSS ファイルをインポートした場合

import '../css/style.css';

Vite の本来の挙動としては以下のようになっています。

.css ファイルをインポートすると、HMR をサポートする style タグを介してそのコンテンツがページに挿入されます。

<ImageWrapper className="w-[80%]" src="screenshots/2021/vscode-autoprefixer-vite/css-import-normal.png" alt="起点JavaScriptファイルからCSSファイルをインポートした場合に挿入されるstyleタグ - 正常" /> 本来はこのように head タグ配下に style タグが挿入され、そこに CSS の内容が展開されます。

しかし、現象発生時は head タグ配下に style タグ自体は挿入されているものの、内容が空になっている状態。 <ImageWrapper className="w-[80%]" src="screenshots/2021/vscode-autoprefixer-vite/css-import-abnormal.png" alt="起点JavaScriptファイルからCSSファイルをインポートした場合に挿入されるstyleタグ - 異常" />

link タグから CSS ファイルを読み込んだ場合

<link href="css/style.css" rel="stylesheet" />

正常時は、CSS ファイルにクエリパラメータがついたものを読み込むような感じに変化。

現象発生時は、CSS ファイルの中身が空になってしまっている状態。 <ImageWrapper className="w-[80%]" src="screenshots/2021/vscode-autoprefixer-vite/css-link-abnormal.png" alt="linkタグからCSSファイルを読み込んだ場合のlinkタグ - 異常" /> <ImageWrapper className="w-[80%]" src="screenshots/2021/vscode-autoprefixer-vite/css-link-file-abnormal.png" alt="linkタグからCSSファイルを読み込んだ場合のCSSファイル - 異常" />

これで、とりあえず CSS がおかしくなっているということは特定。あとは、なぜ CSS がおかしくなってしまっているのか？という部分の調査へ。

Google 先生に頼る・Issue を見てみる

まずは、同じ現象に遭遇した方がいないかググってみよう！ ↓ 似たような現象が起きてる方すら見つからず...。

じゃあ、Vite のリポジトリの Issue に上がってないか見てみよう！ ↓ 少し似ている現象の Issue は見つかるも、よく読み込んでいくとなんか違う...

これはもしや、レアケースな現象をひいてしまったのか？もし原因を特定できたら Vite リポジトリに contribute するチャンスか？なんて考えていました。

...が、ここで VSCode 拡張によるファイル保存時の自動整形のことを思い出し。あ、これ、自動整形とバッティングしてるんじゃね？ということで、そちらを見ていくことに。

バッティングしている VSCode 拡張の特定

この時、VSCode 上でファイル保存時の自動整形を動作させている拡張のうち、CSS ファイルに関するものは以下の3つ。

StyleLint：CSS の静的解析 + 自動整形
Prettier：コードフォーマッタ
Autoprefixer：自動でベンダープレフィックス付き CSS プロパティを付与してくれるやつ

設定を調整しながら、1つずつ見ていくと...

StyleLint：現象発生せず
Prettier：現象発生せず
Autoprefixer：現象発生！

はい、Autoprefixer のファイル保存時の自動整形とバッティングして、おかしな挙動になっていたようです。

Vite と Autoprefixer の共存

ただ、Autoprefixer は非常に便利なのでどうにか共存させたい。またググってみた結果、Vite 側で実行させるようにすればいいじゃん～という結論に至りました。（というか、大多数の方は普通にそうしている気がする...🙄）

VSCode 拡張の自動整形設定は削除（デフォルトがオフなので）

- "autoprefixer.formatOnSave": true

ライブラリとしてインストール.

yarn add -D postcss autoprefixer

PostCSS として Autoprefixer を使用するよう設定.

module.exports = {
  plugins: [require('autoprefixer')],
};

もしプロジェクトに有効な PostCSS が含まれている場合 (postcss-load-config でサポートされている任意の形式、例: postcss.config.js)、インポートされたすべての CSS に自動的に適用されます。

と公式にあるように、これだけで自動的に適用されます。 Autoprefixer のオプションについてはお好みで。 Vite の設定ファイルであるvite.config.jsにも、PostCSS の設定を書けるプロパティがあるので、そっちで書いても OK。自分の場合は、別ファイルにしたかったので分けてます。

ローカルサーバを立ち上げてみると、展開される CSS にちゃんとベンダープレフィックス付き CSS プロパティが付与されてる！本番ビルド生成物でも無事確認できたので、これにて解決🎉 これで Vite の爆速環境を満喫できるぞーー！

{/*  */}

ちなみに、これでベンダープレフィックス付き CSS プロパティは自分で書かないようになるので、StyleLint のproperty-no-vendor-prefixというルールを導入しておくとよいです。これはベンダープレフィックスを禁止にするルールなので、もし書いてしまっていてもすぐに気付けます。

{/*  */}

余談

この調査をしている時に、ちょうど StyleLint の VSCode 拡張のアップデートにも遭遇。 1系リリースに伴い StyleLint 14系からのサポート + 破壊的変更、とあり、この拡張が動作しなくなったという...。

調査してる時に微妙に関係ある別の対応入るのやめてくれよぉぉぉと内心思っていましたが、公式の移行ガイドを見ながら設定を見直して事なきを得ました(笑)

今回は、大した文字数の記事じゃないこともあり、いつもと少し文体を変えて遊んでみました。うざかったらすみません。

これ書いていて、この現象に遭遇したの自分くらいなのでは？という気もしたりしなかったりですが、まぁ何かのお役に立てば幸いです。

参考リンクまとめ

{/*  */}

{/*  */}

こんにちはMUI！新しくなったMaterial UI v5

Sun, 26 Sep 2021 00:00:00 GMT

{/*  */}

どうもよしです。久しぶりの投稿になります。元々、Material Design をベースとした UI コンポーネントライブラリである、Material UI の v5 が遂にリリースされました！ v4 からどう変わったのか自分でも試すなど、さらっと見てみたので、ここにまとめてみました。

※2023/07/09 MUI の更新に伴い、MUI v5.0系のドキュメント参照したほうが良い部分はリンクを差し替えました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

Material UI とは？

元々、Google の Material Design をベースに開発された、UI コンポーネントライブラリです。

Material UI の概要や v4 の機能に関しては、以前に記事を書いていますので、よろしければそちらをご参照ください。

React向けUIコンポーネントライブラリ、Material UI(v4)の紹介

※今回の記事は、主に以下の公式ブログ記事をもとにしています。引用文の出典もそちらです。そのため、すでにそちらをご覧になっている方には、あまり真新しい情報はないやもしれません。 <OG url="https://mui.com/blog/material-ui-is-now-mui" /> <OG url="https://mui.com/blog/mui-core-v5" />

※翻訳には Google 翻訳を使用しています。 ※比較では、v4.12.3 と v5.0.0 とで比較しています。

v5 の開発背景

In our last survey, the number of developers that commented about improving the Material Design implementation was down by 60% compared to the year before. At the same time, 5X more developers were struggling to customize the components.

It was based on this context that we started work on v5 in 2019. Our primary focus was to revamp the customization Developer Experience (DX). It had become clear that design (aesthetic, UX) and DX were key to unlocking the next stage of growth.

The new brand supports the v5.0.0 release while also creating space for new initiatives that broaden the company horizon. It's a big deal!

Our ultimate goal is to become the most effective and efficient tool to build UIs while making it accessible to the many.

↓

前回の調査では、Material Design の実装の改善についてコメントした開発者の数は、前年と比較して60％減少しました。同時に、5倍以上の開発者がコンポーネントのカスタマイズに苦労していました。

2019年に v5 の作業を開始したのは、このコンテキストに基づいていました。私たちの主な焦点は、カスタマイズの開発者エクスペリエンス（DX）を刷新することでした。デザイン（美的、UX）と DX が成長の次の段階を解き放つ鍵であることが明らかになりました。

新しいブランドはv5.0.0リリースをサポートすると同時に、会社の視野を広げる新しいイニシアチブのためのスペースを作成します。それは大したことです！

私たちの究極の目標は、多くの人がアクセスできるようにしながら、UI を構築するための最も効果的かつ効率的なツールになることです。

{/*  */}

Material UI は元々、React の開発者が Material Design を使用できるようにと、Material Design ガイドラインの React 実装として 2014年に開発開始されました。 2018年に v1 をリリース。

{/*  */}

その後も開発は続けられ、日々改善が行われていましたが、コンポーネントのカスタマイズ性に関して課題を抱えていたようです。それを解決するというのが、v5 開発の大きな目的だったとのこと。実際に、v5 にはコンポーネントのカスタマイズをよりやりやすくするような新機能が取り入れられています。

新ブランド

これまでのMaterial UIから、MUIというブランド名に変わりました。

We are breaking the strong association with Material Design as we have seen too many people confusing Material-UI with Google, or as a synonym of Material Design.

We are now called MUI. It stands for Material to build UIs and is pronounced /ɛm juː aɪ/.

It's shorter, it distinguishes us, and it's familiar – many people already used it for abbreviating Material-UI. More importantly, it allows for the release of products not directly coupled to Material Design, such as an unstyled/headless version of the components, a brand new second design system as an alternative to MD, and more ambitious initiatives.

↓

Material-UI を Google と混同している人や、Material Design の同義語として多くの人が見ているため、Material Design との強い関連性を断ち切っています。

現在は MUI と呼ばれています。 UI を構築するための Material の略で、/ɛmjuːaɪ/と発音されます。

短く、私たちを区別し、よく知られています。多くの人がすでにMaterial-UI の省略形として使用しています。さらに重要なことは、コンポーネントのスタイルなし/ヘッドレスバージョン、MD の代替としてのまったく新しいセカンドデザインシステム、より野心的なイニシアチブなど、Material Design に直接結合されていない製品のリリースを可能にすることです。

Material Design の枠だけにとらわれない、新たな試みを行っていくことが示されていますね。

その中で、3つのプロダクトに分かれることにもなりました。

MUI Core：すぐに使用できる基本コンポーネント群 + 永久に無料で使えるもの
MUI X：より複雑なユースケース向けの高度なコンポーネント群 + 有料部分も含むもの
Templates：コミュニティによって開発された、MUI を使用したテンプレート

ロゴ

微妙に変わりました。

<ImageWrapper className="w-[70%]" src="screenshots/2021/material-ui-v5/material-ui-new-logo.png" alt="Material UI - ロゴの比較画像" /> （画像は公式ブログ記事より）

It's basically the same, to keep it familiar – we're keeping the geometrical shape, to resonate with the building blocks idea of the components – however, we're reducing the emphasis on the 3D perspective, stepping away from the notion of elevation that Material Design coined.

↓

基本的には同じです。慣れるために、幾何学的な形状を維持し、コンポーネントのビルディングブロックのアイデアに共鳴します。ただし、3D パースペクティブの重要性を減らし、標高の概念から離れています。Material Design の造語。

リポジトリ名

2021/09/26現在、material-ui のままでした。ただ、README では、ちゃんとMUIという表記になっていました。

ドメイン

これまではこちらでした。

https://material-ui.com/

現在はこちら。シンプルになりましたね。 v5 の公式サイトはデザインが一新されています。

ちなみにhttps://material-ui.com/にアクセスすると、https://mui.com/へリダイレクトするようになっていました。

パッケージ名

こちらも新ブランド名に応じた名称へ変わりました。

MUI Core プロダクトに含まれるパッケージ一覧。

@material-ui/core -> @mui/material
@material-ui/system -> @mui/system
@material-ui/unstyled -> @mui/core
@material-ui/styles -> @mui/styles
@material-ui/icons -> @mui/icons-material
@material-ui/lab -> @mui/lab
@material-ui/types -> @mui/types
@material-ui/styled-engine -> @mui/styled-engine
@material-ui/styled-engine-sc ->@mui/styled-engine-sc
@material-ui/private-theming -> @mui/private-theming
@material-ui/codemod -> @mui/codemod
@material-ui/docs -> @mui/docs
@material-ui/envinfo -> @mui/envinfo

インストール方法も同様に変わっています。以下は基本パッケージである@material-ui/core（@mui/material）をライブラリとしてインストールする例です。

React：16.8.0 以上
react-dom：16.8.0 以上

npm install @material-ui/core
or
yarn add @material-ui/core

↓

React：17.0.0 以上
react-dom：17.0.0 以上

# emotion を使う場合
npm install @mui/material @emotion/react @emotion/styled
or
yarn add @mui/material @emotion/react @emotion/styled

# styled-components を使う場合
npm install @mui/material @mui/styled-engine-sc styled-components
or
yarn add @mui/material @mui/styled-engine-sc styled-components

後述しますが、v5 ではデザインシステムの実体であるスタイリングソリューションが変更され、emotion か styled-components を使うようになりました。そのため、このようなインストール方法となっています。

パッケージ名が変更になっている分、v4 と v5 を共存させることもできそうです。（CodeSandbox では確認できました） 1プロジェクトのコードでパフォーマンスの比較をしたり、一時的に共存させて、段階的に v5 に移行していくということもできそうですね。

セカンドデザインシステム

Developing a new design system is one of the main initiatives, alongside this new brand and the unstyled components, to grow MUI beyond Material Design. Its codename is Joy and we have just started the high-level discussion around it.

It will be built on top of our foundation packages (the base/unstyled components and @mui/system) to provide the API shaped similarly to our Material Design components. We plan on having built-in CSS variables generated from the theme, a great dark mode API, a custom look and feel, and more.

We're aiming for developing the most frequently used components first, as we plan on releasing them continuously with each milestone. We intend to have Joy versions of all components already available on Material Design so that developers can then pick between them, choosing the design they like the most. The main difference will be the theme structure, where we want to achieve the right amount of flexibility while providing an amazing design by default.

We'll keep you updated about the progress. And as always, you're invited to contribute to it as well. Stay tuned!

↓

新しいデザインシステムの開発は、この新しいブランドやスタイルのないコンポーネントと並んで、Material Design を超えて MUI を成長させるための主要なイニシアチブの1つです。そのコードネームは Joy で、私たちはそれに関するハイレベルな議論を始めたばかりです。

これは、ファンデーションパッケージ（ベース/スタイルなしコンポーネントおよび @mui / system）の上に構築され、Material Design コンポーネントと同様の形状の API を提供します。テーマから生成された組み込みのCSS変数、優れたダークモード API、カスタムのルックアンドフィールなどを計画しています。

マイルストーンごとに継続的にリリースする予定であるため、最も頻繁に使用されるコンポーネントを最初に開発することを目指しています。開発者が最も気に入ったデザインを選択できるように、Material Design ですでに利用可能なすべてのコンポーネントの Joy バージョンを用意する予定です。主な違いはテーマの構造です。テーマの構造では、デフォルトですばらしいデザインを提供しながら、適切な量の柔軟性を実現したいと考えています。

進捗状況を随時お知らせします。そしていつものように、あなたもそれに貢献するように招待されています。乞うご期待！

前述の通り、新ブランドへの移行に関して Material Design の枠だけにとらわれない、新たな試みを行っていくことが示されていました。そのなかでセカンドデザインシステムのことに触れられていましたが、Joy というコードネームのデザインシステムが開発されているようです。全てのコンポーネントの Joy バージョンを開発予定ということで、より表現の幅が広がりそうですね！

デザインシステム

スタイリングソリューションの再考

v5 でコンポーネントのカスタマイズ性の向上させるにあたって、まずはデザインシステムの実体であるスタイリングソリューションを再考。

これまでも何度か移行を繰り返してきた中で、v4 ではスタイリングソリューションとして JSS が使われていました。 <OG url="https://github.com/cssinjs/jss" />

しかし、以下のような問題を抱えていたとのこと。

The React community is settling on styled() as the most popular CSS-in-JS API. We have used popularity as a proxy for "best". You can find it in styled-components, emotion, goober, stitches, or linaria. While MUI is compatible with any styling solution (as long as the styles have more specificity, for example, Tailwind CSS), many developers still felt the need to learn something new: the makeStyles API.

Our React integration with JSS (@mui/styles) is too slow to unlock the next layer of customization DX we aim for. The static CSS generation using v4 was fast enough, even faster than emotion, however, the dynamic style generation was too slow to be used in production. We would have needed to reimplement it.

Many developers were advocating for MUI to migrate to styled-components, which would allow us to drop the custom React JSS wrapper we maintain. From our experience, maintaining a custom styling solution takes a considerable amount of time.

↓

React コミュニティは、最も人気のある CSS-in-JS APIとしてstyled（）を採用しています。私たちは「最高」の代用として人気を利用してきました。あなたはそれを styled-components, emotion, goober, stitches, または linaria で見つけることができます。 MUI はどのスタイリングソリューションとも互換性がありますが（たとえば、Tailwind CSS など、スタイルの特異性が高い限り）、多くの開発者は、makeStyles API という新しいことを学ぶ必要性を感じていました。

React と JSS（@mui/styles）の統合は遅すぎて、私たちが目指すカスタマイズ DX の次のレイヤーのロックを解除できません。 v4 を使用した静的 CSS 生成は十分に高速で、emotion よりも高速でしたが、動的スタイル生成は遅すぎて本番環境で使用できませんでした。それを再実装する必要があったでしょう。

多くの開発者は、MUI を styled-components に移行することを提唱していました。これにより、私たちが維持しているカスタム React JSS ラッパーを削除できるようになります。私たちの経験から、カスタムスタイリングソリューションの維持にはかなりの時間がかかります。

これらを解決するために検討を重ねた結果がこちら。

After exploring many different options, we settled on what we believe is a great tradeoff to solve the above issues:

1.We have made styled() the lowest level primitive to add styles. This API is already known by many.

2.We have defined a common interface with concrete implementations:

@mui/styled-engine: implemented with emotion (default).

@mui/styled-engine-sc: implemented with styled-components

If you are using a different styling library, feel free to contribute a wrapper. For instance, there is one attempt with goober, a library obsessing on bundle size (3kB gzipped). This allows developers to swap between different style engines. For example, styled-components users no longer need to bundle emotion and styled-component, nor do they need to configure the server-side rendering for each. How does the swap work? The same way it does from React to Preact.

3.For the last couple of months, we have been sponsoring emotion with a $100/month grant. We are now increasing this amount to $1,000/month. It's in our best interest to help ensure the library keeps pushing the envelope, leading the state of the art in a competitive space.

↓

多くの異なるオプションを検討した後、上記の問題を解決するための大きなトレードオフであると私たちが信じていることを決定しました。

1.styled()を、スタイルを追加するための最低レベルのプリミティブにしました。この API はすでに多くの人に知られています。

2.具体的な実装との共通インターフェースを定義しました。

@mui/styled-engine：emotion で実装されます（デフォルト）

@mui/styled-engine-sc：styled-components で実装

別のスタイリングライブラリを使用している場合は、ラッパーを自由に提供してください。たとえば、バンドルサイズ（3kB gzip圧縮）にこだわるライブラリである goober を使用した1つの試みがあります。これにより、開発者は異なるスタイルのエンジン間で交換できます。たとえば、styled-components のユーザーは、emotion と styled-components をバンドルする必要がなくなり、それぞれのサーバー側レンダリングを構成する必要もなくなりました。スワップはどのように機能しますか？ React から Preact までと同じ方法です。

3.過去数か月間、私たちは月額100ドルの助成金で emotion を後援してきました。現在、この金額を月額1,000ドルに増やしています。図書館が限界を押し上げ続け、競争の激しい分野で最先端をリードすることを確実にすることは、私たちの最大の利益です。

インストール方法の所でも少し触れましたが、v5 では emotion もしくは styled-components がデザインシステムの実体として使われることになりました。 <OG url="https://github.com/emotion-js/emotion" /> <OG url="https://github.com/styled-components/styled-components" />

共通インタフェースを定義したうえで、この2つの実装がされているため、どちらか好きな方を使えます。デフォルトでは emotion が使われるようになっており、emotion を採用した決め手としては、パフォーマンス面が大きかったようです。

こちらで Box コンポーネントを使ったパフォーマンス比較のコードが用意されていて、v4 と比べると5倍以上も高速化しているのが確認できます。早い👀 <OG url="https://codesandbox.io/s/zlh5w?file=/src/App.js" />

v4 でも styled()を使ったスタイルのカスタマイズは可能でしたが、makeStylesを使った書き方が一般的でした。

v4：makeStyles方式例.

import { VFC, ReactNode } from 'react';
import { makeStyles } from '@material-ui/core/styles';
import Button from '@material-ui/core/Button';

const useStyles = makeStyles({
  button: {
    backgroundColor: 'green'
  }
});

type Props = {
  children: ReactNode;
}

const HooksButton: VFC<Props> = ({ children }) => {
  const classes = useStyles();

  return (
    <Button variant="contained" className={classes.button}>
      {children}
    </Button>
  );
}

export default HooksButton;

v4：styled方式例.

import { VFC, ReactNode } from 'react';
import { styled } from '@material-ui/core/styles';
import Button from '@material-ui/core/Button';

const CustomButton = styled(Button)({
  backgroundColor: 'red'
});

type Props = {
  children: ReactNode;
}

const StyledButton: VFC<Props> = ({ children }) => {
  return <CustomButton variant="contained">{children}</CustomButton>;
};

export default StyledButton;

v5 では、makeStylesは廃止され、styled()でカスタマイズがメインになっていくようです。

v5：styled方式例.

import { VFC, ReactNode } from 'react';
import { styled } from '@mui/material/styles';
import Button from '@mui/material/Button';

const CustomButton = styled(Button)({
  backgroundColor: 'red'
});

type Props = {
  children: ReactNode;
}

const StyledButton: VFC<Props> = ({ children }) => {
  return <CustomButton variant="contained">{children}</CustomButton>;
};

export default StyledButton;

なお、v5 でもmakeStyles方式を使いたい場合は、@mui/stylesに従来の JSS でのスタイルシステムが残されているので、そちらから使うことができるとのこと。（基本的にはコアコンポーネントと一致させるために移行を推奨）

プレーンな CSS、CSS Modules との併用は引き続き可能です。 emotion 版を使っているのであれば、emotion の css props を使うのも1つの手ですね。（個人的な好みとして、emotion では css props を使う派でして...）

ちなみに v4 時代から styled-components および emotion との親和性はあったようで、v4 の公式ドキュメントにも使い方は載っていました。

/** @jsxImportSource @emotion/react */
import { VFC, ReactNode } from 'react';
import Button from '@mui/material/Button';
import { css } from '@emotion/react';

type Props = {
  children: ReactNode;
};

const EmotionButton: VFC<Props> = ({ children }) => {
  return (
    <Button
      css={css`
        width: 100px;
      `}
      variant="contained"
    >
      {children}
    </Button>
  );
};

export default EmotionButton;

sx props

styled()を使うまでもない、少しのスタイルカスタマイズや1回きりのスタイル定義に使える新機能。 sxという props にスタイルを定義することで、スタイルのカスタマイズができます。その特性から「ユーティリティ」とも呼ばれているそうです。

// my は marginTop と marginBottom のエイリアス
// margin: 8px 0px;
<Button sx={{ my: 1 }}>Test</Button>

このsx propsは、以下のコンポーネントで使用できます。

MUI Core プロダクトに含まれる（@mui/material, @mui/icons-material, @mui/lab など）コンポーネント
（@mui/material/styles の）styled()で作成したカスタムコンポーネント
babel プラグインを含む任意の要素（※2021/09/26時点で TODO になっていました）

一見、styleによるインラインスタイルと似ていますね。 sx propsの場合は通常のスタイル定義が書けることに加え、特定の CSS プロパティでエイリアスが使えたり、テーマ情報とマッピングされた値が使えたり。疑似要素やメディアクエリが使えたり、ネストができたり。より柔軟に書くことができるようになっています。

特定の CSS プロパティ（デザインシステムに実装されているシステムプロパティ）の一覧はこちら。 <OG url="https://v5-0-6.mui.com/system/properties" />

sx propsの使用例.

import Box from '@mui/material/Box';

const BoxSx = () => {
  return (
    <Box
      sx={{
        boxShadow: 1 // theme.shadows[1]
        color: 'primary.main', // theme.palette.primary.main
        m: 1, // margin: theme.spacing(1)
        p: {
          xs: 1, // [theme.breakpoints.up('xs')]: { padding: theme.spacing(1) }
          md: 2  // [theme.breakpoints.up('md')]: { padding: theme.spacing(2) }
        },
        zIndex: 'tooltip', // theme.zIndex.tooltip
      }}
    >
      test
    </Box>
  );
}

export default BoxSx;

疑似要素の例.

<Box
  sx={{
    '&:hover': {
      boxShadow: 1
    }
  }}
/>

メディアクエリの例.

<Box
  sx={{
    '@media (max-width: 600px)': {
      width: 300,
    }
  }}
/>

ネストの例.

<Box
  sx={{
    '& div': {
      bgcolor: 'primary.main',
    }
  }}
>
  <div>test</div>
</Box>

また、テーマ情報を受け取るコールバック式でも書くことができます。こちらは、テーマ情報を元に加工した値を設定したい時などに使うイメージです。

<Box sx={{ height: (theme) => theme.spacing(10) }} />

優先度

同一 CSS プロパティの指定が複数あった時の優先度は、低い順から.

そのコンポーネントが元々受け入れる props によるスタイル（Button コンポーネントの color props など）
sx propsによるスタイル
インラインスタイル

となっていました。

パフォーマンス

公式に比較表がありました。 <ImageWrapper className="w-[90%]" src="screenshots/2021/material-ui-v5/sx-props-performance.png" alt="MUI - sx props のパフォーマンス比較画像" />

sx propsを使用すると、やや速度が落ちるようです。それでもほとんどの用途では十分高速であるとされていますが、あまりの多用は控えた方がいいやもしれませんね。

CSS コンポーネントユーティリティ

新機能のsx propsですが、実は v4 の Box コンポーネントでも少し似たようなことは出来ていました。こちらはsx propsを使わずに直接 props として渡す感じ。違いといえば、疑似要素やメディアクエリ等は使えず、特定の CSS プロパティ（デザインシステムに実装されているシステムプロパティ）のみ対応だったことでしょうか。

v4 での Box コンポーネントの使用例.

import { VFC } from 'react';
import { Box, Button } from '@material-ui/core';

const App: VFC = () => {
  return (
    <Box m={2}>
      <Button variant="contained">Test</Button>
    </Box>
  );
}

export default App;

このシステムプロパティを受け入れるコンポーネントは、CSS コンポーネントユーティリティと言われるそうで。 v5 においては以下の4つのコンポーネントが該当します。

Box
Stack
Typography
Grid

なぜこの4つだけなのかは、公式ドキュメントの API トレードオフの項に記述があります。 <OG url="https://v5-0-6.mui.com/system/basics/#api-tradeoff" />

これ以外のコンポーネントでシステムプロパティを使いたかったり、小さなスタイルのカスタマイズをしたい時にsx propsを使っていく感じになるようです。ちなみに CSS コンポーネントユーティリティに該当する4つのコンポーネントでもsx propsは使用できます。 sx propsの方がカスタマイズ性に優れているので、直接システムプロパティを使っていくことはあまりないやもしれませんね。（公式のサンプルコードでもsx propsを使っているものが多く見受けられました）

直接システムプロパティを指定するのと、sx propsで指定するのとで、同一 CSS プロパティを指定した場合は後者の値が使われました。

開発背景

v5 におけるスタイルのカスタマイズはstyled()を使うのがメインになったわけですが、少しのスタイルカスタマイズでもこれを使うということは、以下のような問題がありました。

Switching context wastes time. The styled API forces you to constantly jump between the use of the styled components and where they are defined. Could we move the style descriptions right where we need them?

Naming things is hard. Have you ever found yourself struggling to find a good name for a styled component? Could we remove the need to create and name yet another component?

Enforcing consistency in UIs is hard. This is especially true when more than one person is building the application, as there has to be some coordination amongst members of the team regarding the choice of design tokens and how they are used, what parts of the theme structure should be used with what CSS properties, and so on.

↓

コンテキストを切り替えると時間が無駄になります。スタイル付き API を使用すると、styled-components の使用とそれらが定義されている場所の間を常にジャンプする必要があります。スタイルの説明を必要な場所に移動できますか？

名前を付けるのは難しいです。styled-components の適切な名前を見つけるのに苦労したことがありますか？さらに別のコンポーネントを作成して名前を付ける必要をなくすことができますか？

UI で一貫性を強制することは困難です。これは、複数の人がアプリケーションを構築している場合に特に当てはまります。デザイントークンの選択とその使用方法、テーマ構造のどの部分をどの CSS で使用するかについて、チームのメンバー間で調整を行う必要があるためです。プロパティなど。

これらの問題を解決するための機能として、sx propsが実装されたとのことです。（これも emotion への移行により可能となったものです）

1と2に関しては、自分が個人的に styled-components 方式をあまり好きになれない理由に近いものがあり、すごいわかるーってなりました(笑)

動的 props

MUI のコンポーネントに独自の props を追加するなど拡張したい時、v4 ではラッパーコンポーネントを作るような方法で多くは対応されてきました。しかし、以下のような問題を抱えていたとのこと。

Each time you create a new component, it's another import option for your team. Now, you have to ensure that the right component is imported.

Adding a new color="success" prop to a Button component requires non-trivial CSS customizations. How do you ensure that all the styles (hover, focus, focus-visible) are consistent with the other built-in colors?

It adds a boilerplate.

↓

新しいコンポーネントを作成するたびに、それはチームのもう1つのインポートオプションになります。ここで、適切なコンポーネントがインポートされていることを確認する必要があります。

新しい color="success" props を Button コンポーネントに追加するには、重要な CSS のカスタマイズが必要です。すべてのスタイル（hover、focus、focus-visible）が他の組み込みの色と一致していることをどのように確認しますか？

ボイラープレートを追加します。

このため、v5 では、テーマから直接コンポーネントの組み込み動作を拡張する機能を追加。公式ブログ記事においては、CodeSandbox のサンプルコードを添えて2パターン紹介されていました。

既存のスタイルマッピングを利用して、Button コンポーネントの color props に色を追加する例 <OG url="https://codesandbox.io/s/stupefied-mclaren-ho4zs?file=/src/App.tsx" />

（このスタイルマッピング部分は v4 にもあり） <OG url="https://v5-0-6.mui.com/customization/palette/#adding-new-colors" />

import createTheme from "@mui/material/createTheme";
import ThemeProvider from "@mui/material/ThemeProvider";
import Button from "@mui/material/Button";

// 1. テーマを拡張
const theme = createTheme({
  palette: {
    neutral: {
      main: "#d79b4a"
    }
  }
});

// 2. パレットの新しい色について TypeScript に通知
declare module "@mui/material/styles" {
  interface Palette {
    neutral: Palette["primary"];
  }
  interface PaletteOptions {
    neutral: PaletteOptions["primary"];
  }
}

// 3. Button の color props を更新
declare module "@mui/material/Button" {
  interface ButtonPropsColorOverrides {
    neutral: true;
  }
}

export default function App() {
  // 4. 使用
  return (
    <ThemeProvider theme={theme}>
      <Button color="neutral">color="neutral"</Button>
    </ThemeProvider>
  );
}

テーマにカスタムバリアントを追加して、特定のコンポーネント props の組み合わせである CSS をオーバーライドする例 <OG url="https://codesandbox.io/s/sharp-sky-xwz3d?file=/src/App.tsx:0-746" />

import createTheme from "@mui/material/createTheme";
import ThemeProvider from "@mui/material/ThemeProvider";
import Button from "@mui/material/Button";

// 1. テーマを拡張
const theme = createTheme({
  components: {
    MuiButton: {
      variants: [
        {
          props: { variant: "dashed", color: "error" },
          style: {
            border: "1px dashed red",
            color: "red"
          }
        }
      ]
    }
  }
});

// 2. Button の color props を更新
declare module "@mui/material/Button" {
  interface ButtonPropsVariantOverrides {
    dashed: true;
  }
}

export default function App() {
  // 3. 使用
  return (
    <ThemeProvider theme={theme}>
      <Button variant="dashed" color="error">
        dashed
      </Button>
    </ThemeProvider>
  );
}

グローバルクラス

MUI の各種コンポーネントへ適用されることになるグローバル CSS のクラス名およびルール名は、公式ドキュメントの各種コンポーネントのページに一覧化されています。それらのクラス自体のカスタマイズや、それらのクラスをベースとしたカスタマイズをしたい場合は、そこから名を特定。特定したクラスを元に独自スタイルを定義する。ということができました。

{/*  */}

以下は TextField コンポーネントでvariant="outlined"を指定した時に適用される、MuiOutlinedInput-notchedOutlineクラス（notchedOutlineルール）をカスタマイズして、枠線を赤色に変更している例です。

{/*  */}

v4：グローバル CSS でカスタマイズ.

/* styles.css */
.MuiOutlinedInput-notchedOutline {
  border-color: red;
}

import './styles.css';
.
.
.
<TextField variant="outlined" />

v4：コンポーネント個別でカスタマイズ（variant="outlined"の時にfooクラスを追加 + & fooクラスでスタイル定義）

import TextField from '@material-ui/core/TextField';
import { styled } from '@material-ui/core/styles';

const CustomizedTextField = styled((props) => (
  <TextField
    {...props}
    variant="outlined"
    InputProps={{ classes: { notchedOutline: 'foo' } }}
  />
))({
  '& .foo': {
    borderColor: 'red'
  }
}) as typeof TextField;
.
.
.
<CustomizedTextField />

v4 の後者では、グローバル CSS クラスと連動させた独自クラスを追加したうえで、そのクラスのスタイル定義をするようなやり方でした。

v5 では、直接グローバル CSS のクラスにスタイルを追加するような感覚で扱える、新しいやり方が追加されました。 <OG url="https://codesandbox.io/s/zealous-dawn-0yr4g?file=/src/App.tsx" /> より型安全に扱うのであれば、2パターン目の方が良さそうです。

import TextField from '@mui/material/TextField';
import { outlinedInputClasses } from '@mui/material/OutlinedInput';
import { styled } from '@mui/material/styles';

// ※v5 では TextField の variant のデフォルト値が standard → outlined に変更された

// Option 1: global class
const CustomizedTextField1 = styled(TextField)({
  '& .MuiOutlinedInput-notchedOutline': {
    borderColor: 'red',
  },
});

// Option 2: global class + const
const CustomizedTextField2 = styled(TextField)({
  [`& .${outlinedInputClasses.notchedOutline}`]: {
    borderColor: 'red',
  },
});
.
.
.
<CustomizedTextField1 />
<CustomizedTextField2 />

実際に適用される CSS を比較するとこんな感じ。

v4 の後者のやり方で適用される CSS <ImageWrapper src="screenshots/2021/material-ui-v5/global-class-v4.png" alt="v4でのグローバルクラスカスタマイズで適用されるCSS（Dev Tools）画像" />

v5 のやり方で適用される CSS <ImageWrapper src="screenshots/2021/material-ui-v5/global-class-v5.png" alt="v5でのグローバルクラスカスタマイズで適用されるCSS（Dev Tools）画像" />

{/*  */}

クラスを追加しているという点はどちらも同じですね。 v4 では、独自に追加したクラス（今回だとfoo）の他に、そのコンポーネントのルート DOM にComponents-root-XXクラスが別途追加されるような仕組みになっています。 v5 では、そのコンポーネントのルート DOM に、元々あるクラス（今回だとMuiFormControl-root, MuiTextField-root）をベースとしたクラス（今回だとcss-1mmysby-MuiFormControl-root-MuiTextField-root）が追加されていますね。

{/*  */}

スタイルなしコンポーネント

コンポーネントのロジックをフックとスタイルのないコンポーネントに分離したものを提供する、という新しい試みです。現状、まだアルファ版で、以下のコンポーネントのみ対応しています。

Autocomplete
Button
Modal
Pagination
Slider
Switch

現在の開発状況に関しては、こちらの Issue で確認できます。 <OG url="https://github.com/mui-org/material-ui/issues/27170" />

スタイルなし Button コンポーネントの例 <OG url="https://codesandbox.io/s/7lc1r?file=/demo.tsx" />

import clsx from 'clsx';
import Stack from '@mui/material/Stack';
import { ButtonUnstyledProps, useButton } from '@mui/core/ButtonUnstyled';
import { styled } from '@mui/system';

const CustomButtonRoot = styled('button')(`
  background-color: #007fff;
  padding: 15px 20px;
  border-radius: 10px;
  color: #fff;
  font-weight: 600;
  font-family: Helvetica, Arial, sans-serif;
  font-size: 14px;
  transition: all 200ms ease;
  cursor: pointer;
  box-shadow: 0 4px 20px 0 rgba(61, 71, 82, 0.1), 0 0 0 0 rgba(0, 127, 255, 0);
  border: none;

  &:hover {
    background-color: #0059b2;
  }

  &.active {
    background-color: #004386;
  }

  &.focusVisible {
    box-shadow: 0 4px 20px 0 rgba(61, 71, 82, 0.1), 0 0 0 5px rgba(0, 127, 255, 0.5);
    outline: none;
  }

  &.disabled {
    opacity: 0.5;
    cursor: not-allowed;
    box-shadow: 0 0 0 0 rgba(0, 127, 255, 0);
  }
`);

const CustomButton = React.forwardRef(function CustomButton(
  props: ButtonUnstyledProps,
  ref: React.ForwardedRef<any>,
) {
  const { children } = props;
  const { active, disabled, focusVisible, getRootProps } = useButton({
    ...props,
    ref,
    component: CustomButtonRoot,
  });

  const classes = {
    active,
    disabled,
    focusVisible,
  };

  return (
    <CustomButtonRoot {...getRootProps()} className={clsx(classes)}>
      {children}
    </CustomButtonRoot>
  );
});

export default function UseButton() {
  return (
    <Stack spacing={2} direction="row">
      <CustomButton onClick={() => console.log('click!')}>Button</CustomButton>
      <CustomButton disabled>Disabled</CustomButton>
    </Stack>
  );
}

開発背景

A key reason why developers pick MUI is to be able to build UIs faster. When they depend on us, they make a tradeoff. They estimate that applying new styles on top of the Material Design components will be faster than creating components from scratch or picking another library. They estimate that it will be performant enough, and they won't miss too much freedom.

This tradeoff works really well when having a small, constrained engineering team or a large team building internal (/secondary) tools. But what about the medium/large size engineering team that works on ambitious projects? Shouldn't they have a better option for not including Material Design and maximizing freedom than building the components from scratch?

We have started working on this exact problem, isolating the logic of the Material Design components into hooks and unstyled components. While the effort is still in alpha, you can already find the first building blocks in a new unstyled package.

↓

開発者が MUI を選択する主な理由は、UI をより高速に構築できるようにするためです。彼らが私たちに依存するとき、彼らはトレードオフをします。彼らは、Material Design コンポーネントの上に新しいスタイルを適用する方が、コンポーネントを最初から作成したり、別のライブラリを選択したりするよりも高速であると見積もっています。彼らはそれが十分に実行可能であると見積もっており、彼らはあまり多くの自由を逃すことはありません。

このトレードオフは、小規模で制約のあるエンジニアリングチームや、内部（/セカンダリ）ツールを構築する大規模なチームがある場合に非常にうまく機能します。しかし、野心的なプロジェクトに取り組む中規模/大規模のエンジニアリングチームはどうでしょうか。コンポーネントを最初から作成するよりも、Material Design を含めず、自由度を最大化するためのより良いオプションがあるべきではないでしょうか。

Material Design コンポーネントのロジックをフックとスタイルのないコンポーネントに分離して、この正確な問題に取り組み始めました。取り組みはまだ alpha版ですが、スタイルが設定されていない新しいパッケージで最初のビルディングブロックを見つけることができます。

スタイルなしコンポーネントに関しては、元々 2017/02 から議論されていたようで。 <OG url="https://github.com/mui-org/material-ui/issues/6218" />

よりカスタマイズ性を高めるための一環として、取り組みが開始されたようです。デザインは自分たちで独自のこだわりがあるが、機能は MUI のものを活用したいという時に良さそうですね。

コンポーネント

大きな変更や基本的な部分のみ記載します。（細かな変更点は公式の移行ガイドを参照ください）

基本的な使い方に関して、シンプルな例であればインポート元が変わるくらいです。

import { VFC } from 'react';
import Button from '@material-ui/core/Button';

const App: VFC = () => {
  return (
    <Button variant="contained" color="primary">
      Test
    </Button>
  );
}

export default App;

↓

import { VFC } from 'react';
import Button from '@mui/material/Button';

const App: VFC = () => {
  return (
    <Button variant="contained" color="primary">
      Test
    </Button>
  );
}

export default App;

機能追加されたコンポーネント

Grid

グリッドレイアウトを表現するためのコンポーネントにいくつかの機能が追加されました。

行と列の間隔をサポート.

<Grid container rowSpacing={1} columnSpacing={2} />

すべての props でレスポンシブ値をサポート.

<Grid container spacing={{ xs: 2, md: 3 }} />

12とは異なる列数のサポート.

<Grid container columns={16} />

Material Icon

5つの異なるテーマで、600の新しいアイコンをリリース。パッケージとしては@mui/icons-material。

Filled：1117
Oulined：1116
Rounded：1109
Two tone：1107
Sharp：1106

↓

Filled：1780
Oulined：1780
Rounded：1775
Two tone：1771
Sharp：1769

所属が変わったコンポーネント

lab → material

v4 で lab だったものが、material に取り込まれました。

Inputs <OG url="https://v5-0-6.mui.com/components/autocomplete" /> <OG url="https://v5-0-6.mui.com/components/rating" /> <OG url="https://v5-0-6.mui.com/components/toggle-button" />

Feedback <OG url="https://v5-0-6.mui.com/components/skeleton" />

Navigation <OG url="https://v5-0-6.mui.com/components/speed-dial" /> <OG url="https://v5-0-6.mui.com/components/pagination" />

pickers → lab

※2023/11/25 リンクをリポジトリ URL に差し替え <OG url="https://github.com/mui/material-ui-pickers" />

v4 の時点では、全くの別パッケージとして存在していた Date Pickers 的なコンポーネント群が lab に取り込まれました。そのため、元々のリポジトリはすでにアーカイブとなっています。

新しく追加されたコンポーネント

()は所属パッケージ。スクショ及び GIF の撮影元は、公式ドキュメントより。

Stack(material)

種別は Layout。 1次元レイアウトを処理するためのコンポーネント。 Figma の auto layout に似ている。

Loading Buttons(lab)

種別は Input。通常の Button コンポーネントを拡張したもので、読み込み中・二度押し防止などの表現もできるようにしたもの。

LoadingButton の例（CircularProgress との組み合わせ） <ImageWrapper className="w-[70%]" src="gifs/2021/material-ui-v5/loading-button.gif" alt="LoadingButtonコンポーネントのプレビューGIF" />

Trap Focus(lab)

子孫コンポーネントの focus を管理するコンポーネント。モーダルダイアログなどのオーバーレイを実装するときに活用できる。

Masonry(lab)

横幅は一定であるが高さが可変というコンテンツブロックリストである、組構造を表現できるコンポーネント。グリッドではスペースが無駄になってしまうときに活用できる。

Masonry、MasonryItem の例 <ImageWrapper className="w-[80%]" src="screenshots/2021/material-ui-v5/masonry.png" alt="Masonry、MasonryItemコンポーネントのプレビュー画像" />

MUI X

これまでに紹介してきたものは、MUI Core プロダクトを中心とした話でした。今回の新ブランド移行に伴い、MUI X というプロダクトが新たに発表されました。

MUI Core に対して MUI X は、より複雑なユースケース向けの高度なコンポーネント群を提供するもので、一部有料の機能も持っています。

以前より、データグリッド機能を提供する@material-ui/data-grid（フル機能版：@material-ui/x-grid）というパッケージが v4-alpha 版で公開されていました。それが MUI X として正式にリリースされた形になるようです。 <OG url="https://github.com/mui-org/material-ui-x" />

パッケージ名

正式リリースに伴い、パッケージ名も変わりました。

@material-ui/data-grid → @mui/x-data-grid
@material-ui/x-grid → @mui/x-data-grid-pro

コンポーネント

公式サイトで確認できたものは、主に以下の8つ。

DataGrid
Date Picker
Tree View
Sparkline（Coming soon!）
Charts（Coming soon!）
Upload（Coming soon!）
Scheduler（Coming soon!）
Gauge（Coming soon!）

現状、Date Picker と Tree View は @mui/labの方に属してますが、その後は @mui/materialに取り込まれるのでなく、こちらに取り込まれるということなのかな？と思いました。また、有料版の機能として、Date Range Picker を提供しているそうです。

~開発ロードマップが公開されているので、そちらから開発状況が確認できます。~ ※2025/09/14...リンク切れを起こしていたので削除。

その他の新仕様と v4 からの移行

公式ドキュメントにガイドがあるので、そちらを参照ください。 <OG url="https://mui.com/guides/migration-v4" />

やや長いページではありますが、コンポーネントごとの仕様変更など、細かい変更点もまとめられています。移行の際は、公式ブログ記事とともに、ぜひ最後まで一読することをおすすめします。

以前に Material UI v4 記事を書いていたこともあり、今回 v5 の記事も書いてみました。公式ブログ記事の内容をそのまま書いてもしょうがないので、なるべく自分でも試しながら v4 と比較できるような内容にしたつもりです。

代表的な部分のみ紹介のつもりが、ずいぶん長くなってしまいました...🙄 ここまで読んでいただいた方、ありがとうございます！

MUI の使用を検討している方にとって、何かの参考になれば幸いです。

参考リンクまとめ

{/*  */}

React × LaravelでSocialiteを使ったGitHubソーシャルログインを実装してみた

Wed, 19 May 2021 00:00:00 GMT

以前、React × Laravel で簡易なログイン機能を作った記事を書いたのですが、あれからソーシャルログインを実装する機会がありました。正直微妙な部分もありつつ、せっかく実装したので記事化して供養します🙏

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

はじめに

以前の記事に引き続き、React 側の状態管理には React Query を使用。

ソーシャルログインを実装するにあたって、Laravel 側では OAuth ライブラリのラッパーである Socialite を使用しました。

デフォルトでは以下のサービスに対応しています。

Facebook
Twitter
Google
LinkedIn
GitHub
GitLab
Bitbucket

他のサービスでのソーシャルログインを実装したいという場合は、コミュニティの方々が作られている Socialite を拡張したものを使うとよいです。ものすごく幅広いサービスに対応しています。

今回作ってみたもの

ソーシャルログイン機能。

認証プロバイダーとなるサービスは、今回 GitHub を使用しました。どのサービスにするとしても、基本的な実装方法は一緒かと思われますが、部分的に異なる可能性があることにご留意ください。

{/*  */}

また、API の認証方式については Cookie を使ったステートフルなものになります。（※2021/11/25追記...Laravel の api ルートで使用するミドルウェアグループを変更、web のミドルウェアグループにある Cookie やセッションの機能を api ルートでも使用する、ということをしています）

{/*  */}

実装にあたって、主に以下の記事を参考にさせていただきました。

前提

React（Laravel Mix）× Laravel による SPA × API 構成です。

今回使用した各種バージョンは以下のとおりです。

基本部分.

Node.js：14.2.0
TypeScript：4.1.3
React：16.14.0
PHP：7.4.14
Laravel：6.20.9

ライブラリ - React 側.

Material UI
- core：4.11.3
- icons：4.11.2
- lab：4.0.0-alpha.57
axios：0.21.1
react-query：3.12.1
camelcase-keys：6.2.2

ライブラリ - Laravel 側.

socialite：5.2.3

おおまかな処理の流れ

主な登場人物

ユーザ
画面
- ログイン画面
- ソーシャルログイン処理中画面
- アプリホーム画面
- （GitHub の）OAuth 認可画面
API
- OAuth 認可画面 URL 取得 API
- ソーシャルログイン API
モデル
- ユーザ
- 認証プロバイダー（ユーザを親に持つ）

処理のフロー

ざっくり書くとこんな感じです。 ※GitHub OAuth 認可画面へリダイレクト時に、GitHub 未ログインであれば先にログインが必要になります。

ログイン画面
- ユーザがログイン画面で、「Login with GitHub」ボタンを押下 → OAuth 認可画面 URL 取得 API で URL 取得
  - 失敗時：エラー表示
  - 成功時：取得した URL にリダイレクト
GitHub OAuth 認可画面
- ユーザが認可承認もしくはキャンセル → ソーシャルログイン処理中画面をコールバック
ソーシャルログイン処理中画面
- 認可失敗（キャンセル含む）時：エラー表示
- 認可成功時：ソーシャルログイン API で以下のソーシャルログイン処理後に、アプリホーム画面へ
  - GitHub アカウントと紐づくユーザがあれば、そのユーザでログイン
  - 紐づくユーザはないが、同一メールアドレスユーザがあれば紐づけて、そのユーザでログイン
  - ユーザがなければ、GitHub アカウントと紐づけたうえでユーザ新規登録して、そのユーザでログイン

ディレクトリ構成

今回も Laravel 側は特に変わったことをしてないので、React 側だけ記載します。（全部載せると多いので、当記事の趣旨にあまり関係ないものは省略しています）

Laravel プロジェクトの resources/ts 配下.

├ components
│   ├ atoms
│   │   ├ GeneralAlert.tsx
│   │   └ GitHubLoginButton.tsx
│   ├ molecules
│   │   └ SocialLoginAlert.tsx
│   ├ pages
│   │   ├ Login.tsx
│   │   └ SocialLoginProgress.tsx
├ constants
│   └ statusCode.ts
├ containers
│   ├ pages
│   │   ├ Login.tsx
│   │   └ SocialLoginProgress.tsx
├ hooks
│   ├ auth
│   │   ├ index.ts
│   │   ├ useOAuthUrl.ts
│   │   └ useSocialLogin.ts
├ models
│   └ OAuth.ts
└ app.tsx

今回も同様にリポジトリにタグをつけていますので、GitHub で見たいという方はこちらをどうぞ。 <OG url="https://github.com/h-yoshikawa44/ooui-memo/releases/tag/post%2Freact-query-socialite" />

※2021/09/13追記関数コンポーネントの型定義に FC ばっかり使ってますが、FC から children がなくなるまでは VFC を使った方がいいです...。

前準備

認証プロバイダーとなるサービスで、クライアント ID を発行する必要があります。

クライアント ID とクライアントシークレットの発行

GitHub の場合は以下のようになります。 Authorization callback URL は今回の場合、ソーシャルログイン処理中画面の URL ですね。

ログイン後、ユーザアイコンから「Settings」を選択
「Developer settings」を選択
「OAuth Apps」を選択し、「New OAuth App」でアプリを作成
必要な情報を入力し「Register application」
- Application name（アプリ名・必須）
- Homepage URL（アプリのホームページ URL・必須）
- Application description（アプリの説明・任意）
- Authorization callback URL（OAuth 処理後にコールバックする URL・必須）

これで OAuth 用のアプリが作成され、クライアント ID が発行されます。クライアントシークレットも発行する必要があるので、アプリ設定画面から「Generate a new client secret」で発行。ともに控えておきます。

アプリの設定がどのように使われるか

画面的な部分で自分が確認できたところとしては、こんな感じです。 Application logo については、一度 OAuth アプリ作成後に設定できます。

OAuth 前のログイン画面 <ImageWrapper className="w-[80%]" src="screenshots/2021/react-query-socialite/login-before-oauth.png" alt="OAuth前のログイン画面画像 - Application logo、Application name" />

OAuth 認可画面 <ImageWrapper className="w-[80%]" src="screenshots/2021/react-query-socialite/oauth.png" alt="OAuth認可画面 - Application logo、Application name、Authorization callback URL（ドメイン部分まで）" />

Authorized OAuth Apps 画面 <ImageWrapper className="w-[80%]" src="screenshots/2021/react-query-socialite/oauth-app.png" alt="Authorized OAuth Apps画面 - Application logo、Application name、Homepage URL" />

環境変数に追加

先ほど控えた値を設定。 GITHUB_CALLBACK_URLについては、Authorization callback URL で設定したものと同じで OK です。

.env の例.

GITHUB_CLIENT_ID=XXXXXXXXXXXXXXXXXXX
GITHUB_CLIENT_SECRET=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
GITHUB_CALLBACK_URL=http://localhost:80/login/github/callback

'github' => [
    'client_id' => env('GITHUB_CLIENT_ID'),
    'client_secret' => env('GITHUB_CLIENT_SECRET'),
    'redirect' => env('GITHUB_CALLBACK_URL'),
],

API（Laravel）側

Web ルートの確認

Laravel Mix を使った SPA × API 構成だと、Web ルートは全受けにして、SPA 側で画面切り分けというやり方になることが多いでしょうか。

ここでの注意点として、apiプレフィックスのルートは除外しておかないと、API ルートで where での制約をかけたときに予期しない動作を起こす原因になります。

というのも、where で制約をかけた場合に制約外のパスパラメータでアクセスすると、ルート不一致として通常は404が返ります。 ...が、ここで全受けにしてると、このルートに来てしまい200が返るという現象が起きてしまいます。

// apiプレフィックスは除外
Route::get('/{any?}', fn() => view('index'))->where('any', '(?!api).+');

users テーブルの改修

ソーシャルログインにおいてはパスワードを使用しないため、null 許容にしておきます。（メールアドレスについては、認証プロバイダーとなるサービスによっては取得できないものもあるようなので、その場合はメールアドレスも null 許容にしておきましょう。）

マイグレーションファイル.

<?php

use App\Enums\AuthType;
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class ChangeSocialLoginUsersTable extends Migration
{
    public function __construct()
    {
        // dbalがenum型のカラム変更に対応していないので、エラー回避策としてstringにマッピングする
        DB::getDoctrineSchemaManager()->getDatabasePlatform()->registerDoctrineTypeMapping('enum', 'string');
    }

    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('users', function (Blueprint $table) {
            // ソーシャルログインではパスワードを使わないのでnull許容にする
            $table->string('password')->nullable()->comment('パスワード')->change();

            $table->enum('auth_type', AuthType::getValues())->after('name')->comment('認証タイプ【' . implode(', ', AuthType::getValues()) . '】');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('users', function (Blueprint $table) {
            $table->string('password')->nullable(false)->comment('パスワード')->change();

            $table->dropColumn('auth_type');
        });
    }
}

認証タイプについて

認証タイプについては、以下の3パターンを enum で持たせています。

ソーシャルログイン
メール・パスワードログイン
どちらも

個人的に処理分けに使用するつもりなので追加してますが、別になくてもいいので詳細は省略します。

ちなみに enum 型を扱う注意点として、テーブル情報変更を担う dbal が enum 型カラムの変更に対応していません（追加はできます）

enum 型カラム自体の内容変更でなくても、enum 型カラムを持つテーブルの内容変更というだけでエラーになってしまいます。今回の場合だとロールバックで down メソッド実行時とか。そのため、エラー回避策として一旦 string にマッピングするという対応を入れています。

認証プロバイダーテーブル作成

ユーザと紐づく認証プロバイダーとなるサービスを管理するテーブルを作成します。認証プロバイダーとなるサービスが1つのみの場合は、users テーブルにカラム増やして対応でもいいですが、今回は別でテーブルを作りました。

もしユーザが削除された時は、一緒に削除したいので cascade を設定しています。自分の場合、users テーブルの主キーは UUID でuser_idという名前にしているので以下のようになっていますが、適宜置き換えてださい。

マイグレーションファイル.

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class CreateIdentityProvidersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('identity_providers', function (Blueprint $table) {
            $table->uuid('user_id')->comment('ユーザID');
            $table->foreign('user_id')->references('user_id')->on('users')->onDelete('cascade'); // 外部キー制約
            $table->string('provider_name')->comment('プロバイダー名');
            $table->string('provider_user_id')->comment('プロバイダーユーザID');
            $table->primary(['provider_name', 'provider_user_id']); // 複合キー
            $table->unique(['user_id', 'provider_name']); // 複合ユニーク
            $table->dateTime('created_at')->nullable()->comment('作成日時');
            $table->dateTime('updated_at')->nullable()->comment('更新日時');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('identity_providers');
    }
}

モデルファイルの用意

identity_providersテーブルを作ったので、モデルファイルも作っておきます。

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class IdentityProvider extends Model
{
    protected $primaryKey = ['provider_name', 'provider_user_id'];
    public $incrementing = false;

    /**
     * The attributes that are mass assignable.
     *
     * @var array
     */
    protected $fillable = ['provider_name', 'provider_user_id'];

    /**
     * リレーション - User
     * @return \Illuminate\Database\Eloquent\Relations\BelongsTo
     */
    public function user()
    {
        return $this->belongsTo('App\User', 'user_id', 'user_id');
    }
}

User モデル側にもリレーションを定義しておきます。

    /**
     * リレーション - IdentityProviders
     * @return \Illuminate\Database\Eloquent\Relations\HasMany
     */
    public function identityProviders()
    {
        return $this->hasMany('App\IdentityProvider', 'user_id');
    }

OAuth 認可画面 URL 取得 API

ログイン画面でソーシャルログインボタンを押下した時に呼ばれる API。 OAuth 処理用のコントローラを用意して作成。

Socialite に認証プロバイダー名を渡すことで、その認証プロバイダー用のドライバーを作成し、機能が使えるようになります。 redirectメソッドで、OAuth 認可画面 URL を持ったRedirectResponseを生成してくれるので、そこからその URL だけ取得して返すようにしています。

    /**
     * （各認証プロバイダーの）OAuth認可画面URL取得API
     * @param string $provider 認証プロバイダーとなるサービス名
     * @return \Illuminate\Http\JsonResponse
     */
    public function getProviderOAuthURL(string $provider)
    {
        $redirectUrl = Socialite::driver($provider)->redirect()->getTargetUrl();
        return response()->json([
            'redirect_url' => $redirectUrl,
        ]);
    }

API のルートに追加。 where で制約をかけて、特定の認証プロバイダー名しか受け付けないようにします。

Route::get('/login/{provider}', 'Auth\OAuthController@getProviderOAuthURL')
            ->where('provider', 'github')->name('oauth.request');

※2021/11/27追記ちなみにステートレス API として作る場合は、statelessメソッドを使えばいいようです。

$redirectUrl = Socialite::driver($provider)->stateless()->redirect()->getTargetUrl();

OAuth 認可画面へのリダイレクトについて

SPA と API に分かれておらず、Laravel でビューも担当している場合はredirectメソッドで302を返すだけで対応できます。

API の場合は、302を返すと、API リクエストがそのリダイレクト先に対して行われるということになります。今回の場合だと GitHub の OAuth 認可画面 URL ということで、別ドメインにリクエストする形です。 CORS ポリシーに引っ掛かってはじかれるだけなので、URL だけ取得して返し、SPA 側でリダイレクトする形にしています。

スコープについて

スコープは、その認証プロバイダーに対して要求するアクセス権限です。 Socialite における GitHub の場合のデフォルトスコープはuser:emailとなっており、特にスコープに関する記述がなければこのスコープが使われます。

GitHub のスコープ一覧は以下のとおりです。 <OG url="https://docs.github.com/ja/developers/apps/scopes-for-oauth-apps" />

スコープを追加したい時はscopesで、スコープを上書きしたい時はsetScopesで対応できます。必要に応じた権限を設定しましょう。

Socialite が生成するリダイレクト URL について

redirectメソッドの中で生成されるリダイレクト URL は以下のような形式になっています。ドライバーとなるクラスで保持している URL に、必要なクエリパラメータを足している感じです。クライアント ID も使われてますね。

https://github.com/login/oauth/authorize?client_id=XXXXXXXXXXXXXXXXXXXX&redirect_uri=http%3A%2F%2Flocalhost%2Flogin%2Fgithub%2Fcallback&scope=user%3Aemail&response_type=code&state=pp7ndAoGIvcTqxkTSxzBklISPWd1PQ7Vyrw4gUsa

stateに関しては、推測不能なランダムな文字列となっていて、クロスサイトリクエストフォージェリ対策で使用されるものです。後に検証するためセッションにもセットされます。このstateは OAuth 認可処理後、GitHub からコールバックされるときに、一緒にクエリパラメータとして返却されます。（※2021/11/25追記...ステートフルの場合のみstateのセットおよび検証されるようです）

ソーシャルログイン API

GitHub の OAuth 認可処理後にコールバックされたソーシャルログイン処理中画面より呼ばれる API。

ソーシャルログイン処理を行うメソッド

ソーシャルログイン処理は少し複雑になるので、モデルファイルにメソッドを用意しておきます。元々あるfindメソッドなどと同じ感じで使いたかったので、static にしました。

処理の分岐についてはコメントに書いてある通りです。複数テーブルの処理になるのでトランザクションブロックを使っています。

     /**
     * ソーシャルログイン処理
     * @param $providerUser プロバイダーユーザ情報
     * @param $provider プロバイダー名
     * @return App\User
     */
    public static function socialFindOrCreate($providerUser, $provider)
    {
        $account = IdentityProvider::whereProviderName($provider)
                    ->whereProviderUserId($providerUser->getId())
                    ->first();

        // すでにアカウントがある場合は、そのユーザを返す
        if ($account) {
            return $account->user;
        }

        $existingUser = User::whereEmail($providerUser->getEmail())->first();

        if ($existingUser) {
            // メールアドレスはユニークの関係上、同一メールアドレスユーザがいる場合は、そのユーザと紐づけて認証プロバイダー情報登録
            $user = DB::transaction(function () use ($existingUser, $providerUser, $provider) {
                $existingUser->update(['auth_type' => AuthType::BOTH]);
                $existingUser->IdentityProviders()->create([
                    'provider_user_id'   => $providerUser->getId(),
                    'provider_name' => $provider,
                ]);

                return $existingUser;
            });
        } else {
            // アカウントがない場合は、ユーザ情報 + 認証プロバイダー情報を登録
            $user = DB::transaction(function () use ($providerUser, $provider) {
                // nameがない時もあるので、その時はnicknameを使う
                $providerUserName = $providerUser->getName() ? $providerUser->getName() : $providerUser->getNickname();
                $user = User::create([
                    'name'  => $providerUserName,
                    'auth_type' => AuthType::SOCIAL,
                    'email' => $providerUser->getEmail(),
                ]);
                $user->IdentityProviders()->create([
                    'provider_user_id'   => $providerUser->getId(),
                    'provider_name' => $provider,
                ]);

                return $user;
            });
        }

        return $user;
    }

API

OAuth 処理用のコントローラに API を追加。

Socialite 経由で GitHub ユーザ情報取得は、内部的に GitHub API を利用しているので、エラー対応として try～catch ブロックを使用しています。メッセージを取り出して500で再度例外を投げてるだけなので、あまり意味ない感じになってますが、本来はログ出力などした方がいいと思われます。

    /**
     * ソーシャルログインAPI（各認証プロバイダーからのコールバック後）
     * @param string $provider 認証プロバイダーとなるサービス名
     * @return App\User
     */
    public function handleProviderCallback(string $provider)
    {
        try {
            $providerUser = Socialite::driver($provider)->user();
        } catch (\Exception $e) {
            // TODO ログ出力など
            abort(500, $e->getMessage());
        }
        $authUser = User::socialFindOrCreate($providerUser, $provider);
        Auth::login($authUser, true);

        // ログインのみ or 既存ユーザに紐づけ + ログイン：200
        // 紐づけしたうえでユーザ新規登録 + ログイン：201
        return $authUser;
    }

API のルートに追加。この API も同様に where で制約をかけておきます。

Route::post('/login/{provider}/callback', 'Auth\OAuthController@handleProviderCallback')
            ->where('provider', 'github')->name('oauth.callback');

既存アカウントがあるかどうかの照合のやり方について

最初に Socialite 実装の記事を調べていたところ、メールアドレスで照合していたものが多い印象を受けました。認証プロバイダーとなるサービスより取得したユーザ情報から、メールアドレスを取得し、そのアドレスのユーザアカウントがあるか確認する方法。

ただこれだと一度ソーシャルログインでユーザアカウント作成後に、もし認証プロバイダーとなるサービス側でメールアドレスを変更されてしまうと、そのユーザアカウントでログインできなくなります。

それってどうなんだろうか？と思っていたら、冒頭にも上げたこの記事のコメント欄で、このことに関するやり取りが行われていました。 <OG url="https://qiita.com/tetsu-upstr/items/d1cccfac362872ed140c" />

認証プロバイダーとなるサービスを示す識別子と、サービスから取得したユーザ識別子といった基本的に不変なものを使うとよいとのことだったので、まずはこの2つを使って照合するようにしています。そのうえで、なければ同一メールアドレスのユーザがいないか確認。いれば紐づける、いなければユーザ情報も含め新規登録する感じです。

レスポンスについて

responseメソッドを使って200で統一してもよかったのですが、ユーザ登録の部分が201にあたると思ったので、そのままにしています。

ログインのみ
既存ユーザ紐づけ + ログイン
ユーザ登録 + ログイン

の3パターンともにApp\Userを返す形になります。ですが、ユーザ登録 + ログインの場合はwasRecentlyCreatedが true になっているので、Laravel が201レスポンスにしてくれるわけです。

既存ユーザ紐づけ + ログインパターンの、認証プロバイダー情報登録部分も201にあたるのでは？という疑問もあったりしますが、そこは特に対応せず200のままです。

Socialite が内部的にやっていることについて

コード的にはこれだけで、認証プロバイダーとなるサービスから情報が取得できますが、内部的には GitHub API が使われています。

$providerUser = Socialite::driver($provider)->user();

また、この内部処理の中では、codeとstateのパラメータが必要になります。 codeは10分の期限つきの一時コード。 stateは OAuth 認可画面 URL 取得 API のところで書いた通り、クロスサイトリクエストフォージェリ対策の文字列。

これらは OAuth 認可処理後の GitHub からのコールバック時にクエリパラメータで渡されてくるので、それをそのままこの API に渡すようにすれば OK です。

userメソッドの実装はここですね。 <OG url="https://github.com/laravel/socialite/blob/v5.2.3/src/Two/AbstractProvider.php#L226" />

stateが（OAuth 認可画面 URL 取得 API の処理の中で）セッションに保持していたものと一致するかの確認が行われています。

GitHub とのやり取りの部分は、まずcodeを使ってアクセストークンを取得。そのアクセストークンを使って、GitHub ユーザ情報を取得...といった感じです。

SPA（React）側

アプリ初期化 + ルーティング

コードの記載は省略。

React Query の初期化と最低限以下のルーティングが定義されていれば OK。

ログイン画面
ソーシャルログイン処理中画面
アプリホーム画面（ログイン後に遷移する画面）

定数

Laravel から返されるステータスコードを定数で定義。（当記事の趣旨では使わないもの含む）

// リソースが見つからないエラー
export const NOT_FOUND = 404;

// CSRFトークン不一致などのエラー
export const UNKNOWN_STATUS = 419;

// バリデーションエラー
export const UNPROCESSABLE_ENTITY = 422;

// サーバエラー
export const INTERNAL_SERVER_ERROR = 500;

ソーシャルログイン（GitHub）ボタン

GitHub でソーシャルログイン用のボタンコンポーネント。

import React, { FC } from 'react';
import Button from '@material-ui/core/Button';
import GitHubIcon from '@material-ui/icons/GitHub';
import { Provider } from '../../models/OAuth';

type Props = {
  handleSocialLoginRequest: (provider: Provider) => void;
};

const GitHubLoginButton: FC<Props> = ({ handleSocialLoginRequest }) => (
  <Button
    variant="contained"
    startIcon={<GitHubIcon />}
    fullWidth
    style={{ color: '#fff', backgroundColor: '#24292e', textTransform: 'none' }}
    onClick={() => {
      handleSocialLoginRequest('github');
    }}
  >
    Login with GitHub
  </Button>
);

export default GitHubLoginButton;

ソーシャルログインアラート表示

Presentational Component

ログイン画面において、ソーシャルログイン失敗（OAuth 認可画面 URL 取得失敗）時に表示するアラートのコンポーネント。

通常のログインの方でも作っていたので、ソーシャルログイン版も一応作りました。

import React, { FC } from 'react';
import GeneralAlert from '../atoms/GeneralAlert';
import {
  UNKNOWN_STATUS,
  INTERNAL_SERVER_ERROR,
} from '../../constants/statusCode';

type Props = {
  statusCode: number;
};

const SocialLoginAlert: FC<Props> = ({ statusCode }) => (
  <>
    {(statusCode === UNKNOWN_STATUS ||
      statusCode === INTERNAL_SERVER_ERROR) && (
      <GeneralAlert
        type="error"
        title="サーバエラー"
        content={`予期しないエラーが発生し、ソーシャルログインに失敗しました。\n恐れ入りますが時間をおいて再度お試しください。`}
      />
    )}
  </>
);

export default SocialLoginAlert;

ここで使っている GeneralAlert コンポーネントは、アラートコンポーネントのラッパーで、こんな感じです。

import React, { FC } from 'react';
import Alert from '@material-ui/lab/Alert';
import AlertTitle from '@material-ui/lab/AlertTitle';

type Props = {
  type: 'error' | 'info' | 'success' | 'warning';
  title: string;
  content: string;
  onClose?: VoidFunction;
};

const GeneralAlert: FC<Props> = ({ type, title, content, onClose }) => (
  <Alert severity={type} onClose={onClose} style={{ whiteSpace: 'pre-wrap' }}>
    <AlertTitle>{title}</AlertTitle>
    {content}
  </Alert>
);

export default GeneralAlert;

ちなみにこういうやつです。 <ImageWrapper className="w-[40%]" src="screenshots/2021/react-query-socialite/social-login-error.png" alt="ログイン画面 - ソーシャルログイン失敗時アラート表示" />

ログイン画面

Container Component

通常のログインに関するコードもあるので少し長いですが、こんな感じです。

{/*  */}

useOAuthUrlフックはuseMutationをラップしたカスタムフックです（後述） OAuth 認可 URL 取得処理を行う関数を実行するトリガー関数を受け取り、ソーシャルログインボタン押下時の関数の中で実行しています。

{/*  */}

ソーシャルログインにおいてもフレンドリーフォワーディングをやりたかったのですが、一旦はやっていません。

import React, { FC, useState, useCallback } from 'react';
import { useHistory, useLocation } from 'react-router-dom';
import Login from '../../components/pages/Login';
import { useLogin, useOAuthUrl } from '../../hooks/auth';
import { Provider } from '../../models/OAuth';

const EnhancedLogin: FC = () => {
  const history = useHistory();
  const location = useLocation();
  const { from } = (location.state as { from: string }) || {
    from: { pathname: '/' },
  };

  const { error, isLoading: loginIsLoading, mutate: login } = useLogin();
  const statusCode = error?.response?.status;
  const {
    error: socialLoginError,
    isLoading: socialLoginIsLoading,
    mutate: redirectOAuth,
  } = useOAuthUrl();
  const socialLoginStatusCode = socialLoginError?.response?.status;
  const isLoading = loginIsLoading || socialLoginIsLoading;

  const [email, setEmail] = useState('');
  const [password, serPassword] = useState('');

  const handleChangeEmail = useCallback(
    (ev: React.ChangeEvent<HTMLInputElement>) => {
      setEmail(ev.target.value);
    },
    []
  );

  const handleChangePassword = useCallback(
    (ev: React.ChangeEvent<HTMLInputElement>) => {
      serPassword(ev.target.value);
    },
    []
  );

  const handleLogin = useCallback(
    (ev: React.FormEvent<HTMLFormElement>) => {
      ev.preventDefault();
      if (!email || !password) {
        return;
      }
      login(
        { email, password },
        {
          onSuccess: () => {
            history.replace(from);
          },
        }
      );
    },
    [email, password, history, from, login]
  );

  const handleSocialLoginRequest = useCallback(
    (provider: Provider) => {
      redirectOAuth(provider);
    },
    [redirectOAuth]
  );

  return (
    <Login
      email={email}
      password={password}
      handleChangeEmail={handleChangeEmail}
      handleChangePassword={handleChangePassword}
      statusCode={statusCode}
      socialLoginStatusCode={socialLoginStatusCode}
      isLoading={isLoading}
      handleLogin={handleLogin}
      handleSocialLoginRequest={handleSocialLoginRequest}
    />
  );
};

export default EnhancedLogin;

Presentational Component

これも通常のログインに関するコードもあるので少し長いですが、こんな感じです。

ログイン、ソーシャルログインいずれか実行中に再度ボタンを押されないようにするため、isLoadingを使って、実行中はBackdropを表示するようにしています。（暗転してスピナークルクル表示の部分）

import React, { FC } from 'react';
import Backdrop from '@material-ui/core/Backdrop';
import Box from '@material-ui/core/Box';
import Button from '@material-ui/core/Button';
import CircularProgress from '@material-ui/core/CircularProgress';
import Container from '@material-ui/core/Container';
import Card from '@material-ui/core/Card';
import CardHeader from '@material-ui/core/CardHeader';
import CardContent from '@material-ui/core/CardContent';
import TextField from '@material-ui/core/TextField';
import { useTheme, makeStyles } from '@material-ui/core/styles';
import Header from '../../containers/organisms/Header';
import LoginAlert from '../molecules/LoginAlert';
import LegalLink from '../molecules/LegalLink';
import SocialLoginAlert from '../molecules/SocialLoginAlert';
import Footer from '../organisms/Footer';
import GitHubLoginButton from '../atoms/GitHubLoginButton';
import { Provider } from '../../models/OAuth';

const useStyles = makeStyles(() => ({
  decorationLine: {
    borderImage: 'linear-gradient(0.25turn, transparent, #888, transparent)',
    borderImageSlice: 1,
  },
}));

type Props = {
  email: string;
  password: string;
  handleChangeEmail: (ev: React.ChangeEvent<HTMLInputElement>) => void;
  handleChangePassword: (ev: React.ChangeEvent<HTMLInputElement>) => void;
  statusCode?: number;
  socialLoginStatusCode?: number;
  isLoading: boolean;
  handleLogin: (ev: React.FormEvent<HTMLFormElement>) => void;
  handleSocialLoginRequest: (provider: Provider) => void;
};

const Login: FC<Props> = ({
  email,
  password,
  handleChangeEmail,
  handleChangePassword,
  statusCode,
  socialLoginStatusCode,
  isLoading,
  handleLogin,
  handleSocialLoginRequest,
}) => {
  const theme = useTheme();
  const classes = useStyles();
  return (
    <Box display="flex" flexDirection="column" minHeight="100vh">
      <Header />
      <main style={{ flex: 1 }}>
        <Container maxWidth="xs">
          <Card style={{ margin: `${theme.spacing(6)}px 0` }}>
            <CardHeader title="login" style={{ textAlign: 'center' }} />
            <CardContent>
              <Box p={2} borderBottom={1} className={classes.decorationLine}>
                {socialLoginStatusCode && (
                  <SocialLoginAlert statusCode={socialLoginStatusCode} />
                )}
                <Box mt={2}>
                  <GitHubLoginButton
                    handleSocialLoginRequest={handleSocialLoginRequest}
                  />
                </Box>
              </Box>
              <form onSubmit={handleLogin}>
                <Box
                  p={2}
                  display="flex"
                  flexDirection="column"
                  alignItems="center"
                >
                  {statusCode && <LoginAlert statusCode={statusCode} />}
                  <TextField
                    label="メールアドレス"
                    variant="outlined"
                    fullWidth
                    value={email}
                    margin="normal"
                    required
                    autoComplete="email"
                    autoFocus
                    onChange={handleChangeEmail}
                  />
                  <TextField
                    type="password"
                    label="パスワード"
                    variant="outlined"
                    fullWidth
                    value={password}
                    margin="normal"
                    required
                    autoComplete="current-password"
                    onChange={handleChangePassword}
                  />
                  <Box my={2}>
                    <LegalLink />
                  </Box>
                  <Box my={2}>
                    <Button type="submit" color="primary" variant="contained">
                      ログイン
                    </Button>
                  </Box>
                </Box>
              </form>
            </CardContent>
          </Card>
        </Container>
      </main>
      <Footer />
      <Backdrop style={{ zIndex: theme.zIndex.drawer + 1 }} open={isLoading}>
        <CircularProgress color="inherit" />
      </Backdrop>
    </Box>
  );
};

export default Login;

ソーシャルログイン処理中画面

認証プロバイダーとなるサービスの OAuth 認可画面での処理後にコールバックされる画面です。 OAuth 認可をキャンセルした場合などもコールバックは実行され、この画面にきます。

Container Component

useSocialLoginはuseMutationをラップしたカスタムフック（後述）ソーシャルログイン処理を行う関数を実行するトリガー関数を受け取り、レンダリングとともに実行しています。成功時はアプリホーム画面へリダイレクト。

なお、GitHub からコールバックされた時のクエリパラメータがソーシャルログイン API で必要になるので、取り出してトリガー関数へ渡すようにしています。

また、OAuth 認可キャンセルなどのエラー発生時は、クエリパラメータにerrorがセットされて返ってくるので分岐をかけています。

import React, { FC, useState, useEffect, useMemo } from 'react';
import { useParams, useHistory, useLocation } from 'react-router-dom';
import queryString from 'query-string';
import SocialLoginProgress from '../../components/pages/SocialLoginProgress';
import { useSocialLogin } from '../../hooks/auth';
import { Provider, OAuthParams } from '../../models/OAuth';

const EnhancedSocialLoginProgress: FC = () => {
  const { provider } = useParams<{ provider: Provider }>();
  const history = useHistory();
  const location = useLocation();
  const socialResponse = useMemo(
    () => queryString.parse(location.search) ?? {},
    [location.search]
  );
  const [oAuthError, setOAuthError] = useState<boolean>(false);
  const { error, mutate: socialLogin } = useSocialLogin();
  const statusCode = error?.response?.status;

  useEffect(() => {
    if (Object.prototype.hasOwnProperty.call(socialResponse, 'error')) {
      setOAuthError(true);
      return;
    }
    socialLogin(
      { provider, authParams: socialResponse as OAuthParams },
      {
        onSuccess: () => {
          history.replace('/');
        },
      }
    );
  }, [history, provider, socialResponse, socialLogin]);

  return (
    <SocialLoginProgress oAuthError={oAuthError} statusCode={statusCode} />
  );
};

export default EnhancedSocialLoginProgress;

Presentational Component

OAuth 認可処理でエラー発生時、自アプリ側のソーシャルログイン処理でエラー発生時とで、それぞれアラート表示をするようにしています。エラーがなければ、処理中ということでスピナーを表示。

import React, { FC } from 'react';
import { Link } from 'react-router-dom';
import Box from '@material-ui/core/Box';
import Container from '@material-ui/core/Container';
import Card from '@material-ui/core/Card';
import CardHeader from '@material-ui/core/CardHeader';
import CardContent from '@material-ui/core/CardContent';
import CircularProgress from '@material-ui/core/CircularProgress';
import Typography from '@material-ui/core/Typography';
import { useTheme } from '@material-ui/core/styles';
import Header from '../../containers/organisms/Header';
import GeneralAlert from '../atoms/GeneralAlert';

type Props = {
  oAuthError: boolean;
  statusCode?: number;
};

const Content: FC<Props> = ({ oAuthError, statusCode }) => {
  if (oAuthError) {
    return (
      <>
        <GeneralAlert
          type="error"
          title="認可エラー"
          content={`ソーシャルサービス側の認可処理でエラーが発生しました。\n恐れ入りますが時間をおいて再度お試しください。`}
        />
        <Box py={2} textAlign="center">
          <Typography variant="caption">
            <Link to="/login">ログイン画面</Link>
            に戻る
          </Typography>
        </Box>
      </>
    );
  }

  if (statusCode) {
    return (
      <>
        <GeneralAlert
          type="error"
          title="サーバエラー"
          content={`予期しないエラーが発生し、ソーシャルログインに失敗しました。\n恐れ入りますが時間をおいて再度お試しください。`}
        />
        <Box py={2} textAlign="center">
          <Typography variant="caption">
            <Link to="/login">ログイン画面</Link>
            に戻る
          </Typography>
        </Box>
      </>
    );
  }

  return (
    <Box textAlign="center">
      <CircularProgress color="inherit" />
    </Box>
  );
};

const SocialLoginProgress: FC<Props> = ({ oAuthError, statusCode }) => {
  const theme = useTheme();
  return (
    <>
      <Header />
      <main>
        <Container maxWidth="xs">
          <Card style={{ margin: `${theme.spacing(6)}px 0` }}>
            <CardHeader
              title={
                oAuthError || statusCode
                  ? 'ソーシャルログイン処理失敗'
                  : 'ソーシャルログイン処理中...'
              }
              style={{ textAlign: 'center' }}
            />
            <CardContent>
              <Content oAuthError={oAuthError} statusCode={statusCode} />
            </CardContent>
          </Card>
        </Container>
      </main>
    </>
  );
};

export default SocialLoginProgress;

モデル

User

Laravel 側の User モデルに合わせて定義。

export type User = {
  name: string;
  authType: 'SOCIAL' | 'MAIL' | 'BOTH';
};

OAuth

ソーシャルログイン機能に関係する型定義をまとめて定義してあります。

OAuthParams については、サービスごとにパラメータが違う可能性を考えて一応わけてます。（Socialite のコードを追った感じだと同じっぽい？）

OAuthRedirect については、OAuth 認可画面 URL 取得 API のレスポンスの型です。当記事では記載していませんが、axios の interceptors でまとめて、キーのキャメルケース変換をかけているのでこうなっています。

export type Provider = 'github';

export type GitHubOAuthParams = {
  code: string;
  state: string;
};

export type OAuthParams = GitHubOAuthParams;

export type OAuthRedirect = {
  redirectUrl: string;
};

ソーシャルログインに関するカスタムフック

※作成したカスタムフックは、それぞれ index.ts で名前付きで再エクスポートしています。

useOAuthURl

useMutationをラップした、OAuth 認可画面 URL 取得処理を行うためのカスタムフック。成功時は、返却された URL にリダイレクト。

import { UseMutationResult, useMutation } from 'react-query';
import axios, { AxiosError } from 'axios';
import { Provider, OAuthRedirect } from '../../models/OAuth';

const getOAuthUrl = async (provider: Provider): Promise<OAuthRedirect> => {
  const { data } = await axios.get(`/api/login/${provider}`);
  return data;
};

const useOAuthUrl = (): UseMutationResult<
  OAuthRedirect,
  AxiosError,
  Provider,
  undefined
> =>
  useMutation(getOAuthUrl, {
    onSuccess: (data) => {
      window.location.href = data.redirectUrl;
    },
  });

export default useOAuthUrl;

useSocialLogin

useMutationをラップした、ソーシャルログイン処理を行うためのカスタムフック。成功時は、返却されたログインユーザ情報を user キーにセット。

import { useQueryClient, UseMutationResult, useMutation } from 'react-query';
import axios, { AxiosError } from 'axios';
import { Provider, OAuthParams } from '../../models/OAuth';
import { User } from '../../models/User';

const socialLogin = async (
  provider: Provider,
  authParams: OAuthParams
): Promise<User> => {
  const { data } = await axios.post(
    `/api/login/${provider}/callback`,
    authParams
  );
  return data;
};

const useSocialLogin = (): UseMutationResult<
  User,
  AxiosError,
  { provider: Provider; authParams: OAuthParams },
  undefined
> => {
  const queryClient = useQueryClient();

  return useMutation(
    ({ provider, authParams }) => socialLogin(provider, authParams),
    {
      onSuccess: (data) => {
        queryClient.setQueryData('user', data);
      },
    }
  );
};

export default useSocialLogin;

おまけ - 認可した OAuth アプリの解除について

自アプリ側でアカウント削除機能があったとして、自アプリ側のユーザに関するデータは削除できますが、自アプリとの OAuth 認可解除はどうするんだろうか？という疑問が浮かびました。

調べた感じだとユーザ自身で解除してもらう感じになるのかなと。

GitHub の場合だと、以下の URL で、このクライアント ID を持つ OAuth アプリの画面にリンクさせることができます。

https://github.com/settings/connections/applications/:client_id

（GitHub の「settings」からだと「Application」「Authorized OAuth Apps」からいけます。）

今回の場合は特に触れてないですが、このリンクがあると親切になりそうですね。

こんな感じでソーシャルログインを実装してみました。

{/*  */}

Socialite の記事は、ビューも Laravel でやっているものがほとんどで、SPA + API 構成でやるための流れがなかなかつかめなくて苦戦しました🙄 この記事にまとめるのも時間かかってしまいました...。とりあえず一旦は形にできてよかったです。

{/*  */}

当記事には記載していませんが、参考記事をベースに API 側のテストは一応書いてるので、気になる方はリポジトリからどうぞ。

この実装が何かの参考になれば幸いです。

参考リンクまとめ

React QueryとIntersection Observer APIで無限スクロールを作ってみた

Tue, 13 Apr 2021 00:00:00 GMT

前回、React Query の記事を書いたのですが、今回はその派生記事です。 React Query と Intersection Observer API を使った無限スクロールを実装したので記事にしてみました。

※2023/07/09 各種リンクの URL を tanstack.com をベースに更新しました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

はじめに

React Query の概要については、前回の記事にも書いたので省略します。

React × LaravelでReact Queryの練習がてら、ログイン機能を作ってみた

データ取得にあたって、通常はuseQueryを使いますが、無限スクロール実装においてはuseInfiniteQueryを使います。

そして、次ページデータ読み込みタイミング検知として、Intersection Observer（交差監視） API というものを使います。

ターゲットとなる要素が、祖先要素もしくは文書の最上位のビューポートと交差する変更を非同期的に監視する方法を提供します。

これを使用することで、特定の要素が指定の割合分、画面へ表示された時に特定の処理をする、ということができます。

使用例

公式の例では、Next.js の中で使われていました　※2023/07/09時点ではコードが変わっていました。 <OG url="https://codesandbox.io/p/sandbox/github/tanstack/query/tree/v3/examples/load-more-infinite-scroll" />

import React from 'react'

export default function useIntersectionObserver({
  root,
  target,
  onIntersect,
  threshold = 1.0,
  rootMargin = '0px',
  enabled = true,
}) {
  React.useEffect(() => {
    if (!enabled) {
      return
    }

    const observer = new IntersectionObserver(
      entries =>
        entries.forEach(entry => entry.isIntersecting && onIntersect()),
      {
        root: root && root.current,
        rootMargin,
        threshold,
      }
    )

    const el = target && target.current

    if (!el) {
      return
    }

    observer.observe(el)

    return () => {
      observer.unobserve(el)
    }
  }, [target.current, enabled])
}

import React from 'react'
import Link from 'next/link'
import axios from 'axios'

import { useInfiniteQuery, QueryClient, QueryClientProvider } from 'react-query'
import { ReactQueryDevtools } from 'react-query/devtools'

//

import useIntersectionObserver from '../hooks/useIntersectionObserver'

const queryClient = new QueryClient()

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

function Example() {
  const {
    status,
    data,
    error,
    isFetching,
    isFetchingNextPage,
    isFetchingPreviousPage,
    fetchNextPage,
    fetchPreviousPage,
    hasNextPage,
    hasPreviousPage,
  } = useInfiniteQuery(
    'projects',
    async ({ pageParam = 0 }) => {
      const res = await axios.get('/api/projects?cursor=' + pageParam)
      return res.data
    },
    {
      getPreviousPageParam: firstPage => firstPage.previousId ?? false,
      getNextPageParam: lastPage => lastPage.nextId ?? false,
    }
  )

  const loadMoreButtonRef = React.useRef()

  useIntersectionObserver({
    target: loadMoreButtonRef,
    onIntersect: fetchNextPage,
    enabled: hasNextPage,
  })

  return (
    <div>
      <h1>Infinite Loading</h1>
      {status === 'loading' ? (
        <p>Loading...</p>
      ) : status === 'error' ? (
        <span>Error: {error.message}</span>
      ) : (
        <>
          <div>
            <button
              onClick={() => fetchPreviousPage()}
              disabled={!hasPreviousPage || isFetchingPreviousPage}
            >
              {isFetchingNextPage
                ? 'Loading more...'
                : hasNextPage
                ? 'Load Older'
                : 'Nothing more to load'}
            </button>
          </div>
          {data.pages.map(page => (
            <React.Fragment key={page.nextId}>
              {page.data.map(project => (
                <p
                  style={{
                    border: '1px solid gray',
                    borderRadius: '5px',
                    padding: '10rem 1rem',
                    background: `hsla(${project.id * 30}, 60%, 80%, 1)`,
                  }}
                  key={project.id}
                >
                  {project.name}
                </p>
              ))}
            </React.Fragment>
          ))}
          <div>
            <button
              ref={loadMoreButtonRef}
              onClick={() => fetchNextPage()}
              disabled={!hasNextPage || isFetchingNextPage}
            >
              {isFetchingNextPage
                ? 'Loading more...'
                : hasNextPage
                ? 'Load Newer'
                : 'Nothing more to load'}
            </button>
          </div>
          <div>
            {isFetching && !isFetchingNextPage
              ? 'Background Updating...'
              : null}
          </div>
        </>
      )}
      <hr />
      <Link href="/about">
        <a>Go to another page</a>
      </Link>
      <ReactQueryDevtools initialIsOpen />
    </div>
  )
}

useInfiniteQuery

基本的な使い方としてはuseQueryと似ており、以下のようになっています。

第1引数：クエリキー
第2引数：データ取得の関数
第3引数：オプション

渡せるオプションや、取得できる返り値の種類もuseQueryのものがベースとなっており、そこにページングに関するものが追加されている形です。

オプションのgetPreviousPageParamとgetNextPageParamが特に重要なもの。ここで返した値がそれぞれ前ページ、次ページのデータを取得する際のpageParamとして使われます。値がない時は、それぞれ前ページ、次ページがないものとして認識されます。

返り値の data の pages キーに1ページあたりのレスポンスデータが配列で格納されていくようになっています。 0：1ページ目 1：2ページ目といった感じ。

返り値のfetchPreviousPageとfetchNextPageがそれぞれ前ページ、次ページのデータを取得する関数です。この例だと、ボタンを押した時と Intersection Observer API で交差を検知した時、実行するようになっていますね。

Intersect Observer API

Intersect Observer API をラップしたカスタムフックが作られていますね。

コンストラクタに渡されたオプションについて書くと、こんな感じです。

root：交差監視の元となる要素（デフォルトではブラウザのビューポート）
onIntersect：交差検知時に実行されるコールバック
threshold：交差率
rootMargin：root 要素のマージン

この内容でオブザーバーを作成して、observe関数で監視対象の要素を指定することで監視が動作し、監視対象が交差率を超えたときに通知。コールバックが実行される、という仕組みになっています。

上記の例で言うと、こんな感じ。

root：指定なし（ブラウザのビューポート）
onIntersect：fetchNextPage（次ページ読み込み関数）
threshold：1.0
rootMargin：opx
監視対象：loadMore ボタン

なので、ブラウザのビューポートの中で loadMore ボタン要素が100%表示（全体が表示）されると検知され、次ページ読み込みを実行...ということになります。

ちなみにターゲット要素が25%見えるたびに処理をしたいといった場合は、threshold に[0, 0.25, 0.5, 0.75, 1]と配列でわたすことにより対応できたりします。

また、unobserve関数を使うことで、そのターゲット要素の監視を解除できます。上記の例では useEffect でクリーンアップ関数として使われますね。

今回作ってみたもの

左側の無限スクロールの部分です。（わかりやすくするために1ページ当たりの件数を10件にしています）前回と同じ勉強用の個人開発で実装したものになります。

公式の実装例をベースとして、実装してみました。

前提

React（Laravel Mix）× Laravel による SPA × API 構成で実装しました。といっても、各種フレームワークのページネーション機能仕様に合わせてさえもらえればいいので、API 側はなんでもいけると思われます。

今回使用した各種バージョンは以下のとおりです。

基本部分.

Node.js：14.2.0
TypeScript：4.1.3
React：16.14.0
PHP：7.4.14
Laravel：6.20.9

ライブラリ.

Material UI
- core：4.11.3
- lab：4.0.0-alpha.57
axios：0.21.1
react-query：3.12.1
camelcase-keys：6.2.2

ディレクトリ構成

Laravel プロジェクトの resources/ts 配下.

├ components
│   ├ molecules
│   │   ├ MemoListHeader.tsx
│   │   ├ MemoListItem.tsx
│   │   └ MemoListItemSkeleton.tsx
│   ├ organisms
│   │   └ MemoList.tsx
│   ├ pages
│   │   └ Memo.tsx
├ constants
│   └ statusCode.ts
├ containers
│   ├ organisms
│   │   └ MemoList.tsx
│   ├ pages
│   │   └ Memo.tsx
├ hooks
│   ├ memo
│   │   ├ index.ts
│   │   └ useGetmemoListQuery.ts
│   ├ util
│   │   ├ index.ts
│   │   └ useIntersectionObserver.ts
├ models
│   ├ Memo.ts
│   └ Memos.ts
└ app.tsx

今回もリポジトリにタグをつけていますので、GitHub で見たいという方はこちらをどうぞ。 <OG url="https://github.com/h-yoshikawa44/ooui-memo/releases/tag/post%2Freact-query-intersection-observer" />

※2021/09/13追記関数コンポーネントの型定義に FC ばっかり使ってますが、FC から children がなくなるまでは VFC を使った方がいいです...。

API（Laravel）側

※User モデルとリレーションを持つ、Memo モデルがあるものとして進めます。

メモ一覧取得 API

ログインユーザのメモ一覧取得 API を作成。

更新日時の降順にしたかったのでorderByで指定。ページネーションを有効にするため、paginateで取得したものを返すようにしています。

このpaginateの引数に渡した値が1ページ当たりの件数になりますので、この辺はお好みで。

/**
 * Create a new controller instance.
 *
 * @return void
 */
public function __construct()
{
    $this->middleware('auth');
}

/**
 * （ログインユーザの）メモ一覧取得API
 *
 * @return \Illuminate\Contracts\Pagination\LengthAwarePaginator
 */
public function index()
{
    $user = Auth::user();
    $memos = Memo::where('user_id', $user->user_id)->orderBy(Memo::UPDATED_AT, 'desc')->paginate(30);

    return $memos;
}

API のルートに追加.

Route::get('/memos', 'MemoController@index')->name('memo.index');

ページネーションを有効にした場合の挙動

Laravel においてページネーションを有効にすると、レスポンスが以下のように変化します。 data 以外にページネーションに関するものが追加されていますね。

{
   "total": 32,
   "per_page": 30,
   "current_page": 1,
   "last_page": 2,
   "first_page_url": "http://localhost/api/memos?page=1",
   "last_page_url": "http://localhost/api/memos?page=2",
   "next_page_url": "http://localhost/api/memos?page=2",
   "prev_page_url": null,
   "from": 1,
   "to": 30,
   "path": "http://localhost/api/memos",
   "data":  [
     {
       "memo_id": "c53f4b50-2556-4285-b63c-0acca6da001f",
       "title": "Est sequi sapiente laudantium maxime aut.",
       "content": "Facere blanditiis et mollitia animi sapiente suscipit eos. Sunt earum dolorem soluta. Autem laboriosam dolor sed voluptas. Laudantium maiores enim numquam voluptas reprehenderit.",
       "created_at": "2021-03-29 16:33:04",
       "updated_at": "2021-03-29 16:33:04",
     }
    .
    .
    .
    {
       "memo_id": "5ada62cd-b590-4c7f-9198-da6a2996f49e",
       "title": "Numquam dolorem maiores quo natus quos tenetur.",
       "content": "Ut quibusdam amet optio amet. Rem ipsam quia sit. Impedit et at enim error et. Error consequatur dolore velit illo debitis inventore.",
       "created_at": "2021-03-29 16:33:04",
       "updated_at": "2021-03-29 16:33:04",
    }
  ]
}

last_page_urlなどにもあるように、クエリパラメータでpageを渡すことによって、そのページのデータを取得できるようになっています。

この仕様を把握したうえで、フロント側からリクエストします。

SPA（React）側

アプリ初期化 + ルーティング

React Query のセットアップを行いルーティングをしているという、前回の記事での内容と大体同じですが、一応載せておきます。（解説を知りたい場合は前回の記事を参照ください）

React Query のデフォルトリトライ回数の変更をしていますが、この辺はお好みで。

/:memoId?のルートが今回無限スクロールを実装したメモ画面のルートになります。ちなみに?をつけているのはあえてやってますが、当記事の趣旨には関係ない部分なので、ここで解説はしません。

import React, { FC } from 'react';
import ReactDOM from 'react-dom';
import {
  BrowserRouter as Router,
  Switch,
  Route,
  Redirect,
} from 'react-router-dom';
import { QueryClient, QueryClientProvider, useQueryClient } from 'react-query';
import { ReactQueryDevtools } from 'react-query/devtools';
import CssBaseline from '@material-ui/core/CssBaseline';

import Login from './containers/pages/Login';
import Memo from './containers/pages/Memo';
import Loding from './components/pages/Loding';
import { useGetUserQuery, useCurrentUser } from './hooks/user';

/**
 * First we will load all of this project's JavaScript dependencies which
 * includes React and other helpers. It's a great starting point while
 * building robust, powerful web applications using React + Laravel.
 */
require('./bootstrap');

/**
 * Next, we will create a fresh React component instance and attach it to
 * the page. Then, you may begin adding components to this application
 * or customize the JavaScript scaffolding to fit your unique needs.
 */
// require('./components/Example');

const client = new QueryClient({
  defaultOptions: {
    queries: {
      retry: 1,
    },
    mutations: {
      retry: 1,
    },
  },
});

type Props = {
  exact?: boolean;
  path: string;
  children: React.ReactNode;
};

const UnAuthRoute: FC<Props> = ({ exact = false, path, children }) => {
  const user = useCurrentUser();
  return (
    <Route
      exact={exact}
      path={path}
      render={() => (user ? <Redirect to={{ pathname: '/' }} /> : children)}
    />
  );
};

const AuthRoute: FC<Props> = ({ exact = false, path, children }) => {
  const user = useCurrentUser();
  return (
    <Route
      exact={exact}
      path={path}
      render={({ location }) =>
        user ? (
          children
        ) : (
          <Redirect to={{ pathname: '/login', state: { from: location } }} />
        )
      }
    />
  );
};

const App: FC = () => {
  const queryClient = useQueryClient();
  const { isLoading } = useGetUserQuery({
    retry: 0,
    initialData: undefined,
    onError: () => {
      queryClient.setQueryData('user', null);
    },
  });

  if (isLoading) {
    return <Loding />;
  }

  return (
    <Switch>
      <UnAuthRoute exact path="/login">
        <Login />
      </UnAuthRoute>
      <AuthRoute path="/:memoId?">
        <Memo />
      </AuthRoute>
    </Switch>
  );
};

if (document.getElementById('app')) {
  ReactDOM.render(
    <Router>
      <QueryClientProvider client={client}>
        <CssBaseline />
        <App />
        {process.env.NODE_ENV === 'development' && (
          <ReactQueryDevtools initialIsOpen={false} />
        )}
      </QueryClientProvider>
    </Router>,
    document.getElementById('app')
  );
}

メモ一覧

構造として、メモ画面を構成する Memo コンポーネントがあり。

メモ一覧を構成する MemoList コンポーネント
メモ詳細を構成する MemoDetail コンポーネント

を使っています。

Memo コンポーネントと MemoDetail コンポーネントでやっていることは、当記事の趣旨に直接関係ないので割愛します。

Container Component

当記事の趣旨に関係ない部分もありますが、一旦、全容を載せると以下のようになっています。

import React, { FC, useCallback, useEffect } from 'react';
import { useHistory } from 'react-router-dom';
import useMediaQuery from '@material-ui/core/useMediaQuery';
import { useTheme } from '@material-ui/core/styles';
import MemoList from '../../components/organisms/MemoList';
import { useGetMemoListQuery, usePostMemoMutation } from '../../hooks/memo';
import { useIntersectionObserver } from '../../hooks/util';

type Props = {
  memoId?: string;
};

const EnhancedMemoList: FC<Props> = ({ memoId }) => {
  const {
    isFetching,
    isLoading,
    error,
    data: paginateMemos,
    hasNextPage,
    isFetchingNextPage,
    fetchNextPage,
  } = useGetMemoListQuery();
  const history = useHistory();
  const statusCode = error?.response?.status;

  // データ取得中でない + 画面幅が広い + メモ未選択時は、メモ一覧の一番新しいメモへ遷移
  const theme = useTheme();
  const iswideDisplay = useMediaQuery(theme.breakpoints.up('sm'));
  useEffect(() => {
    const firstMemoId = paginateMemos?.pages[0]?.data[0].memoId;
    if (!isFetching && !memoId && iswideDisplay && firstMemoId) {
      history.push(`/${firstMemoId}`);
    }
  }, [history, isFetching, paginateMemos, memoId, iswideDisplay]);

  // 無限スクロール処理
  const { loadMoreRef } = useIntersectionObserver({
    onIntersect: fetchNextPage,
    enabled: hasNextPage,
  });

  const { mutate } = usePostMemoMutation();
  const handleAddMemo = useCallback(() => {
    mutate({ title: '', content: '' });
  }, [mutate]);

  const handleSelectItem = useCallback(
    (selectMemoId: string) => {
      history.push(`/${selectMemoId}`);
    },
    [history]
  );

  return (
    <MemoList
      paginateMemos={paginateMemos?.pages}
      isLoading={isLoading}
      statusCode={statusCode}
      loadMoreRef={loadMoreRef}
      hasNextPage={hasNextPage}
      isFetchingNextPage={isFetchingNextPage}
      handleAddMemo={handleAddMemo}
      handleSelectItem={handleSelectItem}
    />
  );
};

export default EnhancedMemoList;

無限スクロールに関係する部分をさらっと説明します。

・useInfiniteQuery を使ったデータ取得

const {
    isFetching,
    isLoading,
    error,
    data: paginateMemos,
    hasNextPage,
    isFetchingNextPage,
    fetchNextPage,
  } = useGetMemoListQuery();
  const history = useHistory();
  const statusCode = error?.response?.status;

useGetMemoListQuery というuseInfiniteQueryをラップしたカスタムフックを使って、メモ一覧を取得しています。データだけでなく、読み込み中などの UI 表示に使用するものや次ページに関するものも併せて取得。

isFetching：データ取得中であるか
isLoading：（既存のキャッシュがない）初回データ取得中であるか
error：エラー内容（エラー時のみ）
hasNextPage：次ページがあるか
isFetchingNextPage：次ページデータを取得中であるか
fetchNextPage：次ページ取得関数

・Intersection Observer API の設定

  // 無限スクロール処理
  const { loadMoreRef } = useIntersectionObserver({
    onIntersect: fetchNextPage,
    enabled: hasNextPage,
  });

Intersection Observer API をラップしたカスタムフックを使用して、無限スクロールの設定をしています。 loadMoreRef はコールバック ref になっており、無限スクロール検知用の要素へ渡すように。

オプション設定により、次ページが存在する場合のみ監視し、通知を検知した時に次ページを読み込むようにしています。

・取得したデータを渡す 冒頭に書いた通り。useInfiniteQueryで取得したデータは、pages キーの中に配列で格納されるので、それを渡します。その他、UI 側で使用するものを一緒に渡しています。

return (
  <MemoList
    paginateMemos={paginateMemos?.pages}
    isLoading={isLoading}
    statusCode={statusCode}
    loadMoreRef={loadMoreRef}
    hasNextPage={hasNextPage}
    isFetchingNextPage={isFetchingNextPage}
    handleAddMemo={handleAddMemo}
    handleSelectItem={handleSelectItem}
  />
);

Presentational Component

初回読み込み中はスケルトン表示、エラー時はアラート表示、読み込みが終わり次第、データを使ったメモ一覧を表示するようにしています。エラー表示はとりあえず500エラーの時だけ。

import React, { FC } from 'react';
import Box from '@material-ui/core/Box';
import List from '@material-ui/core/List';
import GeneralAlert from '../atoms/GeneralAlert';
import MemoListHeader from '../molecules/MemoListHeader';
import MemoListItem from '../molecules/MemoListItem';
import MemoListItemSkeleton from '../molecules/MemoListItemSkeleton';
import { INTERNAL_SERVER_ERROR } from '../../constants/statusCode';
import { Memos } from '../../models/Memos';

type Props = {
  paginateMemos?: Memos[];
  isLoading: boolean;
  statusCode?: number;
  loadMoreRef: (node: Element) => void;
  hasNextPage?: boolean;
  isFetchingNextPage: boolean;
  handleAddMemo: VoidFunction;
  handleSelectItem: (selectMemoId: string) => void;
};

const MemoList: FC<Props> = ({
  paginateMemos,
  isLoading,
  statusCode,
  loadMoreRef,
  hasNextPage,
  isFetchingNextPage,
  handleAddMemo,
  handleSelectItem,
}) => {
  if (isLoading) {
    return (
      <>
        <Box height={48} px={2} />
        {[1, 2, 3, 4, 5].map((value) => (
          <MemoListItemSkeleton key={value} />
        ))}
      </>
    );
  }

  if (statusCode) {
    return (
      <>
        <Box height={48} px={2} />
        {statusCode === INTERNAL_SERVER_ERROR && (
          <GeneralAlert
            type="error"
            title="サーバエラー"
            content="予期しないエラーが発生し、メモデータ取得に失敗しました。恐れ入りますが時間をおいて再度お試しください。"
          />
        )}
      </>
    );
  }

  let loadMoreMessage;
  if (isFetchingNextPage) {
    loadMoreMessage = '読み込み中...';
  } else {
    loadMoreMessage = hasNextPage ? '続きを読み込む' : ' ';
  }

  return (
    <>
      <MemoListHeader handleAddMemo={handleAddMemo} />
      {/* 140px = ヘッダー：64 + メモ一覧ヘッダー：48 + 下部余白：28 */}
      <List style={{ height: 'calc(100vh - 140px)', overflowY: 'scroll' }}>
        {paginateMemos?.map((page) => (
          <React.Fragment key={page.currentPage}>
            {page.data.map((memo) => (
              <MemoListItem
                key={memo.memoId}
                memoId={memo.memoId}
                title={memo.title}
                content={memo.content}
                handleSelectItem={handleSelectItem}
              />
            ))}
          </React.Fragment>
        ))}
        <Box {...{ ref: loadMoreRef }} textAlign="center">
          {loadMoreMessage}
        </Box>
      </List>
    </>
  );
};

export default MemoList;

・データ表示とスクロール

  {/* 140px = ヘッダー：64 + メモ一覧ヘッダー：48 + 下部余白：28 */}
  <List style={{ height: 'calc(100vh - 140px)', overflowY: 'scroll' }}>
    {paginateMemos?.map((page) => (
      <React.Fragment key={page.currentPage}>
        {page.data.map((memo) => (
          <MemoListItem
            key={memo.memoId}
            memoId={memo.memoId}
            title={memo.title}
            content={memo.content}
            handleSelectItem={handleSelectItem}
          />
        ))}
      </React.Fragment>
    ))}
    .
    .
    .
  </List>

渡されたデータ配列を map で回します。 1ページあたりのデータの data キーをさらに map を使って回して、一件ずつのデータで MemoListItem コンポーネントを構築しています。

このメモ一覧をスクロールしたいので、height と overflowY を設定。 height の値の計算はコメントに書いている通りです。動的に計算できればいいなと思ったのですが、複雑になりそうだったので固定で指定しています。

・無限スクロール検知用要素

  let loadMoreMessage;
  if (isFetchingNextPage) {
    loadMoreMessage = '読み込み中...';
  } else {
    loadMoreMessage = hasNextPage ? '続きを読み込む' : ' ';
  }

  <Box {...{ ref: loadMoreRef }} textAlign="center">
    {loadMoreMessage}
  </Box>

メモ一覧の末尾に Box コンポーネントで要素を置いており、これにコールバック ref を渡しています。この要素がどれだけ表示されたかで検知するようにしているわけです。

状態に応じて表示内容を変えたいので、分岐でメッセージを作っています。

モデル

Memo

export type Memo = {
  memoId: string;
  title: string;
  content: string;
  createdAt: Date;
  updatedAt: Date;
};

Memos

Laravel のレスポンス形式に合わせてますが、データ取得時にプロパティキーをキャメルケースに変換するので、こちらではキャメルケースで定義しています。

import { Memo } from './Memo';

export type Memos = {
  total: number;
  perPage: number;
  currentPage: number;
  lastPage: number;
  firstPageUrl: string;
  lastPageUrl: string;
  nextPageUrl: string | null;
  prevPageUrl: string | null;
  path: string;
  from: number;
  to: number;
  data: Memo[];
};

カスタムフック

※作成したカスタムフックは、それぞれ index.ts で名前付きで再エクスポートしています。

useGetMemoListQuery

useInfiniteQueryをラップした、メモ一覧取得のためのカスタムフック。成功時は、取得したデータを memos キーにセット。

import {
  UseInfiniteQueryResult,
  UseInfiniteQueryOptions,
  useInfiniteQuery,
} from 'react-query';
import axios, { AxiosError } from 'axios';
import camelcaseKeys from 'camelcase-keys';
import { Memos } from '../../models/Memos';

const getMemoList = async ({ pageParam = 1 }): Promise<Memos> => {
  const { data } = await axios.get(`/api/memos?page=${pageParam}`);
  return camelcaseKeys(data, { deep: true });
};

const useGetMemoListQuery = <TData = Memos>(
  options?: UseInfiniteQueryOptions<Memos, AxiosError, TData>
): UseInfiniteQueryResult<TData, AxiosError> =>
  useInfiniteQuery('memos', getMemoList, {
    ...options,
    getPreviousPageParam: (firstPage) =>
      firstPage.prevPageUrl ? firstPage.currentPage - 1 : false,
    getNextPageParam: (lastPage) =>
      lastPage.nextPageUrl ? lastPage.currentPage + 1 : false,
  });

export default useGetMemoListQuery;

API 定義のところで書いたように、Laravel でページネーションを有効にすると、pageクエリパラメータで取得ページを指定できるので、こちらもそれに合わせます。

getPreviousPageParamオプションでは、前ページの URL が存在する時に、現在のページ数から -1 したページ数を返すように。

同様にgetNextPageParamオプションでは、次ページの URL が存在する時に、現在のページ数から +1 したページ数を返すように。

ちなみに取得したデータのプロパティキーのスネークケース・キャメルケース問題解消のためにcamelcaseKeysで変換をかけています。本来は axios の interceptors でまとめてやった方がいいと思われます。

useIntersectionObserver

Intersect Observer API をラップしたカスタムフック。公式の実装例をベースとしています。

import React, { useState, useCallback, useEffect } from 'react';
import { FetchNextPageOptions, InfiniteQueryObserverResult } from 'react-query';
import { AxiosError } from 'axios';

type Argument = {
  root?: React.RefObject<HTMLElement> | null;
  onIntersect: (
    options?: FetchNextPageOptions | undefined
  ) => Promise<InfiniteQueryObserverResult<unknown, AxiosError>>;
  threshold?: number | number[];
  rootMargin?: string;
  enabled?: boolean;
};

type Response = {
  loadMoreRef: (node: Element) => void;
};

const useIntersectionObserver = ({
  root = null,
  onIntersect,
  threshold = 1.0,
  rootMargin = '0px',
  enabled = true,
}: Argument): Response => {
  const [target, setTarget] = useState<Element | null>(null);

  // コールバックref（呼び出し側はこれを無限スクロール検知用要素のrefに渡せばいい）
  const loadMoreRef = useCallback((node: Element) => {
    if (node !== null) {
      setTarget(node);
    }
  }, []);

  const newIntersectionObserver = useCallback(
    () =>
      new IntersectionObserver(
        (entries) =>
          entries.forEach((entry) => entry.isIntersecting && onIntersect()),
        {
          root: root && root.current,
          rootMargin,
          threshold,
        }
      ),
    [root, onIntersect, threshold, rootMargin]
  );

  useEffect(() => {
    if (!enabled) {
      return;
    }
    const el = target;

    if (!el) {
      return;
    }
    const observer = newIntersectionObserver();

    observer.observe(el);

    // eslint-disable-next-line consistent-return
    return () => {
      observer.unobserve(el);
    };
  }, [enabled, target, newIntersectionObserver]);

  return { loadMoreRef };
};

export default useIntersectionObserver;

公式の例ではターゲット要素の指定に useRef の ref オブジェクトが使用されていましたが、コールバック ref にしています。というのも ref オブジェクトの仕様上、少し都合が悪かったためです。

useRef は中身が変更になってもそのことを通知しないということを覚えておいてください。.current プロパティを書き換えても再レンダーは発生しません。DOM ノードを ref に割り当てたり割り当てを解除したりする際に何らかのコードを走らせたいという場合は、コールバック ref を代わりに使用してください。

自分の場合、初回データ取得中はスケルトンのみを表示していて、取得後に実際のデータのメモ一覧 + loadMore 要素を表示するようにしています。

つまり、ターゲット要素の ref が初回データ取得中：なし（null） ↓ データ取得後：loadMore 要素と変化するわけですが、ref オブジェクトだとそれを通知してくれません。

その結果、オブザーバーの監視対象がうまく設定されず動作しなくなってしまいました。そのため、コールバック ref を使うことで対応しています。

それと useEffect で値を返す return と返さない return が混在しているせいか、ESLint の consistent-return ルールにひっかかったので、無効にしています。（うまい対応方法があれば知りたい...）

実は Intersection Observer API の存在を、公式の実装例を見て初めて知ったわけですが、なかなか便利だなぁと思いました。今回はuseInfiniteQueryと組み合わせて使うような作りで作ってはいますが、少し変えれば他の状態管理ライブラリ等でも使えそうです。

React Query の機能をまた1つ知れて、良い勉強になりました。引き続き、使っていきますー。

参考リンクまとめ

React × LaravelでReact Queryの練習がてら、ログイン機能を作ってみた

Sun, 21 Mar 2021 00:00:00 GMT

React の状態管理ライブラリと言うと Redux や Recoil がメジャーなイメージでしょうか。少し前から React Query なるものが便利らしいぞと見聞きしたので使ってみたのを、せっかくなので記事にしてみました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

※2023/07/09 各種リンクの URL を tanstack.com をベースに更新しました。

React Query とは？

ものすごくざっくりいうと、React アプリで使用するデータの取得、更新。そのデータ管理まで一気にやってくれるライブラリといった感じです。

データの取得や更新の方法はこちらで指定する必要がありますが、実体のデータを Promise で返す関数なら何でも使えます。なので、fetch でも ky でも axios でも OK。

キャッシュ機能が統合されており、取得したデータは指定したクエリキーと紐づけて管理されます。このキャッシュされたデータは、どのコンポーネントからもアクセス可能です。キャッシュの有効時間が過ぎると、バックグラウンドでデータの再取得が自動で行われるようになっています。（その分、API リクエスト等が増えるということでもあるので、導入するアプリに応じてオプションで調整した方がいいです）

それと個人的に特にいいなと思った部分として、データ取得、更新の状態を返してくれます。データ取得中なのか、成功したのか、エラーになったのかといったあたり。この状態を使って、読み込み中やエラーの時の UI に切り替えるということも、楽にできるようになっています。

使用例

React Query を使えるようにするには、まず最初にQueryClientを作成。アプリをQueryClientProviderで囲み、そこに作成したクライアントを渡すようにします。こうすることで、この配下のコンポーネントで React Query の機能が使えるようになります。

React Query が提供するフックはいろいろあるのですが、基本となるものとしては以下の2つです。

データ取得：useQuery
データ更新：useMutation

useQuery

公式の例 <OG url="https://codesandbox.io/s/github/tanstack/query/tree/v3/examples/simple" />

/* eslint-disable jsx-a11y/anchor-is-valid */
import React from "react";
import ReactDOM from "react-dom";
import { QueryClient, QueryClientProvider, useQuery } from "react-query";
import { ReactQueryDevtools } from "react-query/devtools";

const queryClient = new QueryClient();

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  );
}

function Example() {
  const { isLoading, error, data, isFetching } = useQuery("repoData", () =>
    fetch(
      "https://api.github.com/repos/tannerlinsley/react-query"
    ).then((res) => res.json())
  );

  if (isLoading) return "Loading...";

  if (error) return "An error has occurred: " + error.message;

  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.description}</p>
      <strong>👀 {data.subscribers_count}</strong>{" "}
      <strong>✨ {data.stargazers_count}</strong>{" "}
      <strong>🍴 {data.forks_count}</strong>
      <div>{isFetching ? "Updating..." : ""}</div>
      <ReactQueryDevtools initialIsOpen />
    </div>
  );
}

const rootElement = document.getElementById("root");
ReactDOM.render(<App />, rootElement);

useQueryに対して、以下を渡しています。

第1引数：クエリキー
第2引数：データ取得の関数

クエリキーには配列の指定もできます。データ取得の関数により取得されたデータは、このクエリキーと紐づけて管理されます。また、第3引数にオプションのオブジェクトを渡して、成功時や失敗時の処理を書いたりとカスタマイズすることも出来たりします。

useMutation

公式の例（useQueryとuseMutation）　※2023/07/09時点では TypeScript になっていました <OG url="https://codesandbox.io/p/sandbox/github/tanstack/query/tree/v3/examples/optimistic-updates-typescript" />

import React from 'react'
import axios from 'axios'
import {
  useQuery,
  useQueryClient,
  useMutation,
  QueryClient,
  QueryClientProvider,
} from 'react-query'
import { ReactQueryDevtools } from 'react-query/devtools'

const queryClient = new QueryClient()

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

function Example() {
  const queryClient = useQueryClient()
  const [text, setText] = React.useState('')
  const { status, data, error, isFetching } = useQuery('todos', async () => {
    const res = await axios.get('/api/data')
    return res.data
  })

const addTodoMutation = useMutation(
    text => axios.post('/api/data', { text }),
    {
      // Optimistically update the cache value on mutate, but store
      // the old value and return it so that it's accessible in case of
      // an error
      onMutate: async text => {
        setText('')
        await queryClient.cancelQueries('todos')
        const previousValue = queryClient.getQueryData('todos')
        queryClient.setQueryData('todos', old => ({
          ...old,
          items: [...old.items, text],
        }))
        return previousValue
      },
      // On failure, roll back to the previous value
      onError: (err, variables, previousValue) =>
        queryClient.setQueryData('todos', previousValue),
      // After success or failure, refetch the todos query
      onSuccess: () => {
        queryClient.invalidateQueries('todos')
      },
    }
  )

  return (
    <div>
      <p>
        In this example, new items can be created using a mutation. The new item
        will be optimistically added to the list in hopes that the server
        accepts the item. If it does, the list is refetched with the true items
        from the list. Every now and then, the mutation may fail though. When
        that happens, the previous list of items is restored and the list is
        again refetched from the server.
      </p>
      <form
        onSubmit={e => {
          e.preventDefault()
          addTodoMutation.mutate(text)
        }}
      >
        <input
          type="text"
          onChange={event => setText(event.target.value)}
          value={text}
        />
        <button>{addTodoMutation.isLoading ? 'Creating...' : 'Create'}</button>
      </form>
      <br />
      {status === 'loading' ? (
        'Loading...'
      ) : status === 'error' ? (
        error.message
      ) : (
        <>
          <div>Updated At: {new Date(data.ts).toLocaleTimeString()}</div>
          <ul>
            {data.items.map(datum => (
              <li key={datum}>{datum}</li>
            ))}
          </ul>
          <div>{isFetching ? 'Updating in background...' : ' '}</div>
        </>
      )}
      <ReactQueryDevtools initialIsOpen />
    </div>
  )
}

useMutationに対して、以下を渡しています。

第1引数：データ更新の関数
第2引数：オプションのオブジェクト

この第1引数に指定した関数は、useMutationが呼ばれただけでは実行されません。 useMutationの返り値の中に、この関数を実行するトリガー関数（mutate）が含まれており、それを使うことで初めて実行されるようになっています。上記の例だとaddTodoMutation.mutate(text)の部分です。トリガー関数に渡した引数が、そのままデータ更新の関数に渡されます。

上記の例で使われているオプションをさらっと説明すると、こんな感じです。

onMutate：データ更新の関数が実行される前に、先に実行される処理（前処理を書く）
onError：エラー発生時に実行される処理
onSuccess：成功時に実行される処理

成功時、エラー時ともに実行される onSettled というものもあります。

また、onSuccess、onError、onSettled に関しては、useMutationだけでなく、トリガー関数のオプション引数としても渡すことができます。どちらにも同名のオプションを渡している場合は、useMutationに渡した方が先に実行されます。

ちなみにReactQueryDevtoolsは開発支援の DevTools です。キャッシュの状態などがわかるので、いれておくとよいです。

詳細については公式ドキュメントをご確認ください。

今回作ってみたもの

勉強用の個人開発でログイン画面を作りました。 React（Laravel Mix）× Laravel による SPA × API 構成です。

メールアドレスとパスワードでログインのスタンダードなタイプ。後々、ソーシャルログインとゲストログインにしたいということもあり、今回メール認証は特にやっていません。

また、API の認証方式については Cookie を使ったステートフルなものになります。

実装にあたっていろんな文献を参考にさせていただいたのですが、以下の2つは特にお世話になりました。

※連載記事 <OG url="https://www.hypertextcandy.com/vue-laravel-tutorial-introduction" /> ※書籍 <OG url="https://github.com/oukayuka/Riakuto-StartingReact-ja3.1" />

それと各種ライブラリの公式ドキュメントも。

前提

今回使用した各種バージョンは以下のとおりです。

基本部分.

Node.js：14.2.0
TypeScript：4.1.3
React：16.14.0
PHP：7.4.14
Laravel：6.20.9

ライブラリ.

Material UI
- core：4.11.3
- lab：4.0.0-alpha.57
axios：0.21.1
react-router-dom：5.2.0
react-query：3.12.1

以下のセットアップはすでにすんでいるものとして進めます。

マイグレーション実行
Laravel UI で React の導入
TypeScript のセットアップ
ライブラリインストール

ディレクトリ構成

Laravel 側は特に変わったことをしてないので、React 側だけ記載します。

Laravel プロジェクトの resources/ts 配下.

├ components
│   ├ molecules
│   │   └ LoginAlert.tsx
│   ├ organisms
│   │   └ Header.tsx
│   ├ pages
│   │   ├ Loding.tsx
│   │   ├ Login.tsx
│   │   └ Memo.tsx
├ constants
│   └ statusCode.ts
├ containers
│   ├ organisms
│   │   └ Header.tsx
│   ├ pages
│   │   ├ Login.tsx
│   │   └ Memo.tsx
├ hooks
│   ├ auth
│   │   ├ index.ts
│   │   ├ useLogin.ts
│   │   └ useLogout.ts
│   ├ user
│   │   ├ index.ts
│   │   ├ useCurrentUser.ts
│   │   └ useGetUserQuery.ts
├ models
│   └ User.ts
├ app.tsx
└ bootstrap.js

以降、今回の実装のコードを記載していますが、だいぶ長くなりました...🙄 GitHub で見たいという方は、こちらのリポジトリにタグをつけてあります。 <OG url="https://github.com/h-yoshikawa44/ooui-memo/releases/tag/post%2Flaravel-react-query-auth" />

※2021/09/13追記関数コンポーネントの型定義に FC ばっかり使ってますが、FC から children がなくなるまでは VFC を使った方がいいです...。

API（Laravel）側

※今回、ユーザ新規登録の部分は記載していません。 Laravel に元々備わっているものを使って API を作るなり、tinker でユーザを作っておくなりでご対応ください。

ルーティング

画面の振り分けは React 側で行うので、Laravel 側では全てのリクエストを受けるようにします。

Route::get('/{any?}', fn() => view('index'))->where('any', '.+');

※2021/05/19 追記全受けにすると、API ルートで where 制約をかけた際に予期しない動作を引き起こすので api プレフィックスは除外しておいた方がいいです。（制約外のパスパラメータでアクセスすると404のはずなのに、このルートに来て200になってしまうので）

Route::get('/{any?}', fn() => view('index'))->where('any', '(?!api).+');

API ルートで使用するミドルウェアグループの変更

今回は Cookie を使った認証にしていきます。下記のとおり、それに必要なミドルウェアは web のミドルウェアグループに含まれています。

protected $middlewareGroups = [
    'web' => [
        \App\Http\Middleware\EncryptCookies::class,
        \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
        \Illuminate\Session\Middleware\StartSession::class,
        // \Illuminate\Session\Middleware\AuthenticateSession::class,
        \Illuminate\View\Middleware\ShareErrorsFromSession::class,
        \App\Http\Middleware\VerifyCsrfToken::class,
        \Illuminate\Routing\Middleware\SubstituteBindings::class,
    ],

    'api' => [
        'throttle:60,1',
        \Illuminate\Routing\Middleware\SubstituteBindings::class,
    ],
];

それを API でも使うように思い切って変えました。

    protected function mapApiRoutes()
    {
        // Webミドルウェアグループの機能を使いたいのでwebへ
        Route::prefix('api')
             ->middleware('web')
             ->namespace($this->namespace)
             ->group(base_path('routes/api.php'));
    }

なんか抵抗があるという場合は、ステートフルな API 用のミドルウェアグループを新たに作って、それを割り当てるのも手です。

CSRF 対策について

この web のミドルウェアグループには CSRF 対策の機能を持つ、\App\Http\Middleware\VerifyCsrfToken::classも含まれています。なので、リクエストの際には CSRF トークンを送らないとはじかれます。 <OG url="https://readouble.com/laravel/6.x/ja/csrf.html" />

今回の場合、SPA 側からのリクエストには axios を使用するので、リクエストヘッダにX-XSRF-TOKENをつけて送る必要があります。ただ、このあたりの設定に関して特にやることはありません。

\App\Http\Middleware\VerifyCsrfToken::classで以下の設定があり、レスポンスヘッダのSet-CookieにXSRF-TOKENを設定してくれています。

/**
 * Indicates whether the XSRF-TOKEN cookie should be set on the response.
 *
 * @var bool
 */
protected $addHttpCookie = true;

そして、axios は Cookie にXSRF-TOKENがあると、自動でX-XSRF-TOKENにセットして送ってくれるようになっているためです。

ログイン API

Laravel が元々備えている機能を拡張して使用。

LoginControllerで使用されているAuthenticatesUsersトレイトに認証に関するメソッドが定義されています。そこにログイン API のレスポンスカスタマイズ用のメソッドとしてauthenticatedがあります。これを使用して、ログイン時はログインしたユーザ情報を返すように。

/**
 * ログインAPI レスポンスカスタマイズ用メソッド
 *
 * @param Illuminate\Http\Request $request
 * @param \App\User $user
 * @return \App\User
 */
protected function authenticated(Request $request, $user)
{
    return $user;
}

API のルートに追加。

Route::post('/login', 'Auth\LoginController@login')->name('login');

ログアウト API

ログイン API と同様に作成。

こちらはloggedOutメソッドがレスポンスカスタマイズ用のメソッドになります。

※2021/04/13 追記レスポンスはresponse(null, 204)で204を返した方がいいやもしれません。 ※2021/04/27 追記セッション再生成処理は、大元のログアウト処理の中ですでに行われているので不要です。

/**
 * ログアウトAPI レスポンスカスタマイズ用メソッド
 *
 * @param Illuminate\Http\Request $request
 * @return \Illuminate\Http\JsonResponse
 */
protected function loggedOut(Request $request)
{
    // セッションを再生成する
    $request->session()->regenerate();

    return response()->json();
}

API のルートに追加。

Route::post('/logout', 'Auth\LoginController@logout')->name('logout');

ログインユーザ取得 API

新しくコントローラーを作って定義します。この API は認証をかけたかったので、auth ミドルウェアを使用。

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;

class UserController extends Controller
{
    /**
     * Create a new controller instance.
     *
     * @return void
     */
    public function __construct()
    {
        $this->middleware('auth');
    }

    /**
     * 現在ログインしているユーザ情報取得
     *
     * @return \App\User|null
     */
    public function show()
    {
        return Auth::user();
    }
}

API のルートに追加。

Route::get('/users/me', 'UserController@show')->name('user');

User モデルのレスポンスのプロパティを変更。

/**
 * The attributes that should be visible for arrays.
 *
 * @var array
 */
protected $visible = [
    'name',
];

元々は$hiddenで書いてあるのですが、今回の場合は React 側で一旦 name しか使わないので、$visibleで name のみ返すようにしています。

ログイン済みの時に、非ログイン時にしかアクセスできない機能にアクセスした時のリダイレクト設定

元々はRouteServiceProvider::HOMEへリダイレクトするようになっています。ただ、それだと HTML が返ってきてしまい SPA 的には不都合なので、ログインユーザ取得 API に変えておきます。

/**
 * Handle an incoming request.
 *
 * @param  \Illuminate\Http\Request  $request
 * @param  \Closure  $next
 * @param  string|null  $guard
 * @return mixed
 */
public function handle($request, Closure $next, $guard = null)
{
    if (Auth::guard($guard)->check()) {
        return redirect()->route('user');
    }

    return $next($request);
}

SPA（React）側

bootstrap.jsは特に変更していないので割愛。

アプリ初期化 + ルーティング

1ファイルの中でやってるので長いですが、こんな感じです。

import React, { FC } from 'react';
import ReactDOM from 'react-dom';
import {
  BrowserRouter as Router,
  Switch,
  Route,
  Redirect,
} from 'react-router-dom';
import { QueryClient, QueryClientProvider, useQueryClient } from 'react-query';
import { ReactQueryDevtools } from 'react-query/devtools';
import CssBaseline from '@material-ui/core/CssBaseline';

import Login from './containers/pages/Login';
import Memo from './containers/pages/Memo';
import Loding from './components/pages/Loding';
import { useGetUserQuery, useCurrentUser } from './hooks/user';

/**
 * First we will load all of this project's JavaScript dependencies which
 * includes React and other helpers. It's a great starting point while
 * building robust, powerful web applications using React + Laravel.
 */
require('./bootstrap');

/**
 * Next, we will create a fresh React component instance and attach it to
 * the page. Then, you may begin adding components to this application
 * or customize the JavaScript scaffolding to fit your unique needs.
 */
// require('./components/Example');

const client = new QueryClient();

type Props = {
  exact?: boolean;
  path: string;
  children: React.ReactNode;
};

const UnAuthRoute: FC<Props> = ({ exact = false, path, children }) => {
  const user = useCurrentUser();
  return (
    <Route
      exact={exact}
      path={path}
      render={() => (user ? <Redirect to={{ pathname: '/' }} /> : children)}
    />
  );
};

const AuthRoute: FC<Props> = ({ exact = false, path, children }) => {
  const user = useCurrentUser();
  return (
    <Route
      exact={exact}
      path={path}
      render={({ location }) =>
        user ? (
          children
        ) : (
          <Redirect to={{ pathname: '/login', state: { from: location } }} />
        )
      }
    />
  );
};

const App: FC = () => {
  const queryClient = useQueryClient();
  const { isLoading } = useGetUserQuery({
    retry: 0,
    initialData: undefined,
    onError: () => {
      queryClient.setQueryData('user', null);
    },
  });

  if (isLoading) {
    return <Loding />;
  }

  return (
    <Switch>
      <UnAuthRoute exact path="/login">
        <Login />
      </UnAuthRoute>
      <AuthRoute exact path="/">
        <Memo />
      </AuthRoute>
    </Switch>
  );
};

if (document.getElementById('app')) {
  ReactDOM.render(
    <Router>
      <QueryClientProvider client={client}>
        <CssBaseline />
        <App />
        {process.env.NODE_ENV === 'development' && (
          <ReactQueryDevtools initialIsOpen={false} />
        )}
      </QueryClientProvider>
    </Router>,
    document.getElementById('app')
  );
}

React Query のセットアップ

冒頭に書いた通り、まずQueryClientを作成。アプリをQueryClientProviderで囲み、そこに作成したクライアントを渡します。

const client = new QueryClient();

if (document.getElementById('app')) {
  ReactDOM.render(
    <Router>
      <QueryClientProvider client={client}>
        <CssBaseline />
        <App />
        {process.env.NODE_ENV === 'development' && (
          <ReactQueryDevtools initialIsOpen={false} />
        )}
      </QueryClientProvider>
    </Router>,
    document.getElementById('app')
  );
}

ログインユーザ情報の保持

まず最初にログインユーザを取得する処理を入れることで、永続化っぽいことをしています。このuseGetUserQueryフックはuseQueryをラップしたカスタムフックで、ログインユーザ情報が取得できた時は user キーの中へセットするようにしてあります（後述）

逆にログインユーザが取得できなかった場合はnullをセット。なお、最初の1回だけでいいので、リトライ回数は0に。

isLoadingを取得して、取得中の時は簡単なローディング画面を表示するようにしています。

const App: FC = () => {
  const queryClient = useQueryClient();
  const { isLoading } = useGetUserQuery({
    retry: 0,
    initialData: undefined,
    onError: () => {
      queryClient.setQueryData('user', null);
    },
  });

  if (isLoading) {
    return <Loding />;
  }

  return (
    <Switch>
      <UnAuthRoute exact path="/login">
        <Login />
      </UnAuthRoute>
      <AuthRoute exact path="/">
        <Memo />
      </AuthRoute>
    </Switch>
  );
};

認証ルートと非認証ルート

React Router が持っているRouteコンポーネントをラップしたコンポーネントをそれぞれ作成。この実装は React Router 公式の例を参考にしました。 <OG url="https://v5.reactrouter.com/web/example/auth-workflow" />

useCurrentUserフックは、キャッシュからログインユーザ情報を取得するカスタムフックです（後述）ログインユーザ情報の有無でリダイレクトするようにしています。

認証ルートの方でリダイレクト時に location を state にセットしているのは、フレンドリーフォワーディングのためです。

type Props = {
  exact?: boolean;
  path: string;
  children: React.ReactNode;
};

const UnAuthRoute: FC<Props> = ({ exact = false, path, children }) => {
  const user = useCurrentUser();
  return (
    <Route
      exact={exact}
      path={path}
      render={() => (user ? <Redirect to={{ pathname: '/' }} /> : children)}
    />
  );
};

const AuthRoute: FC<Props> = ({ exact = false, path, children }) => {
  const user = useCurrentUser();
  return (
    <Route
      exact={exact}
      path={path}
      render={({ location }) =>
        user ? (
          children
        ) : (
          <Redirect to={{ pathname: '/login', state: { from: location } }} />
        )
      }
    />
  );
};

ローディング画面

Presentational Component

画面中央にスピナーを出すだけのシンプルな画面です。

import React, { FC } from 'react';
import Box from '@material-ui/core/Box';
import CircularProgress from '@material-ui/core/CircularProgress';
import Container from '@material-ui/core/Container';

const Loding: FC = () => (
  <Container maxWidth="xs">
    <Box
      width={1}
      height="100vh"
      display="flex"
      alignItems="center"
      justifyContent="center"
    >
      <CircularProgress color="inherit" />
    </Box>
  </Container>
);

export default Loding;

ヘッダー

Container Component

useLogoutフックはuseMutationをラップしたカスタムフックです（後述）ログアウト処理を行う関数を実行するトリガー関数を受け取り、ログアウトボタン押下時の関数の中で実行しています。ログアウト処理が成功した場合はログイン画面へリダイレクトするようにしています。

import React, { FC, useCallback } from 'react';
import { useHistory } from 'react-router-dom';
import Header from '../../components/organisms/Header';
import { useLogout } from '../../hooks/auth';
import { useCurrentUser } from '../../hooks/user';

const EnhancedHeader: FC = () => {
  const user = useCurrentUser();

  const history = useHistory();
  const { mutate } = useLogout();

  const handleLogout = useCallback(() => {
    mutate(undefined, {
      onSuccess: () => {
        history.push('/login');
      },
    });
  }, [history, mutate]);

  return <Header userName={user?.name} handleLogout={handleLogout} />;
};

export default EnhancedHeader;

Presentational Component

ヘッダーにユーザ名表示とログアウトボタンを置くというと、メニューにすることが多いと思われますが、今回は横に並べて配置にしています。

import React, { FC } from 'react';
import AppBar from '@material-ui/core/AppBar';
import Button from '@material-ui/core/Button';
import Toolbar from '@material-ui/core/Toolbar';
import Typography from '@material-ui/core/Typography';
import useTheme from '@material-ui/core/styles/useTheme';

type Props = {
  userName?: string;
  handleLogout: VoidFunction;
};

const Header: FC<Props> = ({ userName, handleLogout }) => {
  const theme = useTheme();
  return (
    <>
      <AppBar
        position="sticky"
        style={{
          color: theme.palette.text.primary,
          backgroundColor: 'white',
        }}
      >
        <Toolbar>
          <Typography
            component="h1"
            variant="h6"
            style={{ flexGrow: 1 }}
            align="center"
          >
            OOUI-MEMO
          </Typography>
          {userName && (
            <>
              <Typography>{userName}</Typography>
              <Button type="button" onClick={handleLogout}>
                ログアウト
              </Button>
            </>
          )}
        </Toolbar>
      </AppBar>
    </>
  );
};

export default Header;

ログインアラート表示

定数

Laravel から返されるステータスコードを定数で定義しています。とりあえずこの2つだけ。

// バリデーションエラー
export const UNPROCESSABLE_ENTITY = 422;

// サーバエラー
export const INTERNAL_SERVER_ERROR = 500;

Presentational Component

ログイン画面において、ログイン失敗時に表示するアラートのコンポーネント。

import React, { FC } from 'react';
import Alert from '@material-ui/lab/Alert';
import AlertTitle from '@material-ui/lab/AlertTitle';
import {
  UNPROCESSABLE_ENTITY,
  INTERNAL_SERVER_ERROR,
} from '../../constants/statusCode';

type Props = {
  statusCode: number;
};

const LoginAlert: FC<Props> = ({ statusCode }) => (
  <>
    {statusCode === UNPROCESSABLE_ENTITY && (
      <Alert severity="error">
        <AlertTitle>認証失敗</AlertTitle>
        入力した情報に誤りがないかご確認ください。
      </Alert>
    )}
    {statusCode === INTERNAL_SERVER_ERROR && (
      <Alert severity="error">
        <AlertTitle>サーバエラー</AlertTitle>
        予期しないエラーが発生しました。恐れ入りますが時間をおいて再度お試しください。
      </Alert>
    )}
  </>
);

export default LoginAlert;

ちなみにこういうやつです。 <ImageWrapper className="w-[40%]" src="screenshots/2021/laravel-react-query-auth/login-alert.png" alt="ログイン画面でのアラート表示画像" />

ログイン画面

Container Component

useLoginフックはuseMutationをラップしたカスタムフックです（後述）ログイン処理を行う関数を実行するトリガー関数を受け取り、ログインボタン押下時の関数の中で実行しています。

フレンドリーフォワーディングにするため、location.state にセットされたものがあれば、ログイン時にその URL へリダイレクトするようにしています。

※2021/05/31 追記 from の型を string にしてしまっていますが、正しくはhistoryのLocationですね...。

import React, { FC, useState, useCallback } from 'react';
import { useHistory, useLocation } from 'react-router-dom';
import Login from '../../components/pages/Login';
import { useLogin } from '../../hooks/auth';

const EnhancedLogin: FC = () => {
  const history = useHistory();
  const location = useLocation();
  const { from } = (location.state as { from: string }) || {
    from: { pathname: '/' },
  };

  const { error, isLoading, mutate } = useLogin();
  const statusCode = error?.response?.status;

  const [email, setEmail] = useState('');
  const [password, serPassword] = useState('');

  const handleChangeEmail = useCallback(
    (ev: React.ChangeEvent<HTMLInputElement>) => {
      setEmail(ev.target.value);
    },
    []
  );

  const handleChangePassword = useCallback(
    (ev: React.ChangeEvent<HTMLInputElement>) => {
      serPassword(ev.target.value);
    },
    []
  );

  const handleLogin = useCallback(
    (ev: React.FormEvent<HTMLFormElement>) => {
      ev.preventDefault();
      if (!email || !password) {
        return;
      }
      mutate(
        { email, password },
        {
          onSuccess: () => {
            history.replace(from);
          },
        }
      );
    },
    [email, password, history, from, mutate]
  );

  return (
    <Login
      email={email}
      password={password}
      handleChangeEmail={handleChangeEmail}
      handleChangePassword={handleChangePassword}
      statusCode={statusCode}
      isLoading={isLoading}
      handleLogin={handleLogin}
    />
  );
};

export default EnhancedLogin;

Presentational Component

ログイン実行中に再度ボタンを押されないようにするため、isLoadingを使って、実行中はBackdropを表示するようにしています。（暗転してスピナークルクル表示の部分）

import React, { FC } from 'react';
import Backdrop from '@material-ui/core/Backdrop';
import Box from '@material-ui/core/Box';
import Button from '@material-ui/core/Button';
import CircularProgress from '@material-ui/core/CircularProgress';
import Container from '@material-ui/core/Container';
import Card from '@material-ui/core/Card';
import CardHeader from '@material-ui/core/CardHeader';
import CardContent from '@material-ui/core/CardContent';
import TextField from '@material-ui/core/TextField';
import useTheme from '@material-ui/core/styles/useTheme';
import Header from '../../containers/organisms/Header';
import LoginAlert from '../molecules/LoginAlert';

type Props = {
  email: string;
  password: string;
  handleChangeEmail: (ev: React.ChangeEvent<HTMLInputElement>) => void;
  handleChangePassword: (ev: React.ChangeEvent<HTMLInputElement>) => void;
  statusCode?: number;
  isLoading: boolean;
  handleLogin: (ev: React.FormEvent<HTMLFormElement>) => void;
};

const Login: FC<Props> = ({
  email,
  password,
  handleChangeEmail,
  handleChangePassword,
  statusCode,
  isLoading,
  handleLogin,
}) => {
  const theme = useTheme();
  return (
    <>
      <Header />
      <Container maxWidth="xs">
        <Card style={{ margin: `${theme.spacing(6)}px 0` }}>
          <CardHeader title="login" style={{ textAlign: 'center' }} />
          <CardContent>
            <form onSubmit={handleLogin}>
              <Box
                p={2}
                display="flex"
                flexDirection="column"
                alignItems="center"
              >
                {statusCode && <LoginAlert statusCode={statusCode} />}
                <TextField
                  label="メールアドレス"
                  variant="outlined"
                  fullWidth
                  value={email}
                  margin="normal"
                  required
                  autoComplete="email"
                  autoFocus
                  onChange={handleChangeEmail}
                />
                <TextField
                  type="password"
                  label="パスワード"
                  variant="outlined"
                  fullWidth
                  value={password}
                  margin="normal"
                  required
                  autoComplete="current-password"
                  onChange={handleChangePassword}
                />
                <Box my={2}>
                  <Button type="submit" color="primary" variant="contained">
                    ログイン
                  </Button>
                </Box>
              </Box>
            </form>
          </CardContent>
        </Card>
      </Container>
      <Backdrop style={{ zIndex: theme.zIndex.drawer + 1 }} open={isLoading}>
        <CircularProgress color="inherit" />
      </Backdrop>
    </>
  );
};

export default Login;

メモ（アプリホーム）画面

Container Component

まだ未実装なので特に処理はないです。

import React, { FC } from 'react';
import Memo from '../../components/pages/Memo';

const EnhancedMemo: FC = () => <Memo />;

export default EnhancedMemo;

Presentational Component

アプリのホーム画面になるわけですが、まだ未実装なので、とりあえず Memo とだけ表示するようにしています。

import React, { FC } from 'react';
import Box from '@material-ui/core/Box';
import Container from '@material-ui/core/Container';
import Header from '../../containers/organisms/Header';

const Memo: FC = () => (
  <>
    <Header />
    <Container>
      <Box m={4}>Memo</Box>
    </Container>
  </>
);

export default Memo;

User モデル定義

name だけのシンプルな型定義です。

export type User = {
  name: string;
};

認証に関するカスタムフック

useLogin

useMutationをラップした、ログイン処理を行うためのカスタムフック。成功時は、返却されたログインユーザ情報を user キーにセット。

import { useQueryClient, UseMutationResult, useMutation } from 'react-query';
import axios, { AxiosError } from 'axios';
import { User } from '../../models/User';

type FormData = {
  email: string;
  password: string;
};

const login = async (formData: FormData): Promise<User> => {
  const { data } = await axios.post('/api/login', formData);
  return data;
};

const useLogin = (): UseMutationResult<
  User,
  AxiosError,
  FormData,
  undefined
> => {
  const queryClient = useQueryClient();

  return useMutation(login, {
    onSuccess: (data) => {
      queryClient.setQueryData('user', data);
    },
  });
};

export default useLogin;

useLogout

useMutationをラップした、ログアウト処理を行うためのカスタムフック。成功時は、user キーのキャッシュをリセット。

※2021/04/13 追記ログアウト API のレスポンスで何も返さない場合は、logout 関数でも何も返さず void 型にした方がいいかもです。

import { useQueryClient, UseMutationResult, useMutation } from 'react-query';
import axios, { AxiosError } from 'axios';

const logout = async (): Promise<[]> => {
  const { data } = await axios.post('/api/logout');
  return data;
};

const useLogout = (): UseMutationResult<[], AxiosError, void, undefined> => {
  const queryClient = useQueryClient();

  return useMutation(logout, {
    onSuccess: () => {
      queryClient.resetQueries('user');
    },
  });
};

export default useLogout;

名前付きエクスポート

使いやすいように、再度エクスポートしてます。

export { default as useLogin } from './useLogin';
export { default as useLogout } from './useLogout';

ユーザに関するカスタムフック

useGetUserQuery

useQueryをラップした、ログインユーザ情報取得処理を行うカスタムフック。

※2021/04/13 追記 useGetUserQuery の返り値の型は UseQueryResult ですね...（中身的には一緒だったりするんですが）

import { QueryObserverResult, useQuery, UseQueryOptions } from 'react-query';
import axios, { AxiosError } from 'axios';
import { User } from '../../models/User';

const getLoginUser = async (): Promise<User> => {
  const { data } = await axios.get('/api/users/me');
  return data;
};

const useGetUserQuery = <TData = User>(
  options?: UseQueryOptions<User, AxiosError, TData>
): QueryObserverResult<TData, AxiosError> =>
  useQuery('user', getLoginUser, options);

export default useGetUserQuery;

useCurrentUser

キャッシュからログインユーザ情報を取得するカスタムフック。いろんなところで使用するのでカスタムフック化してます。

import { useQueryClient } from 'react-query';
import { User } from '../../models/User';

// ログイン：User  非ログイン時：null  デフォルト：undefined
const useCurrentUser = (): User | null | undefined => {
  const queryClient = useQueryClient();
  return queryClient.getQueryData('user');
};

export default useCurrentUser;

名前付きエクスポート

使いやすいように、再度エクスポートしてます。改行してるのは、なんとなく API リクエストとそれ以外とでわかりやすくしたかったので。

export { default as useGetUserQuery } from './useGetUserQuery';

export { default as useCurrentUser } from './useCurrentUser';

ものすごく長くなってしまいましたが、今回はこんな感じで実装してみました。

特に React 側に関しては、なるべくきれいに書けるようになりたいという思いもあり、りあクト！のコードを参考にしながら、コード分割をしていきました。試行錯誤しながらやっていったので、時間もかかってコミット数も無駄に多いです🙄

TypeScript に関しては、まだ使い始めたばかりなので慣れてないのですが、型定義がきれいにハマった時の入力補完が便利でやばいですね(笑) 引き続き向き合っていきます。

課題として.

React.Suspense を使って宣言的に書く
CSRF トークンの期限が切れたときの対応をいれる
React QUery のオプションの調整

とか、まだできそうなことはあるので、そのへんはおいおいやっていこうかとー。

この実装が何かの参考になれば幸いです。

参考リンクまとめ

2020年振り返り～技術活動、ブログ編～

Mon, 21 Dec 2020 16:00:00 GMT

{/*  */}

いよいよ今年が終わりますね。どうも、よしです。先日は精神疾患、体調に関する振り返りを行いましたが、今回は技術活動周りに関する振り返りをやっていきますー。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

2020年の活動履歴

コミット履歴

昨年と同様、まずは Git の Contributions を見ていきます。

個人 - GitHub

こうして見ると割とまばらですね(笑) 昨年から始めた TIL 活動は正直あまりできていなかったかなと。それでも900を越えるくらいになってます。昨年は230程度でしたので、まぁそれと比べれば活動できたとも言えるかもしれません。

土日活動が少し多いなか、5月と9月が比較的多めなのは、web1week というハッカソンイベントに参加していたからです。それぞれの作品自体は小規模なものでしたが、期間中はゴリゴリと開発やってました。こういったイベントに参加したのは初めてでしたが、楽しかったですし、参加してよかったです。

レポート記事.

あ、でも、5月に関しては仕事が休業中で時間があったので勉強していたというのもありますね。

8/8に226とかあるのは、当ブログのリポジトリを GitLab から GitHub へ一気に移行したからです。ちなみにその移行時に使用したスクリプトツールに対して、プルリクを送って、無事にマージされるという経験をしました。漏れている型定義を追加しただけなので、その内容自体は大したことないのですが、ちょっとした OSS 活動みたいでやってよかったなと。

仕事 - GitHub

<ImageWrapper src="screenshots/2020/looking-back-2020-tech/github-contributions-work.png" alt="GitHubの仕事アカウントのcontributions履歴" /> ※10月の退職にあたって、アカウントを削除する前に撮っておいたものです。

3月までの案件では、割とゴリゴリと開発をやっていたので活動多めです。 4月からやっていた案件は保守案件であったため、控えめの活動になっています。

また、5月は休業となったため活動がありません。

個人 - GitLab

元々、当ブログのリポジトリは GitLab で管理していたため、GitHub に移行した8月までは活動がありました。ただ、移行に伴い GitLab でのリポジトリは削除し、 Contributions から消えたのでスクショは撮っていません。

今後は GitHub をメインで使用していくので、使わなくなっていくと思います。

ブログ

2020年のブログ履歴はこんな感じでした。昨年と同様に Google Analytics のデータ部分のみ抜粋しています。（12月に関しては、執筆時点でのものです）

月	記事数	月のアクセスユーザ数	月のページビュー数
1月	36	287	502
2月	38	317	442
3月	41	568	867
4月	44	1,095	1,583
5月	47	430	640
6月	49	397	549
7月	49	586	787
8月	51	518	766
9月	53	501	709
10月	53	591	859
11月	55	434	623
12月	57	998	1,343

アクセスユーザ数計：6,722
ページビュー数計：9,670

昨年は一年集計しても、ユーザ数 711、ページビュー数 1,318 でしたので、悠々とそれを越えました。

4月になんか一気に伸びてましたが、5月の Google コアアルゴリズムアップデートをもろに被弾してしまったようで、一気にアクセスが落ちました。とはいえ、自分は別にブロガーというわけではないので、そこまで気にせず。

それから少しずつアクセスが戻っていってる感じでしょうか。 12月の Google コアアルゴリズムアップデートに関しては、いい影響をうけられたみたいです。

月に最低1記事は書くという目標が達成できなかったですが、書けなかった月はちょうど不調の時期でもあったので、まぁしょうがないかなと。書いてる月は2記事以上書けていたので、1年で12記事という意味では達成できてますし。

ブログ以外の技術記事活動

※Zenn および Qiita に投稿した記事は、すべて当ブログでも投稿しています。

これまで、ブログ + Qiita で活動してきましたが、今年の9月に Zenn がリリースされたことにより、以降は Zenn + ブログで活動していくことにしました。 Qiita からの移行にあたって、React 関連の記事をいくつか Zenn にも転載しています。 Zenn は GitHub と連携して、コンテンツ管理できるのでいいですね（自分はプライベートリポジトリで管理してます）

web1week に参加した時は、イベント自体が Crieit 発のものであるため、その参加レポート記事を Crieit に投稿しました。こういった参加レポート記事は、いつもよりも自分の言葉そのままで書ける感じがして、書いていてちょっと楽しかったですね。

※2024/09/14追記：Crieit はサービスクローズされました。

2021年はどうしていきたいか

※前回の体調編の振り返り記事と同じようなことを言っている部分もありますが、ご容赦ください。

個人勉強

今年も TIL 活動を継続しようとして、年始に Docusaurus でサイト化したのはよかったものの、あまり活動できていなかったなと。最低限、毎月ポートフォリオページを更新することくらいは、さすがにやってはいたのですが。なので来年はざっくりとでも、勉強・TIL 活動のペースを作るかなぁとか考えてます。

まぁ、まずは社会復帰するところからですし、他にちゃんと趣味の時間も作りたいと思っているので、自分の調子を見ながら試行錯誤していく感じになるかと。

「フロントエンドとバックエンドで1つずつ自分の技術の軸になるものがほしい」なんて、昨年の振り返りの時は書いていました。 ...が、今の自分のスキルを考えると結局中途半端でなんだか嫌になってくるので、まずはフロントエンドかバックエンド、どちらかを専門とした方がいいかなと思うようになり。

経験3年もあって、〇〇エンジニアと名乗れないレベルってどうなのよ？という。 React 周りを勉強して、もっと伸ばしたい欲があるので、フロントエンドをメインにしていこうかなぁとぼんやり思っています。 TypeScript とか Next.js とか習得したかったのに、全然できてないので、そこらへんとか。そのうえで、バックエンドとか他の分野のことも少しわかるよみたいな。

それと個人開発してたら、一応は一通り体験するわけですし、個人開発も何かしらやりたいですね。 web1week みたいなハッカソンイベントにまた参加したり、OOUI ワークアウト実践（設計するなら実際に作ってみよう企画）をやったりしようかなとか。

仕事

まずは新しい会社を探すところからですね。会社を退職してから、最低でも年内は療養にあてるということで過ごしてきましたが、もう少し充電・勉強期間が欲しいかなという思いもあり。とはいえ、無収入が続くのはつらいので、さすがに春先くらいまでには決めたいところです。

できれば精神疾患に理解のある会社さんに巡り合いたいですね。新しい会社を探すにあたって、精神疾患のことは不利に働く可能性が高いと思っていますが、自分はオープンにして活動するつもりです。オープンにしておいた方が、後から無用のトラブルになるのを避けられると思うからです。

精神疾患に理解がある = 手厚く配慮してほしいというわけではないです。もちろんサポートが得られるのであれば、それがいいのは確かにそうなんですが、それって別に精神疾患の人に限ったことじゃないよね？って。普通にチームメンバー間でサポートしあったりすると思いますし、そういう環境であれば仕事しやすいんじゃないかなぁと。

ブログ・技術記事

来年も、1か月に最低1記事のペースでゆるりとやるつもりです。今年、会社の中での目標として記事を月に2記事書くなんて決めたこともあったのですが、「書かないといけない」みたいな意識になってしまった結果捗りませんでした。なので、ゆるりとやった方が自分には合っているようです。

Zenn にはまだ新しい記事を投稿できていないですし、来年は Zenn + ブログで記事投稿していきます。

また、構想として、ブログを Next.js 製に移行しようかなと考えていたりもします。 React 周りを勉強するにあたって、TypeScript や Next.js なども習得することになるので、なんとなく使用技術スタックを狭めたいという思いがあり。

執筆時点の Jekyll 製でも特に困ったことはないので、まぁ気が向いたらやるかもしれません。

緩やかな目標の中で過ごしてきた2020年。達成できなかった目標もありましたが、総合してみれば、まぁそれなりに頑張った方かなと思うことにします。前年より活動できていれば、まぁいいかっていう。

昨年の振り返りの時期には、まさか会社を退職することまでになるとは考えてもいなかったですが、人生何が起こるかわからないですからね。起きてしまったことはしょうがないので、また地道に人生の軌道修正をしていこうと思います。この機会に今後の立ち回り方とか、改めて考えてみるのも楽しそうですね。

2021年の振り返りの頃には、いろんな意味で自立できているといいなぁ。

ではでは、皆様、よいお年をお迎えくださいー。

{/*  */}

GitリポジトリをGitLabからGitHubへ移行する

Thu, 13 Aug 2020 00:00:00 GMT

当ブログのソースコードは GitLab で管理していたのですが、普段 GitHub の方を使用することがほとんどなので、先日 GitHub へ移行しました。ソースコードのほかに、Issue やマジリクなどの移行できたので、その手順を残しておきます。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

移行にあたって

ミラーリングで対応できるもの

ソースコード（+ コミット履歴）
ブランチ
タグ

これらはリポジトリのミラーリングを行うことで比較的すぐに移行できます。

これに加えて Wiki についても、Wiki データのミラーリングを行うことで対応できるようです。 ※今回は Wiki については試してません。

移行スクリプトで対応できるもの

以下のデータも移行したかったのですが、リポジトリのミラーリングでは対応していませんでした。

ラベル
マイルストーン
Issue
マジリク

しかし、有志の方がこれらのデータを移行するスクリプトを公開されていたので、今回はこちらを使わせていただきました。 <OG url="https://github.com/piceaTech/node-gitlab-2-github" />

移行スクリプトを使うための前提

Node.js 導入済み
npm か yarn コマンドが使えること

ちなみに移行元、移行先ともにプライベートリポジトリでも使用できました。

移行の仕様

移行スクリプトの 2020/08/08 時点での仕様です。

ラベル

GitHub のデフォルトのラベルに、移行したラベルが追加されます。色も同じっぽかったです。

また、gitlab merge requestというラベルも追加されます。このラベルは、マジリクを Issue 変換したものに付与されます。

マイルストーン

タイトルや対象範囲、open か close なのかなど、ほぼそのまま移行されます。

Issue

移行元 ※すみません、移行元のスクショは撮り忘れました...。

移行先 <ImageWrapper src="screenshots/2020/migrate-gitlab-to-github/convert-issue.png" alt="移行先のGitHub Issue詳細画面" />

{/*  */}

タイトルやコメント、open なのか close なのかなど、ほぼそのまま移行されます。ただ、その作成日時は移行実施した日時になるため、コメントにIn GitLab by @h-yoshikawa0724 on Jun 28, 2020, 18:14のような、移行元での情報が記載されるようになっています。

画像アップロード内容まで移行されるかは未確認ですが、S3にアップロードするような設定もあるようです。

また、何らかの原因で Issue 移行（移行先リポジトリに Issue 作成）に失敗することがありますが、その救済設定（useReplacementIssuesForCreationFails）がデフォルトで有効になっています。（移行スクリプトの設定も参照）

{/*  */}

自分の場合は、最初の頃、少し手伝ってもらっていた先輩が作ったIssue が移行時にエラーとなっていました。移行元と移行先ともにプライベートリポジトリであったこと、今は移行元リポジトリからも抜けていて、移行先リポジトリにいなかったことが、恐らくエラーの原因じゃないかと思われます。

この設定が有効になっていると、以下のような代替 Issue が作成されます。移行元の Issue の説明が失われてしまいますが、その他の情報は引き継がれるようです。 <ImageWrapper src="screenshots/2020/migrate-gitlab-to-github/convert-replacement-issue.png" alt="移行先のGitHub （代替）Issue詳細画面" />

マジリク

そのマジリクの状態に応じて、挙動が変わります。

Open → プルリク（Open）に移行される？（今回、この状態のマジリクがなかったので未確認）
Closed → プルリク（Closed）に移行される
Merged + ブランチ削除済み → Issue（Closed）に変換される（gitlab merge requestのラベルがつく）
Merged + ブランチあり → エラーで変換されない

{/*  */}

こちらについても作成日時は移行実施した日時になるため、コメントにIn GitLab by @h-yoshikawa0724 on Jun 28, 2020, 18:14のような、移行元での情報が記載されます。

{/*  */}

注意点としては、マージ済みの際の挙動でしょうか。 3については以下のような感じです。

移行元 <ImageWrapper src="screenshots/2020/migrate-gitlab-to-github/convert-merge-request-to-issue-before.png" alt="移行元のGitLab マージ済みマジリク一覧画面" />

移行先 <ImageWrapper src="screenshots/2020/migrate-gitlab-to-github/convert-merge-request-to-issue-after.png" alt="移行先のGitHub 変換されたクローズ済みIssue一覧画面" />

4については、マージ元のブランチはあるが、マージ先との差分がないためにエラーとなってしまうようです。何も移行されない問題がありますが、移行スクリプトの設定（useIssuesForAllMergeRequests）により、強制的に3と同じ挙動にすることで対応可能です。（移行スクリプトの設定も参照）

使用上限

README - import-limit に注意書きがあります。

この移行スクリプトでは、内部的に GitHub API を使用しています。この GitHub API では、1時間あたり5000 API リクエストという制限があるため、移行内容が多いリポジトリだと上限に引っ掛かる可能性があることに注意です。

リポジトリ移行手順

前置きが長くなってしまいましたが、ここから実際の手順になります。

リポジトリの用意とミラーリング

※補足

移行元 - GitLabリポジトリ：h-yoshikawa0724/changeofpace
移行先 - GitHubリポジトリ：h-yoshikawa0724/change-of-pace

として書いていっているので、適宜ご自分のリポジトリ情報に置き換えてください。

GitHub で移行先リポジトリを用意（作成するだけで OK）
移行元のベアリポジトリをクローン

git clone --mirror git@gitlab.com:h-yoshikawa0724/changeofpace.git

移行元のベアリポジトリを、移行先に反映

cd changeofpace.git

git push --no-verify --mirror git@github.com:h-yoshikawa0724/change-of-pace.git

この時点で、コード（コミット履歴）、ブランチ、タグは移行完了です。

なお、ベアリポジトリというのは作業ディレクトリを持たず、操作履歴などの情報のみを持つリポジトリのことを指すそうです。末尾に.gitとつくのも特徴で、実際に配下ディレクトリを見ると以下のようになっていました。

ls changeofpace.git/

config  description  HEAD  hooks/  info/  objects/  packed-refs  refs/

アクセストークンの用意

GitLab

プロフィールアイコンのSettings → Access Tokens. から。 apiとread_repositoryの scope を持ったトークンを生成し、その値を控えておきます。

GitHub

プロフィールアイコンのSettings → Developer settings → Personal access tokens. から。「Generate new token」を押すと、アカウントのパスワード入力を求められるので入力。 repoの scope を持ったトークンを生成し、その値を控えておきます。

移行スクリプトの用意

移行スクリプトのダウンロード

git clone https://github.com/piceaTech/node-gitlab-2-github.git

ライブラリのインストール

cd node-gitlab-2-github

npm -i
# or
yarn install

移行スクリプトの設定

設定ファイルの用意

src/settings.tsに以下を追記（useReplacementIssuesForCreationFails: boolean;の下にでも）

useIssuesForAllMergeRequests: boolean;

※最近追加された設定の型定義が漏れていたようです。これがないとスクリプトが動きません。ただ、自分がこの修正のプルリクを出したので、マージされるなり対応されたら、この手順は不要になります。 → 2020/09/01追記 無事マージされました！

sample_settings.tsをsettings.tsにリネームして、設定を編集自分の場合の例.

import Settings from './src/settings';

export default {
  gitlab: {
    // url: 'https://gitlab.mycompany.com' // 公式でなく独自にホスティングしている場合のみ、その URL
    token: 'XXXXXXXXXXXXX', // 先ほど控えたトークン
    projectId: 'XXXXXXX', // 後述参考
  },
  github: {
    // baseUrl: 'https://gitlab.mycompany.com:123/etc', // 公式でなく独自にホスティングしている場合のみ、その URL
    owner: 'h-yoshikawa0724', // 移行先リポジトリのオーナーアカウント ID
    token: 'XXXXXXXXXXXXX', // 先ほど控えたトークン
    repo: 'change-of-pace', // 移行先リポジトリ名
  },
  usermap: {
    'h-yoshikawa0724': 'h-yoshikawa0724', // GitLab アカウントID: GitHub アカウント ID のマッピング（移行時にこれに応じて変換される）
  },
  projectmap: {
    'h-yoshikawa0724/changeofpace': 'h-yoshikawa0724/change-of-pace', // GitLab リポジトリ名: GitHub リポジトリ名
  },
  conversion: {
    useLowerCaseLabels: true,
  },
  debug: false, // デバッグ実行するかどうか
  usePlaceholderIssuesForMissingIssues: true, // 削除されたIssue があった時などに、移行元と移行先とでその分 Issue 番号がずれるを防ぐために空の Issue を作成するか
  useReplacementIssuesForCreationFails: true, // 何らかの原因で Issue 移行に失敗した際に、代替 Issue を作成するか（移行元の説明は失われるが、それ以外は引き継がれる）
  useIssuesForAllMergeRequests: true, // 強制的に全ての移行元マジリクを移行先 Issue に変換するか
  skipMatchingComments: [], // コメント移行をスキップするワード設定（このワードを含むコメントは移行されない、ワードの大文字小文字は区別しない）
  mergeRequests: {
    logFile: './merge-requests.json',
    log: false, // 移行元マジリクを logFile に出力するかどうか（出力する場合は移行先へ移行されない）
  },
} as Settings;

設定の詳細や他の設定が知りたい場合は、README - Where to find info for the settings.ts に説明が記載されています。

プロジェクト ID の確認方法

GitLab のリポジトリトップ画面に表示されているので、そこで確認できます。

もしくは、一度projectIdをnullにした状態で、このスクリプトを実行すると確認できます。他の設定が問題なければ、リポジトリの一覧が表示されて、そこへプロジェクト ID が表示されるようになっています。

yarn start

yarn run v1.22.4
node node_modules/ts-node/dist/bin.js ./src/index.ts
XXXXXXX          change-of-pace         --



Select which project ID should be transported to github. Edit the settings.js accordingly. (gitlab.projectID)



Done in 14.89s.

移行スクリプトの実行

npm run start
# or
yarn start

これで移行が開始されます。当然、移行内容の量が多いほど時間がかかるので気長に待ちましょう。

Transfer complete!

と表示されたら移行完了です。ちゃんと移行されているか確認してみましょう。

ちなみに自分の場合は、設定の関係上2回実行することになったのですが、基本的には前回の移行で作成された分と重複して移行（作成）されるということはないようです。

ログ出力を見た感じ、ラベルやマイルストーンは「既に存在しています」 Issue やプルリクは「更新しました」みたいな英語が表示されていたような気がします。

{/*  */}

ただ、useReplacementIssuesForCreationFails設定により作られた代替 Issue（Issue タイトル末尾に[REPLACEMENT ISSUE]がついているもの）に関しては、既に存在すると認識されないようで、重複して作られてしまいました。

{/*  */}

その他の設定移行

必要に応じて、その他の設定も移行しましょう。自分の場合は、移行元リポジトリと Netlify を連携させていたので、移行先リポジトリで連携しなおしました。

Netlify

Settings → Build & Deploy → Continuous Deployment → Build settings → 「Edit settings」から、連携するリポジトリ更新。

後処理

これもまた必要に応じて行いましょう。

旧 GitLab リポジトリの削除
ミラーリング時にローカルへ作った、ベアリポジトリの削除
今回移行したプロジェクトのローカルリポジトリのリモートURLを、移行先リポジトリの方に設定
アクセストークンを削除

今回、特に大きな問題もなくリポジトリの移行ができて安心しました。

この移行スクリプトを作成された方に感謝ですね！使い方をちゃんと理解したうえで使用すれば、とても便利なスクリプトなので、移行を考えられている方はぜひ使ってみてはいかがでしょうか。

ではでは。

参考リンクまとめ

React(SPA)アプリをFirebase Hostingにデプロイ

Sat, 06 Jun 2020 00:00:00 GMT

先日、初めて Firebase を使ってデプロイする機会がありました。基本的には案内に沿って進めるだけでしたが、せっかくなので手順をメモしておきます。

※この記事は元々 Qiita からの転載です。現在は Qiita でなく Zenn の方で更新しています。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

前提

デプロイする React アプリがすでにある
npm or yarn が使える環境である（自分は yarn を使用しているので、以降 yarn で書いていきます）

Firebase 側

新規登録・プロジェクト作成

Firebase へアクセス
「使ってみる」「プロジェクトを作成」を選択 <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase.png" alt="Firebase トップ画面" />
プロジェクトの作成
- プロジェクト名を入力 + 利用規約にチェックして「続行」 <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase-project-name.png" alt="Firebaseプロジェクトプロジェクト名入力画面" />
- Google Analytics を有効にして「続行」（※今回は有効にしていますが任意） <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase-ga.png" alt="Firebaseプロジェクト Google Analytics設定画面" />
- 連携する Google Analytics アカウントを選択（もしくは新規作成）して「プロジェクトを作成」 <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase-ga-account.png" alt="Firebaseプロジェクト Google Analytics連携設定画面" />

少し時間がかかりますが、これでプロジェクトが作成されます。

アプリを追加

プロジェクトトップから、追加するアプリのプラットフォームの中から「ウェブ」を選択 <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase-project-top.png" alt="Firebaseプロジェクトトップ画面" />
ウェブアプリに Firebase を追加
- アプリのニックネームを入力 + Firebase Hosting 設定を有効化して「アプリを登録」 <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase-app-add.png" alt="Firebaseアプリ追加基本設定画面" />
- Firebase SDK を予約済み URL から使用する場合は、スクリプトを控えておき「次へ」（※予約済み URL についてはこちらも参照） <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase-app-sdk.png" alt="Firebaseアプリ追加 SDKスクリプト案内画面" />
- Firebase CLI のインストール方法を確認して「次へ」 <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase-app-cli-install.png" alt="Firebaseアプリ追加 CLIインストール案内画面" />
- Firebase Hosting へのデプロイ方法を確認して「コンソールに進む」 <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase-app-hosting-deploy.png" alt="Firebaseアプリ追加デプロイ案内画面" />

これで Firebase プロジェクトにウェブアプリが追加されました。

React アプリ側

基本的には、Firebase プロジェクトにアプリを追加した時に表示された手順で進めていきます。

Firebase SDK の導入

Firebase SDK を導入する方法としては、以下の3つがあり。

予約済み URL にあるものを読み込み使用する
CDN で配信されているものを読み込み使用する
ライブラリとしてインストールし使用する

Firebase SDK Snippet に関しては Firebase プロジェクトの「設定」「プロジェクトを設定」のマイアプリから確認できます。

補足として、予約済み URL というのは Firebase Hosting での URL のことを指します。その URL 配下に SDK およびアプリの識別情報のファイルが配置されるようになっており、それを読み込んで SDK を使用する形になります。そのため、この方法は Firebase Hosting を使ってホスティングする場合のみ、使用可能です。主に同じコードを複数の Firebase Hosting へデプロイする際に便利な方法のようです。

自分も最初は予約済み URL での方法にしていましたが、yarn startでの通常のローカルサーバからは SDK を読み込むことができないために、Warning が出てしまいます。これが気になりやめました。

※2020/10/18追記 firebase serveによるエミュレートであれば、予約済み URL 経由の SDK 使用が可能のようです。ただ、こちらの場合は、あくまでビルド生成物ディレクトリの中身をローカルでホスティングしているものです。そのため、デプロイ前のテストに使うような感じで、ホットリロードで動作を見ながら開発という用途には向いていません。

今回はライブラリとしてインストールして使用する方法で進めます。

ライブラリのインストール

yarn add firebase

`.env`を作成

設定値は Firebase SDK Snippet の「構成」から確認できます。 <ImageWrapper className="w-[80%]" src="screenshots/2020/react-firebase-deploy/firebase-sdk.png" alt="Firebase SDK Snippet 構成情報画面" />

.envの例.

# Firebase
REACT_APP_APP_KEY=※apikey
REACT_APP_AUTH_DOMAIN=※authDomain
REACT_APP_DATABASE_URL=※databaseURL
REACT_APP_PROJECT_ID=※projectId
REACT_APP_STORAGEBUCKET=※storageBucket
REACT_APP_MESSAGING_SENDER_ID=※messagingSenderId
REACT_APP_APP_ID=※appId
REACT_APP_MEASUREMENT_ID=※measurementId

Firebase SDK の初期化を行うファイルを作成

各種 Firebase の機能を使うには最初に初期化処理を行う必要があります。そのため、初期化処理をするファイルをあらかじめ用意しておき、機能を使う際、 import するようにします。

例.

import firebase from 'firebase/app';
import 'firebase/analytics';

const config = {
  apiKey: process.env.REACT_APP_APP_KEY,
  authDomain: process.env.REACT_APP_AUTH_DOMAIN,
  databaseURL: process.env.REACT_APP_DATABASE_URL,
  projectId: process.env.REACT_APP_PROJECT_ID,
  storageBucket: process.env.REACT_APP_STORAGEBUCKET,
  messagingSenderId: process.env.REACT_APP_MESSAGING_SENDER_ID,
  appId: process.env.REACT_APP_APP_ID,
  measurementId: process.env.REACT_APP_MEASUREMENT_ID,
};

firebase.initializeApp(config);

export default firebase;

Google Analyticsにデータ送信する設定を追記

自分の場合はindex.jsに追記しました。最初は、SDK 組み込みだけで自動的にデータ送信してくれるものと思っていましたが、firebase.analytics()をやらないといけないようです。

以下の内容をReactDOM.renderの上に追記。

import firebase from './libs/Firebase';

// 本番環境のみ計測
if (process.env.NODE_ENV === 'production') {
  firebase.analytics();
}
.
.
.

Firebase プロジェクトのアプリとの連携

Firebase CLI の導入

yarn global add firebase-tools

これで firebase コマンドが使えるようになります。

firebase へログイン

もし Docker の Node.js 環境を使用している場合は、OAuth 認証で9005ポートを使用するので事前に開けておきましょう。

firebase login

Firebase optionally collects CLI usage and error reporting information to help improve our products. Data is collected in accordance with Google's privacy policy (https://policies.google.com/privacy) and is not used to identify you.

? Allow Firebase to collect CLI usage and error reporting information? (Y/n)

Firebase はオプションで、CLI の使用状況とエラー報告情報を収集して、製品の改善に役立てます。データは Google のプライバシーポリシー（ https://policies.google.com/privacy ）に従って収集され、ユーザーの特定には使用されません。

Firebase が CLI の使用状況とエラー報告情報を収集することを許可しますか？（はい/いいえ）

任意で回答。

To change your data collection preference at any time, run `firebase logout` and log in again.

データ収集の設定をいつでも変更するには、 firebase logoutを実行して、再度ログインします。

Visit this URL on this device to log in:
https://accounts.google.com/o/oauth2/auth?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Waiting for authentication...

認証のための URL が表示されるので、ブラウザでアクセス（Docker を使用しない場合は、恐らく自動でブラウザが開きます）

内容を確認して「許可」 <ImageWrapper className="w-[60%]" src="screenshots/2020/react-firebase-deploy/firebase-oauth.png" alt="Firebase Googleアカウント認証確認画面" />

✔  Success! Logged in as XXX@gmail.com

無事に認証できると CLI 側はこの表示が出ます。また、ブラウザ側では以下のような表示が出ます。 <ImageWrapper className="w-[60%]" src="screenshots/2020/react-firebase-deploy/firebase-oauth-complete.png" alt="Firebase認証完了画面" />

連携・初期化処理

firebase init

? Which Firebase CLI features do you want to set up for this folder? Press Space to select features, then Enter to confirm your choices. (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◯ Database: Deploy Firebase Realtime Database Rules
 ◯ Firestore: Deploy rules and create indexes for Firestore
 ◯ Functions: Configure and deploy Cloud Functions
 ◯ Hosting: Configure and deploy Firebase Hosting sites
 ◯ Storage: Deploy Cloud Storage security rules
 ◯ Emulators: Set up local emulators for Firebase features

このフォルダに設定する Firebase CLI 機能はどれですか？スペースを押して機能を選択し、Enter を押して選択を確認します。（スペースを押して選択、a を押してすべてを切り替え、i を押して選択を反転します）

今回はHostingのみ選択。

First, let's associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add,
but for now we'll just set up a default project.

? Please select an option: (Use arrow keys)
❯ Use an existing project
  Create a new project
  Add Firebase to an existing Google Cloud Platform project
  Don't set up a default project

{/*  */}

まず、このプロジェクトディレクトリを Firebase プロジェクトに関連付けます。複数のプロジェクトエイリアスを作成するには、firebase use --add, ただし、ここではデフォルトのプロジェクトを設定します。

{/*  */}

今回はすでに Firebase プロジェクトを作っているのでUse an existing projectを選択。

? Select a default Firebase project for this directory: (Use arrow keys)
❯ project-name (project-name)

このディレクトリのデフォルトの Firebase プロジェクトを選択：（矢印キーを使用）

連携させるプロジェクトを選択。

Your public directory is the folder (relative to your project directory) that
will contain Hosting assets to be uploaded with firebase deploy. If you
have a build process for your assets, use your build's output directory.

? What do you want to use as your public directory? (public)

パブリックディレクトリは、プロジェクトディレクトリを基準にしたフォルダです。 firebase deploy でアップロードされるホスティングアセットが含まれます。もし、あなたがアセットのビルドプロセスがある場合は、ビルドの出力ディレクトリを使用します。

yarn buildでの生成物は/buildに作成されるので、buildと入力。

? Configure as a single-page app (rewrite all urls to /index.html)? (y/N)

SPA アプリとして構成しますか（すべての URL を /index.html に書き換えます）？（はい/いいえ）

今回は SPA なのでyを入力。

✔  Wrote build/index.html

i  Writing configuration info to firebase.json...
i  Writing project information to .firebaserc...

✔  Firebase initialization complete!

これで設定ファイルが作成されて、連携は完了です。

Firebase Hosting へデプロイ

ビルドして、その生成物をデプロイします。

yarn build

# 全ての Firebase サービスリソースをデプロイ
firebase deploy

# Hosting のリソースのみデプロイ + コメント
firebase deploy --only hosting -m "※任意のコメント"

※2021/09/05追記デプロイ時にコメントをつけておくと、Firebase Hosting のデプロイ履歴にも表示されるのでわかりやすくなります。

=== Deploying to 'project-name'...

i  deploying hosting
i  hosting[project-name]: beginning deploy...
i  hosting[project-name]: found 19 files in build
✔  hosting[project-name]: file upload complete
i  hosting[project-name]: finalizing version...
✔  hosting[project-name]: version finalized
i  hosting[project-name]: releasing new version...
✔  hosting[project-name]: release complete

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/project-name/overview
Hosting URL: https://project-name.web.app

表示されるホスティング URL にアクセスして、アプリの内容がちゃんと表示されれば、無事デプロイ完了です。

おまけ・GitHub Actions での自動デプロイ

※2021/09/05追記.

CI 用トークンの取得

Firebase CLI を使うためにブラウザでログインが必要になりましたが、CI 環境ではそういうわけにもいかないのでトークンを使用する方法が提供されています。

まずはローカルで以下コマンドを実行してログインし、CI 環境用のトークンを取得。

firebase login:ci

後はこのトークンを Firebase CLI 使用時にオプションで渡すようにすれば OK です。 GitHub Secrets にFIREBASE_TOKENと登録しておいて、そこから使うようにします。

ビルド

※Node.js のセットアップやライブラリのインストールのステップ部分については、当記事では省略します。

今回は、Firebase アプリの情報を環境変数で管理しているので、CI 環境でも環境変数を設定。 GitHub Secrets にあらかじめ登録しておき、その値で設定する例です。

# ビルド
- name: Build
  env:
    REACT_APP_APP_KEY: ${{ secrets.REACT_APP_APP_KEY }}
    REACT_APP_AUTH_DOMAIN: ${{ secrets.REACT_APP_AUTH_DOMAIN }}
    REACT_APP_DATABASE_URL: ${{ secrets.REACT_APP_DATABASE_URL }}
    REACT_APP_PROJECT_ID: ${{ secrets.REACT_APP_PROJECT_ID }}
    REACT_APP_STORAGEBUCKET: ${{ secrets.REACT_APP_STORAGEBUCKET }}
    REACT_APP_MESSAGING_SENDER_ID: ${{ secrets.REACT_APP_MESSAGING_SENDER_ID }}
    REACT_APP_APP_ID: ${{ secrets.REACT_APP_APP_ID }}
    REACT_APP_MEASUREMENT_ID: ${{ secrets.REACT_APP_MEASUREMENT_ID }}
  run: yarn build

デプロイ

Firebase CLI を使えるアクションがあるので、これを使うと楽にデプロイできます。

- name: Deploy to Firebase Hosting
  uses: w9jds/firebase-action@v2.0.0
  with:
    args: deploy --only hosting -m \"${{ github.event.head_commit.message }}\"
  env:
    FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}

2021/09/05 時点で最終リリースが 2020/11/09 というのが少し気になるところですが、比較的最近のコミット履歴はありましたので、このアクションを紹介してみました。

Firebase を初めて使いましたが、思っていた以上に簡単にデプロイ出来てよかったです。 React との相性もいいみたいですし、他の機能も使ってみたいなーと。可能性が広がりますね！

参考リンクまとめ

React×HOC環境を支援する、Recompose入門

Wed, 06 May 2020 00:00:00 GMT

今回は React Hooks が普及する前の話。主に関数コンポーネントに機能を付与することに使われる HOC を取り扱う Recompose についてです。

※この記事は元々 Qiita からの転載です。現在は Qiita でなく Zenn の方で更新しています。

※2022/01/24追記あくまでライブラリの記事であるとわかりやすくするために、記事タイトルを変更しました（旧：React入門～Recompose編～）

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

Recompose とは？

前提知識として、React には高階コンポーネント (Higher-Order Component、通称 HOC)という概念があります。具体的には、あるコンポーネントを受け取って、それに機能を付与した新規のコンポーネントを返すような関数のことを指します。これまでの記事でも HOC と書いていたものは、これのことでした。

HOC を利用することで、HOC 側にロジック、コンポーネント側はビューといったように責務を分離させたり、ロジック部分を複数のコンポーネントで再利用したりといったことができます。また、state やライフサイクルを持てない関数コンポーネントに、これらの機能を付与も可能です。

Recompose はこの HOC を扱うユーティリティ的なライブラリです。以前は多くの方々に利用されていましたが、React 16.8 で追加された React Hooks により、React 本体だけでも同様のことができるようになりました。

そのためライブラリの更新はすでに止まっており、今後は使われなくなっていくのではないかと考えられますが、業務で使用する機会があったので今回記事として書くことにしました。

インストール

yarn add recompose

今回使用するバージョンは0.30.0です。

使い方

以下、記載しているコードは公式サンプルのコードを元にしています。

基本的な使い方

HOC を使う場合、主に以下のような書き方をします。

const enhance = HOC(Component);

ここでの定数名、HOC 名、コンポーネントはあくまで仮のものです。その中身としては、以下のようなものになります。

enhance：機能が追加され、新たに作成されたコンポーネント
HOC：引数のコンポーネントに何らかの処置を施す関数
Componet：元となるコンポーネント

元となるコンポーネントをHOCでラップするイメージですね。

これを踏まえたうえで、Recompose が提供する HOC を使用した例がこちら。

import React from 'react';
import { withState } from 'recompose';

const enhance = withState('counter', 'setCounter', 0);

const Component = enhance(({ counter, setCounter }) => {
  return (
    <div>
      <p>カウンター: {counter}</p>
      <button onClick={() => setCounter(n => n + 1)}>Increment</button>
      <button onClick={() => setCounter(n => n - 1)}>Decrement</button>
    </div>
  );
});

export default Component;

上記では state を扱えるようにするwithStateで、ビュー側であるコンポーネントをラップするようになっています。withStateで定義した state と state を更新する関数は props に渡されるので、そこから使用できます。

複数の HOC を併用するやり方

Recompose ではいろんな種類の HOC が提供されているので、それらを併用して使用したい場合もあります。

その場合、普通にやろうとすると以下のようになります。

const enhance = HOC1(HOC2(Component));

実際のコードにするとこんな感じです。 withStateとwithHandlersの組み合わせ。

import React from 'react';
import { withState, withHandlers } from 'recompose';

const stateEnhance = withState('counter', 'setCounter', 0);

const handleEnhance = withHandlers({
  incrementCounter: props => () => {
    props.setCounter(v => v + 1)
  },
  decrementCounter: props => () => {
    props.setCounter(v => v - 1)
  },
});

const Component = stateEnhance(handleEnhance((
  { counter, incrementCounter, decrementCounter }) => {
  return (
    <div>
      <p>カウンター: {counter}</p>
      <button onClick={incrementCounter}>Increment</button>
      <button onClick={decrementCounter}>Decrement</button>
    </div>
  );
}));

export default Component;

この例では2つの HOC なのでまだいい方ですが、こここからさらに数が増えるとラップする数が増えて可読性が落ちてえらいことに...。また、先に書いた HOC から実行されるので、上記のようにwithHandlersのなかでwithStateにて定義したものを使用している場合は、withStateの方を先に書く必要があります。

この可読性の問題を解消するためにはcomposeという関数を使うとよいです。 composeを使うと、以下のように書くことができます。

const enhance = compose(HOC1, HOC2)(Component);

実際のコードだとこんな感じです。複数の HOC をまとめて書けるので、すっきりしますね。

import React from 'react';
import { compose, withState, withHandlers } from 'recompose';

const enhance = compose(
  withState('counter', 'setCounter', 0),
  withHandlers({
    incrementCounter: props => () => {
      props.setCounter(v => v + 1)
    },
    decrementCounter: props => () => {
      props.setCounter(v => v - 1)
    }
  })
)

const ComposeComponent = enhance(
  ({
    counter,
    incrementCounter,
    decrementCounter
  }) => {
    return (
      <div>
        <p>カウンター：{counter}</p>
        <button onClick={incrementCounter}>Increment</button>
        <button onClick={decrementCounter}>Decrement</button>
      </div>
    )
})

export default ComposeComponent;

Redux との併用

Redux と併用したい場合は、react-redux のconnectを使うとよいです。このconnectも HOC が使われているそうで、同様にcomposeで他の HOC とまとめて書くことができます。

import React from 'react';
import { connect } from 'react-redux';
import { compose } from 'recompose';
import { bindActionCreators } from 'redux';
import { incrementOn, decrementOn } from '../../Actions/Counter';

const enhance = compose(
  connect(
    state => ({
      counter: state.counter
    }),
    dispatch => ({
      actions: bindActionCreators({ incrementOn, decrementOn }, dispatch)
    })
  )
)

const ComposeComponent = enhance(
  ({ counter, actions }) => {
    return (
      <div>
        <p>カウンター：{counter}</p>
        <button onClick={actions.incrementOn}>Increment</button>
        <button onClick={actions.decrementOn}>Decrement</button>
      </div>
    )
})

export default ComposeComponent;

HOC の種類

数が多いので一部のみ紹介。

無駄な再レンダリングを抑制する：pure

props が変更されない限り、コンポーネントが更新されないようにします。変更されたことを検知するロジックとしてはshallowEqualが使われているようです。

import React from 'react';
import { pure } from 'recompose';

const enhance = pure;

const Component = enhance(
  () => {
    return (
      <div>
        <p>pure test</p>
      </div>
    );
});

export default Component;

props を置き換える：mapProps

現在の props を関数が返すものに置き換えます。

mapProps実行後は、num1とnum2はなくなり、sumという props のみに置き換えられます。

使用例（propsに num1={10}、num={20} 指定）

import React from "react";
import { mapProps } from 'recompose';

const enhance = mapProps(props => {
  return {
    sum: props.num1 + props.num2
  }
})
const Component = enhance(({ num1, num2, sum }) => {
  return (
    <div>
      <p>{num1 ? num1 : 'propsなし'}</p>
      <p>{num2 ? num2 : 'propsなし'}</p>
      <p>{sum}</p>
    </div>
  );
});

export default Component;

props を追加する：withProps

現在の props に関数が返すものを追加します。

使用例（propsに num1={10}、num2={20} 指定）

import React from "react";
import { withProps } from 'recompose';

const enhance = withProps(props => {
  return {
    sum: props.num1 + props.num2
  }
})
const Component = enhance(({ num1, num2, sum }) => {
  return (
    <div>
      <p>{num1 ? num1 : 'propsなし'}</p>
      <p>{num2 ? num2 : 'propsなし'}</p>
      <p>{sum}</p>
    </div>
  );
});

export default Component;

指定した props が変更された時のみ、props を追加する：withPropsOnChange

基本的にはwithPropsと同じであるものの、こちらは指定した props が変更された場合のみ props の追加が行われます。

使用例.

import React from "react";
import { withPropsOnChange } from 'recompose';

const enhance = withPropsOnChange(['num'], props => {
  return {
    sum: props.num * 2
  }
})
const Component = enhance(({ num, sum }) => {
  return (
    <div>
      <p>{num ? num : 'propsなし'}</p>
      <p>{sum ? sum : 'propsなし'}</p>
    </div>
  );
});

export default Component;

props にnumを指定しなかった場合 <ImageWrapper className="w-[60%]" src="screenshots/2020/react-recompose/with-props-on-change-no-props.png" alt="withPropsOnChangeを使って、propsを指定しなかった場合のサンプル画像" />

props にnumを指定した場合 <ImageWrapper className="w-[60%]" src="screenshots/2020/react-recompose/with-props-on-change.png" alt="withPropsOnChangeを使って、propsを指定した場合のサンプル画像" />

props のデフォルト値を指定する：defaultProps

React 本体で使用できるdefaultPropsプロパティとほぼ同じことができるものの、厳密には違う模様。なお、コンポーネント呼び出し時に対象の props が指定されていた時は、そちらが優先して使われます。

使用例（props に指定なし）

import React from "react";
import { defaultProps } from 'recompose';

const enhance = defaultProps({
  text: 'default'
})

const Component = enhance(({ text }) => {
  return (
    <div>
      <p>{text}</p>
    </div>
  );
});

export default Component;

props の名前を変更する：renameProp

第1引数の名称の props を第2引数の名称にリネーム。この HOC 1つにつき、1つしか書けません。

使用例（props にtext="テスト"を指定）

import React from "react";
import { renameProp } from 'recompose';

const enhance = renameProp('text', 'renameText');

const Component = enhance(({ text, renameText }) => {
  return (
    <div>
      <p>{text ? text : 'propsなし'}</p>
      <p>{renameText ? renameText : 'propsなし'}</p>
    </div>
  );
});

export default Component;

一度に複数の props の名前を変更する：renameProps

renameProps の複数版。

使用例（propsにtext="テスト" num={10}を指定）

import React from "react";
import { renameProps } from 'recompose';

const enhance = renameProps({
  'text': 'renameText',
  'num': 'renameNum'
});

const Component = enhance(({ text, renameText, num, renameNum }) => {
  return (
    <div>
      <p>{text ? text : 'propsなし'}</p>
      <p>{renameText ? renameText : 'propsなし'}</p>
      <p>{num ? num : 'propsなし'}</p>
      <p>{renameNum ? renameNum : 'propsなし'}</p>
    </div>
  );
});

export default Component;

平坦化した props を追加する：flattenProp

あくまで平坦化した props を追加なので、平坦化の元になった props もそのまま残ります。

使用例（propsにobj={{'a': 'A', 'b': 'B', 'c': 'C'}}を指定）

import React from "react";
import { flattenProp } from 'recompose';

const enhance = flattenProp('obj');

const Component = enhance(({ obj, a, b, c }) => {
  return (
    <div>
      <p>{obj.a}・{obj.b}・{obj.c}</p>
      <p>{a}</p>
      <p>{b}</p>
      <p>{c}</p>
    </div>
  );
});

export default Component;

state を追加する：withState

第1引数に state 名、第2引数に state を更新する関数、第3引数にデフォルト値を指定します。 state を更新する関数を使用する際の引数は、ただ設定値だけを渡すほかに、現在の値を引数とした処理の記述も可能です。デフォルト値の指定に関しても、単純な値のほかにコールバック関数も指定できます。

使用例（基本的な使い方の例と同じです）

import React from 'react';
import { withState } from 'recompose';

const enhance = withState('counter', 'setCounter', 0);

const Component = enhance(({ counter, setCounter }) => {
  return (
    <div>
      <p>カウンター: {counter}</p>
      <button onClick={() => setCounter(n => n + 1)}>Increment</button>
      <button onClick={() => setCounter(n => n - 1)}>Decrement</button>
    </div>
  );
});

export default Component;

関数ハンドラーを追加する：withHandlers

定義した関数ハンドラーには props が渡されるので、その値を使った処理を記述できます。

使用例（複数の HOC を併用するやり方の例と同じです）

import React from 'react';
import { compose, withState, withHandlers } from 'recompose';

const enhance = compose(
  withState('counter', 'setCounter', 0),
  withHandlers({
    incrementCounter: props => () => {
      props.setCounter(v => v + 1)
    },
    decrementCounter: props => () => {
      props.setCounter(v => v - 1)
    }
  })
)

const ComposeComponent = enhance(
  ({
    counter,
    incrementCounter,
    decrementCounter
  }) => {
    return (
      <div>
        <p>カウンター：{counter}</p>
        <button onClick={incrementCounter}>Increment</button>
        <button onClick={decrementCounter}>Decrement</button>
      </div>
    )
})

export default ComposeComponent;

※プレビューは withState の例と同じなので省略。

state と関数ハンドラーを追加する：withStateHandlers

state と、その state に関する関数ハンドラーをまとめて定義したい時は、こちらを使用。

使用例（props に指定なし）

import React from 'react';
import { withStateHandlers } from 'recompose';

const enhance = withStateHandlers(
  ({ initialCounter = 0 }) => ({
    counter: initialCounter,
  }),
  {
    incrementOn: props => () => ({
      counter: props.counter + 1,
    }),
    decrementOn: props => () => ({
      counter: props.counter - 1,
    }),
    resetCounter: (_, { initialCounter = 0 }) => () => ({
      counter: initialCounter,
    }),
  }
)

const ComposeComponent = enhance(
  ({ counter, incrementOn, decrementOn, resetCounter }) => {
    return (
      <div>
        <p>カウンター：{counter}</p>
        <button onClick={incrementOn}>Increment</button>
        <button onClick={decrementOn}>Decrement</button>
        <button onClick={resetCounter}>Reset</button>
      </div>
    )
})

export default ComposeComponent;

ローカル Reducer を追加する：withReducer

Action を発行して、そのタイプに応じた状態更新をする Redux ライクな処理を書くことができます。 Redux を使うまでではないが、より複雑な状態管理をしたいという時に向いています。

import React from 'react';
import { compose, withReducer, withHandlers } from 'recompose';

const counterReducer = (count, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return count + 1
    case 'DECREMENT':
      return count - 1
    default:
      return count
  }
}

const enhance = compose(
  withReducer('counter', 'dispatch', counterReducer, 0),
  withHandlers({
    incrementOn: props => () => props.dispatch({type: 'INCREMENT'}),
    decrementOn: props => () => props.dispatch({type: 'DECREMENT'}),
  })
);

const ComposeComponent = enhance(
  ({ counter, incrementOn, decrementOn }) => {
    return (
      <div>
        <p>カウンター：{counter}</p>
        <button onClick={incrementOn}>Increment</button>
        <button onClick={decrementOn}>Decrement</button>
      </div>
    );
});

export default ComposeComponent;

※プレビューは withState の例と同じなので省略。

ライフサイクルを追加する：lifecycle

componentDidMountをはじめとした、ライフサイクルを追加できます。

使用例.

import React from 'react';
import { compose, withState, lifecycle } from 'recompose';

const enhance = compose(
  withState('text', 'setText', ''),
  lifecycle({
    componentDidMount() {
      this.props.setText('initial');
    }
  })
)

const ComposeComponent = enhance(({ text }) => {
    return (
      <div>
        <p>{text}</p>
      </div>
    )
})

export default ComposeComponent;

Recompose は業務で使用した経験があったので、記事に起こすのそんなに難しくないと思いきや、思いのほか機能が多かったです（苦笑）自分が使った機能はほんの一部にすぎなかったようです。

またもや長くなって力尽きたので、一部機能のみ紹介にしました。気が向いたら他の機能も書くかも？

今後使われなくなっていくと思われるライブラリではありますが、保守案件とかで触れる機会がある可能性はあるので、さらっとした知識は一応持っておきたいですね。

参考リンクまとめ

React向けUIコンポーネントライブラリ、Material UI(v4)の紹介

Thu, 23 Apr 2020 00:00:00 GMT

今回は React 向けに UI コンポーネント群を提供する Material UI のお話です。

※この記事は元々 Qiita からの転載です。現在は Qiita でなく Zenn の方で更新しています。

※2021/08/26追記 TypeScript ベース + バージョン 4.12.3 で全体的に見直しました。 ※2021/09/26追記 Material UI v5記事投稿に伴い、一部追記しました。 ※2022/01/24追記あくまでライブラリの記事であるとわかりやすくするために、記事タイトルを変更しました（旧：React入門～Material UI(v4)編～）

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

Material UI とは？

最新 <OG url="https://mui.com" />

4系 <OG url="https://v4.mui.com" />

Google の Material デザインをベースに開発された、UI コンポーネントライブラリです。

お手軽に Material デザインを取り入れられることに加えて、コンポーネントの種類が豊富に用意されているため、それらを組み合わせるだけでも見栄えの良いものを作ることができます。一からコンポーネントを作るのはつらいとか、デザインを考えるのが難しいとか、それらに工数をあまりかけたくないなどの場合にもおすすめです。

React 向けの UI コンポーネントライブラリはいろんなものがあります。（2021/08/26時点で）最近では Chakra UI や daisy UI、Headless UI。などといった、Tailwind CSS をベースとしていたり、影響をうけたライブラリが特に伸びている印象ですね。そんな中でも、Material UI は変わらず伸び続けています。（Ant Design もすごい伸び続けてる👀）

執筆時点でのリポジトリスター数（※2021/08/26更新）

UI コンポーネントライブラリ	GitHub スター数	最終リリース
Material UI	70.5k	2021/07/30
Ant Design	73.9k	2021/08/16
Chakra UI	20.1k	2021/08/09
daisyUI	4.5k	2021/08/22
Headless UI	10.5k	2021/07/29
React Toolbox	8.7k	2018/06/02
Rebass	7.4k	2019/08/28
Belle	2.5k	2017/10/10
MUI	4.4k	2020/06/02
Grommet	7.4k	2021/07/28
React-Bootstrap	19.8k	2021/06/04
reactstrap	10.1k	2021/01/20

注意書き

あらかじめ言っておくのですが、今回はそこまで実践的なことは書いていません。というのも、Material UI の機能を紹介するにしても、できることが多すぎてどこを抜粋するか悩んでしまったためです（苦笑）

公式ドキュメントを見ていただくとよくわかるのですが、あらゆる使用例、サンプルコード（JS、TS ともに）およびプレビュー表示が豊富に載っています。さらっと見ていくだけでも、こんなコンポーネントも用意されているのかと発見があって楽しいくらいです。

なので、提供されているコンポーネントに関しては、大まかな概要を紹介する程度にとどめます。もし興味がわいた方はぜひ公式ドキュメントを見てみてください。各コードには CodeSandbox へのリンクもあるので、お気軽に試せますよ。

{/*  */}

~~2021/09/16時点で、5系が beta リリースされています~~ 2021/09/16に5系がリリースされましたが、当記事では4系を扱っています。 4系と5系とでは、ブランド名が変わっていたり、一部コンポーネントの所属が変わっていたり（lab のものが core に取り込まれるなど）と大きな変更点もありますのでバージョンには注意です。 ↓ ※2021/09/26追記 v5 の記事を書きました。

こんにちはMUI！新しくなったMaterial UI v5

{/*  */}

インストール

一言で Material UI と言っても、パッケージ（ライブラリ）的にはいくつかに分かれています。その中で基本となるのが@material-ui/coreで、このライブラリだけでもほとんどのコンポーネントが使用できます。

yarn add @material-ui/core

その他のライブラリとしては以下のようなものがあります。必要に応じて適宜インストールしてください。

@material-ui/icons：SVG アイコンコンポーネント集（アイコン一覧：Material UI - Material Icons）
@material-ui/lab：トグルボタンなど、core に取り込む前のコンポーネント集
@material-ui/pickers：Date Picker 的なコンポーネント集
@material-ui/x-grid：データグリッド機能を提供するコンポーネント（フル機能のエンタープライズ版）
@material-ui/data-grid：データグリッド機能を提供するコンポーネント（無料のコミュニティ版）

今回の使用バージョンは以下のとおりです。

React：17.0.2
@material-ui/core：4.12.3
@material-ui/icons：4.12.2
@material-ui/lab：4.0.0-alpha.60
@material-ui/pickers：3.3.10
@material-ui/data-grid：4.0.0-alpha.37

以下、記載しているコードは公式ドキュメントのコードを元にしています。画像や GIF に関しても、公式ドキュメントのプレビューが撮影元です。

基本的な使い方

使いたいコンポーネントをインポートして使用。独自定義のコンポーネントを使用する時とほぼ同じですが、コンポーネント特有の props を設定して見た目のカスタマイズができます。

import { VFC } from 'react';
import Button from '@material-ui/core/Button';

const App: VFC = () => {
  return (
    <Button variant="contained" color="primary">
      Test
    </Button>
  );
}

export default App;

スタイルのカスタマイズ

デザインシステムの実体であるスタイリングソリューションとしては JSS が採用されています。 <OG url="https://github.com/cssinjs/jss" />

カスタマイズ方法は、さすがに全部は紹介しきれないので、代表的なものだけ紹介。

各コンポーネントは props でカスタマイズできる範囲外で、自分で好きなスタイルをあてることも可能です。 JSX においてインラインスタイルを書く時と同様に、CSS プロパティ名はキャメルケースで記述することに注意です。

スタイル定義の優先度は、低い方から.

各コンポーネント特有の props によるスタイル
Hooks 式・styled-components 式・HOC 式による独自定義のスタイル
インラインスタイルによる独自定義のスタイル

となります。もし同一の CSS プロパティを複数指定した場合は、この優先度に沿ってスタイルがあたります。

Hooks 式

@material-ui/core/stylesのmakeStylesを使います。

「クラス名とスタイル定義をマッピングしたものを返す関数」を生成するので、あとはその関数をコンポーネント側で使用して取り出し。従来の HTML・CSS でクラスをあてるように、各要素に割り当てていく方式です。

import { VFC, ReactNode } from 'react';
import { makeStyles } from '@material-ui/core/styles';
import Button from '@material-ui/core/Button';

const useStyles = makeStyles({
  button: {
    backgroundColor: 'green'
  }
});

type Props = {
  children: ReactNode;
}

const HooksButton: VFC<Props> = ({ children }) => {
  const classes = useStyles();

  return (
    <Button variant="contained" className={classes.button}>
      {children}
    </Button>
  );
}

export default HooksButton;

引数を渡して、その値でスタイル定義をしたい場合はこんな感じ。クラス単位でも CSS プロパティ単位でも受け取ることができます。

import { VFC, CSSProperties, ReactNode } from 'react';
import { makeStyles } from '@material-ui/core/styles';
import Button from '@material-ui/core/Button';

type MyButtonStyle = {
  bgColor: CSSProperties['backgroundColor'];
  textColor: CSSProperties['color'];
}

const useStyles = makeStyles({
  // クラス単位
  button: (style: MyButtonStyle) => ({
    backgroundColor: style.bgColor,
  }),
  textColor: {
    // CSS プロパティ単位
    color: (style: MyButtonStyle) => style.textColor
  }
});

type Props = {
  children: ReactNode;
}

const HooksExButton: VFC<Props> = ({ children }) => {
  const styles = { bgColor: 'green', textColor: 'black'}
  const classes = useStyles(styles);

  return (
    <Button
      variant="contained"
      className={`${classes.button} ${classes.textColor}`}
    >
      {children}
    </Button>
  );
};

export default HooksExButton;

この例では受け取った引数の値をそのまま使っていますが、引数と三項演算子の組み合わせで、あてるスタイルを分岐させたりということも可能です。さらにコンポーネントの呼び出し側から props で渡された値を引数として渡すようにすれば、コンポーネントの呼び出し側からスタイル指定する。ということもできますね。

また、makeStylesでは後述するテーマの情報を受け取れるので、その値を使ってスタイル定義もできます。

import { VFC, ReactNode } from 'react';
import { makeStyles } from '@material-ui/core/styles';
import Button from '@material-ui/core/Button';

const useStyles = makeStyles((theme) => ({
  button: {
    backgroundColor: theme.palette.primary.dark
  }
}));

type Props = {
  children: ReactNode;
}

const HooksButton: VFC<Props> = ({ children }) => {
  const classes = useStyles();

  return (
    <Button variant="contained" className={classes.button}>
      {children}
    </Button>
  );
}

export default HooksButton;

Styled Component 式

@material-ui/core/stylesのstyledを使います。

あらかじめスタイルをあてたコンポーネントを作成し、それを使用していくような方式です。

import { VFC, ReactNode } from 'react';
import { styled } from '@material-ui/core/styles';
import Button from '@material-ui/core/Button';

const CustomButton = styled(Button)({
  backgroundColor: 'red'
});

type Props = {
  children: ReactNode;
}

const StyledButton: VFC<Props> = ({ children }) => {
  return <CustomButton variant="contained">{children}</CustomButton>;
};

export default StyledButton;

props の値を使ってスタイル定義をしたい場合はこんな感じ。 color props はButtonコンポーネントが元々受け付けている props のため、Omit で除外したうえで、独自定義側の color props 型定義と組み合わせています。

import { VFC, CSSProperties, ReactNode } from 'react';
import { styled } from '@material-ui/core/styles';
import Button, { ButtonProps } from '@material-ui/core/Button';

type MyButtonStyle = {
  color: CSSProperties['backgroundColor'];
};

type MyButtonProps = MyButtonStyle & Omit<ButtonProps, keyof MyButtonStyle>;

const CustomButton = styled(({ color, ...other }: MyButtonProps) => (
  <Button {...other} />
))({
  // CSS プロパティ単位
  // 型を MyButtonStyle にしているが、
  // 実際は渡された props は全て受け取れる（今回だと variant, color, children）
  backgroundColor: (props: MyButtonStyle) => props.color
});

type Props = {
  children: ReactNode;
}

const StyledExButton: VFC<Props> = ({ children }) => {
  return (
    <CustomButton variant="contained" color="red">
      {children}
    </CustomButton>
  );
};

export default StyledExButton;

こちらも同様に、コンポーネント（この例だと StyledExButton）の呼び出し側から props で渡された値を使うようにすれば、コンポーネントの呼び出し側からスタイル指定ができますね。

HOC 式（※旧式）

@material-ui/core/stylesのwithStylesとcreateStylesを使います。

createStylesで、クラス名とスタイル定義をマッピングしたものを作成。 withStylesでラップすることにより、定義したスタイルとコンポーネントを結合。スタイルの情報は props の classes に格納されるので、それを従来の HTML・CSS でクラスをあてるように、各要素に割り当てていく方式です。

import { VFC, ReactNode } from 'react';
import { withStyles, WithStyles, createStyles } from '@material-ui/core/styles';
import Button from '@material-ui/core/Button';

const styles = createStyles({
  button: {
    backgroundColor: 'orange'
  }
});

type Props = WithStyles<typeof styles> & {
  children: ReactNode;
};

const HOCButton: VFC<Props> = ({ classes, children }) => {
  return (
    <Button variant="contained" className={classes.button}>
      {children}
    </Button>
  );
};

export default withStyles(styles)(HOCButton);

props の値を使ってスタイル定義をしたい場合はこんな感じ。こちらも、クラス単位でも CSS プロパティ単位でも受け取ることができます。

import { VFC, CSSProperties, ReactNode } from 'react';
import { withStyles, WithStyles, createStyles } from '@material-ui/core/styles';
import Button, { ButtonProps } from '@material-ui/core/Button';

type MyButtonStyle = {
  bgColor: CSSProperties['backgroundColor'];
  textColor: CSSProperties['color'];
};

const styles = createStyles({
  // クラス単位
  // 型を MyButtonStyle にしているが、
  // 実際は呼び出し側から渡された props は全て受け取れる（今回だと bgColor, textColor, children）
  button: (props: MyButtonStyle) => ({
    backgroundColor: props.bgColor
  }),
  textColor: {
    // CSS プロパティ単位
    // 型を MyButtonStyle にしているが、
    // 実際は呼び出し側から渡された props は全て受け取れる（今回だと bgColor, textColor, children）
    color: (props: MyButtonStyle) => props.textColor
  }
});

type Props = WithStyles<typeof styles> &
  MyButtonStyle &
  Omit<ButtonProps, 'color'> & {
    children: ReactNode;
  };

const HOCButton: VFC<Props> = ({ classes, children }) => {
  return (
    <Button
      variant="contained"
      className={`${classes.button} ${classes.textColor}`}
    >
      {children}
    </Button>
  );
};

export default withStyles(styles)(HOCButton);

// コンポーネント呼び出し側
<HOCButton bgColor="orange" textColor="white">
  HOC
</HOCButton>

インラインスタイル

これは別に Material UI 特有の方式ではないですが、style でインラインスタイルを書くことも出来ます。

import { VFC, ReactNode } from 'react';
import Button from '@material-ui/core/Button';

type Props = {
  children: ReactNode;
}

const InlineStyleButton: VFC<Props> = ({ children }) => {
  return (
    <Button
      variant="contained"
      style={{ backgroundColor: 'pink' }}
    >
      {children}
    </Button>
  );
};

export default InlineStyleButton;

レイアウトコンポーネント

Material UI には以下のようなレイアウト用のコンポーネントがあります。

Box：幅広いスタイルを props であてることができるコンポーネント
Container：コンテンツを水平方向に中央揃えするコンポーネント
Grid：Grid レイアウトが構成できるコンポーネント
Hidden：画面サイズによって表示非表示を切り替えられるコンポーネント
Image List：画像のコレクションを構成できるコンポーネント

大まかなレイアウトは、これらのコンポーネントを使って組んでいくのもありです。この中で、Boxコンポーネントだけ少し紹介します。

Box コンポーネント

HTML を書いていて、スタイルをあてるために要素を div や span で囲んでスタイルを書くということがよくあります。それと同じような感覚で扱える、Boxコンポーネントというものが存在しており、これがなかなか便利です。

下記のコードの例ではmと指定していますが、これはmarginのエイリアスです。スペースのデフォルトテーマ値は8であるため、8 * 2 = 16px が実際の設定値となります。

import { VFC } from 'react';
import { Box, Button } from '@material-ui/core';

const App: VFC = () => {
  return (
    <Box m={2}>
      <Button variant="contained">Test</Button>
    </Box>
  );
}

export default App;

この 8px というのは、マテリアルデザインにおいて使われる値で、この値を基準として要素を配置していくようになっています。そのため、Boxコンポーネントを使うと、自然とその配置ができるというわけです。

また、特定の CSS プロパティはテーマの値と関連付けられており、その値を使うことも出来ます。

<Box
  color="primary.main"
  bgcolor="background.paper"
  fontFamily="h6.fontFamily"
  fontSize={{ xs: 'h6.fontSize', sm: 'h4.fontSize', md: 'h3.fontSize' }}
  p={{ xs: 2, sm: 3, md: 4 }} // 画面サイズによって設定値を変化
>
  Test
</Box>

あてられるスタイルとその props の書き方の種類一覧は、こちらをご参照ください。比較的よく使われる CSS プロパティが用意されている印象です。 <OG url="https://v4.mui.com/system/api" />

Material UI - System 配下のページで、種類ごとのドキュメントがあるので詳細はそちらを。 <OG url="https://v4.mui.com/system/basics" />

独自のデザイン性の高いものでなければ、このBoxコンポーネントを活用することで、ほとんど CSS を書かずにすむなと個人的には感じました。

デフォルトテーマ

@material-ui/coreには、全体のスタイル定義であるテーマ情報も含まれており、デフォルトで適用されています。 Material UI のコンポーネントは props でスタイルのカスタマイズができますが、仕組みとしては、その props の値によってクラスが割り当てられるようになっています。そのクラスのスタイル定義の設定値として、このテーマ情報から使っていたりするわけです。

@material-ui/core/stylesのuseThemeで、そのテーマ情報にアクセスし使用できます。

import { VFC } from 'react';
import { Button } from '@material-ui/core';
import { useTheme } from '@material-ui/core/styles';

const App: VFC = () => {
  const theme = useTheme();

  return (
    <Button
      variant="contained"
      style={{ backgroundColor: theme.palette.primary.light }}
    >
      Test
    </Button>
  );
};

export default App;

デフォルトテーマ情報に含まれている代表的なものとしては、以下のものがあります。

palette：パレットカラー
typography：フォントなど、文字に関する設定値（h1 などのタグ別のフォント情報も）
spacing：空白を計算する関数（デフォルトのベースは 8px で、8 * 引数を返す）
breakpoints：ブレイクポイントの値と、メディアクエリ指定を補助する関数
z-index：z-index の設定値

このデフォルトテーマが持っている情報に関しては、こちらをご参照ください。 <OG url="https://v4.mui.com/customization/default-theme" />

デフォルトテーマベースの独自テーマ

デフォルトテーマをベースとした独自テーマを作りたい場合は、createThemeを使った書き方ができます。

ルート階層にてThemeProviderコンポーネントを使ってラップすることで、下層のコンポーネントにテーマ情報を渡します。

以下はデフォルトテーマのパレットカラーを上書きしている例になります。

import ReactDOM from "react-dom";
import { createTheme, ThemeProvider } from '@material-ui/core/styles';
import purple from '@material-ui/core/colors/purple';
.
.
.
const theme = createTheme({
  palette: {
    primary: purple,
  }
});
.
.
.
ReactDOM.render(
  <ThemeProvider theme={theme}>
    <App />
  </ThemeProvider>,
  document.getElementById('root')
);

テーマ情報は各コンポーネント側で使用できます。 primary の元々の色は青ですが、変更しているので紫になります。一方、secondary の色は変更していないので、デフォルトテーマの色が使われます。

import { VFC } from 'react';
import Button from '@material-ui/core/Button';

const App: VFC = () => {
  return (
    <div>
      <Button variant="contained" color="primary">primary</Button>
      <Button variant="contained" color="secondary">secondary</Button>
    </div>
  );
}

export default App;

デフォルトテーマに存在していない独自のプロパティを追加する場合は、型定義を拡張したうえで独自テーマを定義する感じです。また、ThemeProviderはネストして使うこともできるようになっています。

ちなみに、createThemeと似ているcreateMuiThemeというものもあります。どうも元々createMuiThemeだったものが、createThemeに名称が変わったとのこと。（4系から5系への移行ガイドにその旨記述がありました）現在の4系では移行期間として両方存在しているみたいです。

2014 マテリアルデザインカラーパレット

テーマ情報のなかにも primary や secondary といったカラー情報がありますが、その他に 2014 マテリアルデザインカラーパレットというものが存在します。元々、マテリアルデザインによって2014年に作成されたもので、調和して機能するように設計された色で構成されています。

使用するには@material-ui/core/colorsからインポートして、HUE（赤、ピンクなどの色）と SHADE（500、600などの濃さ）を指定。

import purple from '@material-ui/core/colors/purple';
import red from '@material-ui/core/colors/red';

const primary = red[500]; // #f44336
const accent = purple['A200']; // #e040fb
const accent = purple.A200; // #e040fb

色の種類については、こちらに一覧があります。 <OG url="https://v4.mui.com/customization/color/#2014-material-design-color-palettes" />

カラー作成に使えるツール

色を考えるときは、コミュニティの方が作られたツールを使うのも手です。

create-mui-theme：マテリアルデザインカラーツールを介して Material UI テーマを作成するためのオンラインツール
material-ui-theme-editor：色を選択してライブプレビューを行うだけで、Material UI テーマを生成するツール
Material palette generator：マテリアルパレットジェネレータを使用して、入力した任意の色のパレットを生成できるツール

その他スタイルの書き方

このクラスの中のこの要素や、この要素のこのアクションといったような、ネストのスタイル指定はこのようになります。

import { VFC } from 'react';
import { makeStyles } from '@material-ui/core/styles';
import Typography from '@material-ui/core/Typography';

const useStyles = makeStyles({
  msg: {
    color: 'blue',
    '& span': {
      color: 'red',
      '&:hover': {
        color: 'black'
      }
    }
  }
})

const App: VFC = () => {
  const classes = useStyles();

  return (
    <Typography className={classes.msg}>
      これは<span>テスト</span>です
    </Typography>
  )
}

export default App;

ここでは紹介していませんが、プレーンな CSS や CSS Modules との併用も可能です。 Material UI で適用されているグローバル CSS をカスタマイズしたり。別ライブラリとしては、styled-comopnents や emotion との併用もできます（v5 ではこの2つがデザインシステムの実体として採用されています）

コンポーネントの種類

大まかな種類の概要だけさらっと書きます。なので、ここに書いているもの以外のコンポーネントもあります。（それでも長くなりました...）

()はどのライブラリに属しているかです。

Layout

他のコンポーネントをラップして使われる、レイアウトに関するコンポーネント集。

Box(core)

他のコンポーネントをラップし、様々なスタイルをあてるためのコンポーネント。デフォルトでは div としてラップするが、他のものに指定もできる。 Box コンポーネントの項も参照。

Container(core)

コンテンツを水平方向に中央揃えするコンポーネント。

Grid(core)

グリッドレイアウトを表現するためのコンポーネント。

Hidden(core)

コンポーネントを非表示にするコンポーネント。ブレイクポイントを設定して、画面幅によって非表示にするなどができる。

ImageList(core)

画像のコレクションを構成できるコンポーネント群。少し前のバージョンでは GridList だった。

Inputs

フォームなどで使用する、入力に関するコンポーネント集。

Button(core)

ボタンコンポーネント群。 Button はシンプルなものから、枠線あり、塗りつぶしのパターン。アイコンと組み合わせたものなど、いろんなパターンに対応。 IconButton はアイコン自体をボタンにしたもの。

Button の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/button.png" alt="Buttonコンポーネントのプレビュー画像" />

IconButton の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/icon-button.png" alt="IconButtonコンポーネントのプレビュー画像"/>

ButtonGroup(core)

ボタンをグループ化したコンポーネント。

ButtonGroup の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/button-group.png" alt="ButtonGroupコンポーネントのプレビュー画像"/>

Checkbox(core)

チェックボックスコンポーネント。 FormControlLabel と組み合わせることで、ラベル付きのものも作れる。

Checkbox の例（FormControlLabel と組み合わせ） <ImageWrapper className="w-[50%]" src="screenshots/2020/react-material-ui/check-box.png" alt="Checkboxコンポーネントのプレビュー画像"/>

Fab(core)

Floating Action Button の略。少し浮いているようなボタンのコンポーネント。

Fab の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/fab.png" alt="Fabコンポーネントのプレビュー画像"/>

Date / Time(pickers)

Date Picker 的なコンポーネント群。詳細は Material-UI Pickers から（2023/11/25 URLが変わっていたので修正）

<OG url="https://github.com/mui/material-ui-pickers" /> なお、この Material-UI Pickers は Matarial UI 5系において lab の方に取り込まれるようです。

KeyboardDatePickerの例（variant に inline 指定） <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/date-picker-inline.gif" alt="KeyboardDatePicker(inline)コンポーネントのプレビューGIF"/>

KeyboardDatePicker の例（variant に dialog 指定） <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/date-picker-dialog.gif" alt="KeyboardDatePicker(dialog)コンポーネントのプレビューGIF"/>

KeyboardTimePicker の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/time-picker.gif" alt="KeyboardTimePickerコンポーネントのプレビューGIF"/>

Radio(core)

ラジオボタンコンポーネント群。 FormControlLabel と組み合わせることで、ラベル付きのものも作れる。

RadioGroup、Radio の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/radio.png" alt="RadioGroup、Radioコンポーネントのプレビュー画像"/>

Select(core)

セレクトボックスコンポーネント。選択肢をグルーピングもできる。

Select の例 <ImageWrapper className="w-[50%]" src="gifs/2020/react-material-ui/select.gif" alt="SelectコンポーネントのプレビューGIF"/>

Slider(core)

スライダーコンポーネント。

Slider の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/slider.png" alt="Sliderコンポーネントのプレビュー画像"/>

Switch(core)

スイッチコンポーネント。 FormControlLabel と組み合わせることで、ラベル付きのものも作れる。

Switch の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/switch.png" alt="Switchコンポーネントのプレビュー画像"/>

Text Field(core)

テキスト入力フォームのコンポーネント群。マルチラインにしたり、セレクトボックスにしたりもできる。また、フォームにアイコンをつけたり、単位の文字をつけるといったことも可能。 InputBase といった下位レベルのコンポーネントが複数存在しており、より細かくカスタマイズしたい時は、そちらを使うとよい。

TextField の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/text-field.png" alt="TextFieldコンポーネントのプレビュー画像"/>

Navigation

ナビゲーションに関するコンポーネント集。

Bottom Navigation(core)

スマホアプリでよくあるような、ボタンナビゲーションコンポーネント群。

BottomNavigation、BottomNavigationAction の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/button-navigation.png" alt="BottomNavigation、BottomNavigationActionコンポーネントのプレビュー画像"/>

Breadcrumbs(core)

パンくずリスト的なコンポーネント。Link と組み合わせたりする。

Breadcrumbs の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/breadcrumbs.png" alt="Breadcrumbsコンポーネントのプレビュー画像"/>

Drawer(core)

ドロワーコンポーネント。Button と組み合わせて、クリックされたときにドロワーを開くといったように使う。画面の上下左右どこからドロワーが開くか設定できる。

Drawer の例（上から開いた例） <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/drawer.gif" alt="DrawerコンポーネントのプレビューGIF"/>

Link(core)

リンクコンポーネント。React Router を併用する場合は、あまり使う機会ないかも？

Link の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/link.png" alt="Linkコンポーネントのプレビュー画像"/>

Menu(core)

メニューコンポーネント群。 Button と組み合わせて、クリックされたときにメニューを開くといったように使う。

Menu、MenuItem の例（メニューを開いた後） <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/menu.gif" alt="Menu、MenuItemコンポーネントのプレビューGIF"/>

Stepper(core)

ステッパーコンポーネント群。ステップ手順を踏んでいくような表現ができる。

Stepper、Step、StepLabel の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/stepper.png" alt="Stepper、Step、StepLabelコンポーネントのプレビュー画像"/>

Tabs(core)

タブコンポーネント群。アイコンを使って、ボタンナビゲーションのようにもできる。

Tabs の例 <ImageWrapper className="w-[50%]" src="screenshots/2020/react-material-ui/tabs.png" alt="Tabsコンポーネントのプレビュー画像"/>

Surfaces

表面的な UI に関するコンポーネント集。

App Bar(core)

ヘッダーに使えるようなバーのコンポーネント群。

AppBar、ToolBar の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/app-bar.png" alt="AppBar、ToolBarコンポーネントのプレビュー画像"/>

Paper(core)

積み重なった紙のような表現ができるコンポーネント。

Paper の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/paper.png" alt="Paperコンポーネントのプレビュー画像"/>

Card(core)

カードコンポーネント群。文字だけでなく画像もいれられる。

Card、CardActions、CardContent、CardHeader、CardMedia の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/card.png" alt="Card、CardActions、CardContent、CardHeader、CardMediaコンポーネントのプレビュー画像"/>

Accordion(core)

ハンバーガメニューのようなコンポーネント群。少し前のバージョンでは ExpansionPanel だった。

Accordion、AccordionDetails、AccordionSummary の例 <ImageWrapper className="w-[50%]" src="gifs/2020/react-material-ui/accordion.gif" alt="Accordion、AccordionDetails、AccordionSummaryコンポーネントのプレビューGIF"/>

Feedback

ユーザに状態を伝えるようなコンポーネント集。

Progress(core)

プログレスコンポーネント群。読み込み中の表現ができる。

CircularProgress の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/progress.gif" alt="CircularProgressコンポーネントのプレビューGIF"/>

Dialog(core)

ダイアログコンポーネント群。 Button と組み合わせて、クリックされたときにダイアログを開くといったように使う。

SimpleDialog の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/dialog.gif" alt="SimpleDialogコンポーネントのプレビューGIF"/>

Snackbar(core)

トースト的な表現ができるコンポーネント群。 Button と組み合わせて、クリックされたときにメッセージを出したり。 Alert と組み合わせて、API リクエストエラー時のアラート表示にしたり。

Snackbar の例 <ImageWrapper className="w-[50%]" src="gifs/2020/react-material-ui/snack-bar.gif" alt="SnackbarコンポーネントのプレビューGIF"/>

Backdrop(core)

アプリ上の状態変化を表現できる、背景のコンポーネント。

Backdrop の例（CircularProgress との組み合わせ） <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/backdrop.gif" alt="BackdropコンポーネントのプレビューGIF"/>

Data Display

データを表示することに関するコンポーネント集。

Avatar(core)

アバターコンポーネント群。画像や名称を指定してユーザのアイコンのような表現ができる。

Avatar の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/avatar.png" alt="Avatarコンポーネントのプレビュー画像"/>

Badge(core)

バッジコンポーネント。アイコンなどと組み合わせて通知を表現できる。

Badge の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/badge.png" alt="Badgeコンポーネントのプレビュー画像"/>

Chip(core)

チップコンポーネント。入力や属性、アクションを表現できる。

Chip の例 <ImageWrapper className="w-[50%]" src="screenshots/2020/react-material-ui/chip.png" alt="Chipコンポーネントのプレビュー画像"/>

Divider(core)

線を表現できるコンポーネント。デフォルトでは hr として変換される。

Divider の例（線の部分） <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/divider.png" alt="Dividerコンポーネントのプレビュー画像"/>

Material Icons(icons)

アイコンのコンポーネント集。アイコンの種類は Material UI - Material Icons を参照。

Listr(core)

リスト表示を表現できるコンポーネント群。

List、ListItem、ListItemIcon、ListItemText の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/list.png" alt="List、ListItem、ListItemIcon、ListItemTextコンポーネントのプレビュー画像"/>

Table(core)

テーブル表示を表現できるコンポーネント群。テーブル内のパーツごとにコンポーネントが分かれており、ソート機能も導入できる。

Table、TableBody、TableCell、TableContainer、TableHead、TableRow の例 <ImageWrapper className="w-[50%]" src="screenshots/2020/react-material-ui/table.png" alt="Table、TableBody、TableCell、TableContainer、TableHead、TableRowコンポーネントのプレビュー画像"/>

Tooltip(core)

ツールチップコンポーネント。ラップしているコンポーネントをホバーした時に、簡易説明を表示するような表現ができる。

Tooltip の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/tooltip.gif" alt="TooltipコンポーネントのプレビューGIF"/>

Typography(core)

文字表示を表現できるコンポーネント。文字位置や文字色、どのタグ（h1 など）とするか、どのタグのスタイルをあてるかなどを設定できる。

Typography の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/typography.png" alt="Typographyコンポーネントのプレビュー画像"/>

Utils

ユーティリティ的なコンポーネント集。

Click Away Listener(core)

要素の外でクリックイベントが発生したかどうかを検出するコンポーネント。

CSS Baseline(core)

normalize.css のような、CSS をリセットするコンポーネント群。ブラウザごとの表示を統一したい時に使用。

Modal(core)

モーダルコンポーネント。 Dialog、Drawer、Menu、Popover から活用されている下位レベルのコンポーネント。モーダルダイアログを作成する場合は、Modal を直接使用するのではなく、Dialog コンポーネントを使用することを推奨としている。

Modal の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/modal.gif" alt="ModalコンポーネントのプレビューGIF"/>

No SSR(core)

ラップしたコンポーネントを SSR（サーバサイドレンダリング）の対象から外すコンポーネント。 SSR の時間を短縮、SSR に対応していないコンポーネントをエスケープなどに使う。

Popover(core)

ポップオーバーコンポーネント。コンテンツを別のコンテンツの上に表示する表現ができる。

Popover の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/popover.gif" alt="PopoverコンポーネントのプレビューGIF"/>

Popper(core)

Popper.js をベースとしたポッパーコンポーネント。これもコンテンツを別のコンテンツの上に表示する表現ができる。上に表示されたコンテンツはスクロールについてこないなど、Popover と微妙な違いがある。

Popper の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/popper.gif" alt="PopperコンポーネントのプレビューGIF"/>

Portal(core)

ポータルコンポーネント。ラップしたコンポーネントを現在の DOM 階層外の新しいサブツリーへレンダリングすることに使う。

Textarea Autosize(core)

テキストエリアコンポーネント。デフォルトでは自由にサイズを変更できるが、サイズや行数を固定もできる。

TextareaAutosize の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/textarea.gif" alt="TextareaAutosizeコンポーネントのプレビューGIF"/>

Collapse(core)

ラップしたコンポーネントで、上から下へ表示される表現ができるコンポーネント。

Collapse の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/collapse.gif" alt="CollapseコンポーネントのプレビューGIF"/>

Fade(core)

ラップしたコンポーネントで、フェードイン、フェードアウトを表現できるコンポーネント。

Fade の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/fade.gif" alt="FadeコンポーネントのプレビューGIF"/>

Grow(core)

ラップしたコンポーネントを順番にフェードインするような表現ができるコンポーネント。

Grow の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/grow.gif" alt="GrowコンポーネントのプレビューGIF"/>

Slide(core)

ラップしたコンポーネントをスライド表示する表現ができるコンポーネント。スライドする方向は指定できる。

Slide の例（derection に up 指定） <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/slide.gif" alt="SlideコンポーネントのプレビューGIF"/>

Zoom(core)

ラップしたコンポーネントが、要素の中心から外側に広がるように表示する（もしくはその逆）表現ができるコンポーネント。

Zoom の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/zoom.gif" alt="ZoomコンポーネントのプレビューGIF"/>

Lab

core へ組み込まれる前のコンポーネント集。

Alert(lab)

アラートコンポーネント群。ユーザへ促す注意や案内を表現する。

Alert の例 <ImageWrapper className="w-[50%]" src="screenshots/2020/react-material-ui/alert.png" alt="Alertコンポーネントのプレビュー画像"/>

Autocomplete(lab)

サジェスト入力フォームを実現できるコンポーネント。複数選択式にすることも可能。

AutoComplete の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/auto-complete.gif" alt="AutoCompleteコンポーネントのプレビューGIF"/>

Data Grid(x-grid, data-grid)

データグリッドを表現できるコンポーネント群。表示だけの Table と違い、値を直接操作できるといった機能も持ち合わせているなど多機能で、ドキュメントの項目も多い。所属するライブラリとして、フル機能のエンタープライズ版である x-grid と、無料のコミュニティ版である data-grid がある。

DataGrid の例 <ImageWrapper className="w-[70%]" src="screenshots/2020/react-material-ui/data-grid.png" alt="DataGridコンポーネントのプレビュー画像"/>

Pagination(lab)

ページネーションを表現できるコンポーネント群。

Pagination の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/pagination.png" alt="Paginationコンポーネントのプレビュー画像"/>

Rating(lab)

レーティングを表現できるコンポーネント。

Rating の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/rating.gif" alt="RatingコンポーネントのプレビューGIF"/>

Skeleton(lab)

コンテンツの読み込み中にスケルトンを表示するような表現ができるコンポーネント。

Skeleton の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/skeleton.gif" alt="SketetonコンポーネントのプレビューGIF"/>

Speed Dial(lab)

スピードダイヤルで3~6の関連アクションを表示するような表現ができるコンポーネント群。

SpeedDial、SpeedDialIcon、SpeedDialAction の例 <ImageWrapper className="w-[40%]" src="gifs/2020/react-material-ui/speed-dial.gif" alt="SpeedDial、SpeedDialIcon、SpeedDialActionコンポーネントのプレビューGIF"/>

Timeline(lab)

タイムラインを表現できるコンポーネント群。 Icon や Paper と組み合わせると、よりリッチな表現ができる。

Timeline、TimelineItem、TimelineSeparator、TimelineConnector、TimelineContent、TimelineDot の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/timeline.png" alt="Timeline、TimelineItem、TimelineSeparator、TimelineConnector、TimelineContent、TimelineDotコンポーネントのプレビュー画像"/>

Toggle Buttons(lab)

トグルボタンコンポーネント群。

ToggleButton、ToggleButtonGroup の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/toggle-button.png" alt="ToggleButton、ToggleButtonGroupコンポーネントのプレビュー画像"/>

Tree View(lab)

ツリービューを表現できるコンポーネント群。

TreeView、TreeItem の例 <ImageWrapper className="w-[40%]" src="screenshots/2020/react-material-ui/tree-view.png" alt="TreeView、TreeItemコンポーネントのプレビュー画像"/>

概要だけさらっと書くつもりがすごく長くなってしまいました。ここまで読んでくださった方、ありがとうございます！

それだけ提供している機能が多いということでもあるので、味方につけるときっと頼もしい存在になってくれるのではないかと。ちなみに自分が過去に業務で使用していた時には、バージョン少し古く対応してなくて泣く泣く使うことができなかった機能もありました（笑）

この記事を書くにあたって、改めて公式ドキュメントを読んで新しい発見もあって、より使いこなせるようになりたいなと思いました。 Material UI がどんなものなのか、大まかにでも伝わっていれば幸いです。

参考リンクまとめ

JS×Reactにおけるpropsの型定義を担うPropTypes入門

Sat, 04 Apr 2020 00:00:00 GMT

今回はコンポーネントに渡す props の使用を補助するものである PropTypes について書きました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

※この記事は元々 Qiita からの転載です。現在は Qiita でなく Zenn の方で更新しています。

※2021/08/26追記全体的に少し内容を見直しました。 ※2022/01/24追記あくまでライブラリの記事であるとわかりやすくするために、記事タイトルを変更しました（旧：React入門～PropTypes編～）

PropTypes とは？

React で登場するコンポーネントは、 props という任意の値を受け取ることができるようになっています。受け取ったコンポーネント側でこの props の値を使い、レンダリング内容に変化をつけたり、ロジックを作ったり。

一見、便利な props ではありますが、通常ではどんな値でも受け取ることができてしまいます。そのため、props の型補完が効かなかったり。誤って想定と違う値を渡してしまうと、予期しない動作をしてアプリがクラッシュする...いったことも起こる可能性があったり。

TypeScript を使用すれば props の型定義ができるため、こういった問題に対応できるのですが...。 JavaScript を使用している場合は、このことを常に考慮する必要があります。

これを補助するものとして、型定義機能を提供してくれるのがPropTypesです。元々は React 本体に組み込まれていましたが、バージョン15.5よりprop-typesという別パッケージとして切り分けされました。

インストール

yarn add prop-types

今回の使用バージョンは以下のとおりです。

React：17.0.2
prop-types：15.7.2

基本的な使い方

import PropsTypesComponent from './PropTypesComponent';

const App = () => {
  return (
    <PropsTypesComponent name="太郎" />
  )
}

export default App;

import PropTypes from 'prop-types';

const PropTypesComponent = ({ name }) => {
  return (
    <h2>Hello {name}</h2>
  );
}

PropTypesComponent.propTypes = {
  name: PropTypes.string
};

export default PropTypesComponent;

ライブラリを import

import PropTypes from 'prop-types';

props ごとの型定義を記述

コンポーネント名.propTypes = {
  props名: PropTypes.型定義
}

今回の場合.

PropTypesComponent.propTypes = {
  name: PropTypes.string
};

これで props の型定義ができました。このコンポーネント呼び出し時に、props の入力補完が効くようになります。

また、自動でバリデーションチェックが行われるようになり、無効な値が渡された場合は DevTools のコンソールに Warning が出力されます。上記の例では問題ありませんが、例えば PropsTypesComponent に渡している name の値を「1」など、string 以外の値にしてみます。すると、以下のような Warning がコンソールに出力されているはずです。

あくまでコンソール上に Warning を出力するだけではありますが、これが出ないようにコーディングすれば、予期せぬ動作を減らすことができるわけです。加えて props にどんな型の値が入るのか可視化される。というメリットもあります。

ただ、このバリデーションチェックはパフォーマンス上の理由から開発モードの場合のみ動作することに注意です。

型定義の種類

数値

PropTypes.number

受け付ける例.

1
1.0

文字列

PropTypes.string

受け付ける例.

'太郎'
'1'

真偽値

PropTypes.bool

受け付ける例.

true
false

一応補足として、あくまで真偽値なので'true'などはダメです。文字列扱いなので、バリデーションに引っ掛かります。

配列

PropTypes.array

受け付ける例.

[1, 'A']
[{ id: 'A'}, { id: 'B' }]

配列であれば、その中の値の型までは問わないため非推奨のようです。中の値の型までチェックする場合はarrayOfを使います。

PropTypes.arrayOf(型定義の種類)

// 例
PropTypes.arrayOf(PropTypes.number)

受け付ける例 ※ PropTypes.arrayOf(PropTypes.number) の場合.

[1, 2, 3]

オブジェクト

PropTypes.object

受け付ける例.

{ a: 'A', b: 'B' }

オブジェクトであれば、その中の値の型までは問わないため非推奨のようです。中の値の型までチェックする場合はobjectOfかshape、もしくはexactを使います。

objectOfは特定の型のみの場合。

PropTypes.objectOf(型定義の種類)

// 例
PropTypes.objectOf(PropTypes.number)

受け付ける例 ※ PropTypes.objectOf(PropTypes.number) の場合.

{ a: 1, b: 2 }

shapeは型がバラバラの場合。

PropTypes.shape({
  props名: 型定義の種類,
  props名: 型定義の種類
})

// 例
PropTypes.shape({
  num: PropTypes.number,
  str: PropTypes.string
})

受け付ける例 ※上の設定例の場合.

{ num: 1, str: '太郎' }

exactも型がバラバラの場合です。 shapeとの違いは、型定義した以外のものがオブジェクトに追加されているとバリデーションに引っ掛かります。こちらの方がより厳密に props をチェックする感じです。

PropTypes.exact({
  props名: 型定義の種類,
  props名: 型定義の種類
})

// 例
PropTypes.exact({
  num: PropTypes.number,
  str: PropTypes.string
})

受け付ける例 ※上の設定例の場合.

// ここにこの二つ以外のキー、値があると警告
{ num: 1, str: '太郎' }

関数

PropTypes.func

受け付ける例.

() => {
  console.log('func');
}

シンボル

PropTypes.symbol

受け付ける例.

Symbol()
Symbol('test')

恥ずかしながら自分はシンボルって何？状態だったので調べたのですが、ES6 で追加された新しいプリミティブのデータ型だったのですね。

でも、いまいち使い方がよくわからない...。

特定の値のいずれかの場合

PropTypes.oneOf(['値１', '値２'])

// 例
PropTypes.oneOf(['A', 'B', 'C'])

受け付ける例 ※上の設定例の場合.

'A'
'B'
'C'

いろんなデータ型が渡される可能性がある場合

PropTypes.oneOfType([
  型定義の種類,
  型定義の種類
])

// 例
PropTypes.oneOfType([
  PropTypes.number,
  PropTypes.string
])

受け付ける例 ※上の設定例の場合.

1
'1'
'A'

クラスオブジェクト

PropTypes.instanceOf(クラス名)

// 例
PropTypes.instanceOf(Date)

受け付ける例 ※上の設定例の場合.

new Date()

React Element

PropTypes.element

受け付ける例.

<Test /> // 独自定義のコンポーネント
<p>Test</p>

React Element Type

PropTypes.elementType

React.element と似ていますが、こちらは以下のような記述がありました。

関数、文字列、または「要素のような」オブジェクト（React.Fragment、Suspenseなど）

詳細は React の isValidElementType を見てね、とのこと。 <OG url="https://github.com/facebook/react/blob/v17.0.2/packages/shared/isValidElementType.js" />

受け付ける例.

Test // 独自定義のコンポーネント名（JSX を返す関数）
React.Fragment
React.Context
React.Suspense

レンダリングできるもの

PropTypes.node

受け付ける例.

1
'A'
['a', 'b']
<p>Test</p>
<Test /> // 独自定義のコンポーネント

数値、文字列、配列、React Element であればいいようです。真偽値やオブジェクトはバリデーションに引っ掛かりました。

型は問わない

PropTypes.any

どんな型でも受け付けるよ。というやつです。これを使ってしまうと PropTypes の意味があまりなくなってしまうので、どうしても使いたい時だけに留めておきましょう。

必須

PropTypes.型定義.isRequired

// 例
PropTypes.number.isRequired
PropTypes.any.isRequired

カスタムルール

// カスタムルールの定義
const customProp = (props, propName, componentName) => {
  if (!/test/.test(props[propName])) {
    return new Error(
      'Invalid prop `' + propName + '` supplied to' +
      ' `' + componentName + '`. Validation failed.'
    );
  }
}

// カスタムルールの使用
コンポーネント名.propTypes = {
  props名: customProp
}

この例は props の値にtestという文字列が含まれているかチェックするものです（公式ドキュメントのコードをベースにしています）

props のデフォルト値

defaultPropsを使って、props のデフォルト値を設定できます。もしその props に値が渡されなかった場合は、このデフォルト値がセットされます。また、型定義と並行して使用している場合は、このデフォルト値セットが行われた後でバリデーションチェックが行われます。

コンポーネント名.defaultProps = {
  props名: 値
}

// 例
PropTypesComponent.defaultProps = {
  defaultValue: 'default'
}

2021/08/26 時点で、自分は TypeScript をメインで使うようになったので、PropTypes と少し縁遠くなりました。ただ、JavaScript のままのアプリも一部管理しているので、そちらでは今でも継続して使用しています。

最初は、渡す props が多いコンポーネントだと型定義がめんどくさいと感じる人少なくないんじゃないかなと。その分、それ以上のメリットがあると思っていますし、JavaScript × React アプリ開発時の使用をお勧めします。（自分の場合は慣れてくると、逆に型定義がないと不安な気持ちなるようになりました(笑)）

参考リンク

Jekyll製ブログのカテゴリーページにもページネーションを導入する

Sat, 07 Mar 2020 00:00:00 GMT

以前、当ブログのカテゴリーページにページネーションを導入したのですが、記事化していなかったので、当時の記録を掘り起こしながら導入手順を書いてみます。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

元々あるページネーション

現時点で、当ブログで使用しているJekyllのバージョンは3.8.1です。この Jekyll 3系ではデフォルトでjekyll-paginateプラグインが導入されており、トップページではページネーションが有効になっていました。

ただ、カテゴリーページにもページネーションを有効にしたいなと思い調べると、jekyll-paginateプラグインでは対応していないとのこと。代わりにjekyll-paginate-v2プラグインを使用するように公式でも案内があったため、こちらへ移行することにしました。

jekyll-paginate-v2導入

※以下導入手順を書いていきますが、使用テーマによって微妙に違いのある可能性があります。（自分は現時点で Hydeout の4.0.2を使用しています）

プラグインのインストール

Gemfileに追記。

group :jekyll_plugins do
  gem "jekyll-feed", "~> 0.6"
  gem "jekyll-sitemap"
  gem "jekyll-paginate-v2" ←追記
end

インストール.

bundle install

基本設定

_config.yml

使用プラグインを修正

plugins:
  - jekyll-feed
  - jekyll-paginate
  - jekyll-sitemap

↓

plugins:
  - jekyll-feed
  - jekyll-paginate-v2 # 変更
  - jekyll-sitemap

旧ページネーション設定を書き換え

paginate: 8
paginate_path: "page:num"

↓

pagination:
  enabled: true
  per_page: 10
  permalink: '/page/:num/'
  title: ':title - :num'
  sort_reverse: true

enabled：ページネーションの有効化
per_page：ページネーションの1ページ当たりのリンク数
permalink：ページネーションでページ送りしたときのURL（:numにはページ数が入る）
title：ページネーションでページ送りしたときの表示タイトル（:titleにはそのページのタイトル、:numにはページ数）
sort_reverse：リンクの並び順を記事が新しい順にするか

_layouts/index.html

トップページのレイアウトファイルです。デフォルトではjekyll-paginateが導入されているため、恐らく以下のようなものが含まれていると思われます。

pagination-newer.html：ページを1ページ戻す部分
pagination-older.html：ページを1ページ進める部分
paginator.posts：ページネーションでの1ページあたりの数の記事情報が入っている

ここについては特に変更しなくてよいです。

---
layout: default
---

<div class="content">
  {% include pagination-newer.html %}

  {{ content }}

  {% for post in paginator.posts %}
  <article class="post-body">
    <h2 class="post-title">
      <a href="{{ site.baseurl }}{{ post.url }}">
        {{ post.title }}
      </a>
    </h2>
    {% include post-meta.html post=post %}

    {% if post.excerpt %}
      {{ post.excerpt }}
    {% else %}
      {{ post.content }}
    {% endif %}

    {% if post.excerpt %}
      {% comment %}Excerpt may be equal to content. Check.{% endcomment %}
      {% capture content_words %}
        {{ post.content | number_of_words }}
      {% endcapture %}
      {% capture excerpt_words %}
        {{ post.excerpt | number_of_words }}
      {% endcapture %}

      {% if content_words != excerpt_words %}
        <a href="{{ site.baseurl }}{{ post.url }}">More &hellip;</a>
      {% endif %}
    {% endif %}
  </article>
  {% endfor %}

  {% include pagination-older.html %}
</div>

index.html

トップページの html ファイルです。

front matter に以下を追記します。これがないと、レイアウトファイルのpaginator.postsに何も値が入らないため、トップページ表示の際に何も表示されなくなってしまいました。

pagination:
  enabled: true

※注意点・URL

使用テーマの影響の可能性もありますが、この設定をしたことで URL が/であるかを条件とした分岐処理が一部うまく動かなくなりました。

その個所については URL が/index.htmlであるかというように修正して対応しました。

この時点ではページネーションの基本設定をやっただけなので、カテゴリーページにページネーションはまだついていません。

カテゴリーページへの設定

各カテゴリーページのマークダウンファイル

front matter にページネーションの設定を追記します。

以下は当ブログのプログラミングカテゴリーの例です。 permalink、paginationが今回必要な設定です。

例.

---
layout: category
title: プログラミング
permalink:  '/プログラミング/'
sidebar_sort_order: 3
pagination:
  enabled: true
  category: プログラミング
  permalink: '/:num/'
---

この場合、URL は(ドメイン)/プログラミング/index.htmlや(ドメイン)/プログラミング/(ページ数)といったようになります。

_layouts/category.html

カテゴリーページのレイアウトファイルです。 pagination-newer.htmlとpagination-older.htmlの include を追記。加えて、 {% for post in site.categories[category] %}となっていたところを{% for post in paginator.posts %}に。ページネーションでの1ページあたりの数の記事情報でforを回すようにします。

以下は一例.

---
layout: page
---

{% unless page.content == '' %}
  {{ content }}
{% endunless %}

{% include pagination-newer.html %}

<ul class="posts-list">
  {% assign category = page.category | default: page.title %}
  {% for post in paginator.posts %}
    <li>
      <h3>
        <a href="{{ site.baseurl }}{{ post.url }}">
          {{ post.title }}
          <small>{{ post.date | date_to_string }}
            {% for tag in post.tags %}
              {{ tag }}
            {% endfor %}
          </small>
        </a>
      </h3>
    </li>
  {% endfor %}
</ul>

{% include pagination-older.html %}

これでカテゴリーページでもページネーションが有効になります。

※注意点・カテゴリーページへのリンク

自分が使用しているテーマの場合、サイドバーにカテゴリーページへのリンクがあり、元々以下のようなコードになっていました。

{% comment %}
  Dynamically generate list of links to all category pages
{% endcomment %}
{% assign pages_list = site.pages|sort:"sidebar_sort_order" %}
{% for node in pages_list %}
  {% if node.title != null %}
    {% if node.layout == "category" %}
      <a class="category-link {% if page.url == node.url %} active{% endif %}"
          href="{{ node.url | relative_url }}">{{ node.title }}</a>
    {% endif %}
  {% endif %}
{% endfor %}

するとカテゴリーページのページネーションを有効にしたことで、サイドバーのリンクが以下のようになってしまいました。ページネーションの各ページまでリンクに出てしまっています。

なので、_includes/category-links.html ファイルを新たに作成して、以下のような内容で上書きするようにしました。これでページネーションの各ページが出なくなります。

{% comment %}
  Dynamically generate list of links to all category pages
{% endcomment %}

{% assign pages_list = site.pages|sort:"sidebar_sort_order" %}
{% for node in pages_list %}
  {% if node.title and node.autogen == nil and node.layout == "category" %}
    <a class="category-link {% if page.url == node.url %} active{% endif %}" href="{{ node.url | relative_url }}">{{ node.title | escape }}</a>
  {% endif %}
{% endfor %}

参考リンクまとめ

GitHub ActionsでReact(SPA)アプリをS3にデプロイ（+ CloudFrontのキャッシュクリア）して、Slackに通知するまで

Sun, 01 Mar 2020 00:00:00 GMT

以前から業務で React を使用していましたが、デプロイは手動でやっていたため、自動化できたらいいなという話をチームでしていました。そこで、正式リリースもされた GitHub Actions をせっかくなので使ってみたいなと思い、自動化に挑戦してみました。

※この記事は元々 Qiita からの転載です。現在は Qiita でなく Zenn の方で更新しています。

※2021/09/05追記全体的に内容を更新しました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

GitHub Actions とは？

ざっくり言うと、GitHub が提供している、ワークフロー自動化機能のことです。あるトリガーをきっかけに、あらかじめ定義しておいた処理を自動実行する。

ビルド
静的解析
テスト
デプロイ

などといったものを自動化することで、いわゆる CI/CD 環境を構築できます。

はじめはベータ版で公開されていましたが、2019年11月に正式公開されました。

これまで CI/CD 環境を構築するにあたって、 Circle CI などの外部サービスと連携させて行うことが多かったです。ですが、この GitHub Actions に登場により、GitHub だけでも構築できるようになりました。

こちらの記事で概要から機能まで幅広く解説されています。 <OG url="https://knowledge.sakura.ad.jp/23478" />

今回構築する構成

React(SPA) アプリのビルド生成物を S3 バケットに配置。その S3 バケットをオリジンとして CDN（CloudFront ディストリビューション）を配置し、そこからコンテンツを配信するというシンプルな構成です。

{/*  */}

※インフラ構築するにあたって、AWS CloudFormation や Terraform 等の IaC（Infrastructure as Code）を実現するものを使う方式もありますが、当記事では使用しませんのでご注意ください。　また、AWS サービスを使用した Web・モバイルアプリ開発支援ツールである AWS Amplify についても同様に当記事では取り扱いません。

{/*  */}

OAI について

Origin Access Identityの略称で、特別な CloudFront ユーザのことを指します。 S3 バケットへのアクセスを、特定の CloutFront ディストリビューション経由からのみにするために使用するものです。

通常、S3 バケット単体でもコンテンツを静的サイトとして公開する機能を持っており、そのドメインを CloudFront ディストリビューションのオリジンとして設定も可能です。しかし、S3 バケット単体でコンテンツを静的サイトとして公開するにあたっては、全てのユーザに S3 バケットへの読み取りアクセス許可を付与する必要があります。どんな人でも S3 バケットへ直接アクセスできるようになるわけで、セキュリティやアクセス制御などの問題が生じてきてしまいます。

それを解決するため、特定の CloutFront ディストリビューション経由からのみ、S3 バケットへのアクセスを受け付けるようにするわけです。 S3 バケット側から見て、どの CloudFront ディストリビューションからのみアクセスを受け付ければいいのか判断するものとして、この OAI が使われます。

事前準備

最初にまずこれらを準備しましょう。

AWS アカウント
Slack ワークスペース
React（SPA）アプリのコード + そのコードを管理している GitHub リポジトリ

S3 の準備

GitHub Actions でデプロイする先を用意します。マネジメントコンソールで S3 の画面へ。

バケットの作成

「バケットを作成」を選択
一般的な設定
- バケット名を入力（全世界で一意の名前である必要があります）
- リージョンを選択
このバケットのブロックパブリックアクセス設定
- パブリックアクセスをすべてブロックにチェック（デフォルトだとチェック済み）
バケットのバージョニング
- 任意でどちらか選択
タグ - オプション
- 任意でタグの追加
デフォルトの暗号化
- 任意でどちらか選択
詳細設定
- 任意でどちらか選択
「バケットを作成」を選択

作成したバケットの ARN（arn:aws:s3:::バケット名）は、ポリシー作成時に使用するので控えておきましょう。バケットのプロパティタブから確認できます。また、バケット名も GitHub Actions ワークフロー定義時に使用します。

静的サイトとして公開に関して

S3 にデプロイしたものを直接静的サイトとして公開もできますが、今回は CloudFront を介しての公開とするので非公開のままで OK です。

Cloud Front の準備

マネジメントコンソールで CloudFront の画面へ。

ディストリビューションの作成

最低限の設定のみ記載します。その他の項目は、ご自身の環境に応じて設定ください。

「ディストリビューションを作成」を選択
オリジン
- オリジンドメイン：AWS オリジンとして、先ほど作成したバケット（{※バケット名}.s3.amazonaws.com）を選択
- S3 バケットアクセス：「はい、OAI を使用します」を選択
  - オリジンアクセスアイデンティティ：既存の OAI を選択か、新しく OAI を作成して選択
  - バケットポリシー：「はい、バケットポリシーを更新します」を選択
デフォルトのキャッシュビヘイビア
- ※任意で設定
関数の関連付け
- ※任意で設定
設定
- デフォルトルートオブジェクト：「index.html」と入力
「ディストリビューションの作成」を選択

これでディストリビューションが作成できました。以前は動作するようになるまで15分ほどかかりましたが、問題なければ即座に有効化のステータスになるかと思われます（設定にもよるかも）

ディストリビューションの ARN をポリシー作成で使用するので控えておきましょう。 arn:aws:cloudfront::XXXXXXXXXXXX:distribution/{※ディストリビューションID} のような形式です。また、ディストリビューションドメインも併せて確認しておきましょう。どちらも一般タブから確認できます。

設定項目に関しての補足

S3 バケットアクセスで OAI を使用

OAI については、冒頭に書いた通りです。

バケットポリシーで「はい、バケットポリシーを更新します」を選択することで、連携した S3 バケットのバケットポリシーに以下のものが追記されます。このポリシーによって、特定の OAI と紐づく CloudFront ディストリビューションのみ、アクセス許可を付与するようになっているわけです。

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity {※OAI ID}"
            },
            "Action": "s3:GetObject",
            "Resource": "{S3バケットのARN}/*"
        }
    ]
}

デフォルトルートオブジェクト

ルート階層のオブジェクトとしたいものを指定します。今回の場合は「index.html」なので、index.html でアクセスを受け取る感じです。

今回はやっていませんが、S3 バケットを直接静的サイトとして公開する設定にしている場合、その設定の中にもインデックスドキュメントを指定するところがあります。これと同様の設定のように思えますが、CloudFront 側でも設定しておく必要がありました（設定しないとブラウザからアクセスしたとき AccessDenied になりました）

S3 と CloudFront における動作確認

ここまでで S3 と CloudFront の準備はできたので、試しに手動デプロイをして動作を見てみましょう。ビルドして、その成果物をデプロイします。

create-react-app で作成した React アプリの場合は、以下でビルド。

yarn build

buildディレクトリにビルド成果物ができるので、build配下のものを作成した S3 バケットにアップロード。

作成した CloudFront ディストリビューションのドメインにアクセスして、React アプリが問題なく動作していれば OK です。

補足：S3 のみでの動作確認

もし CloudFront ディストリビューションのドメインにアクセスしても React アプリが表示されない場合。問題個所の切り分けとして、まず S3 バケットへのデプロイ内容が問題ないか確認したい時もあるでしょう。

そういった時、一時的に S3 バケットを直接静的サイトとして公開し、動作を確認するのも1つの方法です。

作成したバケットを選択
プロパティタブ → 静的ウェブサイトホスティングの「編集」を選択
静的ウェブサイトホスティング：「有効にする」を選択
ホスティングタイプ：「静的ウェブサイトをホストする」を選択
インデックスドキュメント：「index.html」を入力
エラードキュメント：任意で指定
「変更の保存」を選択

静的ウェブサイトホスティングが有効と表示されていれば公開されています。ただ、これだけだとバケット（静的サイト）へのアクセスが許可されていないため、エンドポイントにアクセスしても403で弾かれてしまう状態です。そのため、ブロックパブリックアクセスの制御と、バケットポリシーでアクセス許可を付与する必要があります。

{/*  */}

ブロックパブリックアクセス (バケット設定)では、以下の2つを一時的に無効化。

「新しいパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする」：バケットポリシーを編集できるようにするため
「任意のパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックする」：設定したバケットポリシーを介してのパブリックアクセスを受け付けるようにするため

{/*  */}

バケットポリシー編集にあたっては、以下のアクセス許可が必要になるので注意です。

s3:GetBucketPolicy
s3:PutBucketPolicy

アクセス許可タブ → バケットポリシーで「編集」を選択し、ポリシーを追記。（すでに記述しているバケットポリシーはどこかに控えておいて、ちゃんと戻せるようにしておきましょう）

指定の S3 バケットコンテンツ全てへ、読み取り許可をする例.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "{※S3 バケットの ARN}/*"
        }
    ]
}

これでエンドポイントからアクセスして、React アプリが正常に動作するか確認してみましょう。問題なければ、各種設定を戻すことを忘れないように。

IAM の準備

GitHub Actions でデプロイする際に使用する、デプロイ用の IAM ユーザを作成します。マネジメントコンソールで IAM の画面へ。

ポリシーの作成

ポリシー一覧から「ポリシーを作成」を選択
JSON に以下を記述して「次のステップ：タグ」を選択 {}の部分はこれまで控えたものに適宜置き換えてください。
タグを追加
- 任意でタグを追加し、「次のステップ：確認」を選択
ポリシーの確認
- 任意の名前と説明を入力して「ポリシーの作成」を選択

2 で記述するポリシーの JSON.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "{※S3バケットのARN}",
                "{※S3バケットのARN}/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudfront:GetDistribution",
                "cloudfront:GetDistributionConfig",
                "cloudfront:CreateInvalidation",
                "cloudfront:ListInvalidations",
                "cloudfront:GetInvalidation"
            ],
            "Resource": "{※CloudFrontディストリビューションのARN}"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudfront:ListDistributions",
                "cloudfront:ListStreamingDistributions"
            ],
            "Resource": "*"
        }
    ]
}

ユーザの作成

ユーザ一覧から「ユーザを追加」を選択
ユーザ名は任意、アクセスの種類は「プログラムによるアクセス」のみ選択して「次のステップ：アクセス権限」を選択
アクセス許可の設定
- 「既存のポリシーを直接アタッチ」を選択
- 先ほど作成したポリシーを選択
- アクセス権限の境界の設定は任意でどちらかを選択し、「次のステップ：タグ」を選択
タグの追加
- 任意（そのまま次のステップでも OK）で追加して、「次のステップ：確認」を選択
確認して「ユーザの作成」を選択
アクセスキーとシークレットキーを控えておく

Slack の準備

GitHub Actions の結果を通知するための Webhook URL を用意します。

Slack App の作成

作成時に From scratch と From an app nanifest の2パターンありますが、今回は前者で作成しています。

Slack ワークスペースのワークスペース名のところからメニューを開く
ビルド画面へ
- ※ワークスペースのオーナーの場合設定と管理 → アプリを管理する → 右上の「ビルド」
- ※オーナーでない場合その他管理項目 → アプリを管理する → 右上の「ビルド」
「Create New App」を選択
「From scratch」を選択
- App Name：任意の名前
- Development Slack Workspace：任意のワークスペース
- 「Create App」を選択

以下、作成した App の画面で進めます。

Incomming Webhook URL の作成

Building Apps for Slack の Add features and functionality を開いて、Incomming Webhooks を選択
Activate Incoming Webhooks を ON にして、「Add New Webhook to Workspace」
投稿するチャンネルを選択して、「許可する」を選択

これで Webhook URL が生成されるので控えておきます。投稿を担う Bots もあわせて作成されました。名前やアイコンを変えたければ編集しましょう。

GitHub の準備

React アプリ

React アプリをリポジトリに push して用意しておきます。

ちなみに自分はcreate-react-appにて作れる雛形でやりました。 npx や yarn コマンドでサクッと作れますが、自分は yarn を使っているので、以降は yarn コマンドで書いていきます。

# TS
yarn create react-app (アプリ名) --template typescript

それと GitHub Actions の中で ESLint を使いたいので、使いやすいように package.json の scripts に以下を追加しておきます。

"scripts": {
  .
  .
  .
  "lint": "yarn run -s eslint './src/**/*.{js,jsx,ts,tsx}'"
}

GitHub Secrets

GitHub Actions で使用する環境変数を設定します。公開したくない秘匿情報などを定義するのに向いており、GitHub Secrets に登録した変数の値は後から確認できないようになっています。

リポジトリの Settings → Secrets で以下の情報を登録しておきましょう。

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_REGION
AWS_S3_BUCKET_NAME
SLACK_WEBHOOK_URL

なお、GITHUB_TOKEN については自動で値がセットされるので、設定しなくて大丈夫です。

GitHub Actions のワークフロー定義ファイル作成

ワークフロー定義ファイルは yml で記述して、リポジトリルート直下に.github/workflows/ワークフロー定義ファイル名.ymlで配置します。配置する場所さえ合っていれば、ファイル名は何でも OK です。

今回は Lint などのチェックを行うものと、デプロイを行うものとで2種類のワークフローを作成します。内容の説明に関しては、ワークフロー定義ファイルの簡単な解説を参照ください。

Lint などのチェック用ワークフロー例

ブランチを問わず、push されたら動作するようにしてあります。今回は Lint チェックくらいしかやっておらず、もし失敗した時のみ Slack 通知をするようにしています。

name: Develop Check
on: push

env:
  project-name: ga-test

jobs:
  dev-check:
    name: Lint
    runs-on: ubuntu-20.04
    timeout-minutes: 5

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup Node
        uses: actions/setup-node@v2
        with:
          node-version: 14.17.3

      - name: Get Yarn Cache Directory Path
        id: yarn-cache-dir-path
        run: echo "::set-output name=dir::$(yarn cache dir)"

      - name: Cache Node Modules
        uses: actions/cache@v2
        with:
          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
          key: ${{ runner.os }}-${{ env.project-name }}-${{ hashFiles(format('{0}{1}', github.workspace, '/yarn.lock')) }}
          restore-keys: |
            ${{ runner.os }}-${{ env.project-name }}-

      - name: Package Install
        run: yarn install

      - name: Lint
        run: yarn lint

      - name: Slack Notification by NonSuccess
        uses: 8398a7/action-slack@v3
        if: success() != true
        with:
          status: ${{ job.status }}
          fields: repo,message,commit,author,action,eventName,ref,workflow
          author_name: 'check'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

デプロイ用のワークフロー例

workflow_run を使って、main ブランチにおいて、チェック用ワークフローが終わった後、動作するようにしています。チェック用ワークフローの成功・失敗問わず動作するため、ジョブの実行条件として事前のワークフローが成功した時という条件を設定。

name: Deploy
on:
  workflow_run:
    workflows:
      - "Develop Check"
    branches:
      - main
    types:
      - completed

env:
  project-name: ga-test

jobs:
  deploy:
    name: Build & Deploy
    runs-on: ubuntu-20.04
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    timeout-minutes: 5

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup Node
        uses: actions/setup-node@v2
        with:
          node-version: 14.17.3

      - name: Get Yarn Cache Directory Path
        id: yarn-cache-dir-path
        run: echo "::set-output name=dir::$(yarn cache dir)"

      - name: Cache Node Modules
        uses: actions/cache@v2
        with:
          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
          key: ${{ runner.os }}-${{ env.project-name }}-${{ hashFiles(format('{0}{1}', github.workspace, '/yarn.lock')) }}
          restore-keys: |
            ${{ runner.os }}-${{ env.project-name }}-

      - name: Package Install
        run: yarn install

      - name: Build
        run: yarn build

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Deploy to S3
        run: |
          aws s3 sync ./build s3://${{ secrets.AWS_S3_BUCKET_NAME }}

      - name: CloudFront Cache Clear
        run: |
          CFID=$(aws cloudfront list-distributions --query "DistributionList.Items[].{Id:Id,Origin:Origins.Items[0].DomainName}[?contains(Origin,'${{ secrets.AWS_S3_BUCKET_NAME }}.s3')] | [0].Id" | sed 's/"//g')
          echo "aws cloudfront create-invalidation ${CFID}"
          aws cloudfront create-invalidation --distribution-id ${CFID} --paths "/*"

      - name: Slack Notification
        uses: 8398a7/action-slack@v3
        if: always()
        with:
          status: ${{ job.status }}
          fields: repo,message,commit,author,action,eventName,ref,workflow
          author_name: 'deploy'
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

workflow_run イベントの注意点

この workflow_run イベントによって実行されるワークフローは、デフォルトブランチの内容をベースとして動作することに注意が必要です。

まず、デフォルトブランチ上のワークフロー定義ファイルの内容で実行されるということと。上記のワークフローの場合、main ブランチで push すれば、チェック用ワークフロー → デプロイ用ワークフローと動作するようになっているわけですが...。例えば、デフォルトブランチが develop だったとすると checkout してくるコードが develop ブランチのものになります。そのため、デプロイする内容も develop ブランチのものになるわけです。

デフォルトブランチは develop で運用しているけど、main ブランチの内容をデプロイしたいなどといった場合は、明示的に参照する ref を指定することで対応できるようです。こちらの記事が参考になります。

この仕様を理解していないと予期せぬ事故を引き起こす可能性があるので、取り扱いに十分注意しましょう。

補足：node_modules キャッシュの新しいやり方（※2021/10/24）

setup-node アクションだけで、node_modules のキャッシュ使用定義ができるようになりました。使用しているパッケージマネージャに合わせて with.cache を追加するだけで OK。こちらの方がすっきりしますね。

- name: Setup Node
  uses: actions/setup-node@v2
  with:
    node-version: 14.17.3
    cache: yarn

いざ、GitHub Actions でデプロイ

今回の定義内容では、 main ブランチに push する（もしくは main ブランチへのプルリクをマージする）ことで、デプロイ用のワークフローまで動作します。ちゃんと動作していれば、リポジトリの Actions からワークフローの状況を確認できるようになっているはずです。それぞれのステップのログも確認できるので、もしどこかでエラーになって失敗しても原因調査に役立ちます。

無事最後まで成功していれば、CloudFront ディストリビューションドメインからアクセスしてみましょう。 React アプリが問題なく表示されているでしょうか？

そして、Slack にもちゃんと通知できているでしょうか？通知の内容は以下のような感じになります。

成功 <ImageWrapper className="w-[80%]" src="screenshots/2020/github-actions-react/github-actions-slack-success.png" alt="ワークフロー成功時のSlack通知" />

キャンセル <ImageWrapper className="w-[80%]" src="screenshots/2020/github-actions-react/github-actions-slack-canceled.png" alt="ワークフローキャンセル時のSlack通知" />

失敗 <ImageWrapper className="w-[80%]" src="screenshots/2020/github-actions-react/github-actions-slack-failed.png" alt="ワークフロー失敗時のSlack通知" />

また、プルリクを出した時、そのリクエスト元ブランチのワークフロー実行状況が表示されるようになります。 <ImageWrapper className="w-[80%]" src="screenshots/2020/github-actions-react/pull-request.png" alt="ワークフロー実行ブランチでのプルリクエスト" />

ワークフロー定義ファイルの簡単な解説

ワークフロー名

GitHub の Actions 上では、この名前が表示されます。

# チェック用ワークフロー
name: Develop Check

# デプロイ用ワークフロー
name: Deploy

トリガー

onでトリガーになるイベントを指定。指定できるイベントについては以下を参照ください。

# チェック用ワークフロー
on: push

これだけだと、全ての push をトリガーとするので、ブランチやタグの指定で絞り込むことも出来ます。

# デプロイ用ワークフロー
on:
  workflow_run:
    workflows:
      - "Develop Check"
    branches:
      - main
    types:
      - completed

workflow_run は他のワークフロー実行をトリガーとするものです。

workflows：依存させるワークフロー名
branches：どのブランチで依存させるワークフローが実行された時か
types：実行するタイミング
- completed：依存させるワークフローが終了した時（成功・失敗は関係なし）
- requested：依存させるワークフローがリクエストされた時

1ファイルのワークフロー定義の中に複数のジョブがあり、その依存関係を定義する際はneedsで出来ますが、別ファイルのワークフローに依存させたい時はこの workflow_run を使います。

ワークフローの環境変数

ワークフロー全体で使用できる環境変数の指定。ここで設定したものはenv.〇〇で使用できます。

env:
  project-name: ga-test

ジョブ

ワークフローで実行するジョブ定義を記述。複数指定可能です。

# チェック用ワークフロー
jobs:
  dev-check: # ジョブID
    name: Lint # ジョブ名
    runs-on: ubuntu-20.04 # 実行環境
    timeout-minutes: 5 # タイムアウト時間（分）

    steps:
      # 各種ステップの定義

# デプロイ用ワークフロー
jobs:
  deploy:
    name: Build & Deploy
    runs-on: ubuntu-20.04
    if: ${{ github.event.workflow_run.conclusion == 'success' }} # 実行条件（今回の場合は、事前のワークフローが成功していること）
    timeout-minutes: 5

    steps:
      # 各種ステップの定義

実行環境の種類については以下を参照。あらかじめ導入されている CLI ツールなども確認できます。

どの実行環境にするとしても、なるべくバージョンまで指定した方がいいです。 latest にしていると、その対象バージョンが更新されたときに予期せず動作しなくなる可能性があるので...。

それとタイムアウト時間も設定しておいた方が無難です。ステップ定義ミスで、実行されたコマンドが入力応答待ちのままになるなど止まってしまったときに、どんどん無料枠の時間を食いつぶしてしまうことを避けられます。実際の実行時間を計測して、それに少し余裕を持たせるくらいで設定しておきましょう。

jobs.<job_id>.stepsで、そのジョブで実行するステップ処理を記述していきます。

ステップ・リポジトリのチェックアウト

リポジトリのコードを落としてきます。どのブランチの内容を参照するかは、トリガーイベントによって異なることに注意です。

- name: Checkout
  uses: actions/checkout@v2

usesで指定している actions は、あらかじめ実行する処理を定義しているもので、これを使用することでステップを組み立てやすくなります。実行環境のバージョンと同様に、このアクションのバージョンもなるべく指定しておいた方がいいです。

ステップ・Node.js のセットアップ

ちなみに Node.js だけでなく、いろんな言語のセットアップ action が提供されています。

- name: Setup Node
  uses: actions/setup-node@v2
  with:
    node-version: 14.17.3

ステップ・yarn のキャッシュを格納するディレクトリのパスを取得

- name: Get Yarn Cache Directory Path
  id: yarn-cache-dir-path
  run: echo "::set-output name=dir::$(yarn cache dir)"

ステップ・キャッシュの復元もしくは作成

keyの完全一致で既存のキャッシュを探し、マッチすればキャッシュをpathに復元。なければrestore-keyの完全一致で既存のキャッシュを探し、マッチすればキャッシュをpathに復元。さらになければrestore-keyの部分一致で既存のキャッシュを探し、見つければ最新のキャッシュをpathに復元。

keyの完全一致がなかった場合、このワークフローが成功して完了した際にキャッシュを作成します。

今回の場合は key の一部として yarn.lock の内容をハッシュ化しているため、もしその内容に変更があった時に key が変わるようになっています。

- name: Cache Node Modules
  uses: actions/cache@v2
  with:
    path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
    key: ${{ runner.os }}-${{ env.project-name }}-${{ hashFiles(format('{0}{1}', github.workspace, '/yarn.lock')) }}
    restore-keys: |
      ${{ runner.os }}-${{ env.project-name }}-

キャッシュのあるなしで実行時間を比較してみたところ、こんな感じになりました。

キャッシュなし・50s <ImageWrapper src="screenshots/2020/github-actions-react/github-actions-no-cache.png" alt="キャッシュなしの場合のワークフロー実行結果" />

キャッシュあり・26s <ImageWrapper src="screenshots/2020/github-actions-react/github-actions-cache.png" alt="キャッシュありの場合のワークフロー実行結果" />

ステップ・yarn でライブラリのインストール

- name: Package Install
  run: yarn install

ステップ・ESLint で静的解析チェック

あらかじめpackage.jsonに定義しておいた、ESLint 実行コマンドを実行。

- name: Lint
  run: yarn lint

ステップ・yarn でビルド

ビルドの成果物は./buildに格納されます。

- name: Build
  run: yarn build

ステップ・AWS Credentials の設定

元々この記事では以下のアクションを使って、S3 デプロイ + CloudFront のキャッシュクリアを行う方法を紹介していました。

2021/09/05 時点で最終更新が 2020/06/05 であることと、内部的に使用されている AWS CLI が1系であることから、記事更新にあたって手動でコマンド実行する形式に変更しました。（このアクションで内部的に実行されているコマンドを参考にしています）今回使用している実行環境の Ubuntu 20.04 では AWS CLI の2系が導入済みなので、それを使っていきます。

# デプロイ用ワークフロー
- name: Configure AWS Credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
    aws-region: ${{ secrets.AWS_REGION }}

ステップ・S3 バケットにデプロイ

ビルド生成物を S3 バケットに同期させる形で反映させています。

# デプロイ用ワークフロー
- name: Deploy to S3
  run: |
    aws s3 sync ./build s3://${{ secrets.AWS_S3_BUCKET_NAME }}

ステップ・CloudFront ディストリビューションのキャッシュクリア

ディストリビューション ID も GitHub Secrets に設定して、そこから使う手もありますが、今回は S3 バケット名から辿って特定する形式にしています。特定した ID をそのまま渡すと、余分なダブルクォートがついて"ディストリビューションID"というディストリビューション ID でアクセスしに行くため、アクセス許可がないよと弾かれてしまいました。そのため、sed を使ってダブルクォートを削除したうえで使用しています。

# デプロイ用ワークフロー
- name: CloudFront Cache Clear
  run: |
    CFID=$(aws cloudfront list-distributions --query "DistributionList.Items[].{Id:Id,Origin:Origins.Items[0].DomainName}[?contains(Origin,'${{ secrets.AWS_S3_BUCKET_NAME }}.s3')] | [0].Id" | sed 's/"//g')
    echo "aws cloudfront create-invalidation ${CFID}"
    aws cloudfront create-invalidation --distribution-id ${CFID} --paths "/*"

ステップ・Slackに通知

if で通知する条件を指定。

success()：ジョブの前のステップが成功した場合
always()：ジョブのこのステップが実行された場合
cancelled()：ワークフローがキャンセルされた場合
failure()：ジョブの前のステップが失敗した場合、もしくはジョブが失敗した場合

status で指定している job.statusにはそのジョブの成功、失敗、キャンセルに応じた値が入ります。 fields は通知内容です。デフォルトでは repo と message のみとなっていますので、お好みで設定。

# チェック用ワークフロー
- name: Slack Notification by NonSuccess
  uses: 8398a7/action-slack@v3
  if: success() != true
  with:
    status: ${{ job.status }}
    fields: repo,message,commit,author,action,eventName,ref,workflow
    author_name: 'check'
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

# デプロイ用ワークフロー
- name: Slack Notification
  uses: 8398a7/action-slack@v3
  if: always()
  with:
    status: ${{ job.status }}
    fields: repo,message,commit,author,action,eventName,ref,workflow
    author_name: 'deploy'
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # 自動で設定される
    SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} # Slack投稿用のWebhook URL

とりあえずデプロイまで無事到達できてよかったのですが、色々検証しながらやっていたら、かなり時間を使ってました(苦笑) まぁ、はじめてやることに時間かかるのはつきものでしょうか。 GitHub Actions を使おうとしている方の何かの参考になれば幸いです。

参考リンクまとめ

ルーティングライブラリ、React Router(v5)入門

Sat, 08 Feb 2020 00:00:00 GMT

前回は React の基礎的なことをまとめましたが、今回は React アプリのルーティング設定をするうえでよく使われている React Router についてまとめました。

※この記事は元々 Qiita からの転載です。現在は Qiita でなく Zenn の方で更新しています。

※2021/08/22追記 TypeScript ベースで、全体的に大幅加筆修正を行いました。 ※2022/01/24追記あくまでライブラリの記事であるとわかりやすくするために、記事タイトルを変更しました（旧：React入門～React Router(v5)編～）

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

React Router とは？

最新 <OG url="https://reacttraining.com/react-router" />

5系 <OG url="https://v5.reactrouter.com" />

React で SPA を書くにあたって、DOM を書き換えて複数ページがあるように見せても URL が変わらないため、ブラウザからは1つのページとしてしか認識されません。そこで、SPA の画面状態と URL とを紐づけ、さらにブラウザ履歴の同期を行います。そうすることで、疑似的なページ遷移を実現できます。

これにより URL を指定して直接特定の画面にいけたり、ブラウザバックを利用できるようになるわけです。また、クライアントサイドでのページ遷移となるため、高速に遷移します。

これを行ってくれるデファクトのルーティングライブラリがReact Routerです。ブラウザ履歴を管理する History API を React Router を通して操作していく形になります。

インストール

React Router は Web とネイティブともに対応しています。今回は Web アプリに導入するので、react-router-dom とその型定義を追加。

yarn add react-router-dom @types/react-router-dom

react-router も必要になりますが、react-router-dom の依存関係にあるので、一緒に追加されます。

今回の使用バージョンは以下のとおりです。

React：17.0.2
react-router-dom：5.2.0
react-router：5.2.0
@types/react-router-dom：5.1.8

※2022/01/24追加 2021/11に6系がリリースされましたが、当記事では5系を扱っていることに注意です。 5系と6系とでは、破壊的な変更も行われています。

基本的な使い方

これ以降のコードは公式ドキュメントをコードを引用、もしくは元にしています。

import { VFC } from 'react';
import {
  BrowserRouter,
  Switch,
  Route,
  Link
} from 'react-router-dom';

const Home: VFC = () => {
  return <h2>Home</h2>;
}

const About: VFC = () => {
  return <h2>About</h2>;
}

const Users: VFC = () => {
  return <h2>Users</h2>;
}

const App: VFC = () => {
  return (
    <BrowserRouter>
      <div>
        <nav>
          <ul>
            <li>
              <Link to='/'>Home</Link>
            </li>
            <li>
              <Link to='/about'>About</Link>
            </li>
            <li>
              <Link to='/users'>Users</Link>
            </li>
          </ul>
        </nav>

        <Switch>
          <Route path='/about'>
            <About />
          </Route>
          <Route path='/users'>
            <Users />
          </Route>
          <Route path='/'>
            <Home />
          </Route>
        </Switch>
      </div>
    </BrowserRouter>
  );
}

export default App;

ルーティングに必要なものを import

使用するコンポーネントを import します。

import {
  BrowserRouter,
  Switch,
  Route,
  Link
} from 'react-router-dom';

ルート階層で、コンポーネント全体をプロバイダーコンポーネントで囲う

React Router が提供しているプロバイダーコンポーネントは複数存在しています。

BrowserRouter：HTML の History API（pushState、replaceState、popstate イベント）を使用して UI を URL と同期させるルーター
HashRouter：URL のハッシュ部分（window.location.hash）を使用して UI を URL と同期させるルーター
StaticRouter：location を変更しないルーター
MemoryRouter：URL の履歴をメモリに保持するルーター（アドレスバーの読み取りまたは書き込みは行わない）

この中で、今回はBrowserRouterを使っていきます。現在の一般的な SPA 開発では、このBrowserRouterを使われることが多いようです。

const App: VFC = () => {
  return (
    <BrowserRouter>
    .
    .
    .
    </BrowserRouter>
  )
}

プロバイダーコンポーネントとはなんぞや？という方は、このコンポーネントの子コンポーネント全体に特定の値や機能を提供するものと、まずは思ってもらえればいいかなと。（context の話が出てくることになりますが、ここでは書きません）

上記のプロバイダーコンポーネントでは、ルーティングに関する機能を提供してくれます。ルート階層で囲っておくことで、その下層のコンポーネントでルーティングに関する機能が使えるようになるわけです。

ルーティングの定義

Switchコンポーネントで囲い、その中にRouteコンポーネントでそれぞれのルートを定義。このSwitchコンポーネントは、現在の URL と一致する Route を上から順に探し、最初に一致するルートの内容を返すようになっています。

注意点として、通常では前方一致で比較します。例として path が/aboutの場合、/about/aなどでも一致とみなされます。精度を変えたい場合は、ルート照合の精度指定参照。

const Home: VFC = () => {
  return <h2>Home</h2>;
}

const About: VFC = () => {
  return <h2>About</h2>;
}

const Users: VFC = () => {
  return <h2>Users</h2>;
}
.
.
.
<Switch>
  <Route path='/about'>
    <About />
  </Route>
  <Route path='/users'>
    <Users />
  </Route>
  <Route path='/'>
    <Home />
  </Route>
</Switch>

なお、Route の path は一度に複数定義も可能です。以下の場合は、/about、/profile両方で About コンポーネントをレンダリングします。

<Route path={['/about', '/profile']}>
  <About />
</Route>

リンクの作成

Linkコンポーネントでリンクを作成。to でリンク先情報を指定。後に a タグへ変換されることになりますが、通常の a タグと違い、クライアントサイドで遷移が動作します。通常の a タグを使うと React Router の管理外となり、アプリ全体が再読み込みされて履歴が消えてしまうので注意。内部リンクは Link コンポーネント、外部リンクは a タグと使い分けるイメージです。

なお、この例では同じコンポーネント内に共存していますが、LinkコンポーネントはSwitchやRouteコンポーネントを使用しているコンポーネント内でしか使用できないということはありません。ルーティングプロバイダーコンポーネントの配下であれば、どこでも使用できます。

<nav>
  <ul>
    <li>
      <Link to='/'>Home</Link>
    </li>
    <li>
      <Link to='/about'>About</Link>
    </li>
    <li>
      <Link to='/users'>Users</Link>
    </li>
  </ul>
</nav>

ちなみに、リンク URL と現在の URL が一致した時に、スタイルを追加できる NavLink コンポーネントという拡張バージョンがあったりもします。 <OG url="https://v5.reactrouter.com/web/api/NavLink" />

これで基本的なルーティングが作成できました。

Hooks API

React Router が提供しているフックは以下の4種類です。

useHistory
useLocation
useParams
useRouteMatch

useHistory

<OG url='https://v5.reactrouter.com/web/api/history' /> React Router が提供する history オブジェクトを返すフック。

履歴の数である length 最後に実行されたアクションである action（PUSH・REPLACE・POP） location オブジェクトとブラウザ履歴に関する関数などを持っているものです。

この history オブジェクトは HTML の History API と完全一致ではありませんが、おおよそ似たようなブラウザ履歴に関する処理ができるようになっています。

// 履歴の追加
history.push('/about')

// 履歴の追加 + ユーザ定義データの受け渡し
history.push('/about', { someState: 'foo' });

// 履歴の書き換え
history.replace('/about');

// 履歴の書き換え + ユーザ定義データの受け渡し
history.replace('/about', { someState: 'foo' });

// 履歴を2つ（引数の値分）進める
history.go(2);

// 履歴を1つ戻る
history.goBack();

// 履歴を1つ進める
history.goForward();

// 上記の履歴変更の前に記述しておくと、遷移前にアラートを出す
history.block('このページを離れますか？');

特定の処理後に遷移させたい（例：ログアウト処理後にログイン画面へリダイレクト）時や、特定の要素をクリックしたときに遷移させたい時などに活用できます。

ボタンを押した時に遷移させる例.

import { VFC } from 'react';
import { useHistory } from 'react-router-dom';

const Home: VFC = () => {
  const history = useHistory();

  const handleClick = () => {
    history.push('/about');
  };

  return (
    <>
      <h2>Home</h2>
      <button type="button" onClick={handleClick}>
        Go about
      </button>
    </>
  );
};

export default Home;

history オブジェクトの中身（history.push で /about に遷移した後の例） <ImageWrapper className="w-[70%]" src="screenshots/2020/react-router/history.png" alt="コンソールに出力したhistoryオブジェクトの内容" />

あくまで処理の中でブラウザ履歴の操作をしているので、場合によっては、ユーザから見てクリックするまで挙動がわからない。遷移なのに別タブで開くことができない。となってしまう可能性があります。特定の要素をクリックで遷移させたい時は、Linkコンポーネントの使用も検討してみましょう。

useLocation

<OG url="https://v5.reactrouter.com/web/api/location" /> React Router が提供する location オブジェクトを返すフック。

location オブジェクトは以下の情報を持っています。

pathname：URL
search：クエリパラメータ
hash：URL ハッシュ
state：ユーザ定義のデータ

これらの情報はLinkコンポーネントや、history オブジェクトで履歴操作時に渡すことができます。その情報を遷移先のコンポーネント側で使いたい場合に活用します。

import {
  BrowserRouter,
  Switch,
  Route,
  Link,
} from 'react-router-dom';

const to = {
  pathname: '/users',
  search: '?class=A',
  hash: '#user-hash',
  state: { test: 'test-state' }
};
.
.
.
<Link to={to}>Users</Link>
.
.
.
<Switch>
  <Route path='/users'>
    <Users />
  </Route>
</Switch>

import { VFC } from 'react';
import { useLocation } from 'react-router-dom';

const Users: VFC = () => {
  const location = useLocation();
  return (
    <>
      <h2>Users</h2>
      <p>pathname：{location.pathname}</p>
      <p>search：{location.search}</p>
      <p>hash：{location.hash}</p>
      <p>state：{(location.state as { test: string }).test}</p>
    </>
  );
}

export default Users

location オブジェクトの中身 <ImageWrapper className="w-[70%]" src="screenshots/2020/react-router/location.png" alt="コンソールに出力したlocationオブジェクトの内容" />

動作 <ImageWrapper className="w-[80%]" src="gifs/2020/react-router/router-uselocation.gif" alt="useLocationを使用した場合の動作GIF" />

ちなみにクエリパラメータを取り出して扱いたい場合は、query-stringというライブラリを使うと便利です。

location オブジェクトのクエリパラメータに対して、以下のようにすると{ class: 'A' }のようにオブジェクト形式に変換してくれるため、扱いやすくなります。

import queryString from 'query-string';
.
.
.
queryString.parse(location.search)

クエリパラメータを頻繁に扱う場合は、あらかじめuseLocationとquery-stringを組み合わせたカスタムフックを作っておく手もありです。

useParams

<OG url="https://v5.reactrouter.com/web/api/match" /> React Router が提供する match オブジェクトの中から、パスパラメータ部分のみ返すフック。遷移元から受け取ったパスパラメータを保持しているため、その情報を遷移先のコンポーネント側で使いたい場合に活用します。

パスパラメータを受け付けるようにするには、Route コンポーネントの path で:aboutIdのように:をつけて定義。この状態で、リンク時にパスパラメータを指定するようにすれば、遷移先の方で取り出せます。

import { VFC } from 'react';
import {
  BrowserRouter,
  Switch,
  Route,
  Link,
  useParams
} from 'react-router-dom';
.
.
.
<Link to='/about/1'>About</Link>
.
.
.
<Switch>
  <Route path='/about/:aboutId'>
    <About />
  </Route>
</Switch>

const About: VFC = () => {
  // { aboutId: '1' } からの、分割代入 + ショートハンド
  const { aboutId } = useParams<{aboutId: string}>();
  return <h2>About：{aboutId}</h2>
}

動作 <ImageWrapper className="w-[80%]" src="gifs/2020/react-router/router-useparam.gif" alt="usePamramを使用した場合の動作GIF" />

ちなみにパスパラメータ定義に?をつけると任意パラメータにもできたりします。

<Route path='/about/:aboutId?'>
  <About />
</Route>

const About: VFC = () => {
  const { aboutId } = useParams<{aboutId?: string}>();
  return <h2>About：{aboutId ?? 'none' }</h2>
}

useRouteMatch

<OG url="https://v5.reactrouter.com/web/api/match" /> React Router が提供する match オブジェクトを返すフック。

match オブジェクトは以下の情報を持っています。

path：ルートパス
url：URL
isExact：URL がルートパスと一致するか
params：パスパラメータのオブジェクト

Route コンポーネントが現在の URL を照合するのと同じ方法で、照合するようになっているようです。

活用例の1つとして、ネストしたルーティングを実現できます。

import { VFC } from 'react';
import {
  BrowserRouter,
  Switch,
  Route,
  Link,
  useRouteMatch
} from 'react-router-dom';

const Home: VFC = () => {
  return <h2>Home</h2>;
}

const Topics: VFC = () => {
  const match = useRouteMatch();

  return (
    <div>
      <h2>Topics</h2>

      <ul>
        <li>
          <Link to={`${match.url}/components`}>Components</Link>
        </li>
        <li>
          <Link to={`${match.url}/props-v-state`}>
            Props v. State
          </Link>
        </li>
      </ul>

      <Switch>
        <Route path={`${match.path}/components`}>
          <h3>Components</h3>
        </Route>
        <Route path={`${match.path}/props-v-state`}>
          <h3>props-v-state</h3>
        </Route>
      </Switch>
    </div>
  );
}

const App: VFC = () => {
  return (
    <BrowserRouter>
      <div>
        <ul>
          <li>
            <Link to='/'>Home</Link>
          </li>
          <li>
            <Link to='/topics'>Topics</Link>
          </li>
        </ul>

        <Switch>
          <Route path='/topics'>
            <Topics />
          </Route>
          <Route path='/'>
            <Home />
          </Route>
        </Switch>
      </div>
    </BrowserRouter>
  );
}

export default App;

match オブジェクトの中身 <ImageWrapper className="w-[70%]" src="screenshots/2020/react-router/match.png" alt="コンソールに出力したmatchオブジェクトの内容" />

動作 <ImageWrapper className="w-[80%]" src="gifs/2020/react-router/router-nest.gif" alt="ネストしたルーティングの動作GIF" />

その他の使い方

ルート定義方法の種類

Switch コンポーネント + Route コンポーネントで囲う形で子要素として渡す

現在推奨されるスタンダードなやり方。 Switchコンポーネントを使用しているため、配下の Route を上から順に照合していって、最初に一致したものがレンダリングされます。

<Switch>
  <Route path='/about'>
    <About />
  </Route>
  <Route path='/users'>
    <Users />
  </Route>
  <Route path='/'>
    <Home />
  </Route>
</Switch>

この他にも指定方法はありますが、それらは主に Hooks API が導入される前のバージョンで使われていた方法で、以下のようなものがあります。これらをSwitchコンポーネントと併用しない場合は、一致するルート全てがレンダリングされることになるため、扱いには注意が必要です。

Route コンポーネントの component に渡す

<Route path='/about' component={About} />
<Route path='/users' component={Users} />
<Route path='/home' component={Home} />

この方法の特徴として、React Router は React.createElement を使用して、指定されたコンポーネントから新しい React 要素を作成します。レンダリングごとに新しいコンポーネントを作成する形になるようです。そのため、既存コンポーネントを更新するだけでなく、既存コンポーネントをアンマウント → 新しいコンポーネントをマウントのような挙動になるとのこと。

また、この方法では、渡すコンポーネントに props を指定できません。その代わりに、RouteComponentProps型のオブジェクトが props へ渡されるようになっています。

このRouteComponentPropsには以下のものが含まれています。

history オブジェクト
location オブジェクト
match オブジェクト
staticContext

通常これらは Hooks API で取得できるものです。

component、render、children が同時に定義されていた場合、component は2番目の優先度となります。

Route コンポーネントの render に渡す

<Route path="/about" render={() => <About />} />
<Route path="/users" render={() => <Users />} />
<Route path="/home" render={() => <Home />} />

ルートが一致したときに呼び出される関数として定義するやり方。この render の引数には、RouteComponentProps型のオブジェクトが渡されるようになっているので、それを利用した処理が可能です。

component、render、children が同時に定義されていた場合、render は3番目の優先度となります。

Route コンポーネントの children に渡す

<Route path="/about" children={() => <About />} />
<Route path="/users" children={() => <Users />} />
<Route path="/home" children={() => <Home />} />

render の時と似ていますね。挙動としても render と似ていますが、children に渡している関数は、ルートが一致したかどうかに関係なく呼び出されます。ルートが一致した時のみ、同様に引数へRouteComponentProps型のオブジェクトが渡されるようになっているため、ルートが一致するかどうかで UI を動的に切り替えるようなことも可能とのこと。

component、render、children が同時に定義されていた場合、children は1番目の優先度となります。

リンク定義方法の種類

URL 形式

URL のみのシンプルなパターン。

<Link to='/about'>About</Link>

オブジェクト形式

location オブジェクト形式のパターン。

<Link
  to={{
    pathname: '/about',
    search: '?class=A',
    hash: '#user-hash',
    state: { test: 'test-state' }
  }}
>
  About
</Link>

関数形式

現在の location 情報を引数として、location オブジェクト形式か URL 形式を返すパターン。

// オブジェクト形式
<Link to={location => ({ ...location, pathname: '/about' })} >About</Link>

// URL 形式
<Link to={location => `${location.pathname}?sort=name`} >About</Link>

ルート照合の精度指定

デフォルトは前方一致です。

完全一致

exact をつけます。

<Route path='/about' exact>
  ...
</Route>

末尾スラッシュ有無確認

path の末尾にスラッシュをつける + strict をつけます。 /abount/に対して/aboutは一致とみなされません。

<Route path='/about/' strict>
  ...
</Route>

大文字・小文字確認

sensitive をつけます。大文字小文字を厳密に照合するようになります。

<Route path='/about' sensitive>
  ...
</Route>

ルート定義していない URL にアクセスされた場合のルート定義

Routeコンポーネントの path で*を指定すると全受けにできるのを利用します。 Switchコンポーネントの仕様上、上から Route を照合していくので、最後に追加しておきます。

<Switch>
  <Route path='/about'>
    <About />
  </Route>
  <Route path='/users'>
    <Users />
  </Route>
  <Route path='*'>
    <Error />
  </Route>
</Switch>

アプリ内リダイレクト

history.replace

useHistoryの項でも書いた通り、history.replaceで履歴の書き換えができるので、これで対応できます。ロジックの中でリダイレクトさせたい時など。

Redirect コンポーネント

to にリダイレクト先情報（URL 形式、location オブジェクト形式）を指定することで、そちらにリダイレクトさせられます。何らかのフラグ変数によって、リダイレクトさせるか切り分ける時など。

以下はauthenticated変数によって遷移する先を変化させている例です。

<Switch>
  <Route path='/mypage'>
    {authenticated ? <MyPage /> : <Redirect to="/" />}
  </Route>
  <Route path='/login'>
    {authenticated ? <Redirect to="/mypage" /> : <Login />}
  </Route>
</Switch>

ログインしている時にログイン画面へアクセスすると、マイページ画面にリダイレクト。ログインしていない時にマイページ画面へアクセスすると、ログイン画面にリダイレクト。といった感じ。

毎回、分岐を書くのがめんどくさければ、認証ルート用と非認証用ルートで Route コンポーネントの薄いラッパーを作るのもありです。公式の example - Redirects(Auth) が参考になります。 <OG url="https://v5.reactrouter.com/web/example/auth-workflow" />

また、以下のような書き方もできます。こちらの場合は from を使用していて、from の URL にアクセスされたら、to の location にリダイレクトします。

<Switch>
  <Redirect from='/test' to='/other' />
  <Route path='/other'>
    <Other />
  </Route>
  .
  .
  .
</Switch>

フレンドリーフォワーディング

ログイン時にしかアクセスできない画面に、未ログイン状態でアクセスしたとします。大体の Web アプリはログイン画面にリダイレクトして、ログインを要求されるでしょう。そうやってログインした後、ログイン後のアプリトップ画面でなく、元々アクセスしようとしていた画面に遷移してくれると嬉しいよね。というやつのことです。

クエリパラメータに URL を保持しておいて、ログイン後にその URL へリダイレクトさせる。というのを割と見かける気がしますが、以下の例では location オブジェクトの state を活用してみています。

まず以下のような認証ルート用のラッパーコンポーネントを用意。

type Props = ComponentPropsWithRef<typeof Route>;

const AuthRoute: VFC<Props> = ({ children, ...rest }) => {
  // 認証情報を取得
  const { authenticated } = useAuth();

  return (
    <Route
      {...rest}
      render={({ location }) =>
        authenticated ? (
          children
        ) : (
          <Redirect
            to={{
              pathname: '/login',
              state: { from: location }
            }}
          />
        )
      }
    />
  );
}

認証していれば、子要素のコンポーネントを返す。認証しなければ、ログイン画面へリダイレクトする。というものです。リダイレクト時に、その時の location 情報（元々アクセスしようとしていた画面情報）を state にセットしておきます。

あとは Login コンポーネント側でそれを取得しておいて、ログイン後にその Location 情報でリダイレクトさせれば OK です。

import { Location } from 'history';
.
.
.
const Login: VFC = () => {
  const history = useHistory();
  const location = useLocation();
  const { login } = useAuth();

  const { from } = (location.state as { from: Location }) || { from: { pathname: '/' } };

  const handleLogin = () => {
    login(); // ログイン処理
    history.replace(from);
  };

  return (
    <div>
      <form>
        {/* フォーム要素 */}
        .
        .
        .
        <button type="submit" onClick={handleLogin}>ログイン</button>
      </form>
    </div>
  );
}

これも先ほど触れた公式の example - Redirects(Auth) が参考になります。

※2021/08/21追記全体加筆修正・更新にあたり、現在は Hooks API を使うことが一般的になっているため、HOC 式の項は削除しました。 HOC 式が気になるという方は、公式ドキュメント withRouter をご参照ください。 <OG url="https://v5.reactrouter.com/web/api/withRouter" />

参考リンクまとめ

GAS + スプレッドシート + Slackで当番決めに使えるガチャを作ってみた

Sun, 19 Jan 2020 00:00:00 GMT

GAS こと Google Apps Script は、手軽に bot や他の Google サービスと連携したツールを作れるから、ちょっと楽しいですよね。今回はスプレッドシートと組み合わせて、Slack から呼び出して使えるガチャを作ってみました。

※この記事は Qiita からの転載です。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

作ろうと思った背景

自分が所属している事業部では、毎月月末にとある当番を決めるのに Slack Bot を使ってガチャみたいにやっていました。

ただ、これだと設定された文言のいずれかをランダムで返しているだけなので、先月に担当した人がまた抽選されたりといった問題がありました。

そこで当番履歴をスプレッドシートに記録しておいて、抽選のたびに当番履歴のメンバーを除外して、抽選するようにすればいいんじゃないか？と思い、思い切って作ってみました。

※2020/01/27追記 当月の当番抽選がすでに行われており、当月の当番履歴がすでにある場合は、新たに抽選せずにその履歴情報から当番を通知するように改修しました。

構成図

全体の処理のおおまかな流れとしてはこんな感じです。

※下部でも書いているのですが、今回は旧方式の Webhook を使用しているので注意です。

作り方

Incoming Webhook の用意

まずは Slack に投稿する部分を担う、Incoming Webhook を用意します。（Slack のワークスペースはすでにあるものとして、進めていきます）

Slack ワークスペースのワークスペース名のところからメニューを開く
App 管理画面へ

※ワークスペースのオーナーの場合その他管理項目 → App 管理
※オーナーでない場合 Slackをカスタマイズ → 左上のメニューを開く → App管理

Incoming Webhook 設定の追加画面へ

※Incoming Webhook をまだ導入していない場合「App ディレクトリを検索」のところに Incoming Webhook で検索し選択 → Slack へ追加
※すでに Incoming Webhook を導入済みの場合カスタムインテグレーション → Incoming Webhook → Slack に追加

チャンネルへの投稿で、投稿したいチャンネルを選択し、Incoming Webhook インテグレーションの追加を選択
インテグレーションの設定

Webhook URL を控えておく（GAS 側で使います）
名前やアイコンを必要に応じてカスタマイズ

設定を保存を選択

スプレッドシートの用意

スプレッドシートを作成、以下のようなシートを用意します。ここではシートの名称を当番履歴表としてください。 <ImageWrapper src="screenshots/2020/duty-gacha/sheet.png" alt="用意するスプレッドシートの内容" />

メンバー表

ガチャ対象は〇か×で選択できるようにしておき、メンバーがガチャに参加するかどうかをここで制御できるようにします。ガチャ対象列のデータ範囲を選択 → データ → データの入力規則以下のように設定しておきます。 <ImageWrapper className="w-[80%]" src="screenshots/2020/duty-gacha/gacha-select.png" alt="メンバー表のデータの入力規則設定" />

Slack member_id は Slack にガチャ結果を投稿する際に、メンションをつけるために使用します。こちらは Slack 上で確認できます。チャンネルのメンバーリストなどから、メンバーを選択し簡易プロフィールを表示。アイコン画像を選択してプロフィールを表示し、三点リーダから確認。 <ImageWrapper className="w-[50%]" src="screenshots/2020/duty-gacha/slack-profile.png" alt="Slackアカウントのプロフィール画面" />

当番履歴表

履歴がある場合は記述しておきます。ない場合は、表のヘッダー部分のみ記述で問題ありません。

GAS の用意

スプレッドシート上でツール → スクリプトエディタから GAS エディタへ行けます。以下のコードを用意します（~~なお、現時点で GAS では ES6 記法は使えません~~）

※2020/2/16 追記 v8 ランタイムに対応したため、let やアロー関数などが新たに使用できるようになりました。これに伴いリファクタリングを行っています。

{/*  */}

ランタイムの変更は、GAS エディタを開いたときに表示される案内（Enable new Apps Script runtime powered by Chrome V8 for this project.）から変更する。もしくは、実行 → Chrome V8 を搭載した新しい Apps Script ランタイムを有効にするからできます。

{/*  */}

// スプレッドシートのデータを元に当番ガチャを行い、結果を Slack に投稿する
function dutyGacha() {
  // メンバー表のデータ部分のセル範囲
  const memberDataCellRange = 'A4:C23';
  // 当番履歴表の開始列
  const historyDataColumnRangeStart = 'E';
  // 当番履歴表の終了列
  const historyDataColumnRangeEnd = 'G';
  // 当番履歴表の列範囲
  const historyDataColumnRange = historyDataColumnRangeStart + ':' + historyDataColumnRangeEnd;
  // ガチャから除外する履歴件数
  const historyDataTargetNum = 5;
  // 抽選する当番の人数
  const dutyMemberNum = 2;
  let msg;
  try {
    const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('当番履歴表');
    const filterHistoryData = getFilterHistoryData(sheet, historyDataColumnRange);
    const lastIndex = filterHistoryData.length - 1;
    const thisMonthMemberNameList = getThisMonthMemberNameList(filterHistoryData, lastIndex, dutyMemberNum);
    // 当月の当番履歴情報がすでにある場合はそのメンバーの情報を取得
    if (thisMonthMemberNameList !== null) {
      const thisMonthMemberList = getThisMonthMemberList(sheet, memberDataCellRange, thisMonthMemberNameList, dutyMemberNum);
      msg = createNoticeMsg(thisMonthMemberList, false);
    // ない場合は抽選に必要な情報を取得し、抽選を行い、スプレッドシートに書き込み
    } else {
      const joinMemberList = getJoinMemberList(sheet, memberDataCellRange, dutyMemberNum);
      const historyMenberList = getHistoryMemberList(filterHistoryData, lastIndex, historyDataTargetNum, dutyMemberNum);
      const gachaMemberList = getGachaMemberList(joinMemberList, historyMenberList, dutyMemberNum);
      const dutyMemberList = getDutyMemberList(gachaMemberList, dutyMemberNum);
      msg = createNoticeMsg(dutyMemberList, true);

      const insertRow = sheet.getRange(historyDataColumnRangeStart + sheet.getMaxRows()).getNextDataCell(SpreadsheetApp.Direction.UP).getRow() + 1;
      const insertRange = historyDataColumnRangeStart + insertRow + ':' + historyDataColumnRangeEnd + insertRow;
      const insertDataArr = createInsertData(dutyMemberList);
      // スプレッドシートに当月当番データを書き込み
      sheet.getRange(insertRange).setValues(insertDataArr);
      // スプレッドシートに書き込んだ行に罫線を引く
      sheet.getRange(insertRange).setBorder(false, true, true, true, true, false);
    }
  } catch (e) {
    msg = 'エラーが発生しました：' + '\nstack：\n' + e.stack;
    Logger.log(msg);
  }

  try {
    const WEBHOOK_URL = PropertiesService.getScriptProperties().getProperty('WEBHOOK_URL');
    const jsonData =
        {
          'text': msg
        };
    const payload = JSON.stringify(jsonData);
    const options =
        {
          'method': 'post',
          'contentType': 'application/json',
          'payload': payload
        };
    UrlFetchApp.fetch(WEBHOOK_URL, options);
  } catch (e) {
    Logger.log('送信エラー：' + '\nstack：\n' + e.stack);
  }
}

// 当番履歴表の列のデータから空白セルを除いたものを返す
function getFilterHistoryData(sheet, historyDataColumnRange) {
  const range = sheet.getRange(historyDataColumnRange);
  const historyData = range.getValues();
  return historyData.filter(data => data[0] !== '');
}

// 当番履歴表に当月当番の情報があればそのメンバー名を、なければ null を返す
function getThisMonthMemberNameList(filterHistoryData, lastIndex, dutyMemberNum) {
  if (Utilities.formatDate(filterHistoryData[lastIndex][0], 'JST', 'yyyy/MM')
                           === Utilities.formatDate(new Date(), 'JST', 'yyyy/MM')) {
    const historyDataTargetNum = 1;
    return getHistoryMemberList(filterHistoryData, lastIndex, historyDataTargetNum, dutyMemberNum);
  } else {
    return null;
  }
}

// メンバー表から当月当番メンバーの slack_id と名前を抽出して、オブジェクトの配列で返す
function getThisMonthMemberList(sheet, memberDataCellRange, thisMonthMemberNameList, dutyMemberNum) {
  const memberData = sheet.getRange(memberDataCellRange).getValues();
  let thisMonthMemberList = [];
  memberData.map(data => {
    if (thisMonthMemberNameList.includes(data[2])) {
      thisMonthMemberList.push({id: data[1], name: data[2]});
    }
  });
  if (thisMonthMemberList.length < dutyMemberNum) {
    throw new Error('当月当番メンバーの情報がメンバー表に不足しています。');
  }
  return thisMonthMemberList;
}

// メンバー表からガチャ参加メンバーの slack_id と名前を抽出して、オブジェクトの配列で返す
function getJoinMemberList(sheet, memberDataCellRange, dutyMemberNum) {
  const memberData = sheet.getRange(memberDataCellRange).getValues();
  let joinMemberList = [];
  memberData.map(data => {
    if (data[0] === '〇') {
      joinMemberList.push({id: data[1], name: data[2]});
    }
  });
  if (joinMemberList.length < dutyMemberNum) {
    throw new Error('ガチャ参加メンバーが抽選する当番の人数より少ないです。ガチャ参加メンバーを増やしてください。');
  }
  return joinMemberList;
}

// 当番履歴表から指定件数分の履歴メンバーを抽出して配列で返す
function getHistoryMemberList(filterHistoryData, lastIndex, historyDataTargetNum, dutyMemberNum) {
  let historyMenberList = [];
  for (let i = 0; i < historyDataTargetNum; i++) {
    for (let l = 1; l <= dutyMemberNum; l++) {
      if (filterHistoryData[lastIndex - i][l] === '') {
        continue;
      }
      if (filterHistoryData[lastIndex - i][l].match(/当番.*/)) {
        return historyMenberList;
      }
      historyMenberList.push(filterHistoryData[lastIndex - i][l]);
    }
  }
  return historyMenberList;
}

// ガチャ参加メンバーから履歴メンバーを除外したものを配列で返す
function getGachaMemberList(joinMemberList, historyMenberList, dutyMemberNum) {
  const gachaMemberList = joinMemberList.filter(data => historyMenberList.indexOf(data.name) === -1);
  if (gachaMemberList.length < dutyMemberNum) {
    throw new Error('ガチャ参加メンバーから履歴メンバーを除外した数が、抽選する当番の人数より少ないです。ガチャ参加メンバーを増やしてください。');
  }
  return gachaMemberList;
}

// 抽選する当番人数分、当番抽選を行い、当月の当番メンバーの配列を返す
function getDutyMemberList(gachaMenberList, dutyMemberNum) {
  let dutyMemberList = [];
  let index;
  for (let i = 0; i < dutyMemberNum; i++) {
    do {
      index = random(gachaMenberList.length);
    } while (dutyMemberList.includes(gachaMenberList[index]));
    dutyMemberList[i] = gachaMenberList[index];
  }

  return dutyMemberList;
}

// 0～(length-1)の乱数を返す
function random(length) {
  //例 5人の場合 0~0.9999… * 5 の小数点切り捨てで、0~4になる
  return Math.floor(Math.random() * length);
}

// Slack 通知メッセージを作成して返す
function createNoticeMsg(noticeMemberList, gachaFlg) {
  let noticeMsg = '今月の当番\n';
  // 新たにガチャを行った場合の通知メッセージ
  if (gachaFlg) {
    noticeMemberList.forEach(memberData => {
      noticeMsg += ':penguin:<ﾃﾞﾚﾚﾚﾚﾚﾃﾞﾃﾞﾝ!!　<' + memberData.id + '> さん\n';
    });
  // 新たにガチャを行わなかった場合の通知メッセージ
  } else {
    noticeMemberList.forEach(memberData => {
      noticeMsg += ':penguin:<ﾃﾞﾃﾞﾝ!!　<' + memberData.id + '> さん\n';
    });
    noticeMsg += '(すでに今月ガチャ済み)\n';
  }
  return noticeMsg;
}

// スプレッドシートに記録する当月データの二次元配列を返す
function createInsertData(dutyMemberList) {
  let insertData = [Utilities.formatDate(new Date(), 'JST', 'yyyy/MM')];
  dutyMemberList.forEach(memberData => insertData.push(memberData.name));
  const insertDataArr = [insertData];
  return insertDataArr;
}

大まかな流れとしては以下のような感じです。

※シートデータの当番履歴表に当月の当番情報がすでにある場合.

スプレッドシートの当番履歴表シートのデータをまるごと取得
↓
当番履歴表に当月の当番情報があるかチェック
↓
シートデータのメンバー表から当月の当番メンバー情報のみ取得
↓
Slack 投稿メッセージの作成
↓
投稿

※シートデータの当番履歴表に当月の当番情報がなく、新たに抽選する場合

スプレッドシートの当番履歴表シートのデータをまるごと取得
↓
当番履歴表に当月の当番情報があるかチェック
↓
シートデータのメンバー表からガチャ対象が〇になっているメンバー情報のみ取得
↓
シートデータの当番履歴表から指定した件数分、履歴データを取得
↓
取得したメンバー情報から、履歴にあるメンバー情報を除外
↓
残りのメンバーで、指定当番人数分ガチャ抽選を行う
↓
Slack 投稿メッセージの作成
↓
ガチャ抽選結果をシートの当番履歴表に記述（＋罫線をひく）
↓
投稿

変数

dutyGacha 関数の最初で初期化している変数については、スプレッドシートからデータを取得するにあたってのデータ範囲の指定であったり、ガチャの機能を制御したりするものです。

特にデータ範囲に関しては、スプレッドシートの状態とあっていないと予期しない動作を起こすので注意してください。

// メンバー表のデータ部分のセル範囲
const memberDataCellRange = 'A4:C23';
// 当番履歴表の開始列
const historyDataColumnRangeStart = 'E';
// 当番履歴表の終了列
const historyDataColumnRangeEnd = 'G';
// 当番履歴表の列範囲
const historyDataColumnRange = historyDataColumnRangeStart + ':' + historyDataColumnRangeEnd;
// ガチャから除外する履歴件数
const historyDataTargetNum = 5;
// 抽選する当番の人数
const dutyMemberNum = 2;

プロパティストア

GAS にはプロパティストアという機能があります。これは、プロジェクトやドキュメントに紐付けて、キーと値形式でデータを格納できる機能で、コードにべた書きしたくない情報などを格納しておくのに向いています。いわば環境変数を別ファイルで管理するような感じです。プロパティストアには3種類あるのですが、今回はその中でプロジェクトに紐づくデータを管理できる、スクリプトプロパティを使用しています。

設定の仕方 GAS エディタ上でファイル → プロジェクトのプロパティを選択。スクリプトのプロパティタブで行を追加から。 今回の場合は、キーをWEBHOOK_URL、値を（先ほど控えたIncomming WebhookのURL）を追加します

※注意点 スクリプトプロパティの編集は、そのGASコードおよび連携している Google サービスのオーナーのアカウントでないとできません。

スクリプトプロパティを取得するには以下のようにして、キーを指定します。

const webHookUrl = PropertiesService.getScriptProperties().getProperty('WEBHOOK_URL');

投稿メッセージ

Imcoming Webhook URL へ送信する際に、以下のようにパラメータとして渡せば、それが投稿メッセージになります。（msg 変数に投稿メッセージが入っています）

// Slack 通知メッセージを作成して返す
function createNoticeMsg(noticeMemberList, gachaFlg) {
  let noticeMsg = '今月の当番\n';
  // 新たにガチャを行った場合の通知メッセージ
  if (gachaFlg) {
    noticeMemberList.forEach(function(memberData) {
      noticeMsg += ':penguin:<ﾃﾞﾚﾚﾚﾚﾚﾃﾞﾃﾞﾝ!!　<' + memberData.id + '> さん\n';
    });
  // 新たにガチャを行わなかった場合の通知メッセージ
  } else {
    noticeMemberList.forEach(function(memberData) {
      noticeMsg += ':penguin:<ﾃﾞﾃﾞﾝ!!　<' + memberData.id + '> さん\n';
    });
    noticeMsg += '(すでに今月ガチャ済み)\n';
  }
  return noticeMsg;
}

投稿メッセージに関して、絵文字も使用できます。:penguin:のようにnameで指定すればOKです。また、個人へのメンションについては<member_id>の形式で指定すると、自動的に@name形式に変換してくれます。全体メンションの場合は<!here>と<!channel>で、それぞれ@here、@channelになります。

// Slack 通知メッセージを作成して返す
function createNoticeMsg(gachaMenber, dutyMemberList) {
  let noticeMsg = '';
  dutyMemberList.forEach(function(memberData) {
    noticeMsg += ':penguin:<ﾃﾞﾚﾚﾚﾚﾚﾃﾞﾃﾞﾝ!!　<' + memberData.id + '> さん\n';
  });
  return noticeMsg;
}

Slack 投稿のテスト

ここまできたら、ガチャを行って、その内容を Slack へ投稿できるようになります。 GAS エディタ上から実行してみましょう。 GAS エディタ上で実行 → 関数を実行 → dutyGacha を選択。初回実行時はアクセス権の許可がいるので、確認して許可してください。 <ImageWrapper className="w-[70%]" src="screenshots/2020/duty-gacha/gas-run-account1.png" alt="アクセス権の許可確認モーダル１" />

なお、案内にある通り、後でこのアクセス権を確認・削除は以下から行えます。 <OG url="https://myaccount.google.com/permissions" />

当番履歴表に当月の当番情報がなく、新たに抽選した場合、以下のようにメッセージが投稿されていて、スプレッドシートの当番履歴表に履歴が追加されていたらOKです。上が member_id に該当するアカウントがある場合。下がない場合で、member_id がそのまま出力されます。 <ImageWrapper className="w-[70%]" src="screenshots/2020/duty-gacha/result-gacha.png" alt="Slack投稿結果(新たにガチャを行った場合)" />

当番履歴表に当月の当番情報がすでにある場合は、その当月の当番がSlackに投稿されていれば OK です。こちらは新たにスプレッドシートに書き込みは行いません。

うまく投稿できない場合は、ここまでの設定を見直してみてください。また、以下の場合はエラーとなるようにしています。

すでに履歴がある当月の当番メンバーの情報がメンバー表に存在しない
ガチャ参加メンバーが抽選する当番の人数より少ない
ガチャ参加メンバーから履歴メンバーを除外した数が、抽選する当番の人数より少ない

あとは、当番履歴表の下に関係ないデータを入れると、当番履歴表の最終行を取得する時におかしくなります。

ちなみに historyDataTargetNum 変数の値（ガチャから除外する履歴件数）より、当番履歴表のデータ件数が少ない場合でもエラーにはならず、存在する履歴データで処理します。

Outgoing Webhook との連携

今度は、このガチャを Slack の指定のチャンネルから実行できるようにしていきます。

Slack 側

Slack ワークスペースのワークスペース名のところからメニューを開く
App 管理画面へ

※ワークスペースのオーナーの場合その他管理項目 → App 管理
※オーナーでない場合 Slack をカスタマイズ → 左上のメニューを開く → App 管理

Outgoing Webhook 設定の追加画面へ

※Outgoing Webhook をまだ導入していない場合「App ディレクトリを検索」のところに Outgoing Webhook で検索し選択 → Slackへ追加
※すでに Outgoing Webhook を導入済みの場合カスタムインテグレーション → Outgoing Webhook → Slack に追加

ガチャを呼び出せるようにするチャンネルを選択し、Outgoing Webhook インテグレーションの追加を選択
インテグレーションの設定

トークンを控えておく（GAS 側で使います）

この段階ではまだ設定を保存としないで、そのまま設定画面のままにしておきます。

GAS 側

スクリプトプロパティに先ほど控えたトークンを登録。（ここではキーをSLACK_OUTGOING_TOKENとしています）
以下のコードを dutyGacha 関数の上に追加します。

// POST リクエスト時に当番ガチャを実行する
// （トークン認証を行い、特定の Slack チャンネルからのリクエストのみ受付）
function doPost(e) {
  const verifyToken = PropertiesService.getScriptProperties().getProperty('SLACK_OUTGOING_TOKEN');

  if (verifyToken !== e.parameter.token) {
    throw new Error("トークンが違います。");
  }
  dutyGacha();
}

Outgoing Webhook で GAS にアクセスがあった時の処理はdoPost関数で記述できます。最初にトークンで認証し、予期しないアクセスははじくようにしておき、その後に dutyGacha 関数を実行します。

GASのコードを公開 GAS エディタ上から公開 → ウェブアプリケーションとして導入.

Project version...公開するバージョンを指定。新しくバージョンを作る場合はNewを選択
Execute the app as...実行時にどのアカウントで実行するか。Meを選択
Who has access to the app...このアプリケーションへのアクセス権限。Outgoing Webhookからのアクセスを受け入れるためにAnyone, even anonymousを選択

公開するとCurrent web app URLが表示されるので控えておきます。

再度 Slack 側

インテグレーションの設定の続きを行います。

インテグレーションの設定

チャンネル...どのチャンネルから実行できるようにするか選択
引き金となる言葉...トリガーの言葉を入力（例：がちゃる）
URL...先ほど控えた GAS アプリケーションのURLを記述
名前やアイコンはそのままで問題なし

Slack 側から呼び出し

ここまで来たら、Slack の指定したチャンネルからトリガーワードで呼び出せるようになっているはずです。呼び出してみましょう。うまくメッセージが投稿され、スプレッドシートに履歴が記述されたでしょうか。

スプレッドシート上でガチャ実行

スプレッドシート上でもガチャを実行したいという場合は、適当な図形を作成して、それにスクリプトを割り当てると実現できます。

スプレッドシート上で挿入 → 図形描画で適当な図形を作成してシートに挿入
挿入した図形を右クリックで選択し、三点リーダからスクリプトの割り当てを選択
dutyGacha 関数を指定

後から設定をカスタマイズしたい時は

例として抽選する当番の人数を増やしたい時はこんな感じ。

スプレッドシートの当番履歴表の右側に列を追加する
GAS の dutyGacha 関数の最初で初期化している以下の変数の値を合わせる

historyDataColumnRangeEnd...変数の値を、追加した列に合わせる
dutyMemberNum...新しい当番人数を指定

GAS を再度公開する（公開 → ウェブアプリケーションとして導入 → New バージョンで指定して公開）

特に、3の GAS の再度公開は忘れがちなので注意して下さい。

基本的には、何かしらGASのコードを更新したら再度公開するようにすれば大丈夫かと。

Webhook のやり方が変わった？

このガチャを作成した後に知ったのですが、今回使用した Webhook の方式がどうやら旧方式になるらしく...。新方式として Slack App を個別に作成し、そのなかで Webhook の設定をするものになったそうです。 <OG url="https://qiita.com/kshibata101/items/0e13c420080a993c5d16" />

すぐに旧方式が使えなくなるようではないですが、将来的にはなくなるようなので、いずれは方式を新しくしておきたいですね。

新方式もちょっとやってみたところ、Incomming Webhook はすんなりできました。ただ、Outgoing Webhookの代わりとなると思われる Event Subscriptions がよくわかりませんでした。トリガーワードが設定できないっぽい...？ message.channelsのイベントを設定したら、メッセージ投稿で反応するっぽい？ですが、投稿の度に毎回 GAS へリクエストされるとしたら微妙なような...。スラッシュコマンドとかでやった方がいいんですかね、う～ん。

連携させることで、GAS からスプレッドシートの操作ができるのは便利ですが、元となるスプレッドシートの状態がおかしかったりすると、うまく動作しなくなる問題があります。スプレッドシートの変化に対応できるような GAS を書くことも考えたものの、どこまで対応すべきなのか？というところを悩み。結果、dutyGacha 関数の最初で初期化することで、せめて修正しやすくしようとしてみました。ここらへんってどうすべきなんでしょうね...。悩ましいところです。

また何か作るネタを思いついたら GAS で作ってみますー。

参考リンクまとめ

勉強した内容をDocusaurus(v2)でドキュメント化してみる

Mon, 13 Jan 2020 00:00:00 GMT

勉強したことは何かしらメモしたり、記録を残したりすることが多いでしょうが、どうせ後から見直すなら見やすい方がいいですよね。ドキュメント化して整理するべく Docusaurus を使ってみました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

Docusaurus とは？

Facebook 製の、React をベースとしたドキュメント特化の静的サイトジェネレータです。その特性の通り、主に OSS のドキュメントサイトの作成に使用されています。

なぜ Docusaurus？

昨年末の記事で書いていたので以下、引用します。

個人勉強のコードは学習記録の可視化にもなるということで、上記にも書いている TIL リポジトリにコミットしています。これは今後も継続していきます。

TILとは「Today I Learned」の略で、Github 上に TIL というリポジトリを作成してそこに今日覚えたことを書いていくというものです。

※TIL リポジトリに関する過去記事はこちら

TILリポジトリで小さなアウトプット

TILリポジトリが150コミット突破

ただ、途中まではいい感じかなーと思っていたのですが、だんだん散らかってきたといいますが、勉強した内容をドキュメントみたいにちゃんとまとめたいという思いが出てきました。

そこで、OSS のドキュメントがどうなっているか見てみようということで、create-react-app のドキュメントのコードを見ていたところ、どうもDocusaurusというドキュメント特化の静的サイトジェネレータを使っていることがわかりました。

今後、これを導入して勉強したことのドキュメントを作ろうか検討中です。言語のバージョンアップで仕様が変わるなど、ドキュメントの更新や整備が大変では...という懸念点もありますが、まずはやってみようかと。自己満足みたいなところがあるので、このドキュメントを評価材料にしてもらおうとかはあんまり考えていません。というか、評価材料になりえるものなんでしょうか...？

簡潔に言ってしまえば、冒頭に書いた通り、勉強したことを後から見返しやすいようにしたいからドキュメント化してみよう。といった感じです。

ということで、早速導入してみました。

※追記 2021年末くらいからは Notion で TIL 活動をすることにしたので、リポジトリの活動停止してます。

Docusaurus の導入

使用バージョンについて

安定版としては執筆時点で1.14.4が最新です。 docusaurus-initという雛形ドキュメントを作成してくれる CLI ツールがあるので、比較的楽に導入できます。また、これで作成された雛形ドキュメントの中には Docker に関するファイルも含まれ、ローカルで Docker でサーバを立ち上げて作業するということができるようになっています。

便利だなーと思いながら導入したのですが、実際に使ってみるとちょっと気になる点がありました。

Docusaurus の1系には i18n による翻訳機能が搭載されているのですが、どうも英語でドキュメントを書いていく前提の作りになっているようでした。最初に英語で書いて、それを多言語に翻訳していくような。

各ドキュメントのタイトルといった、翻訳対象になりそうなものを検知してi18n/en.jsonファイルにまとめてくれる機能があり。便利ではあるものの、このファイルはあくまで英語用のファイルです。ドキュメントを日本語で書いていようとi18n/en.jsonファイルにまとめられます。

GitHub のコードを見たりもしましたが、ドキュメントを書いていく上でのデフォルト言語は変えられなさそうでした。

そこでいろいろと調べているうちに、開発中の alpha 版ではあるものの、2系も使えることに気づきました。 2系は一から作り直されているようで、翻訳機能はまだ搭載されていませんが、それ以外の1系の主な機能は移植されているとのこと。現状日本語でしか作らないつもりなので十分です。

すでに2系を使われている OSS ドキュメントもありますし、むしろ、2系を使った方がいいのではないか？ということで、今回は2系を使うことにしました。なお、執筆時点での最新バージョンは2.0.0-alpha.40です。 ↓ ※2020/05/03追記 2.0.0-alpha.54に対応して一部修正。 ※2020/10/12追記 2.0.0-alpha.65に対応して一部修正。 ※2021/04/02追記 2.0.0-alpha.72に対応して一部修正。

導入手順

前提として以下が必要です。

Node.js：12.13.0以上
yarn：1.5以上

npxコマンドを使って、Docusaurus 導入 + 雛形作成の CLI ツールを直接利用します。

npx @docusaurus/init@latest init [name] [template]

今回は classic テンプレートでの導入で進めます。（以降の内容はclassic テンプレートでの内容であることに注意です）

npx @docusaurus/init@latest init website classic

なお、classic以外のテンプレートとしてはfacebook、bootstrapなどがあります。

website
├ blog
│  ├ 2019-05-28-hola.md
│  ├ 2019-05-29-hello-world.md
│  └ 2020-05-30-welcome.md
├ docs
│  ├ create-a-blog-post.md
│  ├ create-a-document.md
│  ├ create-a-page.md
│  ├ getting-started.md
│  ├ markdown-features.mdx
│  └ thank-you.md
├ node_modules
├ src
│  ├ css
│  │  └ custom.css
│  └ pages
│      ├ index.js
│      ├ markdown-page.md
│      └ styles.module.css
├ static
│  ├ img
│  │  ├ docusaurus.png
│  │  ├ favicon.ico
│  │  ├ logo.svg
│  │  ├ undraw_docusaurus_mountain.svg
│  │  ├ undraw_docusaurus_react.svg
│  │  └ undraw_docusaurus_tree.svg
│  └ .nojekyll
├ .gitignore
├ babel.config.js
├ docusaurus.config.js
├ package.json
├ README.md
├ sidebars.js
└ yarn.lock

この classic テンプレートには、基本的なテーマやプラグインをまとめたプリセットである@docusaurus/preset-classicが含まれています。

@docusaurus/preset-classicに含まれているものはこちら.

@docusaurus/theme-classic
@docusaurus/theme-search-algolia
@docusaurus/plugin-content-docs
@docusaurus/plugin-content-blog
@docusaurus/plugin-content-pages
@docusaurus/plugin-debug
@docusaurus/plugin-google-analytics
@docusaurus/plugin-google-gtag
@docusaurus/plugin-sitemap

サーバの起動.

yarn start

サーバを起動すると、自動でブラウザが立ち上がり、localhost:3000が開きます。

以下のような画面が表示されればOKです。 <ImageWrapper src="screenshots/2020/docusaurus-ver-2/docusaurus-init-top.png" alt="Docusaurus 2系の雛形ドキュメントのトップ画面" />

ちなみにホットリロードに対応しているので、基本的には変更が即座に反映されます（一部設定はサーバを再起動しないといけないときもありました）

Docusaurus の基本的な構成

ページ

Docusaurus では通常のページやドキュメントページが作れるほか、ブログを書くこともできます。確かに OSS だと開発ブログみたいなものがあったりしますよね。

ページの種別ごとにディレクトリ階層が決まっています。

通常のページ：src/pages配下
ドキュメントページ：docs配下
ブログページ：blog配下

通常のページは React 式にも書けますし、マークダウンファイルでも書けます。また、mdx にも対応しています。

サイトの基本設定

docusaurus.config.js にまとめられています。

/** @type {import('@docusaurus/types').DocusaurusConfig} */
module.exports = {
  title: 'My Site',
  tagline: 'The tagline of my site',
  url: 'https://your-docusaurus-test-site.com',
  baseUrl: '/',
  onBrokenLinks: 'throw',
  onBrokenMarkdownLinks: 'warn',
  favicon: 'img/favicon.ico',
  organizationName: 'facebook', // Usually your GitHub org/user name.
  projectName: 'docusaurus', // Usually your repo name.
  themeConfig: {
    navbar: {
      title: 'My Site',
      logo: {
        alt: 'My Site Logo',
        src: 'img/logo.svg',
      },
      items: [
        {
          to: 'docs/',
          activeBasePath: 'docs',
          label: 'Docs',
          position: 'left',
        },
        {to: 'blog', label: 'Blog', position: 'left'},
        {
          href: 'https://github.com/facebook/docusaurus',
          label: 'GitHub',
          position: 'right',
        },
      ],
    },
    footer: {
      style: 'dark',
      links: [
        {
          title: 'Docs',
          items: [
            {
              label: 'Getting Started',
              to: 'docs/',
            },
          ],
        },
        {
          title: 'Community',
          items: [
            {
              label: 'Stack Overflow',
              href: 'https://stackoverflow.com/questions/tagged/docusaurus',
            },
            {
              label: 'Discord',
              href: 'https://discordapp.com/invite/docusaurus',
            },
            {
              label: 'Twitter',
              href: 'https://twitter.com/docusaurus',
            },
          ],
        },
        {
          title: 'More',
          items: [
            {
              label: 'Blog',
              to: 'blog',
            },
            {
              label: 'GitHub',
              href: 'https://github.com/facebook/docusaurus',
            },
          ],
        },
      ],
      copyright: `Copyright © ${new Date().getFullYear()} My Project, Inc. Built with Docusaurus.`,
    },
  },
  presets: [
    [
      '@docusaurus/preset-classic',
      {
        docs: {
          sidebarPath: require.resolve('./sidebars.js'),
          // Please change this to your repo.
          editUrl:
            'https://github.com/facebook/docusaurus/edit/master/website/',
        },
        blog: {
          showReadingTime: true,
          // Please change this to your repo.
          editUrl:
            'https://github.com/facebook/docusaurus/edit/master/website/blog/',
        },
        theme: {
          customCss: require.resolve('./src/css/custom.css'),
        },
      },
    ],
  ],
};

ナビゲーションバー

docusaurus.config.js の themeConfig のなかに設定があります。

react-router-dom の Link タグの書き方に似ていますね。 to には相対パスで URL を指定します。内部リンクだけでなく、外部リンクも設定できます。

// ※一部抜粋
navbar: {
  title: 'My Site',
  logo: {
    alt: 'My Site Logo',
    src: 'img/logo.svg',
  },
  items: [
    {
      to: 'docs/',
      activeBasePath: 'docs',
      label: 'Docs',
      position: 'left',
    },
    {to: 'blog', label: 'Blog', position: 'left'},
    {
      href: 'https://github.com/facebook/docusaurus',
      label: 'GitHub',
      position: 'right',
    },
  ],
},

画面側 <ImageWrapper src="screenshots/2020/docusaurus-ver-2/navbar.png" alt="ナビゲーションバー" />

サイドバー

sidebars.js に設定があります。

ここで指定しているcreate-a-pageなどは各ドキュメントの id です。この id は、デフォルトでドキュメントのマークダウンファイル名から拡張子を抜いたものが割り当てられますが、マークダウンファイル側で別途 id を指定することも出来ます。

ここでサイドバーとドキュメントの紐づけが行われ、表示上ではデフォルトで title が使われます。（ドキュメントタイトルとサイドバー表示タイトルを分けたい場合は、マークダウンファイル側で sidebar_label を設定することで対応できます）

module.exports = {
  docs: [
    {
      type: 'category',
      label: 'Docusaurus Tutorial',
      items: [
        'getting-started',
        'create-a-page',
        'create-a-document',
        'create-a-blog-post',
        'markdown-features',
        'thank-you',
      ],
    },
  ],
};

ドキュメントのマークダウンファイル.

※Frontmatter 部分
---
title: Create a Blog Post
---

画面側 <ImageWrapper className="w-[60%]" src="screenshots/2020/docusaurus-ver-2/sidebar.png" alt="サイドバー" />

階層構造にしたい場合は、以下のように書けば OK。

module.exports = {
  docs: {
    Guides: [
      'creating-pages',
      {
        type: 'category',
        label: 'Docs',
        collapsed: false,
        items: ['markdown-features', 'sidebar'],
      },
    ],
  },
};

画面側 <ImageWrapper className="w-[50%]" src="screenshots/2020/docusaurus-ver-2/sidebar-subcategory.png" alt="階層構造にしたサイドバー" />

フッター

docusaurus.config.js の themeConfig のなかに設定があります。

// ※一部抜粋
footer: {
  style: 'dark',
  links: [
    {
      title: 'Docs',
      items: [
        {
          label: 'Getting Started',
          to: 'docs/',
        },
      ],
    },
    {
      title: 'Community',
      items: [
        {
          label: 'Stack Overflow',
          href: 'https://stackoverflow.com/questions/tagged/docusaurus',
        },
        {
          label: 'Discord',
          href: 'https://discordapp.com/invite/docusaurus',
        },
        {
          label: 'Twitter',
          href: 'https://twitter.com/docusaurus',
        },
      ],
    },
    {
      title: 'More',
      items: [
        {
          label: 'Blog',
          to: 'blog',
        },
        {
          label: 'GitHub',
          href: 'https://github.com/facebook/docusaurus',
        },
      ],
    },
  ],
  copyright: `Copyright © ${new Date().getFullYear()} My Project, Inc. Built with Docusaurus.`,
},

画面側 <ImageWrapper src="screenshots/2020/docusaurus-ver-2/footer.png" alt="フッター" />

URL

通常のページ

基本的には/{拡張子なしファイル名}になります。 src/pages配下でディレクトリ階層が分かれていれば、/{dir}/{拡張子なしファイル名}といった感じです。

ただ、ファイル名がindex.jsだった場合は/になります。まとめると以下のような感じです。

/src/pages/index.js → /
/src/pages/foo.js → /foo
/src/pages/foo/test.js → /foo/test
/src/pages/foo/index.js → /foo/

docs 配下のドキュメント

マークダウンファイルの FrontMatter に slug があるか、docs 配下でディレクトリ階層になっているかで変わってきます。

slug 設定あり：/docs/{slug}
slug 設定なし： /docs/{dir}/{id}

docs
├ greeting.md
└ guide
    └ hello.md

docs/greeting
docs/guide/hello

となります。

ブログ

トップ：/blog

ブログ記事の URL も FrontMatter に slug があるかで変化します。

slug 設定あり：/blog/{slug}
slug 設定なし：/blog/{YYYY}/{MM}/{dd}/{id}

デプロイ

今回は Netlify でデプロイして、いつでもサイトとして見られるようにしておきます。

初回デプロイ

docusaurus.config.js の内容を確認

url と baseUrl の設定を確認してください
url は Netlify で公開する上での URL（Netlify のサブドメインは{プロジェクト名}.netlify.app）
baseUrl は/のままでも問題なかったです

netlify.toml を用意

[build]
  publish = "build"
  command = "yarn build"

[build.environment]
  NODE_ENV = "production"

もしサブディレクトリにサイトのソースがある場合は、base で指定すれば対応できます。

[build]
  base    = "website"
  publish = "build"
  command = "yarn build"

Netlify とリポジトリを連携させてデプロイ基本的なやり方は過去記事に書いているので、こちらをご覧ください。

Netlifyでブログをデプロイ

ビルド・デプロイの設定例 <ImageWrapper className="w-[80%]" src="screenshots/2020/docusaurus-ver-2/docusaurus-netlify.png" alt="Netlifyのビルド設定" />

これでうまくいっていればデプロイされて、サイトとして閲覧できるようになれるはずです。

2回目からのデプロイ

初回デプロイ以降は、デプロイブランチが更新されるたびに自動でデプロイを行ってくれます。そのほか、デプロイブランチに対するプルリク（マジリク）を出したときに、デプロイのプレビューを生成してくれるので、マージした後にどうなるか事前に確認ができます。

補足：Node.js のバージョン指定

バージョン指定をしたい場合は、以下の2通りのやり方があります。

環境変数にNODE_VERSIONでバージョンを設定する（設定方法は以下のいずれか）
- netlify.tomlに記述する
- Netlify の管理画面の Settings → Build & Deploy → Environment で設定
.node-versionか.nvmrcをリポジトリ直下に作成して、バージョンを記述する。

Textlint の導入（2020/1/19追記）

<OG url="https://github.com/textlint/textlint" /> Textlint は文書向けの Lint ツールです。せっかくなので使用してみることにしました。

導入手順

インストール

yarn add -D textlint textlint-rule-preset-ja-technical-writing

Textlint 単体だと何もルールを持っていないので、技術書向けのルールセットであるtextlint-rule-preset-ja-technical-writingを一緒にインストールしています。 <OG url="https://github.com/textlint-ja/textlint-rule-preset-ja-technical-writing" />

設定ファイルの作成

yarn run -s textlint --init

以下のような.textlintrcファイルが作られます。すでにインストールしているルールを認識して作ってくれるようです。

{
  "filters": {},
  "rules": {
    "preset-ja-technical-writing": true
  }
}

コマンドで実行

この時点でコマンドが使えるようになっています。設定ファイルで設定したルールに沿ってチェックされます。

yarn run -s textlint (ファイルパス)

また、以下のコマンドではルールにもよりますが、自動修正できるものは修正してくれるようです。

yarn run -s textlint --fix (ファイルパス)

VSCode 上で実行

毎回コマンド実行するのも手間なので、VSCode のエディタ上で確認できるようにしておきます。

<OG url="https://marketplace.visualstudio.com/items?itemName=taichi.vscode-textlint" /> インストールして、必要に応じて VSCode を再起動。プロジェクトルート直下に.textlintrcやnode_modulesがある場合は、この時点で動作します。

もしサブディレクトリにサイトのソースがある場合は、この拡張の設定で別途.textlintrcやnode_modulesのパスの指定が必要になります。

設定例.

Textlint: Config Path → website/.textlintrc
Textlint: Node Path → website/node_modules

その他の設定には以下のようなものがあります。この辺はお好みで。

Textlint: Auto Fix On Save（保存時に自動修正できるものを修正するか）
Textlint: Run（入力時にチェックするか、保存時にチェックするか）

こんな感じで動いてくれるようになります。 <ImageWrapper src="screenshots/2020/docusaurus-ver-2/textlint.png" alt="VSCode上で動作するTextlint" />

設定のカスタマイズ

今回使用しているtextlint-rule-preset-ja-technical-writingは複数のルールから構成されており、ルールそれぞれのカスタマイズが可能です。デフォルト値が厳しめに設定されているため、自分に合った設定へカスタマイズしてみましょう。

デフォルトルール一覧.

1文の長さは100文字以下とする
カンマは1文中に3つまで
読点は1文中に3つまで
連続できる最大の漢字長は6文字まで
漢数字と算用数字を使い分けます
「ですます調」、「である調」を統一します
文末の句点記号として「。」を使います
二重否定は使用しない
ら抜き言葉を使用しない
逆接の接続助詞「が」を連続して使用しない
同じ接続詞を連続して使用しない
同じ助詞を連続して使用しない
UTF8-MAC 濁点を使用しない
不必要な制御文字を使用しない
感嘆符!！、感嘆符?？を使用しない
半角カナを使用しない
弱い日本語表現の利用を使用しない
同一の単語を間違えて連続しているのをチェックする
よくある日本語の誤用をチェックする
冗長な表現をチェックする
入力ミスで発生する不自然なアルファベットをチェックする
対になっていない括弧をチェックする

設定例.

{
  "filters": {},
  "rules": {
    "preset-ja-technical-writing": {
      "sentence-length": {
        "max" : 90
      },
    }
  }
}

この場合、sentence-length（1文の長さ）を90以下にして、それ以外のルールはデフォルト値が使われます。他の設定や例外の設定の仕方などは textlint-rule-preset-ja-technical-writing の README を参考にしてください。

ここまで簡単に概要を書きました。開発版とはいえ、2系の方が扱いやすい印象をうけました。これから少しずつ、TIL リポジトリにあげた勉強内容をドキュメント化していきますー。

また、プログラマーとしての経歴や経験をまとめたページなんかも作ったり、当ブログとリンクさせたりしていきたいですね。

参考リンクまとめ

Jekyll製ブログの各見出しに自動アンカー生成を導入する

Sat, 04 Jan 2020 00:00:00 GMT

Qiita や GitHubのマークダウンって、各見出しに自動的にアンカーがついていて、すぐにその見出しのリンク取得できるから便利ですよね。あれを Jekyll で導入する方法を調査して、よいものを見つけたので早速導入してみました。

import OG from "@/components/OG.astro"

調査したきっかけ

自分はとあるエンジニアのコミュニティに参加しています。そのコミュニティを立ち上げられた方を Twitter でフォローさせていただいているのですが...。あるとき、その方が「Jekyll で見出しにアンカーを自動で付与する方法はないか？」というつぶやきをされていました。

最初は目次から見出しへ飛べるようにするのかな？と思ってやりとりをしたのですが、そこで Qiita や GitHub の見出しの話になりました。 Qiita や GitHub のマークダウンの見出しって、自動的にアンカーリンクが付与されていて、すぐにその見出しのアンカーリンクが取得できるんですよね。あれってどうやってるんだろうと。

そこで何かプラグイン等がないか調査してみることにしました。何か見つかれば当ブログにも導入できるなと。

jekyll-anchor-headings

調査したところ、こちらのリポジトリを見つけました。 <OG url="https://github.com/allejo/jekyll-anchor-headings" />

概要

GitHub Pages can't run custom Jekyll plug-ins so when generating anchors for your headings (i.e. h1 - h6), you're stuck with JavaScript solutions that will inject anchors. But what if your users don't have JavaScript enabled on their browsers? If you're building a static website, why not make your anchors static as well?

簡単に静的サイト構築のできる GitHub Pages でも Jekyll が使われているのですが、あちらはプラグインが使用できないという制約があります。そこで JavaScript で見出しをカスタマイズするという選択肢が出ますが、JavaScriptが無効化されていると、利用できません。静的サイトでは、アンカーも静的にしましょうといったことが書いてありました。

A GitHub Pages compatible way of adding anchors to your headings without a plug-in or JavaScript

こちらに書いてあるとおり、プラグインや JavaScript を使わずとも、このスニペットを使えば、見出しに自動的にアンカーを付与できますよとのことです。プラグインでないので GitHub Pages でも問題なく使用できます。

導入実績

こちらも README に記述がありました。比較的有名なサービスや OSS のドキュメントに使われているそうです。すごいですね！

Travis CI Docs (fixed in #1960)

Bitrise's Documentation

di's personal website

sitespeed.io

Duality's developer docs

Australia's Vote Flux campaign

mlpack.org

Riot.js website

"Just the Docs" Jekyll theme

Microsoft's TypeScript website

VMWare's Octant documentation

導入方法

導入はとても簡単です。

リポジトリから最新のanchor_headings.htmlファイルをダウンロードする
ダウンロードしたファイルを、自ブログコードの_includes配下に格納
レイアウトファイルで{{ content }}のところを以下のように置き換える

{% include anchor-headings.html html=content %}

自分は_layouts/default.htmlの該当箇所を置き換えました。他のレイアウトファイルもこのレイアウトファイルをベースにしているので、まとめて適用できました。

オプション

include 文にオプションを渡すことができます。

一例はこちら.

beforeHeading 見出しの文字の前にアンカーを生成するか（bool で指定、デフォルトは false）
anchorBody アンカー内に配置するコンテンツ（string で指定、デフォルトは''）文字列で指定ですが、HTML の i タグで指定もできました。
anchorClass アンカーに指定するクラス（string で指定、デフォルトは''）このクラスに CSS をあてて、カスタマイズもできます。

詳しくはリポジトリの README でご確認ください。 <OG url="https://github.com/allejo/jekyll-anchor-headings#parameters" />

自分の場合は以下のようにしました。

{% include anchor-headings.html html=content anchorBody='#' anchorClass='anchor-heading' %}

とても簡単に見出しに自動アンカーを導入できました！ Jekyll を利用している方はぜひ導入してみてはどうでしょうか。

README を読んでて気づいたのですが、この製作者の方は、以前目次導入の調査をしていた時に見つけた jekyll-toc を作った方でもあったそうです。 <OG url="https://github.com/allejo/jekyll-toc" /> jekyll-toc に関しても、同様に導入でき、GitHub Pages でも使えるようになっていました。

こういう便利なものを作れる方ってすごいですね！自分もいつか挑戦してみようかな...。

遅ればせながら、あけましておめでとうございます。今年も少しずつブログ書いていきますので、どうぞよろしくお願い致します。

参考リンクまとめ

2019年振り返り～Gitコミット、ブログ編～

Tue, 31 Dec 2019 00:00:00 GMT

{/*  */}

ついに大晦日になりましたね。どうも、よしです。先日は精神疾患に関して振り返りを行いましたが、今度は Git のコミット履歴、ブログに関する振り返りをやってみました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

2019年の活動履歴

コミット履歴

まずは各アカウントのプロフィール画面から、コミット履歴を確認してみます。

個人 - GitHub

4月後半から7月にかけてが多いですね。このあたりは精神疾患の症状が比較的落ち着いていて、勉強していた時期でもあります。 6月に復職した頃は、通勤リハビリ～午前中勤務だったので、自分の時間に余裕があったというのもありました。なので、勤務時間が戻っていくにつれてコミットが少なくなっていっています。大半は勉強用のTILリポジトリにコミットしていたものです。

仕事 - GitHub

年始の頃は当時の案件をやっていましたが、プライベートリポジトリでしたし、そのリポジトリからは抜けたので、ここには表示されていないようです。 2月中頃～5月末まで休職。 6月に復職して、React の勉強～React 案件参加となってから少しずつコミットが増えていっています。

個人 - GitLab

個人の GitLab に関しては、当ブログに関する活動履歴になります。年始に立てた、毎月1記事は投稿するという目標の元やっていましたが、後半は1か月あたり2～5記事投稿できました。他にブログ自体の機能の追加といった改修や過去記事の見直しなどをやっていたため、このような履歴になりました。

ブログ

2019年の大まかなブログの履歴は以下のような感じでした。（Google Analytics のスクショは貼れる、貼れないで意見が分かれるようなので、貼らずにデータを抜粋しました）

月	記事数	月のアクセスユーザ数	月のページビュー数
1月<br />(1/1 ブログ公開)	7	※データなし	※データなし
2月	8	※データなし	※データなし
3月	9	※データなし	※データなし
4月	10	※データなし	※データなし
5月	12	※データなし	※データなし
6月<br />(6/5 GA導入)	14	7	24
7月	16	21	86
8月	18	26	61
9月	23	80	247
10月	26	118	196
11月	29	163	246
12月	33	291	449

Google Analytics を導入したのが6月なので、およそ7か月の履歴になりますが、一気に5記事書いた9月に急激に伸びましたね。約7か月でユーザ数が約41倍、ページビュー数が約18倍になりました。

自分はブロガーではないのでアクセス数を伸ばすことに注力しているわけではないですが、それでもちょっと嬉しいですね。

2020年はどうしていきたいか

個人勉強

個人勉強のコードは学習記録の可視化にもなるということで、上記にも書いている TIL リポジトリにコミットしています。これは今後も継続していきます。

TILとは「Today I Learned」の略で、Github上にTILというリポジトリを作成してそこに今日覚えたことを書いていくというものです。

※TILリポジトリに関する過去記事はこちら。

ただ、途中まではいい感じかなーと思っていたものの、だんだん散らかってきたといいますが、勉強した内容をドキュメントみたいにちゃんとまとめたいという思いが出てきました。

そこで、OSS のドキュメントがどうなっているか見てみようということで、create-react-app のドキュメントのコードを見ていたところ...。どうもDocusaurusというドキュメント特化の静的サイトジェネレータを使っていることがわかりました。

今後、これを導入して勉強したことのドキュメントを作ろうか検討中です。言語のバージョンアップで仕様が変わるなど、ドキュメントの更新や整備が大変では...という懸念点もありますが、まずはやってみようかと。自己満足みたいなところがあるので、このドキュメントを評価材料にしてもらおうとかはあんまり考えていません。というか、評価材料になりえるものなんでしょうか...？

仕事としては、フロントとバックエンドで1つずつ自分の技術の軸になるものがほしいということで。 JavaScript（React）と Java（Spring）をメインにしようかと思ってはいるのですが、興味のあることは個人勉強で色々やってみたいと思っています。

個人勉強で特にこれをやりたい！というものは現状決めていません。これが吉と出るか、凶とでるか...。

仕事

年明けから週5日勤務に戻るので、まずはそれを維持したいなと。維持できていれば自然とコードを書く量も増えていくと思います。

ブログ

1か月に複数記事も意外といけるなーと思ったのですが、変に無理せず最低1記事書くというのを継続していきます。書けたら複数記事書こうくらいの緩い感じで。

アクセス数が伸びたら、それはそれで嬉しいですが、短期的なアクセス数目当てだけの質の悪い記事を書かないよう気を付けたいところです。

前回の記事でも書いたのですが、精神疾患を抱えている分ハンデもあります。ただ、それでもできることはやっていきたいと思っています。

身体の調子を見ながら、緩やかな目標の中で2020年は過ごしていきたいですね。

皆様、よいお年をお迎えくださいー。ではでは。

{/*  */}

React入門～基礎編～

Wed, 18 Dec 2019 00:00:00 GMT

現在業務で使用している React について、より理解を深めていくために勉強したことを記事として書くことにしました。ということで、まずは基礎編です。

※この記事は元々 Qiita からの転載です。現在は Qiita でなく Zenn の方で更新しています。

※2021/09/13追記全体的に内容を見直しました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

記事を書くにあたって

2019年秋頃から Qiita の記事を書いてきましたが、環境構築系ばかりで、いまだ技術の中身についての記事を書いたことがなかったので、そろそろ書いてみたいなーと思っていました。（ブログで多少技術記事は書いていました）

技術記事となると、すでに同じテーマで記事を書かれている方がいてクオリティも高くてと、自分なんかが書いてもなと尻込みをしていたのですが、自分の理解を深めるという目的で思い切って書くことにしました。記事を書く上で自然とまとめるようになるので、頭の中が整理できるので。

もし自分がその技術から離れてしまって、また戻ってきたときに記事を見返して助けになればとも。まだまだ勉強中の身であるため内容に間違い等ありましたら、コメントいただけると幸いです。

React とは

Facebook およびコミュニティによって開発されている、ユーザインターフェース構築のための JavaScript ライブラリです。

これだけ聞いてもなんのこっちゃとなりそうなので、公式ドキュメントにある特徴を引用してみます。

宣言的な View

React は、インタラクティブなユーザインターフェイスの作成にともなう苦痛を取り除きます。アプリケーションの各状態に対応するシンプルな View を設計するだけで、React はデータの変更を検知し、関連するコンポーネントだけを効率的に更新、描画します。

宣言的な View を用いてアプリケーションを構築することで、コードはより見通しが立ちやすく、デバッグのしやすいものになります。

通常の JavaScript のみであったり jQuery を使っての「命令型」の UI 構築となると、操作したい DOM 要素を取得して、その要素を操作していく形になるでしょう。もちろんこれでも UI 構築は出来るわけですし、そう複雑なものでなければ問題はないこともあります。ただ、より複雑なことをしようとすると、ロジックの複雑さは当然増してきます。保守性が落ちて、バグが発生しやすくなったり。最終的にどんな UI になるのかイメージしにくくなったり。

React では主に JSX という JavaScript の拡張構文を使って UI を記述していきます。こちらは「宣言型」で UI を記述するため、基本的には最終的な UI の状態を記述（宣言）すればいいだけです。その UI にするための DOM 操作は React の方でやってくれます。

また、React における DOM 構築に関して、仮想DOMというものがあります。 React は DOM 操作時に、すぐにブラウザ上の DOM に反映させるのではなく、まずはメモリ上に仮想 DOM として構築し記録。そして、前回の記録されている仮想 DOM と比較して差分を特定し、その差分のみをブラウザ上の DOM に同期させる。という仕組みになっています。従来の JavScript、jQuery による DOM 操作では、DOM 全体が再構築されていたため、それに比べると高速で動作するようになっているわけです。

コンポーネントベース

自分自身の状態を管理するカプセル化されたコンポーネントをまず作成し、これらを組み合わせることで複雑なユーザインターフェイスを構築します。

コンポーネントのロジックは、Template ではなく JavaScript そのもので書くことができるので、様々なデータをアプリケーション内で簡単に取り回すことができ、かつ DOM に状態を持たせないようにすることができます。

React ではコンポーネントベースの設計思想が取り入れられています。インタフェースさえ分かっていれば内部の実装を知らなくても使える、独立したコンポーネントを組み合わせて、UI を構築していく形です。あるコンポーネントを呼び出して使うほか、複数のコンポーネントを組み合わせて新たなコンポーネントを作るということもできます。

前項でも書いた通り、React では JSX という JavaScript の拡張構文を使って UI を記述していくわけですが、JSX の中で JavaScript の処理を書くということも可能です。コンポーネント自体が持つロジックも JavaScript で書けるため、UI 部分とロジック部分とでデータのやり取りも楽にできたりします。

一度学習すれば、どこでも使える

React と組み合わせて使用する技術に制限はありません。React を使って新しい機能を追加する際に、既存のソースコードを書き換える必要はありません。

React は Node を使ったサーバ上でもレンダーできますし、React Native を使うことでモバイルアプリケーションの中でも動きます。

React は、本体と、仮想 DOM の内容を実際に UI へ反映させるレンダラー（react-dom など）とが分かれています。このレンダラーの部分は、様々なプラットフォームのものが提供されているため、いろんなものが作れるよーという話です。 react-dom 以外の代表的なものとして、クロスプラットフォームのモバイルアプリ向けである React Native があります。

環境構築

環境構築のやり方は色々あるのですが、パパっと作りたい場合は、Facebook 製の Create React App を使うと楽です。

初期セットアップが済んだ React プロジェクトを作成してくれます。

npx create-react-app ※アプリ名
# or
yarn create react-app ※アプリ名

任意ではありますが、オプションで--templateを指定することで、テンプレートを利用出来たりもします。

# TypeScript テンプレートによるセットアップ例
npx create-react-app ※アプリ名 --template typescript
# or
yarn create react-app ※アプリ名 --template typescript

セットアップ後、ローカルサーバを立ち上げて開発をしていく形です。なお、webpack-dev-server によりホットリロードが自動で動作します。

npm start
# or
yarn start

react-scripts

Create React App によるセットアップで作成された React アプリは、以下のライブラリが導入されています。

react：React 本体
react-dom：DOM を抽象化して React から操作できるようにするレンダラー
react-scripts：React アプリ開発に必要な様々なライブラリを管理するもの

手動で React 環境を作ろうとすると、自分でいろんな設定をしなくてはならなくなるため、なかなか大変なのですが...。それを react-scripts がまとめて管理してくれているのです。 lock ファイルで react-scripts の依存関係を見てもらうとわかりますが、実にたくさんのライブラリが依存関係となっています。

代表的な例。

Babel：新仕様の JavaScript や JSX、TypeScript のコードを、古いブラウザでも実行できるように、旧式の JavaScript コードに変換するトランスコンパイラ
Webpack：コンパイラと連携しながら、依存関係を解決し、ソースコードファイルをまとめて最適化を行うモジュールバンドラー
webpack-dev-server：ファイル変更を検知して再ビルドとリロードを行う、開発用の webpack サーバ
dotenv：環境ごとに異なる環境変数を管理
ESLint：JavaScript および TypeScript 向け静的解析

Babel や Webpack の設定は react-scripts によって隠蔽されており、これにより設定を意識することなく、React アプリ開発が可能になっているわけです。とはいえ、内部で何が動いているかは一応意識しておいた方がいいかと思われます。

ただ、場合によっては、自分で設定をカスタマイズしたいということもあるでしょう。そんな時は eject することで、react-scripts の依存関係を解除し、隠蔽されていた設定を直接カスタマイズできます。

npm eject
# or
yarn eject

この eject は一度やってしまうと元に戻せないため、取り扱いには十分注意しましょう。

部分的なカスタマイズであれば、こちらを使うのもありです。 <OG url="https://github.com/gsoft-inc/craco" />

なお、ローカルに環境作るのすらめんどくさい場合は、オンラインエディタを使う手もあります。自分もパパっと検証をしたい時などに、CodeSandbox をよく活用しています。

React の基本

以下、記述しているコードは以下を引用、もしくはベースにしています。

Create React App で生成されたもの
React 公式ドキュメント
React 公式チュートリアル

今回の使用バージョンは以下のとおりです。

React：17.0.2
react-scripts：4.0.3

起点

index.html

まずはおなじみの起点となる index.html。この例において、body タグの中身としては、root という id を持つ div 要素だけです。

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" href="%PUBLIC_URL%/favicon.ico" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta name="theme-color" content="#000000" />
    <meta
      name="description"
      content="Web site created using create-react-app"
    />
    <link rel="apple-touch-icon" href="%PUBLIC_URL%/logo192.png" />
    <link rel="manifest" href="%PUBLIC_URL%/manifest.json" />
    <title>React App</title>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
  </body>
</html>

index.js

React アプリ側の起点となる部分。

レンダラーであるReactDOMのrender関数で以下を指定。

第1引数：レンダリングするコンポーネント
第2引数：どの DOM 要素にレンダリンクするか

この例では、App というコンポーネントに定義された React 要素を、（index.html の）id が root の要素にレンダリングするよう定義しています。ここで HTML の DOM 要素との関連付けが行われているわけです。この関連付けされた React 要素全てが React DOM によって管理されることになるため、この関連付けされた DOM 要素をルート DOM ノードと呼んだりもします。

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';

ReactDOM.render(
  <App />,
  document.getElementById("root")
);

紐づけだけをパパっと試したいのであれば、第1引数に直接 React 要素を書いて試すことも出来ます。

ReactDOM.render(
  <h1>Hello, world!</h1>,
  document.getElementById('root')
);

プロバイダーコンポーネントという、子孫コンポーネントに特定の値や機能を提供するコンポーネントでアプリ全体を囲うというときに触ることはありますが、基本的にはあまり触ることのないファイルです。

App.js

今回の例において、index.js から呼ばれているコンポーネント。

コンポーネントが return で返している React 要素が、そのコンポーネントのレンダリングする内容になります。（※関数コンポーネントのため省略されていますが、正確にはrenderメソッドが返す React 要素のこと）エクスポートすると、他ファイルからこのコンポーネントを呼び出すことができるようになります。

import logo from './logo.svg';
import './App.css';

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>
  );
}

export default App; // コンポーネントをエクスポート

あとは、この App コンポーネントをカスタマイズしていき React アプリ開発を進めていくイメージです。このコンポーネントにルーティングを定義したり。他のコンポーネントを呼び出したり。（React 本体自体はルーティング機能を持っていないため、別途ルーティングライブラリが必要になります）

ビルド

ソースコードをビルドすると、React 部分のコードは Babel でトランスコンパイルされ、Webpack で依存関係を解決したのちにファイルをまとめられることになります。そのビルド結果のファイルを、HTML から読み込んで使用している。といった形です。

試しにローカルサーバを立ち上げて、ブラウザから DevTools で Elements を確認すると、ビルド成果物を読み込む script タグが追加されているはずです。

なお、ローカルサーバ起動時は、webpack-dev-server がファイル変更を検知して自動で再ビルド実行（開発モード）デプロイ時など本番モードでビルドしたい時は、ビルドコマンドを実行します。

npm build
# or
yarn build

実行結果のビルド生成物は/build配下へ作成されるようになっています。

React.StrictMode

Create React App で作成した React アプリの場合、index.js が以下のようになっているでしょう。

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById("root")
);

strict モードというのは、アプリケーションの潜在的な問題点を洗い出すためのツールです。この React.StrictMode 自体は特に何も UI を提供しませんが、子孫要素において不可的な問題を検知した時に、コンソールに警告を出してくれるようになります。コード品質の向上に役立ってくれるでしょう。

検知する例（それぞれの詳細は公式ドキュメントを参照）

安全でないライフサイクルの特定
レガシーな文字列 ref API の使用に対する警告
非推奨な findDOMNode の使用に対する警告
意図しない副作用の検出
レガシーなコンテクスト API の検出

なお、この strict モードは、開発モードでのみ動作するようになっています。本番ビルドには影響がありません。

コンポーネント

冒頭にも書いた通り、React ではコンポーネントベースの設計思想が取り入れられています。

クラスコンポーネント

React.Componentを継承したクラスで定義されたコンポーネント。後述する状態（state）やライフサイクルを元から持つことができます。

import React from 'react';

class App extends React.Component {  // React.component を継承するクラスの定義
  render() {  // React 要素 を返り値とする render メソッドを定義
    return (
      <h1>Hello World</h1>
    );
  }
}

export default App;

React Hooks の登場により、クラスコンポーネント特有機能の大部分が関数コンポーネントでも使用できるようになったため、ほとんど使わなくなってきています。

関数コンポーネント

クラスコンポーネントと違い、状態（state）やライフサイクルを持たないコンポーネントをよりシンプルに記述したもの。 const で変数定義などはできますが、基本的にrenderメソッドのみであるため、render()の記述が省略できます。

元々、状態（state）やライフサイクルを持つことができませんでしたが、関数コンポーネントでもそれらが使えるようにと様々な試みが行われていました。その後、React 公式から React Hooks という機能が提供され、現在では React Hooks と関数コンポーネントの組み合わせが主流となっています。

// 関数宣言方式
function App() {
  return (
    <h1>Hello World</h1>
  );
}

export default App;

関数式 + アロー関数方式で以下のようにも書くことができます。個人的にはこちらが好みです（これ以降のコードはこちらの方式で書いています）

// 関数式 + アロー関数方式
const App = () => {
  return (
    <h1>Hello World</h1>
  );
}

export default App;

また変数定義などがなく、純粋にrenderメソッドのみの場合は、さらにreturnも省略できます。

const App = () => (
 <h1>Hello World</h1>
)

export default App;

JSX

コンポーネントのrenderメソッド内に記述する JavaScript の拡張構文。 XML っぽく記述ができるような作りになっています。テンプレート言語に似ていますが、完全に JavaScript だけで動作するものです。

Babel でのトランスコンパイル時にReact.createElement形式へ変換されます。そのため、以下のコードは等価のものになります。

const element = (
  <h1 className="title">
    Hello, world!
  </h1>
);

const element = React.createElement(
  'h1',
  {className: 'title'},
  'Hello, world!'
);

このことから、React において JSX を使うことは必須でありません。また、JSX は React 特有のものでもありません。ただ、どちらが扱いやすいかといえば、多くの方が JSX の方になるのではないでしょうか。

この JSX は、必ず1つのReact要素を返す必要があります。複数の要素から構成される場合は、div で囲うなどして、1つの React 要素を返すようにしましょう。（※div などでは支障が出る場合は、React.Fragment の欄を参照）

// NG な例
render() {
  return (
    <h1>h1です</h1>
    <h2>h2です</h2>
    <p>pです</p>
  )
}

// OK な例
render() {
  return (
    <div>
      <h1>h1です</h1>
      <h2>h2です</h2>
      <p>pです</p>
    </div>
  );
}

JSX は一見 HTML とも似ていますが、閉じタグに関しては注意が必要です。 img タグのように HTML では閉じタグが必要なかったものについては、末尾に/とつけて閉じる必要があります。

<img src='画像URL' />

React.Fragment

React 要素をまとめたい時、場合によっては div などを使いたくないこともあるでしょう。そういったときはReact.Fragmentというものを使うことができ、DOM に余分なノードを追加することなく子要素をまとめられます。

render() {
  return (
    <React.Fragment>
      <h1>h1です</h1>
      <h2>h2です</h2>
      <p>pです</p>
    </React.Fragment>
  );
}

短縮記法で以下のようにも書くことができますが、こちらでは後述する key や props を持つことができないので注意が必要です。

render() {
  return (
    <>
      <h1>h1です</h1>
      <h2>h2です</h2>
      <p>pです</p>
    </>
  );
}

変数や関数の埋め込み

JSX 内に変数を埋め込む際は{}で囲って記述します。

const name = 'Yamada Taro';
const element = <h1>Hello, {name}</h1>;

なお、デフォルトでは、React DOM は JSX に埋め込まれた値をレンダリングされる前にエスケープします。そのため、以下のようにユーザーの入力を受け付ける場合でも、XSS などインジェクション攻撃を防ぐことができます。

const title = response.potentiallyMaliciousInput;
const element = <h1>{title}</h1>;

関数の場合はこんな感じ。

const formatName = (user) => {
  return user.firstName + ' ' + user.lastName;
}

const user = {
  firstName: 'Taro',
  lastName: 'Yamada'
};

const element = (
  <h1>
    Hello, {formatName(user)}!
  </h1>
);

式としての JSX

前述したとおり、JSX はトランスコンパイルされるとReact.createElement()形式に変換されます。つまり、通常の JavaScript 関数呼び出しと同じようになるわけです。

このことから、JSX を if 分や for ループの中で使うことも可能です。変数に代入したり、引数として受け取ったり、関数から返すということもできます。

const getGreeting = (user) => {
  if (user) {
    return <h1>Hello, {formatName(user)}!</h1>;
  }
  return <h1>Hello, Stranger.</h1>;
}

条件付きレンダー

論理値 or 論理式と && の組み合わせで、条件によってレンダリングする内容の切り替えができます。

render() {
  const flg = true;
  return (
    <div>
      {/* flg変数がtrueの時のみレンダリング */}
      {flg && <p>フラグ：true</p>}
      {/* flg変数がfalseの時のみレンダリング */}
      {!flg && <p>フラグ：false</p>}
    </div>
  )
}

// 三項演算子を使用した例
render() {
  const flg = true;
  return (
    <div>
      {flg ? <p>フラグ：true</p> : <p>フラグ：false</p>}
    </div>
  )
}

props

React のコンポーネントには、props という任意の値を渡すことができるようになっています。親コンポーネントから子コンポーネントにデータを渡すイメージ。これにより、同じコンポーネントでも、渡された props によって UI やロジックに変化をつけることができます。

// コンポーネント呼び出し側
<Message name="Taro" />

// コンポーネント側（関数コンポーネントの例）
const Message = (props) => {
  return <h1>Hello, {props.name}</h1>;
}

// コンポーネント側（クラスコンポーネントの例）
class Message extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}</h1>;
  }
}

children

子要素を意味する props。要素やコンポーネントの中身を children で指定する書き方もできます。そのため、以下のコードは等価になります。

<h1>test</h1>

<Message>test</Message>

<h1 children="test" />

<Message children="test" />

props として渡されるので、コンポーネント側で使用できます。

const Message = (props) => {
  return <h1>{props.children}</h1>
}

HTML の属性名

React DOM においても、HTML の属性を使うことができますが、キャメルケースの命名規則を使用します。例として、tabindex はtabIndexなど。変わった例として、class はclassNameとなりますが、これは class が JavaScript において予約語であるためです。

また、style でインラインスタイルを指定する時は、文字列形式でなくオブジェクト形式で渡します。（疑似要素やメディアクエリは指定できません）

<h1 style={{ color: 'red' }}>test title</h1>

読み取り専用

全ての React コンポーネントは、自己の props に対して純関数のように振る舞わねばなりません。

React にはこのようなルールがあります。

つまり、受け取った props を変更するようなことはしてはいけません。同じ入力に対し同じ結果を返す「純関数」のような振る舞いをする必要があります。

// 純関数でない例
const withdraw = (account, amount) => {
  account.total -= amount;
}

// 純関数の例
const sum = (a, b) => {
  return a + b;
}

props の型定義

一見、便利な props ではありますが、デフォルトではどんな値も受け取れてしまうという特徴があります。そのため、ぱっと見どんな値を渡せばいいかわからなかったり。誤って予期しない値を渡してエラーとなり、アプリをクラッシュさせてしまったり。

もし TypeScript を使用しているのであれば、そのまま型定義が可能です。しかし、JavaScript だとそうはいかないので、別途PropTypesというライブラリを導入する必要があります。

自記事もありますので、よかったらこちらも参照ください。

JS×Reactにおけるpropsの型定義を担うPropTypes入門

state

コンポーネントに持たせられる「状態」のことを指します。

デフォルトでは、クラスコンポーネントのみ state を持つことができます。設定するには、まずクラスコンポーネントにコンストラクタを追加して state を初期化。 (クラスコンポーネントのコンストラクタは、常に props を引数として、親クラスのコンストラクタを呼び出す必要があります)

class Square extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      value: 'no set',
    };
  }

  render() {
    return (
      <div>
        <h1>Hello, world!</h1>
        <h2>state：{this.state.value}.</h2>
      </div>
    );
  }
}

state の更新

読み取り専用の props と違い、state は値の更新が可能です。

更新するには、直接 state に再代入するのでなく、this.setStateを使用して更新するようにします。なお、一度のsetStateで複数の state の値更新も可能です。

state が更新されると、そのコンポーネントは再度レンダリングされます。（setStateを使用せずに state を直接変更した場合は再レンダリングされないのでやらないこと）

class Square extends React.Component {
  ※一部省略

  render() {
    return (
      // ボタンクリックで state に値をセットする
      <button className="square" onClick={() => this.setState({value: 'X'})}>
        {this.state.value}
      </button>
    );
  }
}

setStateを使った更新では、引数のオブジェクトを現在の state にマージするというやり方で更新されます。例えば、複数の state を持っていた場合。

constructor(props) {
  super(props);
  this.state = {
    posts: null,
    comments: null
  };
}

this.setState({ posts: 'posts value'})のように posts だけの更新をしても、comments の現在の値には影響しません。逆もまた然りです。マージ時における比較の仕方としては shallow （浅く）で行われます。

state の更新タイミング

this.props と this.state は非同期に更新されるため、setState時にそれらの値に依存してはいけません。予期しない動作を引き起こす可能性があります。

// NG な例
this.setState({
  counter: this.state.counter + this.props.increment,
});

子コンポーネント側から親コンポーネントが持つ state を更新

子コンポーネントから親コンポーネントが持つ state を変更したいという時、this.stateはその親コンポーネント内でのプライベートになるため、子コンポーネントから直接呼び出しはできません。この場合は、親コンポーネントから子コンポーネントに state を更新する関数を渡すようにして、その関数を子コンポーネントから呼び出すことで対処できます。

// 子コンポーネント側
class Square extends React.Component {
  ※一部省略

  render() {
    return (
      <button className="square" onClick={() => this.props.onClick()}>
        {this.props.value}
      </button>
    );
  }
}

// 親コンポーネント側
class Board extends React.Component {
  ※一部省略

  handleClick(i) {
      // 配列のコピーを作成
      const squares = this.state.squares.slice();
      squares[i] = 'X';
      this.setState({squares: squares});
  }

  renderSquare(i) {
    return <Square value={this.state.squares[i]} onClick={() => this.handleClick(i)}/>;
  }
}

イベント

通常の DOM 要素でのイベント処理とほとんど同じですが、主な違いとしては、以下の2つです。

React のイベントは小文字でなく、キャメルケース（onclick → onClick）
JSX ではイベントハンドラとして、文字列でなく関数を渡す

<button onClick={() => {console.log('Hello World')}}>こんにちは</button>

イベントの例。

onClick：クリックされた時、button タグなど
onSubmit：送信された時、form タグなど
onChange：入力や削除が行われた時、input タグなど
onMouseOver：マウスカーソルが上に置かれた時
onMouseOut：マウスカーソルが外れた時

onChange の例 eventは合成 (synthetic) イベントです。event.target.valueで入力された値を取得できます。

<input onChange={(event) => {console.log(event.target.value)}} />

preventDefault

a タグのリンクや form の送信など、その要素が持つデフォルトのイベントをキャンセルしたい時。 HTML では false を返すようにすることで、デフォルトのイベントを抑制できましたが、React ではpreventDefaultを使う必要があります。

const ActionLink = () => {
  const handleClick = (e) => {
    e.preventDefault();
    console.log('The link was clicked.');
  }

  return (
    <a href="#" onClick={handleClick}>
      Click me
    </a>
  );
}

リストと key

要素のリストをレンダリングする際、リストの項目それぞれについて、React は情報を保持します。リストに変更、追加、削除などがあった時に、どのアイテムが変更になったのかを React へ伝えるために key を与えるようにしましょう。

リストが再レンダリングされる際、React はそれぞれのリスト項目の key について、前回のリスト項目内に同じ key を持つものがないか探します。その結果によってリスト項目を追加したり、削除したりするわけです。もし key が設定されていないリスト項目を変更した場合、React は正しく再レンダリングできなくなります。

ちなみに key の値は兄弟要素の中で一意であれば問題ないようです。

なお、リスト項目に key プロパティを設定していないと、コンソールで警告が表示されます。また、key プロパティは props の一部のようにも見えますが、this.props.keyで参照はできません。

const numbers = [1, 2, 3, 4, 5];
const listItems = numbers.map((number) =>
  <li key={number.toString()}>
    {number}
  </li>
);

リスト項目をコンポーネント化した際は、呼び出し時に key を設定するようにしましょう。

const ListItem = (props) => {
  // ここでは key を指定しない
  return <li>{props.value}</li>;
}

const NumberList = (props) => {
  const numbers = props.numbers;
  const listItems = numbers.map((number) =>
    // ここで key を指定
    <ListItem
      key={number.toString()}
      value={number}
    />
  );
  return (
    <ul>
      {listItems}
    </ul>
  );
}

ライフサイクル

React において、以下のようなライフサイクルがあります。これらは、デフォルトではクラスコンポーネントのみ使用できるようになっています。

ライフサイクルの流れ図 <ImageWrapper className="w-[80%]" src="screenshots/2019/react-basics/react-lifecycle.png" alt="Reactコンポーネントのライフサイクル図" />

マウント

コンポーネントのインスタンスが作成されて DOM に挿入される時、以下のメソッドが次の順序で呼び出されます。

constructor()
static getDerivedStateFromProps()
render()
componentDidMount()

更新

props や state の変更によって発生します。コンポーネントが再レンダリングされるときに、以下のメソッドが次の順序で呼び出されます。

static getDerivedStateFromProps()
shouldComponentUpdate()
render()
getSnapshotBeforeUpdate()
componentDidUpdate()

アンマウント

コンポーネントが DOM から削除されるときに呼び出されます。

componentWillUnmount()

エラーハンドリング

任意の子コンポーネントのレンダリング中、ライフサイクルメソッド内、またはコンストラクタ内でエラーが発生したときに呼び出されます。

static getDerivedStateFromError()
componentDidCatch()

それぞれのメソッドの解説

長くなりそうなので省略します。

こちらで詳しく解説されていますのでご参照ください。 <OG url="https://ja.reactjs.org/docs/react-component.html" /> <OG url="https://qiita.com/Julia0709/items/3c3fc8d29fd2e56ed7a9" />

React Hooks

React 16.8 より React Hooks という機能が導入されました。これにより、今までクラスコンポーネントでしか使うことのできなかった state やライフサイクルなどの機能を、関数コンポーネントへ付与できるようになりました。 use〇〇という名称が特徴です。

フックのルール

フックのルールとしては、以下の2つがあります。

フックは関数のトップレベルのみで呼び出すこと（ループや条件分岐、ネストした関数の中では呼び出さない）
フックは React の関数コンポーネントの内部もしくはカスタムフックの内部でのみ呼び出すこと

これらのルールを強制するための ESLint ルールがあるため、それを利用すると変な使い方をせずにすみます。（Create React App で作った環境の場合は、react-scripts の依存関係として導入されています） <OG url="https://github.com/facebook/react/blob/main/packages/eslint-plugin-react-hooks/README.md" />

フックの種類

フックだけでも記事を書けるくらいのボリュームなので、ここでは簡単な紹介のみ記載します。基本的には、最後の3つはあまり使いません。

useState：state 機能を提供するフック（現在の state の値と、state を更新するための関数を返す）
useEffect：副作用のためのフック（マウント時・アンマウント時の処理、依存配列にある特定の値変更を検知して特定の処理実行など）
useContext：コンテクスト（props を使わず、コンポーネント間でデータを共有できるもの）オブジェクトを受け取り、そのコンテクストの現在値を返すフック
useReducer：useState の代替となるフック（より複雑な state ロジックがある場合などに有効）
useCallback：メモ化されたコールバックを返すフック（依存配列にある値が変化した時のみ再生成するようにするため、パフォーマンス最適化に活用）
useMemo：メモ化された値を返すフック（計算結果などをメモ化。依存配列にある値が変化した時のみ再計算するようにするため、パフォーマンス最適化に活用）
useRef：ミュータブルな ref オブジェクトを返すフック（特定の DOM 要素へのアクセスや、置き換え可能な値を保持に使える）
useImperativeHandle：親コンポーネントから渡された ref をカスタマイズするフック（ref を通して、子コンポーネントで定義した関数を親コンポーネントから呼び出すのに使える）
useLayoutEffect：useEffect と類似しているが、呼び出されるタイミングが微妙に異なるフック（基本的には useEffect を使うのを推奨している）
useDebugValue：React DevTools でカスタムフックのラベル表示ができるフック

項の初めに以下のように書きました。

今までクラスコンポーネントでしか使うことのできなかった state やライフサイクルなどの機能を、関数コンポーネントに付与できるようになりました。

クラスコンポーネントで使える機能が関数コンポーネントでも使えるというのは、おおよそ間違ってはいないのですが、厳密には微妙に仕様が異なる部分もあることに注意です。詳細は公式ドキュメントを読んでみてください。

カスタムフック

フックは、自分で独自のものを作ることも出来ます。

use〇〇の命名規則
カスタムフックのトップレベルで他のフックを呼び出せる

これ以外は、通常の関数と同じです。

コンポーネントファイルにロジックを書くとごちゃごちゃしがちなので、カスタムフックに処理を切り出して、そのロジックを使いたいコンポーネントで適宜呼び出すという使い方をします。

TypeScript での React

現在、新たに React アプリを作成するとすれば、TypeScript を使うのがデファクトになっているような印象を受けます。自分も、この記事を最初に投稿した頃は JavaScript を使用していましたが、現在は TypeScript をすっかり使うようになりました。

各種型定義が必要になるので、慣れないうちは面倒に感じることもあるでしょう。しかし、型定義がある分、強力な入力補完や型補完が効くようになります。とても心強いものになってくれることでしょう。

TypeScript での React について、ここでは少しだけ紹介します。

関数コンポーネントの型定義

FCもしくはVFCを使います。 FCは、関数コンポーネントの型インタフェースFunctionComponentのエイリアス。 VFCも同様に、関数コンポーネントの型インタフェースであるVoidFunctionComponentのエイリアス。

その違いをざっくりいうと、暗黙的に children props を許容しているかです。

const MyButton: FC = ({ children }) => {
  return (
    <button>{children}</button>
  )
}

const MyButton: VFC = () => {
  return (
    <button>VFC Button</button>
  )
}

独自 props の型定義をするとなると以下のような感じになるのですが...。 FCの場合、デフォルトで children props の定義が含まれているので、独自で children props の型定義を追加しなくても受け取って使えます。

type Props = {
  title: string;
}

const TextBlock: FC<Props> = ({ title, children }) => {
  return (
    <div>
      <h2>{title}</h2>
      <p>{children}</p>
    </div>
  )
}

もし children を使用しない場合でも children を許容する形となるため、それってどうなの？という議論がありまして。元々、FCから children を外す動きがあったようで、将来的になくす予定のようです。ただ、破壊的な変更となってしまうため、移行措置として children を含まないVFCが導入されたとのこと。

現状ではVFCを使用して、children を使いたい時は明示的に型定義を追加。 FCから children がなくなったのちに、VFCだったものをFCに置換する。という流れがよさそうです。

ちなみにかつてはSFC（Stateless Functional Component）というものが使われていましたが、現在は非推奨となっています。

既定の型を使った型定義

props の型定義をするにあたって、既存要素の型定義や、既存コンポーネントの型定義を使いたい時があります。そんな時はComponentPropsWithRefかComponentPropsWithoutRefで取得できます。両者の違いがよくわかってなかったのですが、どうも ref を含むかどうかの違いのようです（前者が ref を含む）

import { VFC, ComponentPropsWithRef } from 'react';

// button 要素が持つ props を取得
type Props = ComponentPropsWithRef<'button'>;

const MyButton: VFC<Props> = ({ children, ...props }) => {
  return (
    <button {...props}>{children}</button>
  )
}

// コンポーネントの props 型定義取得
type TestButtonProps = ComponentPropsWithRef<typeof MyButton>;

特定のプロパティを除外するOmitや、特定のプロパティを抽出するPickなどと組み合わせると、より柔軟な型定義ができます。 &で独自のプロパティを追加して拡張したり。

その他、style 属性の型定義について触れてみます。 style 属性の型定義としてはCSSPropertiesとなっているので、個別の CSS プロパティの型定義を使う際は、そのプロパティにアクセスすれば OK です。

import { CSSProperties } from 'react';

type Props = {
  width: CSSProperties['width'];
  textAlign: CSSProperties['textAlign'];
}

React の基礎としてどこまで書くか迷いましたが、公式チュートリアルで扱われたものを中心に今回書きました。続編として、フォームや Router、Recompose や Redux、React Hooks などについて書いていけたらと。

{/*  */}

※2021/09/13 追記この記事は、自分が React 記事を書くようになったきっかけの記事なので、少々思い入れがありまして。当時の React 歴としては、3か月程度。今の自分として読み返すと、色々説明不足なところあるなぁとか思いながら、今回記事内容を見直してみました。それだけ、当時と比べて成長できているということかもしれませんね。

{/*  */}

引き続き、React 周辺の知識を深めていきますー。

参考リンクまとめ

Jekyll製ブログの記事に目次を追加する

Sun, 10 Nov 2019 00:00:00 GMT

より良いブログ記事を書くために...と解説されている記事などを見ていて、そういえば自分の記事には目次がなかったなと気づきました。記事が長くなってくると目次ありの方が見やすいですよね。 Jekyll の記事に目次を追加する方法を調べて、導入してみました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

目次をどうやって導入する？

まずはどうすれば追加できるのか、楽に追加できるプラグインなどはあるのかと調べました。

プラグイン

プラグインは主に以下の2つがあるようでした。 <OG url="https://github.com/dafi/jekyll-toc-generator" /> <OG url="https://github.com/toshimaru/jekyll-toc" />

記事で使用するレイアウトファイルに記述しておけば、すべての記事に適用される点は便利そうだなと思いました。 1つのファイルに記述しておけばいいだけなので、各記事のマークダウンファイルに記述を追加する必要がありません。

ただ、自分が目次を入れたい場所は記事の中（contentの中）の導入文の後でした。プラグインを使用すると、これは実現できそうになさそうでした。

kramdown の機能

Jekyll のマークダウンにはkramdownが使用されています。

このkramdownには目次を追加する機能、Automatic "Table of Contents: Generationが元々搭載されており。各記事にコードを記述する必要がありますが、自由に表示場所を指定できるということで今回はこちらを使用することにしました。

目次の追加

直接マークダウンファイルに追記

使用するには、各記事のマークダウンファイルで目次を挿入したい箇所に以下のコード追加するだけです。なお、*以降の文言はなんでもOK。

* A markdown unordered list which will be replaced with the ToC, excluding the "Contents header" from above
{:toc}

これだけで、記事内の見出しタグを検知して自動で目次を作成してくれます。コードとしては以下のようになります。（前回の記事の例）各要素に id が設定されるので、見た目のカスタマイズも自由に行えます。

<ul id="markdown-toc">
  <li>
    <a href="#eslint" id="markdown-toc-eslint">ESLint</a>
    <ul>
      <li>
        <a href="#導入" id="markdown-toc-導入">導入</a>
        <ul>
          <li><a href="#手順" id="markdown-toc-手順">手順</a></li>
          <li><a href="#error対応" id="markdown-toc-error対応">Error対応</a></li>
          <li><a href="#warning対応" id="markdown-toc-warning対応">Warning対応</a></li>
        </ul>
      </li>
      <li>
        <a href="#設定のカスタマイズ" id="markdown-toc-設定のカスタマイズ">設定のカスタマイズ</a>
        <ul>
          <li><a href="#設定ファイルについて" id="markdown-toc-設定ファイルについて">設定ファイルについて</a></li>
          <li><a href="#ウィザードで設定ファイルを作成して使用" id="markdown-toc-ウィザードで設定ファイルを作成して使用">ウィザードで設定ファイルを作成して使用</a></li>
          <li><a href="#既存の設定ファイルを使用" id="markdown-toc-既存の設定ファイルを使用">既存の設定ファイルを使用</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li>
    <a href="#prettier" id="markdown-toc-prettier">Prettier</a>
    <ul>
      <li><a href="#コマンドラインとしてeslint連携" id="markdown-toc-コマンドラインとしてeslint連携">コマンドラインとしてESLint連携</a></li>
      <li><a href="#vscode上でeslint連携" id="markdown-toc-vscode上でeslint連携">VSCode上でESLint連携</a></li>
      <li>
        <a href="#設定のカスタマイズ-1" id="markdown-toc-設定のカスタマイズ-1">設定のカスタマイズ</a>
        <ul>
          <li><a href="#設定ファイル" id="markdown-toc-設定ファイル">設定ファイル</a></li>
        </ul>
      </li>
    </ul>
  </li>
  <li><a href="#ファイル保存時に自動整形" id="markdown-toc-ファイル保存時に自動整形">ファイル保存時に自動整形</a></li>
  <li><a href="#参考" id="markdown-toc-参考">参考</a></li>
</ul>

HTML ファイルに分離して追記

目次生成のコードを直接マークダウンファイルに記述してもいいのですが、より柔軟にカスタマイズできるよう HTML ファイルに分離して、それを読み込むようにもできます。

こちらの方がよりスマートな感じに思ったので、自分はこちらの方法にしました。

_includes配下にファイルを作成して、目次生成コードを記述自分はtoc.htmlというファイルを作成しました。

<nav class="post-nav-links">
  <h4>目次</h4>
  * table
  {:toc}
</nav>

sassファイルを用意して、目次のレイアウトを整えるこの辺はお好みで。 ※補足：以下で使用している$gray-1、$gray-6については使用テーマで定義されている色を指定しています。

// 例
.post-nav-links {
  border: 1px solid $gray-6;
  background-color: $gray-1;
  margin-top: 2rem;
}

.post-nav-links h4 {
  font-weight: bold;
  text-align: center;
}

各記事のマークダウンファイルにて、1で作成したファイルを読み込む includeを使用して読み込みます。
_config.ymlに設定を追記

kramdown:
  parse_block_html: true

1で記述した目次生成コードについては、あくまで kramdown の機能であるため、通常はマークダウンファイル内でしか使用できません。上記設定を追記することで、ブロックレベルの要素を含むテキストとしてブロック HTML タグのコンテンツのマークダウン構文を処理できるようになり、目次が生成できるようになります。 (2020/1/3 一部説明を修正)

これらで生成された目次が以下のようになります（前回の記事の例） ↓ <ImageWrapper className="w-[80%]" src="screenshots/2019/jekyll-toc/toc.png" alt="kramdownの機能で生成した目次の例" />

これでいくらか記事が見やすくなりましたね。これからもこういったブログ改善をやっていきますー。

参考リンクまとめ

create-react-appで作成した雛形 + VSCodeにESLintとPrettierを導入する

Wed, 06 Nov 2019 00:00:00 GMT

前回、DockerでReact + Swagger 環境を作ろうという記事を書いたのですが、VSCode へ ESLint 導入時に少し手間取ったので別記事にしました。あわせてコード整形ツールである Prettier も導入したので、その手順を書いておきます。

※この記事は Qiita からの転載です。

※2021/03/22追記　eslint-plugin-prettierが非推奨になったりと情報が古くなったので、全体的に書き直しました。 ※2021/08/22追記　--template typescriptで TypeScript にした場合にも対応しました。

import OG from '@/components/OG.astro'

ESLint

静的解析ツールです。コーディングする上でのルールを決められるので、チーム開発するうえでコードのスタイルを統一できます。

セットアップの確認

create-react-app で作成された雛形では、すでに ESLint に関するパッケージが導入されており。 yarn.lock でreact-scriptsの依存関係となっているのを確認できます。 create-react-app を--template typescriptとしていても、同様です。

以下はcreate-react-app@4.0.3で作成した React プロジェクトの例です。

※一部抜粋
react-scripts@4.0.3:
  version "4.0.3"
  resolved "https://registry.yarnpkg.com/react-scripts/-/react-scripts-4.0.3.tgz#b1cafed7c3fa603e7628ba0f187787964cb5d345"
  integrity sha512-S5eO4vjUzUisvkIPB7jVsKtuH2HhWcASREYWHAQ1FP5HyCv3xgn+wpILAEWkmy+A+tTNbSZClhxjT3qz6g4L1A==
  dependencies:
    "@babel/core" "7.12.3"
    "@pmmmwh/react-refresh-webpack-plugin" "0.4.3"
    "@svgr/webpack" "5.5.0"
    "@typescript-eslint/eslint-plugin" "^4.5.0"
    "@typescript-eslint/parser" "^4.5.0"
    babel-eslint "^10.1.0"
    babel-jest "^26.6.0"
    babel-loader "8.1.0"
    babel-plugin-named-asset-import "^0.3.7"
    babel-preset-react-app "^10.0.0"
    bfj "^7.0.2"
    camelcase "^6.1.0"
    case-sensitive-paths-webpack-plugin "2.3.0"
    css-loader "4.3.0"
    dotenv "8.2.0"
    dotenv-expand "5.1.0"
    eslint "^7.11.0"
    eslint-config-react-app "^6.0.0"
    eslint-plugin-flowtype "^5.2.0"
    eslint-plugin-import "^2.22.1"
    eslint-plugin-jest "^24.1.0"
    eslint-plugin-jsx-a11y "^6.3.1"
    eslint-plugin-react "^7.21.5"
    eslint-plugin-react-hooks "^4.2.0"
    eslint-plugin-testing-library "^3.9.2"
    eslint-webpack-plugin "^2.5.2"
    file-loader "6.1.1"
    fs-extra "^9.0.1"
    html-webpack-plugin "4.5.0"
    identity-obj-proxy "3.0.0"
    jest "26.6.0"
    jest-circus "26.6.0"
    jest-resolve "26.6.0"
    jest-watch-typeahead "0.6.1"
    mini-css-extract-plugin "0.11.3"
    optimize-css-assets-webpack-plugin "5.0.4"
    pnp-webpack-plugin "1.6.4"
    postcss-flexbugs-fixes "4.2.1"
    postcss-loader "3.0.0"
    postcss-normalize "8.0.1"
    postcss-preset-env "6.7.0"
    postcss-safe-parser "5.0.2"
    prompts "2.4.0"
    react-app-polyfill "^2.0.0"
    react-dev-utils "^11.0.3"
    react-refresh "^0.8.3"
    resolve "1.18.1"
    resolve-url-loader "^3.1.2"
    sass-loader "^10.0.5"
    semver "7.3.2"
    style-loader "1.3.0"
    terser-webpack-plugin "4.2.3"
    ts-pnp "1.2.0"
    url-loader "4.1.1"
    webpack "4.44.2"
    webpack-dev-server "3.11.1"
    webpack-manifest-plugin "2.2.0"
    workbox-webpack-plugin "5.1.4"
  optionalDependencies:
    fsevents "^2.1.3"

設定に関してはpackage.jsonに記述があり、デフォルトではこの設定で ESLint が動作します。

"eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },

最低限のセットアップはすでに行われているので、あとはそれをカスタマイズしていくだけです。

CLI で動かしてみる

チェックを行いたいファイルパスを指定して実行します。

コマンド例。

# JS
yarn run -s eslint './src/**/*.{js,jsx}'

# TS
yarn run -s eslint './src/**/*.{js,jsx,ts,tsx}'

自動整形までやりたい場合は--fixをつけて実行します。

コマンド例。

# JS
yarn run -s eslint './src/**/*.{js,jsx}' --fix

# TS
yarn run -s eslint './src/**/*.{js,jsx,ts,tsx}' --fix

注意点として、自動整形は必ずしも全ての問題個所を直してくれるわけではありません。自動整形で対応できない箇所は、自分たちで直す必要があります。

VSCode エディタ上で ESLint を動作させる際は、あまりコマンドを使用しなくなりそうですが、CI でのテスト時に使用したりということがあります。使いやすいようにpackage.jsonの scripts にコマンドを設定しておくとよいです。

TypeScript 向けの例。

"scripts": {
  .
  .
  .
  "lint:eslint": "eslint './src/**/*.{js,jsx,ts,tsx}'",
  "fix:eslint": "yarn lint:eslint --fix"
}

VSCode 上で動かす

インストールして再起動。特に問題なければこれだけでチェックが動作します。

ファイル保存時に自動整形を走らせたい場合は、VSCode の設定ファイルにその旨追記します。デフォルトのフォーマッタは無効にして、ESLint によるフォーマットをかけるイメージです。

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "editor.formatOnSave": false,
}

ESLint の設定ファイル

設定の定義の仕方としては、以下の4パターンがあります。

package.jsonの eslintConfig に書く
JavaScript ファイル（例　.eslintrc.js）に書く
JSON ファイル（例　.eslintrc.json）に書く
YAML ファイル（例　.eslintrc.yml）に書く

個人的な好みとしては2番目です。別ファイルにしておいた方が、一度作成した設定を別プロジェクトで使いまわしたりしやすいです。

設定の記述方式は公式をご参照ください。 <OG url="https://eslint.org/docs/latest/use/configure/" />

それと、ESLint のチェックから除外したいファイルがある場合は、.eslintignore ファイルを作って書いておくことで対応できます。

node_modules/

ESLint の設定ファイルを対話式で作成

ESLint の設定ファイルは対話式で作成も可能です。まずこれで雛形を作成して、そこからカスタマイズしていくとよいです。

以下は回答の流れの例です。

yarn run -s eslint --init

ESLint をどのように使用しますか？

? How would you like to use ESLint?
  To check syntax only
  To check syntax and find problems
❯ To check syntax, find problems, and enforce code style

どんなモジュールを使用していますか？

? What type of modules does your project use?
❯ JavaScript modules (import/export)
  CommonJS (require/exports)
  None of these

どのフレームワークを使用していますか？

? Which framework does your project use?
❯ React
  Vue.js
  None of these

TypeScriptは使用していますか？

? Does your project use TypeScript? No / Yes

コードはどこで実行されますか？

? Where does your code run? (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯ Browser
  Node

プロジェクトのスタイルをどのように定義しますか？

? How would you like to define a style for your project?
❯ Use a popular style guide
  Answer questions about your style
  Inspect your JavaScript file(s)

どのスタイルガイドをフォローしますか？

? Which style guide do you want to follow? (Use arrow keys)
❯ Airbnb (https://github.com/airbnb/javascript)
  Standard (https://github.com/standard/standard)
  Google (https://github.com/google/eslint-config-google)

設定ファイルのフォーマットはどれにしますか？

? What format do you want your config file to be in? (Use arrow keys)
❯ JavaScript
  YAML
  JSON

npm でこれらのパッケージをインストールしますか？（yarn でインストールしたい場合は No を選択して、案内されたパッケージを手動でインストールする必要があります）

eslint-plugin-react@^7.14.3 eslint-config-airbnb@latest eslint@^5.16.0 || ^6.1.0 eslint-plugin-import@^2.18.2 eslint-plugin-jsx-a11y@^6.2.3 eslint-plugin-react-hooks@^1.7.0
? Would you like to install them now with npm? No / Yes
  No

この回答例だと、以下のような設定ファイルが作られます。

// TypeScript を使わないと回答した場合
module.exports = {
    "env": {
        "browser": true,
        "es2021": true
    },
    "extends": [
        "plugin:react/recommended",
        "airbnb"
    ],
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 12,
        "sourceType": "module"
    },
    "plugins": [
        "react"
    ],
    "rules": {
    }
};

// TypeScript を使うと回答した場合
module.exports = {
    "env": {
        "browser": true,
        "es2021": true
    },
    "extends": [
        "plugin:react/recommended",
        "airbnb"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 12,
        "sourceType": "module"
    },
    "plugins": [
        "react",
        "@typescript-eslint"
    ],
    "rules": {
    }
};

スタイルガイドの導入

ESLint の設定ファイルを対話式で作成時の回答にもありましたが、企業などのスタイルガイドを準拠した ESLint の共有設定が存在します。全く一からルール設定をするのは大変なので、この共有設定を適用して、適宜カスタマイズするとよいです。

以下は Airbnb の共有設定を使用する例です。

パッケージをインストール。

yarn add -D eslint-config-airbnb

設定の extends に追加（.eslintrc.jsでの例）

extends: [
  'plugin:react/recommended',
  'airbnb', // 追記
]

トラブルシューティング

ルート階層に設定ファイルがない場合

VSCode の ESLint 拡張は、ワークスペースに追加したフォルダの直下に設定ファイル（.eslintrc.js、package.jsonなど）がある前提で動作します。直下にない場合は、VSCode の設定ファイルで別途指定する必要があります。

※例（app 直下に設定ファイルがある場合）

{
  "eslint.workingDirectories": [
	  "./app"
  ]
}

React のバージョン検知に問題がある場合

ESLint 実行時に eslint-plugin-react の設定で React のバージョンが指定されていませんと表示されることがあります。

Warning: React version not specified in eslint-plugin-react settings. See https://github.com/yannickcr/eslint-plugin-react#configuration .

ESLint の設定ファイルに以下を追記することで、バージョンを自動検知させることが可能です。

settings: {
  react: {
    version: 'detect'
  }
}

しかし、Docker コンテナの中に Node.js 環境があるが、ローカルの VSCode 上で ESLint 拡張を動かしている（ローカルに Node.js 環境がない）。などといった、環境によって次の Warning が出ることもあります。

Warning: React version was set to "detect" in eslint-plugin-react settings, but the "react" package is not installed. Assuming latest React version for linting.

上記のような環境においては、さすがにバージョン検知ができないようです。

この場合は ESLint の設定に、明示的にバージョンを指定することで対応できます。

settings: {
  react: {
    version: '17.0.2'
  }
}

@typescript-eslint/typescript-estree のサポートバージョン外の場合

TypeScript のバージョンにより、@typescript-eslint/typescript-estree がサポートしているバージョンでないとの Warning が表示されることがあります。

=============

WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree.

You may find that it works just fine, or you may not.

SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <4.2.0

YOUR TYPESCRIPT VERSION: 4.3.5

Please only submit bug reports when using the officially supported version.

=============

あくまで Warning のため、ESLint 自体は動作します。気になる方は、バージョンを合わせる。そのままのバージョンを使う方は、そのバージョンではバグレポート受付に対応していないことを理解したうえで使用しましょう。

Prettier

幅広いファイル形式に対応したコードフォーマッタです。 ESLint とあわせて導入しておくと、さらなるコードの品質向上に繋がります。

react-scriptsの依存関係に Prettier に関するものはないので、追加でライブラリをインストールしていく必要があります。

連携セットアップ

ライブラリインストール。

yarn add -D prettier eslint-config-prettier

ESLint の設定ファイルに追記。

extends: [
  'plugin:react/recommended',
  'airbnb',
  'prettier', // 追記
],

ESLint と Prettier はルール競合することがあるので、eslint-config-prettier を適用することで競合するルールを無効化して調整します。その性質上、追加するのは extends の最後にしてください。

ちなみに eslint-config-prettier は、競合しているルールがないかチェックする CLI ツールを持っていたりします。

# JS
yarn run -s eslint-config-prettier './src/**/*.{js,jsx}'

# TS
yarn run -s eslint-config-prettier './src/**/*.{js,jsx,ts,tsx}'

問題なければ以下のような表示になります。

No rules that are unnecessary or conflict with Prettier were found.

CLI で動かしてみる

チェックを行いたいファイルパスを指定して実行します。

# JS
yarn run -s prettier --check './{public,src}/**/*.{js,jsx,html,gql,graphql,json}'

# TS
yarn run -s prettier --check './{public,src}/**/*.{js,jsx,ts,tsx,html,gql,graphql,json}'

自動整形までやりたい場合は--writeをつけて実行します。

# JS
yarn run -s prettier --check './{public,src}/**/*.{js,jsx,html,gql,graphql,json}' --write

# TS
yarn run -s prettier --check './{public,src}/**/*.{js,jsx,ts,tsx,html,gql,graphql,json}' --write

このコマンドも ESLint の時と同様に、package.jsonの scripts に追加しておくとよいです。

TypeScript 向けの例。

"scripts": {
  .
  .
  .
  "check:prettier": "prettier --check './{public,src}/**/*.{js,jsx,ts,tsx,html,gql,graphql,json}'",
  "fix:prettier": "yarn check:prettier --write",
}

ESLint とセットで1コマンド実行したい場合は、下記のようにする手もあります。

TypeScript 向けの例。

"scripts": {
  .
  .
  .
  "lint-check": "yarn lint:eslint && yarn check:prettier",
  "lint:eslint": "eslint './src/**/*.{js,jsx,ts,tsx}'",
  "check:prettier": "prettier --check './{public,src}/**/*.{js,jsx,ts,tsx,html,gql,graphql,json}'",
  "fix": "yarn fix:eslint && yarn fix:prettier",
  "fix:eslint": "yarn lint:eslint --fix",
  "fix:prettier": "yarn check:prettier --write",
}

VSCode 上で動かしてみる

インストールして必要に応じて再起動。

VSCode の設定ファイルに以下を追記。

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.formatOnSave": true
  },
  "[javascriptreact]": {
    "editor.formatOnSave": true
  },
  "[json]": {
    "editor.formatOnSave": true
  },
  // TypeScript の場合は以下も
  "[typescript]": {
    "editor.formatOnSave": true
  },
  "[typescriptreact]": {
    "editor.formatOnSave": true
  },
}

VSCode のデフォルトのフォーマッタとして Prettier を設定。加えて、上記3つのファイル形式において、保存時に自動整形が動作するようにしています。

Prettier の設定ファイル

設定の定義の仕方としては、以下の6パターンがあります。

package.jsonの prettier に書く
.prettierrcファイルに書く
JavaScript ファイル（例　.prettierrc.js）に書く
JSON ファイル（例　.prettierrc.json）に書く
YAML ファイル（例　.prettierrc.yml）に書く
TOML ファイル（例　.prettierrc.toml）に書く

個人的な好みとしては2番目です。 ESLint と同様に別ファイルにしておいた方が、一度作成した設定を別プロジェクトで使いまわしたりしやすいです。

設定の記述方式は公式をご参照ください。 <OG url="https://prettier.io/docs/en/configuration.html" />

それと、Prettier のチェックから除外したいファイルがある場合は、.prettierignoreファイルを作って書いておくことで対応できます。

補足：glob を Windows にも対応させる（※2021/11/17追記）

上記では ESLint、Prettier のコマンドで、実行パスである glob 部分をシングルクォートで囲うようにしていました。 Mac や Linux といった Unix 環境であれば、これで問題ないのですが、Windows だとうまく動作しません。

Windows にも対応させる場合は、シングルクォートでなくダブルクォートで囲う必要があります。

"scripts": {
  .
  .
  .
  "lint-check": "yarn lint:eslint && yarn check:prettier",
  "lint:eslint": "eslint \"./src/**/*.{js,jsx,ts,tsx}\"",
  "check:prettier": "prettier --check \"./{public,src}/**/*.{js,jsx,ts,tsx,html,gql,graphql,json}\"",
  "fix": "yarn fix:eslint && yarn fix:prettier",
  "fix:eslint": "yarn lint:eslint --fix",
  "fix:prettier": "yarn check:prettier --write",
}

参考リンクまとめ

DockerでReact + Swagger 環境を作ろう

Thu, 24 Oct 2019 00:00:00 GMT

現在業務で React を使用しているのですが、事前勉強する際に Docker 環境を作成していたので、それを共有します。ちなみに Swagger 環境に関しては、自分で作成してうまくいかなかったので、上司が作成した環境を参考にさせてもらいました。感謝です。

※この記事は Qiita からの転載です。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

前提

Docker 導入済み
docker-compose コマンドが使用できる

※2020/02/29 create-react-appがグローバルインストールをサポートしなくなったことに伴い、React 用のコンテナ周りを見直しました。

事前準備

今回は4つのコンテナを使用。

node...React のコードを実行するコンテナ
swagger-editor...Swagger Editor のコンテナ
swagger-api...Swagger 定義ファイルから生成されたコードを実行するコンテナ
swagger-nginx...swagger-api の内容を配信するアプリケーションサーバのコンテナ（nginx をさらに高性能に使えるようにした openresty を使用）

これらに必要な設定ファイルを用意していきます。ちなみに作成後のディレクトリは以下のようになります。

(root)
├ docker
│ ├ nginx
│ │  └ swagger.conf
│ └ swagger-api
│     ├ Dockerfile
│     └ swagger.json
└ docker-compose.yml

nginx/swagger.conf

nginx（openresty）の設定を記述します。ここで CORS に関する設定をしておかないと、Reac t側から axios でリクエストする際にエラーとなってしまいます。（自分が最初環境を作ろうとしたときに、ここでつまづいていました。今も設定に関しては疎いです...。）

server {
  listen 80;
  server_name localhost;

  location /docs/ {
    proxy_pass http://swagger-api:8000/docs/;
  }

  location / {
    if ($request_method = 'OPTIONS') {
      add_header Access-Control-Allow-Origin $http_origin;
      add_header Access-Control-Allow-Headers 'X-Requested-With, Authorization, Origin, Accept, Content-Type';
      add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE';
      add_header Access-Control-Max-Age 86400;
      add_header Access-Control-Allow-Credentials true;
      add_header Access-Control-Expose-Headers Set-Cookie;
      add_header Content-Type 'text/plain charset=UTF-8';
      add_header Content-Length 0;
      return 204;
    }
    proxy_pass http://swagger-api:8000;
    add_header Access-Control-Allow-Origin $http_origin always;
    add_header Access-Control-Allow-Credentials true always;
    add_header Access-Control-Expose-Headers Content-Disposition;
  }
}

swagger-api/Dockerfile

Swagger 定義ファイルをもとにコードを生成するSwagger Codegenをインストールして、実際に Node.js のコードを生成しています。

FROM openjdk:8-jdk-alpine

ARG CLI_VERSION=2.4.5

RUN wget http://central.maven.org/maven2/io/swagger/swagger-codegen-cli/${CLI_VERSION}/swagger-codegen-cli-${CLI_VERSION}.jar -O /swagger-codegen-cli.jar

RUN apk --update add bash nodejs npm && rm -rf /var/cache/apk/*

ADD swagger.json swagger.json

RUN java -jar /swagger-codegen-cli.jar generate -l nodejs-server -i swagger.json -o src && \
    cd src && npm install

CMD ["java", "-jar", "/swagger-codegen-cli.jar"]

swagger-api/swagger.json

Swagger 定義ファイルです。ここでは簡単に1つだけ API を定義しています。

{
  "swagger": "2.0",
  "info": {
    "description": "テスト用API",
    "version": "1.0.0",
    "title": "Swagger test API設計書",
    "contact": {},
    "license": {
      "name": ""
    }
  },
  "host": "localhost:8000",
  "basePath": "/",
  "tags": [
    {
      "name": "User",
      "description": "User Controller"
    }
  ],
  "paths": {
    "/user": {
      "get": {
        "tags": [
          "User"
        ],
        "summary": "ユーザ情報取得",
        "description": "ユーザ情報を取得する。",
        "operationId": "doGetUsingGET",
        "consumes": [
          "application/json"
        ],
        "produces": [
          "application/json"
        ],
        "responses": {
          "200": {
            "description": "OK",
            "schema": {
              "$ref": "#/definitions/UserGetOut"
            }
          },
          "400": {
            "description": "バリデーションエラー",
            "schema": {
              "$ref": "#/definitions/ValidationErrorsOut"
            }
          },
          "500": {
            "description": "想定外のエラー",
            "schema": {
              "$ref": "#/definitions/ErrorInfo"
            }
          }
        }
      }
    }
  },
  "definitions": {
    "UserGetOut": {
      "type": "object",
      "required": [
        "userId",
        "name",
        "kana"
      ],
      "properties": {
        "userId": {
          "type": "string",
          "example": "abc001",
          "description": "ユーザID"
        },
        "name": {
          "type": "string",
          "example": "山田 太郎",
          "description": "名前"
        },
        "kana": {
          "type": "string",
          "example": "ヤマダ タロウ",
          "description": "カナ"
        }
      }
    },
    "ValidationError": {
      "type": "object",
      "required": [
        "itemName"
        "code",
        "content"
      ],
      "properties": {
        "itemName": {
          "type": "string",
          "example": "userId",
          "description": "項目名"
        },
        "code": {
          "type": "string",
          "example": "NotBlank",
          "description": "code"
        },
        "content": {
          "type": "string",
          "example": "必須項目が設定されていません。",
          "description": "content"
        }
      }
    },
    "ValidationErrorsOut": {
      "type": "object",
      "required": [
        "validationInfo"
      ],
      "properties": {
        "validationInfo": {
          "type": "array",
          "description": "バリデーション情報",
          "items": {
            "$ref": "#/definitions/ValidationError"
          }
        }
      }
    },
    "ErrorInfo": {
      "type": "object",
      "required": [
        "code",
        "content"
      ],
      "properties": {
        "code": {
          "type": "string",
          "example": "exception.errors.unexpeced.exception",
          "description": "エラーコード"
        },
        "content": {
          "type": "string",
          "example": "システムエラーが発生しました。誠に恐れ入りますが、初めからやり直して下さい。",
          "description": "メッセージ"
        }
      }
    }
  }
}

docker-compose.yml

今回使用する4つのコンテナ定義を書いていきます。なお、node の environment のCHOKIDAR_USEPOLLING=trueはホットリロードを有効化にするものです。

node の command については一旦コメントアウトしておきます。

※node_modules について補足説明 node_modules は volume マウントすることが多いとは思われます。コンテナ内のnpm or yarn の速度的にも、volume マウントの方がいいそうです。

ただ、そうするとローカルに node_modules ができなくなり、VSCode の ESLint 拡張を動かす時などに支障が出るので、あえてやっていません。（VSCode のRemote - Containers拡張を使えばコンテナ内で作業できるので、解決する話ではあるのですが今回はやってません）

version: "3"
services:
  node:
    image: node:12-alpine
    environment:
      - NODE_ENV=development
      - CHOKIDAR_USEPOLLING=true
    volumes:
      - ./:/usr/app
    tty: true
    stdin_open: true
    working_dir: /usr/app
    # command: /bin/sh -c "yarn install && yarn start"
    ports:
      - "3000:3000"

  swagger-editor:
    image: swaggerapi/swagger-editor
    ports:
      - "8081:8080"

  swagger-api:
    build: ./docker/swagger-api
    working_dir: /src
    command: node index.js

  swagger-nginx:
    image: openresty/openresty:alpine
    ports:
      - 8000:80
    depends_on:
      - swagger-api
    volumes:
      - ./docker/nginx/swagger.conf:/etc/nginx/conf.d/default.conf:ro

コンテナの作成と起動

コンテナのビルド

docker-compose build

コンテナ起動確認

State が Up になっていれば立ち上がっています。

docker-compose ps

React プロジェクト作成

プロジェクトの雛形作成

create-react-appを使用して雛形を作成します。なお、ここで使用しているバージョンは3.4.0です。

docker-compose exec node yarn create react-app my-app

yarn create v1.19.1
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
warning Your current version of Yarn is out of date. The latest version is "1.22.0", while you\'re on "1.19.1".
info To upgrade, run the following command:
$ curl --compressed -o- -L https://yarnpkg.com/install.sh | bash
success Installed "create-react-app@3.4.0" with binaries:
      - create-react-app
[####################################################################################################] 100/100
Creating a new React app in /usr/app/my-app.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...

yarn add v1.19.1
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.11: The platform "linux" is incompatible with this module.
info "fsevents@1.2.11" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents@2.1.2: The platform "linux" is incompatible with this module.
info "fsevents@2.1.2" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
warning "react-scripts > eslint-config-react-app@5.2.0" has incorrect peer dependency "eslint-plugin-flowtype@3.x".
warning "react-scripts > @typescript-eslint/eslint-plugin > tsutils@3.17.1" has unmet peer dependency "typescript@>=2.8.0 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev || >= 3.5.0-dev || >= 3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || >= 3.7.0-beta".
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 9 new dependencies.
info Direct dependencies
├─ cra-template@1.0.2
├─ react-dom@16.13.0
├─ react-scripts@3.4.0
└─ react@16.13.0
info All dependencies
├─ cra-template@1.0.2
├─ is-docker@2.0.0
├─ open@7.0.2
├─ react-dev-utils@10.2.0
├─ react-dom@16.13.0
├─ react-error-overlay@6.0.6
├─ react-scripts@3.4.0
├─ react@16.13.0
└─ scheduler@0.19.0
Done in 161.91s.
Git repo not initialized Error: Command failed: git --version
    at checkExecSyncError (child_process.js:621:11)
    at execSync (child_process.js:657:15)
    at tryGitInit (/usr/app/my-app/node_modules/react-scripts/scripts/init.js:46:5)
    at module.exports (/usr/app/my-app/node_modules/react-scripts/scripts/init.js:267:7)
    at [eval]:3:14
    at Script.runInThisContext (vm.js:116:20)
    at Object.runInThisContext (vm.js:306:38)
    at Object.<anonymous> ([eval]-wrapper:9:26)
    at Module._compile (internal/modules/cjs/loader.js:956:30)
    at evalScript (internal/process/execution.js:80:25) {
  status: 127,
  signal: null,
  output: [ null, null, null ],
  pid: 104,
  stdout: null,
  stderr: null
}

Installing template dependencies using yarnpkg...
yarn add v1.19.1
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@2.1.2: The platform "linux" is incompatible with this module.
info "fsevents@2.1.2" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents@1.2.11: The platform "linux" is incompatible with this module.
info "fsevents@1.2.11" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
warning "react-scripts > eslint-config-react-app@5.2.0" has incorrect peer dependency "eslint-plugin-flowtype@3.x".
warning "react-scripts > @typescript-eslint/eslint-plugin > tsutils@3.17.1" has unmet peer dependency "typescript@>=2.8.0 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev || >= 3.5.0-dev || >= 3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || >= 3.7.0-beta".
warning " > @testing-library/user-event@7.2.1" has unmet peer dependency "@testing-library/dom@>=5".
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 18 new dependencies.
info Direct dependencies
├─ @testing-library/jest-dom@4.2.4
├─ @testing-library/react@9.4.1
├─ @testing-library/user-event@7.2.1
├─ react-dom@16.13.0
└─ react@16.13.0
info All dependencies
├─ @sheerun/mutationobserver-shim@0.3.2
├─ @testing-library/dom@6.12.2
├─ @testing-library/jest-dom@4.2.4
├─ @testing-library/react@9.4.1
├─ @testing-library/user-event@7.2.1
├─ @types/prop-types@15.7.3
├─ @types/react-dom@16.9.5
├─ @types/react@16.9.23
├─ @types/testing-library__dom@6.12.1
├─ @types/testing-library__react@9.1.2
├─ css.escape@1.5.1
├─ csstype@2.6.9
├─ min-indent@1.0.0
├─ react-dom@16.13.0
├─ react@16.13.0
├─ redent@3.0.0
├─ strip-indent@3.0.0
└─ wait-for-expect@3.0.2
Done in 41.98s.
Removing template package using yarnpkg...

yarn remove v1.19.1
[1/2] Removing module cra-template...
[2/2] Regenerating lockfile and installing missing dependencies...
info fsevents@2.1.2: The platform "linux" is incompatible with this module.
info "fsevents@2.1.2" is an optional dependency and failed compatibility check. Excluding it from installation.
info fsevents@1.2.11: The platform "linux" is incompatible with this module.
info "fsevents@1.2.11" is an optional dependency and failed compatibility check. Excluding it from installation.
warning " > @testing-library/user-event@7.2.1" has unmet peer dependency "@testing-library/dom@>=5".
warning "react-scripts > eslint-config-react-app@5.2.0" has incorrect peer dependency "eslint-plugin-flowtype@3.x".
warning "react-scripts > @typescript-eslint/eslint-plugin > tsutils@3.17.1" has unmet peer dependency "typescript@>=2.8.0 || >= 3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev || >= 3.5.0-dev || >= 3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || >= 3.7.0-beta".
success Uninstalled packages.
Done in 48.44s.

Success! Created my-app at /usr/app/my-app
Inside that directory, you can run several commands:

  yarn start
    Starts the development server.

  yarn build
    Bundles the app into static files for production.

  yarn test
    Starts the test runner.

  yarn eject
    Removes this tool and copies build dependencies, configuration files
    and scripts into the app directory. If you do this, you can’t go back!

We suggest that you begin by typing:

  cd my-app
  yarn start

Happy hacking!
Done in 267.52s.

これでプロジェクトの雛形が作成されます。この時点でのディレクトリ構成は以下のようになります。

(root)
├ my-app
│  ├ node_modules
│  │  └ （各種パッケージ）
│  ├ public
│  │  ├ favicon.ico
│  │  ├ index.html
│  │  ├ logo192.png
│  │  ├ logo512.png
│  │  ├ manifest.json
│  │  └ rebots.txt
│  ├ src
│  │  ├ App.css
│  │  ├ App.js
│  │  ├ App.test.js
│  │  ├ index.css
│  │  ├ index.js
│  │  ├ logo.svg
│  │  ├ serviceWorker.js
│  │  └ setupTests.js
│  ├ .gitignore
│  ├ package.json
│  ├ README.md
│  ├ yarn.lock
├ docker
│  ├ nginx
│  │  └ swagger.conf
│  └ swagger-api
│      ├ Dockerfile
│      └ swagger.json
└ docker-compose.yml

作成したプロジェクトの雛形を移動

ここで自分の場合は、プロジェクトルート直下にmy-appの中身を置きたかったので移動させました。

docker-compose exec node mv ./my-app/* .
docker-compose exec node mv ./my-app/.gitignore .
docker-compose exec node rm -rf my-app

移動後のディレクトリ構成。

(root)
├ node_modules
│  └ （各種パッケージ）
├ public
│  ├ favicon.ico
│  ├ index.html
│  ├ logo192.png
│  ├ logo512.png
│  ├ manifest.json
│  └ rebots.txt
├ src
│  ├ App.css
│  ├ App.js
│  ├ App.test.js
│  ├ index.css
│  ├ index.js
│  ├ logo.svg
│  ├ serviceWorker.js
│  └ setupTests.js
├ .gitignore
├ package.json
├ README.md
├ yarn.lock
├ docker
│  ├ nginx
│  │  └  swagger.conf
│  └  swagger-api
│      ├ Dockerfile
│      └  swagger.json
└  docker-compose.yml

後から移動させるなら、元からカレントディレクトリに雛形を作成すればいいのでは？と思われそうですが...。カレントディレクトリだと docker ディレクトリや docker-compose.yml があるため、雛形作成の邪魔になるらしく、エラーになります。

コンテナ起動時のコマンドの有効化

docker-compose.yml の node の command のコメントアウトを解除します。

command: /bin/sh -c "yarn install && yarn start"

コンテナの再ビルド

有効化したコマンドを反映させるために再ビルドします。

docker-compose up -d --build

うまくいっていれば、コマンドが実行されてサーバが起動しているはずです。

ブラウザでアクセス

localhost:3000にアクセスして、以下のような画面になればOKです。ちなみにホットリロードを有効化にしているため、コードを変更して保存すると即座に反映されます。 <ImageWrapper className="w-[70%]" src="gifs/2019/docker-react-swagger/react-app.gif" alt="Reactアプリトップ画面" />

Swagger

Swagger Editor

localhost:8081にアクセス。左側がエディタ、右側が定義をもとにしたドキュメントとなっています。

デフォルトではサンプルの API 定義が表示されます。 <ImageWrapper src="screenshots/2019/docker-react-swagger/swagger-editor.png" alt="Swagger Editor画面" />

Swagger 定義ファイルを読み込む場合は、File → Import File からインポートできます。なお、エディタ上から定義をもとにしたコードを生成もできます。

{/*  */}

※注意点 エディタ上の変更は自動で保存されますが、インポートしたファイル自体を保存までは行ってくれません。 エディタで変更した定義ファイルをアプリケーションサーバに反映させたい場合は、File → Convert and save as JSON でファイルをダウンロード。 (root)/docker/swagger-api 配下に設置して、コンテナをビルドしなおす必要があります。

{/*  */}

Swagger UI

Swagger Codegen を使用してコードを生成すると、あわせてドキュメントも作成してくれています。 localhost:8000/docsにアクセスすることで確認できます。 <ImageWrapper src="screenshots/2019/docker-react-swagger/swagger-ui.png" alt="Swagger UI画面" />

ちなみに最初は Swagger UIのコンテナをまた別で立ち上げていました。ただ、参照する Swagger 定義ファイルを編集しているうちに、ファイルに間違いがない状態でもなぜかエラーが出てしまい、いまいち使えなくなってしまいました。（Swagger Editor 上で何もエラーが出ていない状態で出力したファイルでもエラーになりました）

Swagger のサーバ

localhost:8000でアクセスできます。今回は Swagger 定義ファイルで定義している API にリクエストしてみます。

ブラウザからアクセス

GET の API なので、直接ブラウザからアクセスしてもレスポンスが返ってきます。 localhost:8000/userにアクセスすると以下のようになります。 <ImageWrapper src="screenshots/2019/docker-react-swagger/swagger-api-browser.png" alt="Swaggerにブラウザでアクセスした画面" />

axios でアクセス

yarn で axios をインストール。

docker-compose exec node yarn add axios

src/App.js を以下のように修正。（あまりいい書き方ではないでしょうが、とりあえず動作確認用のコードです）

import React from 'react';
import logo from './logo.svg';
import './App.css';
import axios from 'axios'; // 追記

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
        {/* 以下を追記 */}
        <button
          onClick={
            () => axios.get('http://localhost:8000/user')
                       .then((result) => {
                         console.log(result)
                       })
                       .catch((error) => {
                         console.log(error)
                       })
          }
        >
          APIリクエスト
        </button>
        {/* ここまで追記 */}
      </header>
    </div>
  );
}

export default App;

localhost:3000にアクセスし、API リクエストのボタンを押すと axios のリクエストが実行されます。コンソールに出力しているので、Developer Tools で確認すると以下のようにデータが取得できているのが確認できるはず。 <ImageWrapper className="w-[80%]" src="screenshots/2019/docker-react-swagger/swagger-api-axios.png" alt="Swaggerにaxiosでアクセスしてコンソールに出力した画面" />

その他必要なもの

使用しているエディタに React に関する拡張を導入するとより開発しやすくなります。

VSCode 拡張

Full React/React Native/React Router/Redux/GraphQL/ES7/Testing/PropTypes snippets

<OG url="https://marketplace.visualstudio.com/items?itemName=walter-ribeiro.full-react-snippets" /> 名称にある通り、各種のスニペットが使用でき、慣れてくるとコーディングが捗るかと思います。（自分はあまり使いこなせてなかったりします...）

{/*  */}

ESLint + Prettier（2019/11/06追記）

~~静的解析ツールであるESLintも導入した方がいいでしょうが、VSCode 上で動かすのがうまくいかなかったので今回は書いていません。~~ ~~（いずれちゃんと設定できたら書くかも...）~~ ↓ 長くなったので別記事に書きました。 create-react-appで作成した雛形 + VSCodeにESLintとPrettierを導入する

{/*  */}

Chrome 拡張

React Developer Tools

Developer Tools に Components と Profiler タブが追加されます。コンポーネントの階層や、props や state の中身を確認できデバッグがしやすくなります。

Chromeウェブストアからインストール
Chrome の React Developer Tools アイコンを右クリックして、「拡張機能を管理」へ
「ファイルの URL へのアクセスを許可する」をONにする

設定のカスタマイズ（2019/11/06追記）

crate-react-app で作成した雛形に Babel、Webpack、ESLint などの設定が見当たりませんが、内部的に設定が行われており、一から手動で設定する必要がありません。

yarn.lock でreact-scriptの中に依存関係となっていることが確認できます。

※一部抜粋
react-scripts@3.4.0:
  version "3.4.0"
  resolved "https://registry.yarnpkg.com/react-scripts/-/react-scripts-3.4.0.tgz#f413680f0b5b937c8879ba1ffdae9b8c5b364bf5"
  integrity sha512-pBqaAroFoHnFAkuX+uSK9Th1uEh2GYdGY2IG1I9/7HmuEf+ls3lLCk1p2GFYRSrLMz6ieQR/SyN6TLIGK3hKRg==
  dependencies:
    "@babel/core" "7.8.4"
    "@svgr/webpack" "4.3.3"
    "@typescript-eslint/eslint-plugin" "^2.10.0"
    "@typescript-eslint/parser" "^2.10.0"
    babel-eslint "10.0.3"
    babel-jest "^24.9.0"
    babel-loader "8.0.6"
    babel-plugin-named-asset-import "^0.3.6"
    babel-preset-react-app "^9.1.1"
    camelcase "^5.3.1"
    case-sensitive-paths-webpack-plugin "2.3.0"
    css-loader "3.4.2"
    dotenv "8.2.0"
    dotenv-expand "5.1.0"
    eslint "^6.6.0"
    eslint-config-react-app "^5.2.0"
    eslint-loader "3.0.3"
    eslint-plugin-flowtype "4.6.0"
    eslint-plugin-import "2.20.0"
    eslint-plugin-jsx-a11y "6.2.3"
    eslint-plugin-react "7.18.0"
    eslint-plugin-react-hooks "^1.6.1"
    file-loader "4.3.0"
    fs-extra "^8.1.0"
    html-webpack-plugin "4.0.0-beta.11"
    identity-obj-proxy "3.0.0"
    jest "24.9.0"
    jest-environment-jsdom-fourteen "1.0.1"
    jest-resolve "24.9.0"
    jest-watch-typeahead "0.4.2"
    mini-css-extract-plugin "0.9.0"
    optimize-css-assets-webpack-plugin "5.0.3"
    pnp-webpack-plugin "1.6.0"
    postcss-flexbugs-fixes "4.1.0"
    postcss-loader "3.0.0"
    postcss-normalize "8.0.1"
    postcss-preset-env "6.7.0"
    postcss-safe-parser "4.0.1"
    react-app-polyfill "^1.0.6"
    react-dev-utils "^10.2.0"
    resolve "1.15.0"
    resolve-url-loader "3.1.1"
    sass-loader "8.0.2"
    semver "6.3.0"
    style-loader "0.23.1"
    terser-webpack-plugin "2.3.4"
    ts-pnp "1.1.5"
    url-loader "2.3.0"
    webpack "4.41.5"
    webpack-dev-server "3.10.2"
    webpack-manifest-plugin "2.2.0"
    workbox-webpack-plugin "4.3.1"
  optionalDependencies:
    fsevents "2.1.2"

これらの設定をカスタマイズしたい場合は、yarn ejectすることで内部的に設定されていた内容で config 配下に設定ファイルが作られ、カスタマイズが可能です。また、あわせてreact-scriptの依存関係のパッケージと設定が package.json に記述されます。 ※ESLint に関してはyarn ejectしなくてもカスタマイズが可能でした。

注意点として一度yarn ejectすると、元に戻すことはできません。

参考リンクまとめ

WSLでexpo startして20～30分後にネットワーク不具合が起こる現象について調べたこと

Wed, 09 Oct 2019 00:00:00 GMT

前回、WSLでReact Native + Expo環境を作ろうという記事を書き、その末尾にも書いていた件。 expo startしたときに起こる謎のネットワーク不具合について調べたこと、わかったことを書いておきます。

※この記事は Qiita からの転載です。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

ネットワーク不具合

起こる問題

WSL でexpo startした後、20～30分後くらいにネットワークが繋がらなくなってしまう。

どこのページにアクセスしようとしても以下のようにエラーが表示され、アクセスできません。ここに表示されている Windows ネットワーク診断ツールを実行してみても、異常がないといわれます。 <ImageWrapper className="w-[60%]" src="screenshots/2019/wsl-expo-network/network-error.png" alt="ネット上のページにアクセスできないエラー画面" />

CONNECTION を Tunnel にした時も、expo start --offlineとオプションをつけた時も、同様の現象が起きます。

一応、Windows 自体を再起動すれば、また繋がるようにはなるのですが...。短時間の間に何度も再起動するのはかなり手間ですし、ストレスにもなります。

対応策

この現象について調べていても、なかなか情報が見つけられませんでしたが、GitHub にほぼ同じ現象が報告されていた Issue を見つけました。

ここで緩和策として、以下の手順を踏めばいいとありました。

I found a palliative solution not to restart the machine: 1 - WIN+R -> services.msc 2 - Find LxssManager 3 - Right-click -> Restart This should restart the WSL service, normalizing the network.

Windows + R でファイル名を指定して実行の画面を出し、services.mscと入力してOK <ImageWrapper className="w-[80%]" src="screenshots/2019/wsl-expo-network/file-run.png" alt="ファイル名を指定して実行画面" />
一覧から LxssManager を見つける <ImageWrapper className="w-[80%]" src="screenshots/2019/wsl-expo-network/lxss-manager.png" alt="サービスの一覧画面" />
右クリックを押し、再起動

LxssManager is the service that manages the layer that communicates between Windows and Linux. Restarting it is basically equivalent to restarting Windows regarding everything that happens in WSL.

LxssManager は、Windows と Linux の間で通信するレイヤーを管理するサービスらしく。これを再起動することで、Windows を再起動したときと同じことが WSL 上で起こるそうです。

この手順を踏めば即座に WSL が再起動され、ネットワークが繋がるようになります。

課題

上記の手順でネットワークが復旧する...のですが、そこからまたexpo startしてしばらくすると、またネットワークが繋がらなくなります...。

This is likely an issue with WSL. There is an issue for this at microsoft/WSL#2913.

どうもこの現象は Expo CLI というより、WSL の問題らしく、Issue が上がっているそうです。

Can confirm that Windows Insider Build 18890 fixes this issue.

Windows 10 Insider Build 18890では、この問題が修正されたとのこと。調べてみると、このバージョンは2020年前半にリリース予定の大型アップデート「20H1」のプレビュービルドとなるそうです。もう少しの間我慢になりますが、正式にリリースがくれば解決できそうですね（Windows Insider Programに参加する度胸はありません...）

Obs: When I run the expo-cli start in CMD and then run on WSL, a network does not fail anymore....

ちなみにこんなことも書いてありましたが、CMD ってことは Windows 側に Expo を入れるってことなのかな？と思い、あまり入れたくないので試していません。直接 Windows に Expo（及びNode.js）を入れてもいいという方は、そうするのも1つの手ですね。

参考リンクまとめ

WSLでReact Native + Expo環境を作ろう

Sat, 28 Sep 2019 00:00:00 GMT

前回、Docker で React Native 環境を作成した記事を Qiita で書いて多くの方に見ていただけたようでした。ただ、結局ホットリロードがうまく働かない、エミュレータ環境との連携がうまくいかない。等、使い勝手がイマイチだったので WSL で環境を作り直しました。

※この記事は Qiita からの転載です。前回の記事：DockerでReact Native環境作成から、Expo Clientで実機確認するまで

基本的な作成手順は一緒なので内容が重複するところもありますが、エミュレータに関する記述も少しあわせて書いておきます。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

前提

Node.js をインストール済み（自分は anyenv + nodenv でいれてます）
npm or yarn コマンドが実行できる

事前準備

React Native の開発支援サービスである Expo を使用します。 Expo に関する説明は前回も書いたので省略します。

Expo アカウントを作成

expo.ioにいき、「Create an account」を選択。
e-mail、ユーザ名、パスワードを入力して「Create your account」を選択。

Expo Client をインストール

使用する iOS/Android 端末に App Store / Google Play からインストール <OG url="https://apps.apple.com/jp/app/expo-client/id982107779" /> <OG url="https://play.google.com/store/apps/details?id=host.exp.exponent&hl=ja" />
作成した Expo アカウントでログインしておく。

Expo CLI のインストール

npm もしくは yarn でインストールします。

# npm
npm install -g expo-cli

# yarn
yarn global add expo-cli

Expo プロジェクト

作成

app の部分は任意の Expo プロジェクトフォルダ名を指定します。

expo init app

テンプレートを選択します。

# expo init app
? Choose a template: (Use arrow keys)
  ----- Managed workflow -----
❯ blank                 a minimal app as clean as an empty canvas
  blank (TypeScript)    same as blank but with TypeScript configuration
  tabs                  several example screens and tabs using react-navigation
  ----- Bare workflow -----
  minimal               bare and minimal, just the essentials to get you started
  minimal (TypeScript)  same as minimal but with TypeScript configuration

Expo プロジェクトの表示名を聞かれます。

? Choose a template: expo-template-blank
? Please enter a few initial configuration values.
  Read more: https://docs.expo.io/versions/latest/workflow/configuration/ ‣ 0% completed
 {
   "expo": {
     "name": "<The name of your app visible on the home screen>",
     "slug": "app"
   }
 }

yarn を使ってパッケージをインストールするか聞かれます。 Y でインストール実行。（n を選択すると npm でパッケージをインストールします）

? Yarn v1.17.3 found. Use Yarn to install dependencies? (Y/n)

これで Expo プロジェクトのひな型が作成されました。ちなみに Expo プロジェクト作成後のディレクトリ構成は以下のようになります。

例
ReactNative（大元のプロジェクトフォルダ）
└ app（Expo プロジェクトフォルダ）
   ├ .expo
   ├ .expo-shared
   ├ assets
   ├ node_moodules
   ├ .gitignore
   ├ .watchmanconfig
   ├ App.js
   ├ app.json
   ├ babel.config.js
   ├ package.json
   └ yarn.lock

起動

環境変数

Expo サーバ起動時の IP を設定します。デフォルトでは Ubuntu の方の IP を使用し、CONNECTION を LAN で接続するため、Expo Client から接続できません。（一応、サーバ起動後に CONNECTION を Tunnel にすることで接続は可能です）

Ubuntu側で以下を~/.profileなど各種 profile のいずれかに追記

export REACT_NATIVE_PACKAGER_HOSTNAME=(Windows側のIP)

各種 profile の読み込み

# 例
source ~/.profile

Expo サーバ起動

以下のいずれかで Expo サーバとして起動。

expo start

npm start

yarn start

しばらくするとQRコードが表示されるとともに、Expo DevTools（localhost:19002）がブラウザで自動的に立ち上がります。 <ImageWrapper className="w-[80%]" src="screenshots/2019/wsl-react-native/expo-start.png" alt="expo start時のQR表示画面" />

動作確認

実機確認

Expo サーバ起動時に表示された QR を、iOS/Android 端末で読み込むことで、Expo Client 起動。ビルド開始。

なお、注意点として、Expo サーバになる PC と iOS/Android 端末は同じネットワークにつないでいる必要があります。 しばらくしてビルドが終わると初期ガイドが表示されます。 <ImageWrapper className="w-[40%]" src="screenshots/2019/wsl-react-native/app-guide.png" alt="Expoアプリのガイド画面" />

ガイドを消すと、Expo アプリの画面が表示されます。これが実行結果になります。 <ImageWrapper className="w-[40%]" src="screenshots/2019/wsl-react-native/app-preview.png" alt="Expoアプリの実行結果画面" />

なお、この状態でコードを変更すると、即座に再読み込みが走り画面に反映されます。ライブリロードが走っているそうです（ホットリロードとの違いがよくわかってません）

エミュレータでの確認

Windows なので、Android のエミュレータのみを書いておきます。

Android Studio のインストール

{/*  */}

公式からダウンロード。
ダウンロードしたインストーラを起動して、インストール（少し時間がかかります）
インストールした Android Studio を起動

初回はセットアップウィザードがあるので、案内に沿って進めていきます
必要に応じてインストールする SDK を選択（Android SDK Build-ToolsやAndroid Emulator、Android SDK Platform-Tools、Android SDK Toolsなどは最初からチェックが入っているかと思われます）

あとから SDK を追加したい場合は、トップ画面の右下の「Configure」→「SDK Manager」から SDK の一覧画面へ行けます。

{/*  */}

環境変数の設定

Android Studio のトップ画面の右下の「Configure」→「SDK Manager」から SDK の一覧画面へ
Android SDK Location を控えておく
環境変数を追記 Windows のシステム環境変数に追記します。

ANDROID_SDK ... (※2でコピーしたパス)
PATH ... %ANDROID_SDK%\emulator と %ANDROID_SDK%\pratform_tools を追加

emulatorコマンドとadbコマンドが使えるか確認

Virtual Deviceの用意

Android Studioトップ画面の「Configure」→「AVD Manager」を選択
「Create Virtual Device」を選択
デバイスを選択して、システムイメージを選択して作成

エミュレータの起動

Android Studioトップ画面の「Configure」→「AVD Manager」からデバイス一覧へ
Actions のプレイボタンを選択して起動

なお、コマンドでエミュレータを起動する場合は以下のコマンドでいけます。

# デバイス名の一覧確認
emulator -list-avds

# 指定デバイスのエミュレータの起動
emulator -avd (デバイス名)

Expo サーバを起動し、Expo DevTools（localhost:19002）の「Run on Android device/emulator」を選択初回のみエミュレータに Expo Client のインストールがあります。また、エミュレータでも同様に、コードを変更すると再読み込みが走ります。

WSL で無事環境が作れたのはよかったのですが、Expo サーバを起動後にしばらくしてネットが繋がらなくなる？（一応繋がってはいるが、ネット上のページにアクセスできない）状態になるのが謎です...。PCを再起動したら直ります。もしかしたら Expo 関係ない可能性がありますが、Expo のサーバ立ち上げたときしかその現象起きないんですよね。これさえなければいいのになぁ。 ↓ 2019/10/09追記これについて調べたことを記事に書きました。 WSLでexpo startして20～30分後にネットワーク不具合が起こる現象について調べたこと

参考リンクまとめ

WSLでWindowsの中にLinuxの開発環境を作ろう

Thu, 26 Sep 2019 00:00:00 GMT

個人 PC を新しくしてから、WSL（Windows Subsystem for Linux）をいれてなかったので改めていれてみました。基本的には参考記事通りに進めましたが、追加でインストールするものも含めて備忘録として手順を書いておきます。

※この記事は Qiita からの転載です。 ※2021/04/22追記またセットアップする機会があったので全体的に少し内容を更新しました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

WSL

WSLとは？

Windows Subsystem for Linux (WSL) とは、Linux の（ELF フォーマット形式の）バイナリ実行ファイルを Windows 10 および Windows Server 上でネイティブ実行するための互換レイヤーである。

ざっくりいえば、その名の通り、Windows のサブシステムとして Linux を動かす仕組みという解釈でいいかなと思っています。 WSL では完全な Linux を動かすことはできませんが、5月に発表された強化版の WSL2 では100%互換が実現されてるみたいですね。まだこちらはベータ版のみの提供のようなので、今回は素直に WSL を使うことにしました。

自分はなるべく Windows に直接言語をいれたりしたくない派なので、Docker 環境を作ったり、WSL 側に言語をいれたりしてます。

※2021/04/22追記ちなみに WSL2 が正式にリリースされてからも、自分は WSL を使っています。 WSL2 の良さはあるでしょうが、どうも WSL2 → Windows のファイルアクセスが遅いとのことだったので、このままでいいかとそのままにしています。

有効化

左下の Windows ボタンを右クリックし、「アプリと機能」を選択
下部の方にある関連設定の「プログラムと機能」を選択
左メニューの「Windows の機能の有効化または無効化」を選択
機能一覧の中から「Linux 用 Windows サブシステム」にチェックをつけて「OK」 <ImageWrapper className="w-[60%]" src="screenshots/2019/wsl-develop/enable-wsl.png" alt="Windowsの機能一覧" />
設定の変更が行われた後、Windows を再起動するよう促されるので、再起動する

Ubuntu のインストール

Microsoft Store を開く
「Ubuntu」で検索する 3つの種類（Ubuntu、Ubuntu 20.04 LTS、Ubuntu 18.04 LTS）がありますがお好みで。
Ubuntu をインストール
Ubuntu を起動して、初回起動時の設定として username と password を設定する（ここで決めたパスワードが sudo コマンド使用時に必要となります）

これで WSL が利用できるようになりました。ちなみにバージョンはcat /etc/os-releaseで確認できます。

cat /etc/os-release

NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

初期設定

パッケージリストの更新

sudo apt update

日本語化対応とタイムゾーン

※2021/04/22追記この辺はお好みで。英語のままで問題ない方はスキップ。

日本語言語パックのインストールとロケールの設定

sudo apt install -y language-pack-ja
sudo update-locale LANG=ja_JP.UTF-8

これで locale が変更されます。

locale

LANG=ja_JP.UTF-8
LANGUAGE=
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=

タイムゾーンの設定、日本語の manpage をインストールタイムゾーンに関してはアジア → 東京を選択してください。

sudo dpkg-reconfigure tzdata
sudo apt install -y manpages-ja manpages-ja-dev

これでタイムゾーンが JST になります。

date

2019年 9月 22日 日曜日 12:13:56 JST

※2021/04/22追記この設定をしなくても一応 JST になっていました。

date

Wed Apr 21 16:44:54 JST 2021

※ここ以降で載せている各種パスの{USER}部分は、人それぞれのユーザ名になりますのでご注意ください。

Windows・WSL それぞれから見た互いのパス

Windows から見た WSL

C:\Users\{USER}\AppData\Local\Packages\CanonicalGroupLimited.{ディストリビューション固有の文字列}

このパスからさらに\LocalState\rootfsでbin、dev、etc、mnt、optなどがあります。

以前は Windows 側から WSL 側のファイルを触るとファイル破損の可能性があったため推奨されていなかったようですが、現在は大丈夫になったみたいです。 <OG url="https://forest.watch.impress.co.jp/docs/news/1170221.html" />

WSL から見た Windows

/mnt/c

/mntから C ドライブが参照できます。

追加でインストールするもの

Linuxbrew

Mac ではおなじみのパッケージ管理ツールである Homebrew の Linux 版です。 Homebrew 2.0.0 からは Homebrew に統合され、正式に Linux をサポートするようになったそうです。

事前に必要なもののインストール中にはすでに入っているものもあるかと思われます。

sudo apt install build-essential procps curl file git

Linuxbrew のインストール

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

インストールが終わると次のステップに関する記述が表示されますので、その通りに進めていきます。 build-essential のインストールは先に済ませているのでスキップ。

==> Next steps:
- Add Homebrew to your PATH in /home/{USER}/.profile:
    echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /home/{USER}/.profile
    eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
- Run `brew help` to get started
- Further documentation:
    https://docs.brew.sh
- Install the Homebrew dependencies if you have sudo access:
    sudo apt-get install build-essential
    See https://docs.brew.sh/linux for more information
- We recommend that you install GCC:
    brew install gcc

パスを通す

echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /home/{USER}/.profile
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

gcc のインストール

brew install gcc

{/*  */}

依存関係のあるものも一緒にインストールされます。（gmp, isl, mpfr, libmpc, zlib, binutils）

{/*  */}

brew が正常に動作するか確認

brew doctor

以下のような表示が出れば OK です。

Your system is ready to brew.

anyenv

言語を複数バージョンで管理できる、〇〇env を一元管理できるものです。今回は Linuxbrew を使用してインストールしていきます。

本体のインストール

インストール

brew install anyenv

anyenv のセットアップ

anyenv init

こちらを実行すると以下のように、~/.bash_profileに追記するように表示が出ます。

# Load anyenv automatically by adding
# the following to ~/.bash_profile:

eval "$(anyenv init -)"

各種 profile のいずれかに追記（自分は~/.profileに追記しました）

echo -e 'eval "$(anyenv init -)"' >> ~/.profile

ちなみにこの段階で Ubuntu を再起動すると以下のような警告が出ますが、次の手順で解消できます。

ANYENV_DEFINITION_ROOT(/home/{USER}/.config/anyenv/anyenv-install) doesn\'t exist. You can initialize it by:
> anyenv install --init

マニフェストディレクトリの用意チェックアウトしますか？と聞かれるので、y で進みます。

anyenv install --init

これで anyenv で各種 env がインストールできるようになりました。なお、インストールできる各種 env は以下のコマンドで確認できます。

anyenv install -l

Renv
crenv
denv
erlenv
exenv
goenv
hsenv
jenv
jlenv
luaenv
nodenv
phpenv
plenv
pyenv
rbenv
sbtenv
scalaenv
swiftenv
tfenv

anyenv-update のインストール

anyenv で管理している各種 env とそれらのプラグインのアップデートをまとめて行えるものです。あわせて入れておきます。

mkdir -p $(anyenv root)/plugins
git clone https://github.com/znz/anyenv-update.git $(anyenv root)/plugins/anyenv-update

これで以下のコマンドでアップデートを実行できます。

anyenv update

nodenv のインストール

ここでは試しに anyenv を使って nodenv をインストールしてみます。

インストール

anyenv install nodenv

インストールが終わると各種 profile をリロードするか、Ubuntu を再起動するように言われます。

Install nodenv succeeded!
Please reload your profile (exec $SHELL -l) or open a new session.

各種 profile をリロード

exec $SHELL -l

これで nodenv が使えるようになりました。

nodenv

nodenv 1.4.0+3.631d0b6
Usage: nodenv <command> [<args>]

Some useful nodenv commands are:
   commands    List all available nodenv commands
   local       Set or show the local application-specific Node version
   global      Set or show the global Node version
   shell       Set or show the shell-specific Node version
   install     Install a Node version using node-build
   uninstall   Uninstall a specific Node version
   rehash      Rehash nodenv shims (run this after installing executables)
   version     Show the current Node version and its origin
   versions    List installed Node versions
   which       Display the full path to an executable
   whence      List all Node versions that contain the given executable

See `nodenv help <command>` for information on a specific command.
For full documentation, see: https://github.com/nodenv/nodenv#readme

インストールできる Node.js のバージョン一覧は以下で確認できます。

nodenv install --list

Node.js をインストール

nodenv install (バージョン)

使用する Node.js のバージョンを指定

# グローバルの場合
nodenv global (バージョン)

# ローカルの場合
nodenv local (バージョン)

インストールしているバージョンの一覧は以下で確認できます。なお、ここで*がついているのが使用しているバージョンです。

nodenv versions
* 14.2.0 (set by /home/{USER}/.anyenv/envs/nodenv/version)

参考リンクまとめ

DockerでReact Native環境作成から、Expo Clientで実機確認するまで

Sat, 14 Sep 2019 00:00:00 GMT

iOS、Android 両方に対応するアプリを作成できる React Native。最近、個人的に興味がわいたので、Docker環境作成にチャレンジしてみたのですが、あまり記事を見かけなかったので構築手順を書いておきます。

※この記事はQiitaからの転載です。

{/*  */}

※2019/9/21追記 後述しますが、自分がやった時にホットリロードが効かなかったり、エミュレータ環境との連動がうまくできなかったりしてます...。 自分のやり方が悪いだけかもしれませんが、あまり Docker で構築するメリットがないかもしれません。

{/*  */}

※2019/9/28追記 WSL で環境作り直しました。 → WSLでReact Native + Expo環境を作ろう

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

前提

docker 導入済み
docker-compose 導入済み

環境構築手順

事前準備

React Native で開発をしていく上で Expo を使うと便利です。環境構築も比較的楽に行え、アプリの内容を QR コードで発行して簡単に実機確認ができます。

Expo アカウントを作成

expo.ioにいき、「Create an account」を選択
e-mail、ユーザ名、パスワードを入力して「Create your account」を選択

Expo Client をインストール

使用する iOS/Android 端末に App Store / Google Play からインストール <OG url="https://apps.apple.com/jp/app/expo-client/id982107779" /> <OG url="https://play.google.com/store/apps/details?id=host.exp.exponent&hl=ja" />
作成した Expo アカウントでログインしておく

Docker環境作成

自分の場合は以下のディレクトリ構成で行っています。

React Native(プロジェクトフォルダ)
├ docker
│ ├ node
│ └ Dockerfile
├ .env
└ docker-compose.yml

Dockerfile

FROM "node:10-alpine"

WORKDIR /usr/src/app/

RUN apk update && apk add bash

RUN yarn global add expo-cli

後ほどexpo startする際にbashが必要になりますが、使用しているイメージの alpine linuxにはbashが入っていないため、インストールしています。はじめからbashが入っているイメージを使用するのもありです。

React Native のプロジェクトを作成する CLI ツールとして、以前はcreate-react-native-appがあったそうです。現在はexpo-cliに統合されたそうなのでこちらをインストール。

.env

REACT_NATIVE_PACKAGER_HOSTNAME=(自分のローカルPCのIPアドレス)

コンテナに渡す環境変数を定義します。

REACT_NATIVE_PACKAGER_HOSTNAMEは、後ほどexpo startで Expo アプリをホスティングする際のIPになります。デフォルトではコンテナの IP を使用してしまうために、Expo Client から接続ができません。そのためローカル PC 自体の IP を指定しておきます。

# Windows
ipconfig

# Mac
ifconfig

docker-compose.yml

version: "3"
services:
  node:
    build: ./docker/node
    volumes:
      - ./app/:/usr/src/app
    tty: true
    stdin_open: true
    environment:
      - REACT_NATIVE_PACKAGER_HOSTNAME=${REACT_NATIVE_PACKAGER_HOSTNAME}
    ports:
      - "19000:19000"
      - "19001:19001"
      - "19002:19002"

tty、stdin_open：docker-compose upしたコンテナを起動させたままにするため設定
environment：.envファイルで定義した環境変数を設定
port：Expo で使用する3つのポートを設定

起動

バックグラウンドで起動。

docker-compose up -d

RUN yarn global add expo-cliの個所で WARN がたくさん出ますが、ERROR がなければ動いてくれると思われます。（すみません、WARNの内容まではちゃんと見られていません）

Expo プロジェクト

作成

# コンテナの中に入る
docker-compose exec node bash

# expo プロジェクト作成
expo init .

テンプレートが選択できます。とりあえずは blank を選択して Enter。

bash-4.4# expo init .
? Choose a template: (Use arrow keys)
  ----- Managed workflow -----
❯ blank                 a minimal app as clean as an empty canvas
  blank (TypeScript)    same as blank but with TypeScript configuration
  tabs                  several example screens and tabs using react-navigation
  ----- Bare workflow -----
  minimal               bare and minimal, just the essentials to get you started
  minimal (TypeScript)  same as minimal but with TypeScript configuration

Expo プロジェクトの表示名を聞かれます。入力して Enter。

? Choose a template: expo-template-blank
? Please enter a few initial configuration values.
  Read more: https://docs.expo.io/versions/latest/workflow/configuration/ ‣ 0% completed
 {
   "expo": {
     "name": "<The name of your app visible on the home screen>",
     "slug": "app"
   }
 }

yarn を使ってパッケージをインストールするか聞かれます。Y でインストール実行。

? Yarn v1.17.3 found. Use Yarn to install dependencies? (Y/n)

これで Expo プロジェクトのひな型が作成されました。

起動

expo startもしくはyarn startで Expo サーバとして起動。しばらくするとQRコードが表示されます。 <ImageWrapper className="w-[80%]" src="screenshots/2019/docker-react-native/expo-start.png" alt="expo startの画面" />

Expo Client で実機確認

表示された QR コードを iOS/Android 端末から読み込むと、Expo Client 起動。ビルド開始。なお、注意点として、Expo サーバになる PC と iOS/Android 端末は同じネットワークにつないでいる必要があります。しばらくしてビルドが終わると初期ガイドが表示されます。 <ImageWrapper className="w-[40%]" src="screenshots/2019/docker-react-native/app-guide.png" alt="Expoアプリのガイド" />

ガイドを消すと、Expo アプリの画面が表示されます。これが実行結果です。 blank テンプレートを選択したのでシンプルな画面ですね。一連の手順で比較的楽に実機確認できました。 ただ、ホットリロードがうまく動作していないのか、コードの変更が即座に反映されませんでした。なぜ...。 <ImageWrapper className="w-[40%]" src="screenshots/2019/docker-react-native/app-preview.png" alt="Expoアプリの実行画面" />

補足

http://localhost:19002

アクセスすると、Expo DevTool が使用できます。ここからシミュレータを起動したりできるみたいです。（X Code、Android Studio のインストールや設定が別途必要になるようです）末尾にも書いていますが、自分はうまくいきませんでした...。 <ImageWrapper src="screenshots/2019/docker-react-native/expo-devtool.png" alt="Expo DevTool画面" />

http://localhost:19001

HTML が表示されます。 expo start時の表示で Metro Bundler だと書いてありましたが、なんなのかはよくわかってません。 <ImageWrapper src="screenshots/2019/docker-react-native/metro-bundler.png" alt="metro bundler画面" />

http://localhost:19000

Expo プロジェクトの情報？が表示されます。 <ImageWrapper src="screenshots/2019/docker-react-native/expo-server.png" alt="Expoサーバの情報" />

エミュレータについて(2019/9/18追記)

自分の環境は Windows なので、Docker 環境の中に Android のエミュレータ環境を作ろうとしましたがうまくいきませんでした...。

一応やってみたこととしてはこんな感じ。

openjdk をインストール
Android 公式からコマンドラインの zip ファイルをダウンロード
Andoid SDK を格納するディレクトリを作成し、zip ファイルを解凍して配置
Android SDK に関するパスを設定
sdkmanager、avdmanager コマンドが実行できることを確認
sdkmanager コマンドで必要な SDK をインストール

ここでエミュレータをインストールしたのですが、なぜか emulator コマンドが実行できませんでした。パスはちゃんと通しているはずなのに、ひたすらNo such file or directoryが出てしまい...。一体なんなのか。

WSL で環境構築した方が、早そうです。だから Docker で構築している記事がほとんどなかったんでしょうか...。

参考リンクまとめ

TILリポジトリが150コミット突破

Sat, 17 Aug 2019 00:00:00 GMT

こんにちは、6月に復職して少しずつ復帰していっているよしです。地道にコミットしていた、勉強用リポジトリのコミット数が150を超えていました。

※2021年末くらいからは Notion で TIL 活動をすることにしたので、リポジトリの活動停止してます。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

TIL リポジトリ

<OG url="https://github.com/h-yoshikawa44/til-engineer" /> ※2021/02/14追記...アカウント名、リポジトリ名を変えました。

<ImageWrapper src="screenshots/2019/til-150/github-til.png" alt="GitHub TILリポジトリ" /> ※contributors が2になっているのは、個人アカウントと仕事アカウントで利用しているからです。

3月に投稿したTILリポジトリで小さなアウトプットの記事。ここから開始して5か月ほどになりましたが、意外とあっという間でしたね。ちゃんと続けられているなーと。

コミット内容

内容に関しては、勉強のアウトプットということで、言語やフレームワークの公式チュートリアル、参考書、講習サイトなどのコードをあげています。それとメモ書きとか。

さすがに勉強したすべてを覚えているわけではないですが。元々あとから振り返られるような、自分の引き出しが増えるようなという意味合いではじめたので、まぁそうなっていればいいです。

コミット履歴

GitHub のアカウントのコミット履歴を見るのも少し楽しみになりました。 <ImageWrapper src="screenshots/2019/til-150/github-commit.png" alt="GitHub コミット履歴" />

5月頑張ってたみたいですね。休職期間だったので家にいたっていうのもありますが。

毎日1コミットしようかと考えていた時もありましたが、最近はペースが落ちてます。著名なエンジニアの方だとほぼ毎日コミットしていてすごいなと。どうにか時間を捻出しておられるんだろうなーと。毎日コミットは自分にはまだハードルが高いようです。

余談

そういえば仮に転職活動をしていたとして、こういう勉強用リポジトリってどういう見方されるんでしょうね。コミット数見て少しは評価されるのか、実際に何か作っているわけではないので何も評価されないのか。評価されないのならやらないなんてことはしないですけど、ちょっと気になりました。

個人開発をやろうかと考えていた時もありましたが、結局しょうもないものしかできなくてモチベーションが持ちませんでした。でも、いずれは自分で何か作ってみたいと思っています。というか作れるくらいにならないといけないなと。しょうもないものとか気にしていると、いつまでも作れないでしょうし、恥ずかしからず最初はハードルを下げて取り組めたらいいなと。

さていつになるやら。

次は300、500とかになったら、また雑談記事でも書こうかと構想中です。 1000コミットになる頃には、自分はどこにいて何をしているかなぁ。プログラマーの仕事は好きなのでちゃんと続けられているといいなと思いつつも、体調崩して休職することになってしまった仕事でもあるので、無理は禁物ですね。

まだまだ暑いので、皆様もお身体お気をつけて。ではではー。

RailsのDocker環境作成

Wed, 14 Aug 2019 00:00:00 GMT

Rails チュートリアルを勉強したかったので、Docker 公式を参考に Docker 環境を作成しました。その際に少しやり方を変えたのと、いくつかエラーに遭遇したので、そのメモを書いておきます。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

前提

Docker 導入済み
docker-compose コマンドが使用できる

なお、この記事の手順では Rails 5系の環境となる点に注意です。

Docker 環境

作成手順

※2021/02/07追記少し公式の手順が変わっていたので見直しを行いました。

公式では、すべてのファイルをルートに置いていますが、自分は以下のようなディレクトリ構造にしたかったので変えました。

自分の場合のディレクトリ構造はこちら。

(root)
├ docker
│ └ ruby
│     └ Dockerfile
├ ※Railsのソース
├ docker-compose.yml
├ entrypoint.sh
├ Gemfile
├ Gemfile.lock
└ README.md

Dockerfile を作成

FROM ruby:2.5
RUN apt-get update -qq && apt-get install -y nodejs postgresql-client
RUN mkdir /src
WORKDIR /src
COPY Gemfile /src/Gemfile
COPY Gemfile.lock /src/Gemfile.lock
RUN bundle install
COPY . /src

# Add a script to be executed every time the container starts.
COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000

# Start the main process.
CMD ["rails", "server", "-b", "0.0.0.0"]

Gemfile を作成

source 'https://rubygems.org'
gem 'rails', '~>5'

Gemfile.lock を作成(中身は空で OK)
entrypoint.sh を作成

#!/bin/bash
set -e

# Remove a potentially pre-existing server.pid for Rails.
rm -f /src/tmp/pids/server.pid

# Then exec the container's main process (what's set as CMD in the Dockerfile).
exec "$@"

docker-compose.yml を作成

version: '3.9'
services:
  db:
    image: postgres
    volumes:
      - ./tmp/db:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: password
  web:
    build:
      context: ./
      dockerfile: ./docker/ruby/Dockerfile
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    volumes:
      - .:/src
    ports:
      - "3000:3000"
    depends_on:
      - db

※Windows の場合は、下記の注意点も参照。

ビルドして、Rails プロジェクトを作成

docker-compose run --no-deps web rails new . --force --database=postgresql

もう一度、コンテナをビルド(rails new で Gemfile の内容が変わったため)

docker-compose build

データベースの接続設定を記述(src/config/database.yml) データベース名は任意の名前で OK。

default: &default
  adapter: postgresql
  encoding: unicode
  host: db
  username: postgres
  password: password
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>

development:
  <<: *default
  database: myapp_development


test:
  <<: *default
  database: myapp_test

Docker の起動

コンテナの起動

docker-compose up -d

初期 DB の作成

docker-compose exec web rails db:create

以下のように表示されれば無事データベースが作成されています。

Created database 'myapp_develop'
Created database 'myapp_test'

ブラウザでアクセス

localhost:3000

以下のような画面が表示されればOKです。 <ImageWrapper className="w-[70%]" src="screenshots/2019/docker-rails/rails.png" alt="Railsトップ画面" />

遭遇したエラー

ビルドコンテキスト外のファイルを COPY しようとしてエラー

docker-compose.yml の以下の部分。

web:
  build:
    context: ./
    dockerfile: ./docker/ruby/Dockerfile

最初はこうしていました。

web:
  build: ./docker/ruby

すると、Dockerfile の中で、Gemfile を COPY するところでエラーになりました。

原因としては、ビルドコンテキスト外のファイルで COPY や ADD ができないとのことでした。つまりビルドコンテキストに./docker/rubyを指定しているので、この配下にあるファイルしか指定できないようです。なので、buildの個所をcontextとdockerfileにわけて記述することで対応しました。

なお、補足として、Dockerfile の COPY などで指定するホスト側のパスは、ビルドコンテキストを基準としたパスになります。

COPY Gemfile /src/Gemfile ← ビルドコンテキスト（./）からのパス

コンテナ起動時に exited with code 1 になる

docker-compose up で起動するとコンテナがうまく起動しませんでした。原因としては、コンテナ起動時に実行しているentrypoint.shの改行コードがCRLF（Windows標準）になっていたことでした。ここは改行コードをLF（Linux標準）に変更して対応しました。

Windows のみで発生するエラー

postgres コンテナの起動に失敗する

コンテナ起動に失敗し、ログを見るとFATAL: data directory "/var/lib/postgresql/data" has wrong ownershipと表示されていました。どうも volume マウントに失敗していたようです。

docker-compose.yml でマウントのパスを/var/lib/postgresql/dataから/var/lib/postgresql/に修正すると、なぜか起動するようになりました。

db:
  image: postgres
  volumes:
    - ./tmp/db:/var/lib/postgresql/ ← パス末尾の data をなくす

Rails アプリが File exists @ dir_s_mkdir - /src/tmp/cache/assets/sprockets/v3.0/2D でエラー落ちする

一度はちゃんと動作していた Rails アプリがこのエラーになり、動作しなくなったことがありました。どうも Windows の場合は、ファイルの大文字小文字を区別しないことにより、ファイル名称がバッティングしてしまい起こるそうです。

参考記事の通りに対応することで解決しました。

src/config/initializers/assets.rb に以下を追加。

Rails.application.config.assets.configure do |env|
  env.cache = Sprockets::Cache::FileStore.new(
    ENV.fetch("SPROCKETS_CACHE", "#{env.root}/tmp/cache/assets"),
    Rails.application.config.assets.cache_limit,
    env.logger
  )
end

docker-compose.yml を以下のように修正。

version: '3.9'
services:
  db:
    image: postgres
    volumes:
      - ./tmp/db:/var/lib/postgresql
    environment:
      POSTGRES_PASSWORD: password
  web:
    build:
      context: ./
      dockerfile: ./docker/ruby/Dockerfile
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    environment:
      - SPROCKETS_CACHE=/cach
    volumes:
      - .:/src
      - cache:/cache
    ports:
      - "3000:3000"
    depends_on:
      - db

volumes:
  cache:

Docker 公式で案内があったのはありがたかったのですが、ディレクトリ構造を変更したこともあり、いくつかエラーに遭遇しました。とりあえず無事起動できてよかったです。

Rails チュートリアルは一応一通り終わったので、一旦 AWS の勉強に戻ります。資格取らねば...。

参考リンクまとめ

QiitaいいねランキングをSlackに投稿

Sun, 23 Jun 2019 00:00:00 GMT

Qiitaのアカウントがあると、定期的にいいねランキングがメールで来ますよね。あれをSlackに投稿出来たらいいなと思って、チャレンジしてみました。

※追記現在、当記事で使用していた API は使用できなくなったため、当記事のやり方はできなくなりました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

どうやって投稿する？

最初にいいねランキングを取得するところですが、Qiita の API を使えばできるのかなと思い見てみたところ、単純に Qiita の API だけでは難しそうでした。いろいろ工夫すればできるのかなとか考えていたなか、自作で API を作られている方の記事を見つけました。

Qiita API をスクレイピングしてランキングデータを構築しているそうです。仕組みに関しても記事に記述がありますが、今の自分にはちょっと難しく感じました...。すごい。

こちらの方の API を利用させていただくとして、投稿までの手順は以下の流れにしました。

API で Qiita いいねランキングデータを取得する
取得したデータを使って、Slack に投稿する文言を組み立てる
Webhookを利用して、Slackに投稿する

なお、今回は GAS を使用します。

準備

Webhook

まずは、Slack に投稿するための Webhook の設定をしていきます。下記のApp管理から設定画面へ。 <ImageWrapper src="screenshots/2019/qiita-ranking/slack.png" alt="SlackでApp管理に行くまで" />

Webhookが追加されていない場合 ヘッダの検索からwebhookで検索して、Incoming Webhookを選択。

すでにWebhookが追加されている場合 ヘッダの管理からカスタムインテグレーションを選択して、Incoming Webhookを選択。

設定の追加を選択して、投稿するチャンネルを決めて、Incoming Webhookインテグレーションの追加を選択。ここでは、投稿時のアイコンや名称などが設定できます。WebhookURL は GAS 側で使用するので控えておきましょう。

GAS

Google ドライブ上でGASプロジェクトを作成して、手順通りにスクリプトを書いていきます。

※2020/2/16 追記 v8 ランタイムが使えるようになったので、それに伴いリファクタリングを行いました。

{/*  */}

ランタイム変更は、GAS エディタを開いて表示される案内（Enable new Apps Script runtime powered by Chrome V8 for this project.）から変更する。もしくは、実行 → Chrome V8 を搭載した新しい Apps Script ランタイムを有効にするからできます。

主な変更点

var で定義していた変数を、その後値を変更するかどうかで let か const に変更
ログの出力方法の変更（stack にファイル名や行数などが含まれるので、stack のみにしました）
HTTP リクエスト時に使用するリクエスト URL は、スクリプトプロパティで設定して使用するよう変更
- （ファイル→プロジェクトのプロパティ→スクリプトのプロパティから設定できますが、オーナー権限のアカウントでないと編集できません）
ダブルクォートをシングルクォートに変更
getYear() は非推奨のため、getFullYear() に変更

{/*  */}

function noticeQiitaRanking() {
  let msg;
  try {
    let response = getQiitaRanking();
    if (response == '') {
      msg = '※最新のQiitaいいねランキングが登録されていません。\n違う取得日を指定してください。';
    } else {
      // Slack 投稿内容の組み立て
      msg = '*■週間いいねランキング■* \n\n';
      // JSON をオブジェクトに変換
      response = JSON.parse(response);
      const dataList = response['data'];
      let count = 1;
      dataList.forEach(data => {
        // <url|文字列> の形式で文字列でのリンクを作成
        msg += count + '位：<' + data['url'] + '|' + data['title'] + '> \n';
        count++;
      })
    }
  } catch (e) {
    Logger.log('Qiitaいいねランキング取得エラー：' + '\nstack：\n' + e.stack);
  }

  try {
    // Slack 側 Incoming WebHook のURL
    const WEBHOOK_URL = PropertiesService.getScriptProperties().getProperty('WEBHOOK_URL');
    // Incoming WebHook に渡すパラメータ
    const jsonData =
        {
          'text': msg
        };
    //パラメータを JSON に変換
    const payload = JSON.stringify(jsonData);
    // 送信オプション
    const options =
        {
          'method': 'post',
          'contentType': 'application/json',
          'payload': payload
        };
    //指定 URL、オプションでリクエスト
    UrlFetchApp.fetch(WEBHOOK_URL, options);
  } catch (e) {
    Logger.log('Slack送信エラー：' + e.message + '\nstack：\n' + e.stack);
  }
}

function getQiitaRanking() {
  const type = 'weekly';
  const date = new Date();
  // リクエスト時に今日を指定するとなぜかデータが取得できないので、前日を指定する
  const yesterday = new Date(date.getFullYear(), date.getMonth(), date.getDate() - 1);
  const formatYesterday = Utilities.formatDate(yesterday, 'JST', 'yyyy-MM-dd');
  const QIITA_SCRAIPING_URL = PropertiesService.getScriptProperties().getProperty('QIITA_SCRAIPING_URL') + type + '/' + formatYesterday;
  return UrlFetchApp.fetch(QIITA_SCRAIPING_URL);
}

Qiita いいねランキングAPIを使用する際に、実行日当日の日付を指定すると、なぜかデータが取得できませんでした。そのため、前日を指定するようにしています。

投稿

上記 GAS スクリプトを実行することで、以下のような投稿になります。ちゃんと、タイトルが記事リンクとして作成されています。 <ImageWrapper className="w-[70%]" src="screenshots/2019/qiita-ranking/ranking.png" alt="Slackにランキング投稿結果" />

GAS は定期実行するようにトリガーの設定ができるので、週に1回投稿するなどもできますよー。

実は最初は GAS ではなく、Serverless Framework + Python + Lambda で作成しました。 (Docker で実行環境も作りました) ただ、こちらの場合、事前に準備が多いので GAS の方が手軽に作成できていいですね。需要があれば、会社でも使ってもらおうかと構想中ですー。

参考リンクまとめ

Qiitaいいね数ランキングAPIの作成

LaradockでLaravel環境構築

Mon, 03 Jun 2019 00:00:00 GMT

Laravel を勉強するために Laradock を使用してみました。いろんなサービスの Dockerfile が用意されていますが、まずは最低限の構成でチャレンジ。 Laradock 便利ー。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

注意書き（※2021/02/24 追記）

Laravel の Docker 環境を作成するにあたって、現在の自分のスタンスとしては、Laradock よりもこちらの環境を使用するのをお勧めしています。 Laradock と比べて圧倒的に早く構築できます。 <OG url="https://github.com/ucan-lab/docker-laravel" />

また、ご本人による解説記事もあり、非常に勉強になります。特に Docker の知識に自信がない方はぜひ読んでみてください。 <OG url="https://qiita.com/ucan-lab/items/5fc1281cd8076c8ac9f4" />

このスタンスのため、この記事は今後更新停止します。ご了承ください。

前提

Docker 導入済み
docker-compose コマンドが使用できる

<OG url="https://liginc.co.jp/364089" /> こちらの記事をベースに進めました。

Laradock

導入

任意のプロジェクトフォルダを作成（ここが git の管理対象になるイメージ）
プロジェクトフォルダに移動して、Git の設定

git init

プロジェクトフォルダの中に Laravel プロジェクト用のフォルダを作成
プロジェクトフォルダの中で Laradock をサブモジュールとして登録

git submodule add https://github.com/Laradock/laradock.git (※Laradock 用のフォルダ名)

この時点のフォルダ構成はこちら。

(git プロジェクトフォルダ)
├ (Laravel プロジェクトフォルダ)
└ (Laradock フォルダ)

env ファイル準備

チームメンバーと環境変数の共有のしやすさとして、シェルを作成します。 (※2019/8/14追記環境変数ファイルを Git にあげることでもあるので、パブリックリポジトリではやらないほうがよさそうです)

シェル作成のあたりは、以下の記事を参考にしました。 <OG url="https://qiita.com/dev_satsuki/items/e2769925da33bfa77df5" />

シェル用のフォルダとファイルを作成（以下の.sh/）

(git プロジェクトフォルダ)
├ (Laravel プロジェクトフォルダ)
├ (Laradock フォルダ)
└ .sh/
   ├ conf/
   └ setup.sh

conf/のなかに.laradock-envを作成（laradock の中のenv-exampleをコピー） (以降、Laradock を更新した際はenv-exampleの内容が更新されている場合があるので、その際は再度合わせるようにしましょう)
.laradock-envを編集

APP_CODE_PATH_HOST...Laradock の web サーバー上で同期するディレクトリパス
DATA_PATH_HOST...docker のストレージなどを保存するローカルのディレクトリパス
COMPOSE_PROJECT_NAME...コンテナの接頭辞（デフォルトの laradock だと、名前被りで上書きしやすいのでプロジェクトごとの命名に変更しておく）

# 例
APP_CODE_PATH_HOST=../(Laravel プロジェクトフォルダ)/
DATA_PATH_HOST=../.(Laradock フォルダ)/data

COMPOSE_PROJECT_NAME=laraveltutorial

setup.sh を編集

SCRIPT_DIR=$(cd $(dirname $0); pwd)

cd $SCRIPT_DIR

cp -f conf/.laradock-env ../(Laradockフォルダ)/.env

MySQL 8 対応

.sh/conf以下に mysql.cnf を作成（Laradock の mysql/my.cnf をコピー）
.sh/conf/mysql.cnfにmysql 8 の対応として以下を追記する

innodb_use_native_aio=0
default_authentication_plugin=mysql_native_password

DockerでPHP環境作成（+ MySQL + PHPMyAdmin）でも書いたとおり、MySQL は8から認証方式が変更になっているため、それを従来の認証方式に設定しなおすものです。 ※追記 innodb_use_native_aio=0 については、他のバージョンでも必要の可能性あり。

.sh/setup.shに以下を追加

cp -f conf/mysql.cnf ../ (Laradockフォルダ)/mysql/my.cnf

setup.sh を実行して .env を作成 + mysql/my.cnf の更新

sh .sh/setup.sh

docker の起動

イメージの作成と起動( laradock フォルダに移動して)

docker-compose up --build -d nginx mysql

※起動するコンテナは使用したいものに応じて変化。 初回は作成に少し時間がかかるので気長に待ちましょう。

起動イメージの確認

docker-compose ps

State がすべて Up になっていればOK。（workspace と php-fpm も一緒に起動しているはず）

動作確認 http://localhostにアクセス。この段階では、nginx の404画面になればOK。

Laravel プロジェクト

作成

workspace コンテナに入る

docker-compose exec workspace bash

Laravel のインストール

composer create-project --prefer-dist laravel/laravel ./

動作確認 http://localhostにアクセス以下の Laravel のトップページが表示されれば OK <ImageWrapper className="w-[50%]" src="screenshots/2019/laravel-laradock/laravel.png" alt="Laravelトップ画面" />

MySQL の接続設定

Laravel プロジェクトの.envを修正接頭辞が DB_ の部分を編集し、laradock フォルダ/.env に記述されている値と合わせる形になります。

# 例
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=default
DB_USERNAME=default
DB_PASSWORD=secret

マイグレーションを実行して接続テスト workspace コンテナの中で以下コマンドを実行。

php artisan migrate

デフォルトで存在するマイグレーションファイルが実行されます。ちゃんとテーブルが作成されていればOK。

Laravel の env ファイル準備

こちらもシェルで env ファイルの内容を共有できるようにしておきます。

.sh/confに.laravel-envを作成 (Laravel プロジェクトの.envをコピー)
setup.sh に以下を追記する

cp -f conf/.**laravel**-env ../(Laravel プロジェクトフォルダ)/.env

他のメンバーが環境を作るときは

プロジェクトをクローン

git clone (プロジェクトパス)

サブモジュールの内容をクローン

git submodule update -i

※Laradock のディレクトリに移動し、git submoduleで状態が確認できる -c7289f7db3b96be585a879ceaf0f208102f8233f ./ のように頭に-がついている場合は、まだ中身を持ってこれてない状態。

シェル実行で env ファイル作成 + mysql 設定ファイルコピー

sh .sh/setup.sh

docker のイメージ作成と起動

docker-compose up --build -d nginx mysql

※作成するコンテナは必要に応じて。

起動イメージの確認

docker-compose ps

State がすべて Up になっていれば OK。

workspace コンテナに入る(2019/12/7追記)

docker-compose exec workspace bash

パッケージのインストール(2019/12/7追記)

composer install

テーブルの作成(2019/12/7追記)

php artisan migrate

動作確認 http://localhostにアクセス。ちゃんとコードに応じた画面が表示されれば OK。

最初は MySQL 8対応で少し手間取りましたが、比較的楽に環境を作ることができました。 Laradock には豊富に Dockerfile が用意されているので、必要に応じてコンテナがすぐ作成できるのはいいですね。機会があれば他のコンテナも試してみます。

参考リンクまとめ

DockerでPHP環境作成（+ MySQL + PHPMyAdmin）

Wed, 15 May 2019 00:00:00 GMT

今更ながら、Docker の勉強もしています。というか、勉強しないといいかげんヤバい...。先日、少々詰まりながらも、なんとか PHP の環境を作ってみました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

自分の Docker 経験

Docker の知識があるのは当たり前くらいのご時世のなか、まだまだ勉強途中です。

先日、こちらの講座を受講して大まかな仕組みやコマンドは学びましたが、まだ自分で進んで環境作れるような状態ではありません。参考書も買って勉強した方がいいのかな...。

とはいえ、勉強もかねて今回環境を作ってみました。

余談ですが、先日から WSL の Ubuntu の調子が悪く、Gitが使えない状態になってしまっています...。調べながらもエラーが解消しなかったため、もう Docker で環境作ろ...となったのでした。

前提

Docker 導入済み
docker-compose コマンドが使用できる

PHP の Docker 環境

<OG url="https://qiita.com/sitmk/items/f911be7ffa4f29293fd5" /> 今回は、こちらの方の記事をベースに進めました。

作成後のフォルダ構成は以下のようになります。

(root)
├ mysql
│  ├ mysql_conf
│  │  └ custom.conf
│  ├ mysql_init
│  │  └ init.sql
│  └ Dockerfile
├ nginx
│  └ nginx.conf
├ php
│  ├ Dockerfile
│  └ php.ini
├ www
│  └ html
│      └ index.php
└ docker-compose.yml

以下、ファイルの簡単な解説です。

custom.conf

[mysqld]
default_authentication_plugin=mysql_native_password
character-set-server=utf8mb4

[client]
default-character-set=utf8mb4

MySQL の設定ファイルです。デフォルトの認証方式と文字コードの設定を定義しています。

認証方式については、MySQL 8.0.4以降からcaching_sha2_passwordがデフォルトとして変更になっています。そのため、従来の方式ではアクセスできなくなってしまう（PHP の MySQL 接続ライブラリが対応していない模様）ので、従来の認証方式であるmysql_native_passwordに変更します。

文字コードは文字化け対策です。

init.sql

CREATE DATABASE test;

USE test;

CREATE TABLE user (
    id int AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255),
    email VARCHAR(255)
);

INSERT INTO user (name, email) VALUES
    ('taro', 'taro@example.com'),
    ('jiro', 'jiro@example.com');

データベースの初期化の SQL です。あとで、PDO の接続テストもしたかったので、簡単な SQL を書いています。

Dockerfile(MySQL)

FROM mysql:8.0

ADD ./mysql_conf/custom.cnf /etc/mysql/conf.d/.

CMD ["mysqld"]

CMD ["client"]

明示的に MySQL の設定ファイルを、Docker 環境内に ADD しています。

こちらについては、ボリュームマウントでも対応可能らしいのですが...。自分の場合ボリュームマウントするよりも先（認証方式を修正するより前）に MySQL の初期ユーザが作られてしまいました。それによりアクセスできなくなる状態になってしまったので、ADD するようにしました。

nginx.conf

server {
    listen 80;
    server_name _;

    root  /var/www/html;
    index index.php index.html;

    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log;

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        fastcgi_pass php:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include       fastcgi_params;
    }
}

Nginx の設定ファイルです。

Dockerfile(PHP)

FROM php:7.2-fpm

COPY php.ini /usr/local/etc/php/

RUN apt-get update && \
  # PHPのExtensionをインストール
  docker-php-ext-install pdo_mysql mysqli

PDO の接続テストをしたかったので、追加でインストールしています。

php.ini

date.timezone = "Asia/Tokyo"

PHP の設定ファイルです。

index.php

<?php
phpinfo();

最初の動作確認で、PHP のインフォメーションを表示するようにしておきます。

docker-compose.yml

version: '3'
services:
  nginx:
    image: nginx:latest
    ports:
      - 8080:80
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf
      - ./www/html:/var/www/html
    depends_on:
      - php

  php:
    build: ./php
    volumes:
      - ./www/html:/var/www/html
    depends_on:
      - db

  db:
    build: ./mysql
    ports:
      - 13306:3306
    volumes:
      # DB data persistence
      - ./mysql/data:/var/lib/mysql
      # DB initialize data
      - ./mysql/mysql_init:/docker-entrypoint-initdb.d
    environment:
      MYSQL_ROOT_PASSWORD: secret
    command: --innodb-use-native-aio=0

  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    ports:
      - 8888:80
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOST=db
      - PMA_USER=root
      - PMA_PASSWORD=secret
    depends_on:
      - db

# DB data persistence
- ./mysql/data:/var/lib/mysql

ここでデータの永続化。

# DB initialize data
- ./mysql/mysql_init:/docker-entrypoint-initdb.d

初期化 SQL のマウントです。データベースの初期化時、/docker-entrypoint-initdb.d以下にある SQL を実行してくれるようになっているそうです。

command: --innodb-use-native-aio=0

エラー対応でいれてます。

environment:
  - PMA_ARBITRARY=1
  - PMA_HOST=db
  - PMA_USER=root
  - PMA_PASSWORD=secret

phpmyadmin のこちらは、環境変数で MySQL へのアクセス情報を記載しています。

ちなみに yml 内のコメントが英語なのは、日本語で書くとなぜかエラーになってしまったからです（なんでや...）

動作確認

docker-compose up -dでコンテナを立ち上げます。

PHP + Nginx

localhost:8080で PHP のインフォメーション画面が表示されればOKです。 <ImageWrapper src="screenshots/2019/docker-php/php-info.png" alt="PHPインフォメーション画面" />

PHPMyAdmin

localhost:8888で次のような画面が表示されればOKです。 docker-compose.yml で記載した環境変数が正しければ、ログインしている状態になるはず。 <ImageWrapper src="screenshots/2019/docker-php/php-my-admin.png" alt="PHPMyAdmin画面" />

PDO

PDO を使用して、データベースにアクセスできるかも確認していきます。

index.php を修正します。

<?php
try {
    $dsn = "mysql:host=db;dbname=test;";
    $db = new PDO($dsn, 'root', 'secret');
    $sql = "SELECT * FROM user";
    $stmt = $db->prepare($sql);
    $stmt->execute();
    $result = $stmt->fetchAll(PDO::FETCH_ASSOC);
    var_dump($result);
} catch (PDOException $e) {
    echo $e->getMessage();
    exit;
}

localhost:8080にアクセスして、以下のようにデータベースから情報が取得できていればOKです。無事 DB にアクセスできています。 <ImageWrapper src="screenshots/2019/docker-php/pdo-test.png" alt="DBからのデータ表示画面" />

たくさんの記事を参考にさせていただきましたが、なんとか PHP 環境を作ることができました。実は Laradock を使って、Laravel 環境を作ったりもしているのですが、それはまた別の記事で書く予定ですー。

参考リンクまとめ

GitLab CI でのみエラーになる問題

Sun, 05 May 2019 00:00:00 GMT

当ブログは Netlify で配信していますが、GitLab CI も一応設定してあります。 Netlify の CI では問題ないのに、GitLab の CI でのみエラーになることがあったので、その対応を載せておきます。

エラー内容

push 時やマジリクの時に動く GitLab の CI の時のみ、なぜかエラーになる。

image: ruby:2.3.6

cache:
  paths:
  - vendor/

before_script:
  - bundle install --path vendor/bundle

test:
  stage: test
  script:
    - bundle exec jekyll build -d test
  artifacts:
    paths:
    - test
  except:
    - master

CI のエラー箇所抜粋。

bundle exec jekyll build -d test

Configuration file: /builds/{GitLabユーザID}/{リポジトリ名}/_config.yml
            Source: ./docs
       Destination: test
 Incremental build: disabled. Enable with --incremental
      Generating...
  Conversion error: Jekyll::Converters::Scss encountered an error while converting 'assets/css/main.scss':
                    Invalid US-ASCII character "\xEF" on line 1
jekyll 3.8.1 | Error:  Invalid US-ASCII character "\xEF" on line 1
ERROR: Job failed: exit code 1

最初の頃は問題なかったのに、途中から上記のようなエラーがしばらく出続けていて、なんだろうなと思いつつ、ブログ記事作成に大きな影響はなかったので後回しにしていました。

解決策

先輩が見てくださいまして、無事エラーが解消されました。どうもロケールの問題だったようです。

.gitlab-ci.yml に以下を追加します。

variables:
  LC_ALL: C.UTF-8

CIに関して、まだ知識が疎いので日々勉強ですね...。

TILリポジトリで小さなアウトプット

Tue, 26 Mar 2019 00:00:00 GMT

こんにちは、2019年入って体調が絶不調のよしです。 AWS の資格の勉強をしなければ...と思いつつも、あまりはかどっていないなか、とある Qiita の記事を見かけました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from '@/components/OG.astro'

TIL

概要

「Today I Learned」の略で、Github 上に TIL というリポジトリを作成してそこに今日覚えたことを書いていくというものです。

こちらの記事の中でも触れられていますが、敷居の低さは自分も感じました。プログラミングの勉強はアウトプットしてこそという考えがありますが、自分結局大したアウトプットできてないなーと。なにか作るとかいうと、より敷居が高く感じてしまって。

あえて人に言えるのは、GAS で掃除当番通知 Bot を作って許可をもらって社内で動かしてるということくらいでしょうか。自分で新しくサービスを立ち上げたりという経験は現時点ではありません。

でも、これなら小さなアウトプットの積み重ねができるかなと思い自分もやり始めてみました。

※2021年末くらいからは Notion で TIL 活動をすることにしたので、リポジトリの活動停止してます。

何をアウトプットする？

<OG url="https://github.com/h-yoshikawa44/til-engineer" /> ※2021/02/14追記...アカウント名、リポジトリ名を変えました。

現状、また始めたばかりで、とりあえず基本的な構文を書いているような状態です。

<?php
// 標準出力処理

// echo
// 一つ以上の文字列を出力する
// 関数でなく言語構造であるため、引数を括弧でくくる必要がない
$test = 'ABC' . "\n";
echo $test; // ABC
echo 'A', 'B', 'C', 'D' . "\n"; // ABCD

// print
// 単一の引数のみ受け付ける出力
// 関数でなく言語構造であるため、引数を括弧でくくる必要がない
$testPrint = 'DEF' . "\n";
print $testPrint; // DEF
print "alphabet $testPrint\n"; // alphabet DEF

// printf
// フォーマット済みの文字列を出力する
$testPrintF = 'alphabet A:%s B:%s';
printf($testPrintF, 'a', 'b'); // alphabet A:a B:b

// var_dump
// 指定した式に関して、その型や値を含む構造化された情報を返す
$testVar = ['A', 'B', 'C', 'D'];
var_dump($testVar);
// array(4) {
//     [0] =>
//     string(1) "A"
//     [1] =>
//     string(1) "B"
//     [2] =>
//     string(1) "C"
//     [3] =>
//     string(1) "D"
//   }

// print_r
// 指定した変数に関する情報をわかりやすく出力する
$testPrintR = ['A', 'B', 'C', 'D'];
print_r($testPrintR);
// Array
// (
//     [0] => A
//     [1] => B
//     [2] => C
//     [3] => D
// )

各言語で標準出力処理、分岐処理、繰り返し処理と書いていって、あとは配列操作とか。仕事していてこういう書き方ができたとか発見したものを書いていこうかなと。

もちろん言語に限らずで、Docker の Dockerfile や yml ファイルの例をコミットしておくとかもありかなと思ってます。ちょっと振り返りにも使えるような内容がいいですね。

これまで独学で勉強していた内容は、Google ドライブに同期してマークダウンファイルに書いていました。バックアップがとれる点では便利なんですが、誰かと共有するという点ではちょっと気になったというか（ただ共有かければいいだけではあるんですけどね...）

Git のリポジトリであれば、パブリックであれば URL 伝えるだけでいいので楽かなぁと。自分としては、コードベースのアウトプットやメモを TIL リポジトリに残していくつもりです。

将来的に...

既存のサービスで SyntaxDB というものがありまして。 <OG url="https://syntaxdb.com" />

これで各言語の構文見たりできるんですが、こういった言語の構文比較もできるサービス作ってみたいなーとか漠然と思ってます。タブで表示する言語切り替えて比較できるみたいな。気が向いたらいつかやるかも？

アウトプットがなかなかできてないという方は、TIL リポジトリで小さなアウトプットを始めてみてはどうでしょうか？ではでは。

参考リンクまとめ

Netlifyでブログをデプロイ

Sun, 10 Feb 2019 00:00:00 GMT

静的サイトを運用するにあたって「Netlify でデプロイすると楽よー」と教えてもらい、細々と書いていた当ブログを、Netlify を使用して思い切って公開してみました。

import ImageWrapper from "@/components/ImageWrapper.astro" import OG from "@/components/OG.astro"

Netlify とは？

静的サイトのホスティングサービスです。 GitHub、GitLab、Bitbucket のリポジトリと連携させて、自動的にデプロイが行えるようになっています。

静的サイトジェネレータやフロントエンド構築ツールとも相性がいいそうで。当ブログはJekyllで作成しているため、まさに相性がよさそうですね。

ともあれ「どれくらい楽なのよ」ということで、リポジトリを連携させてデプロイするまでの流れを書いていきますー。

初回デプロイするまで

（※すでにアカウントがある場合、1、2はスキップ）

公式サイトにアクセスしてGet started for freeを選択
Netlify アカウントの作成各種 Git のアカウントでも作成できます。 <ImageWrapper src="screenshots/2019/netlify-deploy/netlify-signup.png" alt="Netlifyアカウント作成画面" />
Netlify の自分のアカウントトップ画面からNew site from Gitを選択
以下のどの Git サービスと連携させるか選択

GitHub
GitLab
Bitbucket

Authorize Netlifyで連携を承認（初回のみ）
一覧から連携させるリポジトリを選択
デプロイの設定 <ImageWrapper className="w-[70%]" src="screenshots/2019/netlify-deploy/deploy-setting.png" alt="Netlidyデプロイ設定画面" /> ※↑ Jekyll で作成されたサイトの場合

Branch to deploy どのブランチをデプロイ対象とするかを指定。
Build command ビルドを実行するコマンド。仕様ツールに応じたコマンドを指定。
Publish directory 公開対象となるディレクトリを指定。（例として Jekyll の場合は、jekyll buildでビルドして生成されたファイルは_site配下に展開されるようになっています）

8.Deploy siteを選択ビルドおよび初回デプロイが実行されます。なお、初回は依存関係をインストールするため少し時間がかかりますが、それ以降はキャッシュを用いるため、はやく終わるようになります。

これが初回デプロイまでの手順になります。はやいです。自分がはじめてやってみた時は、5分もかからず、思わず「はやー」と言っていました(笑)。

ビルド + 初回デプロイが終わると、自動的にドメインが割り当てられて公開されます。（プロジェクトの Overview で公開サイト URL のリンクがあるので、そこからもいけます）

独自ドメインへの変更も比較的簡単に行えます。もちろんカスタムドメインに変更も可能です。

初回デプロイ以降は、デプロイ対象のブランチへ push するたびに、自動的にビルド+デプロイが実行されるようになります。楽ちんです。

その他の特徴

プルリク（マジリク）検知デプロイ対象のブランチに対してリクエストを出すと、検知して自動的にプレビューが作成され、マージされた後の状態を事前に確認できます。（※プレビューも公開 URL になるため、商用で使用する際は別途セキュリティを考慮する必要があることに注意）
ロールバック公開するサイトの状態を簡単に過去のデプロイの状態に戻すことができます。（デプロイ一覧から任意のものを選択して、Publish deployを選択するだけ）
Slack 連携デプロイ成功時など、Slack に通知を送ることができます。

この他にも機能はあるのですが、とても書ききれないのでこの辺で。

Netlify は無料プランでも便利な機能が多く使用できるようです。

今回はじめて Netlify を使用したのですが、比較的扱いやすい印象です。他の紹介記事でも書かれていたのですが、なにより UI が優れているので英語でもわかりやすいですー。わかりやすいの大事。

<OG url="https://docs.netlify.com" /> Netlify docs を見れば、おおよそどんな機能があるかもわかります。まだ、半分しか読めてないので読まねば...

Netlify の機能を用いて、少しずつ当ブログを改修していきますー。

参考リンクまとめ

GitLabでリポジトリ（ソースコード）を別アカウントのリポジトリに移行する

Mon, 17 Sep 2018 00:00:00 GMT

仕事用アカウントで個人的に作っていたプロジェクトを、個人用アカウントの方に移行したので、念のための備忘録。（こんなの誰でもわかるやろって言われそうですが...）

※2020/05/06追記この記事での移行は、あくまでコード部分のみの移行であることに注意です。

移行先リポジトリ

作成

GitLab のメニューからProjects→Your Projectsでプロジェクト一覧へ
New Projectから新規プロジェクト作成
任意の名前、任意の設定でCreate Projectを選択

移行元リポジトリ

ローカルのプロジェクトの設定変更

push 先の変更 vi .git/configなどで、リポジトリの URL を移行先リポジトリの URL に変更する。

# 例
[core]
        repositoryformatversion = 0
        filemode = false
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = git@gitlab.com:XXXX/〇〇〇〇 ←このURLを変更
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
[branch "develop"]
        remote = origin
        merge = refs/heads/develop

移行先リポジトリに push する git push origin (ブランチ名)で push して、移行先リポジトリに反映させる。

リポジトリの削除

無事に push が成功し、移行先リポジトリに反映されたら、不要になった移行元のリポジトリを削除する。

移行元リポジトリのトップ画面のサイドメニューからSetting→Generalを選択
一番下のAdvancedのなかの、Remove projectを選択
表示される警告モーダルのなかで、そのプロジェクト名を入力しconfirmを選択

自分がこの移行をした際は、使用する GitLab のアカウントも変えたり SSH キーを設定したりもしたので、もう少し手順が増えましたが慣れてしまえばそう難しくはなかったです。（はじめてやった時は時間かかってしまってましたが...苦笑）

しょっちゅう、こういった移行をすることはないですが一応覚えておきたいものです。

GASで掃除当番Botを作ってみる ③ランダムで掃除当番決め（複数グループ）

Sun, 09 Sep 2018 14:00:00 GMT

前回までで、1つのグループ内でランダムに当番決め + 通知ができました。今回は、これを複数グループ対応にしていきます。

import ImageWrapper from "@/components/ImageWrapper.astro"

事前準備

スプレッドシート側

こんな感じで5グループにしてみました。人数も増やしています。 <ImageWrapper src="screenshots/2018/cleaning-duty/five-group-list.png" alt="グループ表" />

実装

※2019/12/29 再代入しない変数の宣言を const に修正しました。 ※2020/2/16 v8 ランタイムに対応したため、let やアロー関数などが新たに使用できるようになりました。これに伴いリファクタリングを行っています。

{/*  */}

ランタイムの変更は、GASエディタを開いたときに表示される案内（Enable new Apps Script runtime powered by Chrome V8 for this project.）から変更。もしくは、実行 → Chrome V8 を搭載した新しい Apps Script ランタイムを有効にするからできます。

{/*  */}

// 掃除当番をランダムで決めて通知
function noticeCleaningDuty() {
  let msg;
  try { // ⑤
    // 連携するスプレッドシートのうち、グループ表のシート情報を取得
    const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('グループ表'); //①
    // 指定シートの全ての値を取得（二次元配列）
    const data = sheet.getDataRange().getValues();
    // 掃除当番のグループ
    const groupNames = ['A', 'B', 'C', 'D', 'E']; //②
    // 掃除当番を決定し、通知メッセージを生成
    msg = decideCleaningDuty(data, groupNames); //③
  } catch (e) {
    msg = 'エラーが発生しました：' + '\nstack：\n' + e.stack;
  }

  try { // ⑤
    // Slack 側 Incoming WebHook の URL
    const WEBHOOK_URL = PropertiesService.getScriptProperties().getProperty('WEBHOOK_URL');

    // Incoming WebHook に渡すパラメータ
    const jsonData =
        {
          'text': msg
        };

    // パラメータを JSON に変換
    const payload = JSON.stringify(jsonData);

    // 送信オプション
    const options =
        {
          'method': 'post',
          'contentType': 'application/json',
          'payload': payload
        };
    // 指定 URL、オプションでリクエスト
    UrlFetchApp.fetch(WEBHOOK_URL, options);
  } catch (e) {
    Logger.log('送信エラー：' + '\nstack：\n' + e.stack);
  }
}

// 掃除当番を決定し、通知メッセージを作成して返す ③
function decideCleaningDuty(data, groupNames) {
  let noticeMsg = '今週の掃除当番のお知らせ\n\n';
  for (let i = 0; i < groupNames.length; i++) {
    const groupNameRow = searchGroupNameRow(data, groupNames[i]);
    const lastColumn = getLastColumn(data, groupNameRow);
    const menbers = data[groupNameRow - 1].slice(2, lastColumn);
    const numbers = toDraw(menbers.length);
    noticeMsg += groupNames[i] + '：' + menbers[numbers[0]] + '・' + menbers[numbers[1]] + '\n';
  }
  noticeMsg+= '\nよろしくお願いします。'
  return noticeMsg;
}

// 指定グループ名がある行番号を返す ④
function searchGroupNameRow(data, groupName) {
  for (let i = 0; i < data.length; i++) {
    if (data[i][0] === groupName) {
      return i + 1;
    }
  }
  throw new Error(groupName + 'グループのデータが見つかりませんでした。');
}

// 指定した行の最終使用列番号を返す
function getLastColumn(data, row) {
  for (let i = 2; i <= data[row-1].length; i++) {
    if (data[row-1][i] === undefined || data[row-1][i] === '') {
      return i;
    }
  }
}

// 掃除当番の抽選結果を返す
function toDraw(length) {
  let numbers = [];
  numbers[0] = random(length);
  do {
    numbers[1] = random(length);
  } while(numbers[0] === numbers[1]);
  return numbers;
}

// 0～(length-1)の乱数を返す
function random(length) {
  //例 5人の場合 0~0.9999… * 5 の小数点切り捨てで、0~4になる
  return Math.floor(Math.random() * length);
}

大まかな変更箇所

① データを取得したいシートの指定でシート名で指定するように変更

// before
const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheets()[0];

// after
const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('グループ表');

に変更し、取得したいシートの名称を指定するように変更。

② グループ名称の配列の用意を追加

今回は複数グループ対応にするため、グループ名称の配列を用意。

③ 通知メッセージの作成部分をメソッドに変更

掃除当番を決定し、通知メッセージを作成する処理をメソッド化。

④ 指定した名称に応じた行番号を取得するメソッドを追加

グループ名に応じた行の番号を取得するメソッドを追加。

上記の変更箇所はありますが、基本的には、前回まで書いていた処理を複数グループ分、for で回しているというだけです。

⑤ try〜catch ブロックを追加（2019/12/29追記）

コードやスプレッドシートのデータがおかしいなどして、エラーになった場合、エラーメッセージを Slack に投稿してくれるよう追記しました。エラーメッセージがあることで、修正もしやすいです。

実行結果

こんな感じになりましたー。複数グループでの当番決めも、なんとかできました。（前回と違い、メンバー名のところが敬称略形式になっていますが、そこは突っ込まないでください...）

ちなみに bot の名称とアイコンが変わっていますが、これはIncoming Webhookの設定から変更可能です。 <ImageWrapper className="w-[80%]" src="screenshots/2018/cleaning-duty/icon-name-setting.png" alt="webhook設定画面" />

※ちなみに JSON ペイロードに渡すパラメータとして、以下のように指定して、設定を上書きもできるそうです。

var jsonData =
  {
    'text': msg,
    'username': 'new-bot-name',
    'icon_url': 'https://slack.com/img/icons/app-57.png'
    //もしくは 'icon_emoji': ':ghost:'
  };

こちらは今回試してはいないのですが、容易に変更できるのを考えると、こちらで設定する方がいいかも...？（人によっての好みでしょうか...）

あとやれたらいいかなと思った機能として、以下のようなものでしょうか。

前回当番になった人を除外するようにする
これまで当番になった回数の少ない人が優先的に選ばれるようにする
当番を決めた後、それをスプレッドシートに書き込んで履歴にする
設定した時間で通知するようにする（これはトリガー設定だけなので恐らく簡単かなと）

GAS の勉強として続きをやるのもいいのですが、ちょっと他の勉強もしたいので、一旦ここまでにしておきます。勉強したいとか、ちょっとやってみたいとか、これも知っておいた方がいいだろうなとか、そういったことが山積みでとても追いつかないですが（涙）

あまりきれいなコードではありませんが、もし「GAS で bot 作るー」という方がいたとして、少しでも何かの参考にでもなれば幸いです。

GASで掃除当番Botを作ってみる ②ランダムで掃除当番決め

Sun, 09 Sep 2018 12:00:00 GMT

前回、テスト投稿ができました。次はスプレッドシートからメンバー情報を読み取り、そのメンバーの中からランダムで掃除当番を決めて通知するようにしていきますー。

import ImageWrapper from "@/components/ImageWrapper.astro"

事前準備

スプレッドシート側

こんな感じで簡易的にメンバー表を作成してみました。今後、複数グループで当番決めをしたいので、一旦 A グループとしています。 <ImageWrapper src="screenshots/2018/cleaning-duty/group-list.png" alt="グループ表" />

実装

GAS 側

一旦、こんな感じで実装。それにしても、スプレッドシートの行や列番号は1から始まるのに対して、配列の添え字は0から始まるのでややこしいですねぇ(遠い目) 実装する上で、この点に関して少し混乱してしまいました。

※2019/12/29 再代入しない変数の宣言を const に修正しました。 ※2020/02/16 v8 ランタイムに対応したため、let やアロー関数などが新たに使用できるようになりました。これに伴いリファクタリングを行っています。

{/*  */}

ランタイムの変更は、GAS エディタを開いたときに表示される案内（Enable new Apps Script runtime powered by Chrome V8 for this project.）から変更。もしくは実行→ Chrome V8 を搭載した新しい Apps Script ランタイムを有効にするからできます。

{/*  */}

function noticeCleaningDuty() {
  // 連携するスプレッドシートの最初のシートを取得
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheets()[0];
  // 指定シート、行の最終使用列番号を取得
  const lastColumn = getLastColumn(sheet, 4);
  // メンバー名称の取得（戻り値は二次元配列）
  const menbers = sheet.getSheetValues(4, 3, 1, lastColumn - 2);
  // 掃除当番抽選結果を取得
  const numbers = toDraw(menbers[0].length);

  const WEBHOOK_URL = // Webhook URL を記述

  // Incoming WebHook に渡すパラメータ
  const jsonData =
      {
        'text': '本日の掃除当番は ' + menbers[0][numbers[0]] + 'さん と ' + menbers[0][numbers[1]] + 'さん です'
      };

  // パラメータを JSON に変換
  const payload = JSON.stringify(jsonData);

  // 送信オプション
  const options =
      {
        'method': 'post',
        'contentType': 'application/json',
        'payload': payload
      };

  // 指定 URL、オプションでリクエスト
  UrlFetchApp.fetch(WEBHOOK_URL, options);
}

// 指定したシート・行の最終使用列を返す
function getLastColumn(sheet, row) {
  let lastColumn = 0;
  for (let i = sheet.getLastColumn(); i > 0; i--) {
    if(sheet.getRange(row, i).getValue() != '') {
      break;
    }
  }
  lastColumn = i;
  return lastColumn;
}

// 掃除当番の抽選結果を返す
function toDraw(length) {
  let numbers = [];
  numbers[0] = random(length);
  do {
    numbers[1] = random(length);
  } while(numbers[0] === numbers[1]);
  return numbers;
}

// 0～(length-1)の乱数を返す
function random(length) {
  // 例 5人の場合 0~0.9999… * 5 の小数点切り捨てで、0~4になる
  return Math.floor(Math.random() * length);
}

実行結果

5回実行してみました。現時点では単純にランダム選定なので、連続して同じ人になっているところもあります。

さすがに3回連続はキレられますね(笑)

リファクタ

上記のコードでも一応動作はするのですが、なんか微妙...。

また、調べながらやっていた中で見つけた記事に「API の呼び出し回数が多いと動作が遅くなる」という文言がありました。今回の場合でいうと、スプレッドシートにアクセスして値を取得したり、値をセットしているときになります。この処理を for 文で回していたりすると、重たくなる原因だそうで。

getLastColumn(sheet, row)の if 文のところでやってるsheet.getRange(row, i).getValue()なんかは、まさしく該当しそうです...。

ということでリファクタをすることに。

function noticeCleaningDuty() {
  // 連携するスプレッドシートの最初のシートを取得
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheets()[0];
  // 指定シートのすべての値を取得（戻り値は二次元配列）
  const data = sheet.getDataRange().getValues();  //①
  // 指定シート、行の最終使用列番号を取得
  const lastColumn = getLastColumn(data, 4);
  // メンバー名称の取得
  const menbers = data[4-1].slice(2, lastColumn);  //②
  // 掃除当番抽選結果を取得
  const numbers = toDraw(menbers.length);

  // Webhook URL を記述
  const WEBHOOK_URL = PropertiesService.getScriptProperties().getProperty('WEBHOOK_URL');  //④

  // Incoming WebHook に渡すパラメータ
  const jsonData =
      {
        'text': '本日の掃除当番は ' + menbers[numbers[0]] + 'さん と ' + menbers[numbers[1]] + 'さん です'
      };
  const payload = JSON.stringify(jsonData);

  // 送信オプション
  const options =
      {
        'method': 'post',
        'contentType': 'application/json',
        'payload': payload
      };
  // 指定 URL、オプションでリクエスト
  UrlFetchApp.fetch(WEBHOOK_URL, options);
}

// 指定した行の最終使用列番号を返す
function getLastColumn(data, row) {  //③
  for (let i = 2; i <= data[row-1].length; i++) {
    if(data[row-1][i] === undefined || data[row-1][i] === '') {
      return i;
    }
  }
}

// 掃除当番の抽選結果を返す
function toDraw(length) {
  let numbers = [];
  numbers[0] = random(length);
  do {
    numbers[1] = random(length);
  } while(numbers[0] === numbers[1]);
  return numbers;
}

// 0～(length-1)の乱数を返す
function random(length) {
  //例 0~0.9999… * 5 の小数点切り捨てで、0~4になる
  return Math.floor(Math.random() * length);
}

大まかな変更箇所

① 最初に行う、シートのデータ取得を全部まとめて取得に変更

シートのデータをその都度取りに行っていたところを、最初にシートのデータをまとめて2次元配列で取得して、それをもとに処理をしていくようにしました。

const data = sheet.getDataRange().getValues();

がその処理です。

② ①の変更に伴い、取得したシート全体のデータから必要箇所を抽出するように変更

// before
const menbers = sheet.getSheetValues(4, 3, 1, lastColumn - 2);

// after
const menbers = data[4-1].slice(2, lastColumn);

元々、sheet.getSheetValues(行番号, 列番号, 行数, 列数)でシートから該当箇所のデータを取得していました。そこを、①で最初にデータをまとめて取得しているため、それを使うようにしています。 sliceを使っているのは、メンバーの名前の部分のみ取得したいからです。

③ 最終列の判定方法を変更

元々、sheet.getLastColumn()でシート全体での最終列を取得し、1列ずつ内側を参照し（シートにデータを取りに行き）、値がセットされていたら最終使用列とみなしていました。それを逆に、（最初にまとめて取得したデータで）内側から1列ずつ外側を参照し、値がセットされていない、もしくはundefinedになったらそこを最終使用列とみなすとしました。

④ WebHookURL をスクリプトプロパティから取得するように変更（※2019/12/21追記）

WebHookURL をそのまま書いていましたが、こういったものはコードへべた書きせずにプロパティストアで管理するとよいです。 GAS プロジェクトに紐づいてデータを持っておける領域で、プロパティ（キー）：値の形式で環境変数のように扱うことができます。

プロパティストアは複数の種類がありますが、今回はスクリプトプロパティを使用しています。

登録、編集 GAS エディタのファイル→プロジェクトのプロパティ→スクリプトのプロパティから ※注意...そのGASプロジェクトのオーナー権限のアカウントである必要があります。
使用

PropertiesService.getScriptProperties().getProperty('プロパティ名');

あとは細かなところを修正しました。

とりあえず、1グループでランダム当番決め + 通知はできました。次は、これを複数グループ対応にしていきます。

参考リンクまとめ

GASで掃除当番Botを作ってみる ①テスト投稿

Sun, 09 Sep 2018 10:00:00 GMT

職場で掃除当番の話が出ていたので、自動で掃除当番を決めて通知してくれる bot がいたらいいのかなぁと思い、ちょっと bot 作成に挑戦してみました。

import ImageWrapper from "@/components/ImageWrapper.astro"

事前準備

まずは構成を構築していきます。（以下、Google Apps ScriptをGASと記述しています）

構成図

大まかな流れはこんな感じ。（相変わらずスプレッドシートで図形描画はしづらいですねぇ...） <ImageWrapper src="screenshots/2018/cleaning-duty/architecture.png" alt="構成図" />

Slack 側

GAS から Slack に投稿するにあたって、 Slack API or Incoming-webhook が必要になりますが、今回は後者の方を使用しています。

ワークスペースとチャンネルを用意

Slack 側で bot の投稿をしたいワークスペースとチャンネルを事前に用意しておきます。

ワークスペースに Incoming-webhook を設定する

ワークスペースメニュー → その他管理項目 → App管理へ（あとからキャプチャを撮ったので、キャプチャ上で投稿されている内容については後から出てきます...） <ImageWrapper className="w-[60%]" src="screenshots/2018/cleaning-duty/incoming-webhook-setting.png" alt="Slackの設定からApp管理へ行くまで" />
(右上の Menu → )検索へ
Incoming webhook で検索し、Incoming webhook を選択し、設定画面へ <ImageWrapper className="w-[60%]" src="screenshots/2018/cleaning-duty/incoming-webhook-search.png" alt="アプリ検索画面" />

※すでに Incoming webhook を追加済みの場合

ワークスペースメニュー → その他管理項目 → App管理 → (セクションを変更する) → カスタムインテグレーション → Incoming webhook を選択でも、同様の画面に行けます。

設定を追加を選択
チャンネルへの投稿で投稿したいチャンネルを選択 → 着信 Web フックインテグレーションの追加を選択で設定詳細画面へ
任意で設定を変更して、設定を保存するを選択なお、この画面にあるWebhook URLはGAS 側で使用するので控えておいてください。また、セットアップの手順、メッセージ添付ファイルの項目で、この webhook の使い方が書いてあるので、読んでおくといいですよー。

Google Drive 側

スプレッドシート

スプレッドシートを作成（この段階では何も記述しなくて OK）
スプレッドシートのメニュー → ツール → スクリプトエディタを選択

Slack に投稿する

GAS に投稿内容を記述

ここから実際に Slack へ投稿する内容を記述していきます。 GAS では、JavaScript で記述していきます。

Webhook URL にデータを送信するには、以下の2つの方法があるようです。（今回は前者のやり方になります）

POST リクエストでpayloadパラメータとして JSON を送信する
POST リクエストの本体として、JSON を送信する

ここでは一旦、ちゃんと投稿ができるか確認するためにテスト投稿を行います。

※2019/12/29 変数宣言の var を const に修正しました。 ※2020/02/16 細かな修正。

function myFunction() {
  const WEBHOOK_URL = // 先ほど控えた WebhookURL を指定

  // Incoming WebHook に渡すパラメータ
  const jsonData =
      {
        'text': 'test'
      };

  // パラメータを JSON に変換
  const payload = JSON.stringify(jsonData);

  // 送信オプション
  const options =
      {
        'method': 'post',
        'contentType': 'application/json',
        'payload': payload
      };

  // 指定 URL、オプションでリクエスト
  UrlFetchApp.fetch(WEBHOOK_URL, options);
}

GAS メニューから関数を選択し実行ボタンを押すことで、選択した関数を実行できます。（※初回実行時には、実行の許可が求められるので許可してください）

実行結果

実行すると指定した Slack のチャンネルに以下のように投稿されます。 <ImageWrapper className="w-[80%]" src="screenshots/2018/cleaning-duty/incoming-webHook-test.png" alt="Slack投稿結果" />

これで投稿ができるようになりました。今度は、投稿内容を変えていきましょうー。

リンクまとめ

【初心者向け】GASを使ってSlackへ自動通知

UbuntuにPHPインストールで格闘した話

Tue, 05 Jun 2018 00:00:00 GMT

先日の anyenv 導入後、PHP をいれたかったのでphpenvも入れることにしたのですが... なかなか長い戦いになりました(遠い目)

import OG from "@/components/OG.astro"

※注意点 結論を先に言いますと、PHP のインストール自体はできたのですが、Ubuntu の apt コマンド使いました...。なので、ここから先はphpenvでの導入の参考にはなりませんし、非常に長くなったのであしからず。

自分が PHP をインストールするまでの戦いの履歴が以下のとおりです。

PHP をインストールする

anyenv → phpenv でインストール

phpenv インストール

anyenv install phpenv

ログインシェルで各種 profile 再読み込み

exec $SHELL -l

インストールできる PHP のバージョンの確認

phpenv install -l

指定したバージョンの PHP をインストール

phpenv install (バージョン)

この時、依存ライブラリも一緒にビルドをしてくれるのですが...以下のようなエラーが。

configure: WARNING: unrecognized options: --with-mcrypt
configure: WARNING: This bison version is not supported for regeneration of the Zend/PHP parsers (found: none, min: 204, excluded: ).
configure: WARNING: You will need re2c 0.13.4 or later if you want to regenerate PHP parsers.
configure: error: libxml2 not found. Please check your libxml2 installation.

調べていくと...。ビルドに必要な拡張ライブラリを入れておき、ビルドの際にそれらを使ってくれるようパスを指定したりしていけば、おおよそ解決する模様。しかし、表示されたエラーに沿って対応していっても、なかなかビルドが通ってくれず。 configureオプションでビルドの設定ができるのはわかったんですが、具体的なことはイマイチわからずで次の方法へ。

phpenv をいれるところまではスムーズだったんですけどねー。

※ちなみにビルドに成功した場合は、以下のコマンドでバージョンを選択できるようです。

バージョン切り替え

システム全体で適用

phpenv global (バージョン)

一部プロジェクトで適用

phpenv local (バージョン)

インストールされているバージョン確認(選択されているバージョンに*がついている)

phpenv versions

brew でインストール

brew で各バージョンをインストールし、phpenv とリンクさせて繋ぐことで管理できないかなと考えてみました。

インストールできるバージョンの確認

brew search php@

表示されるphp@5.6 php7.0 php@7.1 php@7.2が対応バージョンです。

※2018/03/31まではPHPのフォーミュラとしてhomebrew/phpがあり。 php56とphp56-*(バージョンに応じた拡張) のような形式だったのですが、homebrew/coreに統合された関係で上記のような形式になった模様。(拡張は組み込み式に変更) ※2024/02/11にはこの情報を参照していた記事が見られなくなっていました。

指定したバージョンのPHPをインストール

brew install php@(バージョン)

依存パッケージも一緒にインストールしてくれますが...。

ncurses, util-linux, apr, libbsd, expat, apr-util, brotli, gdbm, readline, sqlite, bzip2, python@2, libxml2, c-ares, libev, libevent, jansson, boost, jemalloc, nghttp2, pcre, httpd, aspell, curl, freetds, libpng, freetype, gettext, libffi, glib, icu4c, jpeg, libpq, libtool, libzip, mhash, mcrypt, unixodbc, libtiff, webp

こんな感じでたくさん入ります。こんなにあるんや...とか、なんかpythonまで入ってるんやけどとか思いつつ。順調にインストールが進んでいたのでいけるかと思いきや、最後の PHP のビルドでまたもやエラーに。こんなにたくさん依存パッケージインストールしといて最後にコケるんかーい。

configure: error: Cannot find sys/sdt.h which is required for DTrace support

エラーメッセージを頼りに調べていくと、どうやらopensslに関するエラーの模様。

Please do not report this issue to Homebrew/brew or Homebrew/core. which support macOS only.

ちなみにエラーメッセージのあとにはこんなメッセージが。「macOS しかサポートしてないから、不具合等の報告は送らないで」ということでしょうか。

ダメもとでopensslの新しいバージョンのものを入れてみたり、パスを確認してみたりするも、うまくいかず...。

この時点で結構な時間を使っていたので、「PHP のビルドがうまくいかなくてキレそう」とつぶやいたところ、先輩から助け舟が。しかし、残念ながらそれもむなしい結果になってしまいました...。

phpbrew でインストール

今度は、以前業務で使ったことがあるphpbrewで挑戦してみることにしました。 phpbrewはphpenvとphp-buildを1つにしたようなもので、こちらでもバージョン管理ができます。業務で使っていたときはbrewでインストールしていましたが、前述のとおりhomebrew/phpが使えなくなったため、curl コマンドでインストールすることに。

<OG url="https://github.com/phpbrew/phpbrew" /> ※環境に応じた事前に必要なものが記載されているので、先に入れておくといいかも

基本的に公式の案内に沿って進めました。

インストール

curl -L -O https://github.com/phpbrew/phpbrew/raw/master/phpbrew

権限変更

chmod +x phpbrew

格納場所を変更

sudo mv phpbrew /usr/local/bin/phpbrew

bash script を初期化

phpbrew init

ここでまたもや問題が。 bash script を初期化しようとしたところ、phpbrewコマンドが使えない状態でした。

php-cliをいれれば良いとのことで、brew でインストールしたところphpbrewコマンドが使えるようになりました。

以下続きます。

以下を .bashrc に追記

source ~/.phpbrew/bashrc

インストールできるバージョン確認

phpbrew known

指定したバージョンの PHP をインストール

phpbrew install (バージョン) (バリアントオプション)

※phpbrew ではバリアントという概念があります。拡張ライブラリをより扱いやすくしたものといった感じでしょうか。

はい、やってきましたビルドの時間。いいかげんビルド成功してほしいという願いもむなしく...やっぱりコケました。う～ん、PHP に嫌われてるのかなぁと思ってみたり。

※ビルド成功時には以下のコマンドでバージョン選択できます。

バージョン切り替え

システム全体で適用

phpbrew switch php-(バージョン)

一部プロジェクトで適用

phpbrew use php-(バージョン)

インストールされているバージョン確認(選択されているバージョンに*がついている)

phpbrew list

apt でインストール

これまでの戦いでヘロヘロになっていた自分は、バージョン管理をあきらめてaptコマンドでインストールすることにしました...。

<OG url="https://qiita.com/yamatmoo/items/b9e8035c55032de88084" /> ほぼこちらの方の記事のとおりに進めました。

リポジトリ追加

sudo add-apt-repository ppa:ondrej/php

apt のアップデート

sudo apt update

インストール

sudo spt install php(バージョン) (拡張ライブラリ)

# 例（必要に応じてライブラリ追加）
sudo apt install php7.2 php7.2-common php7.2-cli php7.2-fpm php7.2-mysql php7.2-dev php7.2-mbstring php7.2-zip

バージョン確認

php -v

PHP 7.2.5-1+ubuntu16.04.1+deb.sury.org+1 (cli) (built: May  5 2018 04:59:13) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
 with Zend OPcache v7.2.5-1+ubuntu16.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies

こんな感じで表示されたら OK です。やっと PHP 使えるようになりました...。それも apt だと拍子抜けするくらいあっさり終わって、いままで使った時間なんやったんや...。

バージョン情報を見てみると、もしや Ubuntu 用の PHP だったりするんでしょうか。

いやはや、とても長い道のりでした（苦笑） Ubuntu に慣れている方だったらこんなことしないんだろうなぁと思いつつ、まぁ無事に PHP 使えるようになって良かったです。

参考リンクまとめ

anyenvでバージョン管理

Sat, 02 Jun 2018 00:00:00 GMT

個人でコード書いていくうえで、そんなに必要ないかも...?と思いつつも、一応、言語をバージョン管理できるようにしておこうと思いまして。

当ブログは Jekyll という静的サイトジェネレータを使用して作成しています。この Jekyll を使う上で Ruby が必要になるので、元々 Linuxbrew で rbenv を入れていました。ふとしたきっかけで、rbenv をはじめとした env 系を一括管理できるanyenvの存在を知りまして。せっかくなのでanyenvを使ってみることにしました。

※2019/11/06追記 この記事ではanyenvをgit cloneで導入しています。 brewを使用して導入するやり方もあり、以下の記事ではLinuxbrewで導入しています。 WSLでWindowsの中にLinuxの開発環境を作ろう

anyenv

※env 系の管理を brew からanyenvに移行する場合は、事前に brew で入れた分をアンインストール＋パスの削除をするか、参考記事のとおり、リンクを張る方法があります。

導入

インストール

git clone https://github.com/riywo/anyenv ~/.anyenv

パスの設定（ここでは.bash_profileに記述していますが、使用している各種profileのいずれかで問題ありません）

echo 'export PATH="$HOME/.anyenv/bin:$PATH"' >> ~/.bash_profile

bash 起動時に自動で init するよう設定

echo 'eval "$(anyenv init -l)"' >> ~/.bash_profile

※これで bash 起動時にanyenvからインストールした各種 env を init してくれるようになるため、すぐ各種コマンドが使えるようになります。

ログインシェルで各種profile再読み込み

exec $SHELL -l

anyenv コマンド確認

anyenv

以下のように表示されればOK。

anyenv
Usage: anyenv <command> [<args>]

Some useful anyenv commands are:
   commands            List all available anyenv commands
   local               Show the local application-specific Any version
   global              Show the global Any version
   install             Install a **env
   uninstall           Uninstall a specific **anv
   version             Show the current Any version and its origin
   versions            List all Any versions available to **env

See 'anyenv help <command>' for information on a specific command.
For full documentation, see: https://github.com/riywo/anyenv#readme

anyenv-update インストール

各種 env とそのプラグインを一括でまとめて更新してくれるものだそうです。それぞれ1つずつ更新するのは、確かに手間ですよね...。

格納するディレクトリの作成

mkdir -p $(anyenv root)/plugins

インストール

git clone https://github.com/znz/anyenv-update.git $(anyenv root)/plugins/anyenv-update

これでanyenv updateコマンドが使えるようになります。

各種 env のインストール

インストールできる env の確認

anyenv install -l

Available **envs:
  crenv
  denv
  erlenv
  exenv
  goenv
  hsenv
  jenv
  luaenv
  ndenv
  nenv
  nodenv
  phpenv
  plenv
  pyenv
  rbenv
  Renv
  sbtenv
  scalaenv
  swiftenv

インストール

anyenv install (各種env)

# 例
anyenv install rbenv

このコマンド1つで、ビルドに必要な各種env-build(rbenvならruby-build)も一緒にインストールしてくれます。

ログインシェルで.bash_profile再読み込み

exec $SHELL -l

自分はまずanyenvでrbenvをインストールしなおしたのですが、特別つまずくこともなくスムーズでした。パスを汚さなくていいですし、楽でいいですねー。

開発関連技術 | Change Of Pace

ポートフォリオサイトをTanStack Startでリプレースしたので振り返ってみよう

ポートフォリオサイトの履歴

起源

TIL の移行

リプレースへ

リプレースしたもの

レイアウト比較

デスクトップ

モバイル

リプレースで採用してみた主な技術

TanStack Start

Tailwind CSS

React Bits

リプレースした感想など

参考リンクまとめ

2025年振り返り ～技術活動、ブログ、キャリア編～

2025年の活動履歴

コミット履歴

GitHub

案件 - GitHub

ブログ

アクセス履歴

記事執筆について

ブログ以外の記事執筆活動

個人開発

個人勉強

フロントエンド

バックエンド

資格試験

イベント参加

リードエンジニア的な立ち回り・キャリア

2026年はどうしていきたいか

ブログ・技術記事

個人開発

個人勉強

フロントエンド

バックエンド

ドキュメント活動

資格試験

イベント参加

リードエンジニア的な立ち回り・キャリア

Windows + Git Bash環境でmiseとSafe Chainを共存させる

背景

環境のつくり方

mise のインストール

Node.js のインストール

Safe Chain のインストール

エイリアスの活用

Safe Chain のマルウェア検知の動作確認

2024年振り返り ～技術活動、ブログ、キャリア編～

2024年の活動履歴

コミット履歴

GitHub

案件 - GitLab・GitHub

ブログ

アクセス履歴

記事執筆について

ブログ以外の記事執筆活動

個人開発

個人勉強

フロントエンド

バックエンド

資格試験

TIL 活動

イベント参加

リードエンジニア的な立ち回り・キャリア

2025年はどうしていきたいか

ブログ・技術記事

個人開発

個人勉強

フロントエンド

バックエンド

ドキュメント活動

資格試験

TIL 活動

イベント参加

リードエンジニア的な立ち回り・キャリア

2023年振り返り ～技術活動、ブログ、キャリア編～

2023年の活動履歴

2025年振り返り～技術活動、ブログ、キャリア編～

2024年振り返り～技術活動、ブログ、キャリア編～

2023年振り返り～技術活動、ブログ、キャリア編～