無事、私もアップデートできました。

はじめまして

Next.js13

こんにちは

use client

今までお疲れさまでした

pages dir

出会いがあれば別れもありです。

ちょっと寂しくて

でも

ちょっとワクワクする

そんな気持ちになったアップデートの作業でした。

easy-notion-blog

今回のような大型アップデート、

実は初めてではありません。

2022/02にありました。

+1,363 −1,765

なんとも清々しいツイートですが、

当時私はeasy-notion-blogを使い始めて

２ヶ月ほどしか経っておらず

「無事にpushできた〜＼(^o^)／」

「style変えられた〜＼(^o^)／」

といったレベルだったので

「今まで改造したことが消えちゃったらどうしよう…」

と不安でたまらず、

震えながらアップデート作業に取り掛かったことを今でも覚えています。

あれから10ヶ月。

「うし！来やがれ！！！！」

という意気込みでエラーを楽しみながらアップデート作業に取り組むことができました。

この10ヶ月

何か対策をしてきたかというと…

これといってありません。

ただただ

ブログの改造を続けていた…

これだけです。

今日は、

PR #139のMigration Next.js to 13 (+1,319 −1,190)を

取り込む上で意識したこと

分かったこと

興味が湧いて調べてみたこと

などを振り返ります。

前回はいきなり作業を始めてしまい火傷しました。

何事も予習は必要だなと学んだので今回はしっかり予習をすることにしました。

アップデートに向けた事前アップデート#138 IMPORTANT: Prepare Next12 では…

同じように差分を見ながら予習をすれば

Next.js13のアップデートもできるかなと軽く考えていたところ…

普段アップデート方法の解説は事前に出ないので、

このツイートを見た時

「解説がないと道に迷うほどの難易度なのか」

と危機的状況をやっと理解しました。

(ㅇㅁㅇ川

解説記事を５回読み返しました。

記事の中で紹介されていたスレッドも見ました。

(ㅇㅁㅇ川

頭で理解することを辞めることにしました。

体当たり作戦に変更です。

今回のアップデートでcommit数が39もあることに圧倒されていましたが…

実は逆でした。

１commitあたりの差分量が程よく

納得した上で競合してしまっている部分(コンフリクト)の吟味をすることができました。

Next.js13の変更点が多すぎて

記事を読んでも理解できなかったのに

以下のような流れで作業をすることで

着実に前に進むことができました。

1. commit名からこれからどんな変更をするのかをイメージ
2. commitのコード差分を確認
3. 解説記事のどの部分に該当するかを見返す
4. さっそくcommitを取り込む
   1. 競合箇所がある場合は慎重に
   2. 自分の改造した箇所で同じパターンで修正できる部分はないか考えて修正

この４つを繰り返し行いました。

場所によってはすぐに修正できない場合もあったので

そこは他のcommitでヒントがないか…

といったアンテナを立てながら次の取り込みに切り替えました。

取り込みを進めてく中で気づいたのですが、

元々あったファイルをすぐ消さず

移行先のファイルが勢揃いした後に

まとめて消す…

という流れがとてもありがたく思いました。

移行先にファイルを作っても

そのディレクトリ内に用意したファイル同士を見比べることはもちろん

移行前のファイルも合わせて必要な状況が多々あり

作業がしやすいなと感じました。

私はいつも改造をするとき

１ファイルを移行し終わると

移行前のファイルを消して１commitとしてpushしてしまうので

反省しないとなと気づきました。

ディレクトリ内にある複数ファイルを変更する場合には

本家のようなやり方を取り入れたいです。

今回特徴的だったのが

index.jsがhead.jsとpage.jsの二本立てになったという部分。

レイアウトを都度変えたい場合はそれにlayout.jsを追加するのですが、

私は本家と同じのままでも不自由ではないかなと思ったのでそのままにしました。

commit名を見ると…

Homeのページ・Component関連の定義を済ませた後に…

Headファイルを作って

Pageファイルを作る

のパターンを掴めたときくらいに楽しめるようになってきました。

yarn devで表示できない部分を解決していく必要があります。

ここで結構頭を使いました。

特に<Link>です。

やるだけのことをやってお手上げ状態になったら

rootブランチに切り替え、

本家のデザインに戻しても

自分の記事は問題なく表示されるかどうかを確認しました。

これによって、

発見できることが多々ありました。

だいたいが消しすぎでした。

「あ、ここ残しておかないと動かないのか〜」

という気づきです。

５日におよんでアップデート祭りを開催していたhotomiですが、

作業を終えて

「結局何が良くなったのさ！？」

という部分に興味が湧いてきました。

以下、horomi意訳です。

サーバーComponentとクライアントComponentに分けることで

それぞれが得意なことに専念できる。

サーバーComponentは複雑なこともするけどクライアントサーバーに送る量も減らせるようになったから

初動がより高速になった。

アクセスした時ランタイムが動くんだけど、

キャッシュもできるしサイズの把握もできる。

しかもアプリを大きくしてもサイズは変わらない！

データの必要のない部分を表示してデータのある部分はローディング表示をするので

アクセスした時に何も表示されないなんてことはない。

何かしらを表示してくれる。

居酒屋のお通しみたいな感じ。

fetch は自動で重複したデータを除去してくれる。

これって柔軟な方法だよね。

Component単位でデータを取得・一時保存・再検証するとき臨機応変に使えるね。

Webpackを使いすぎちゃったからTurbopackを取り入れて高速にしたよ。

imageコンポーネントはとっても人気だから

もっと使やすくしたよ。

• カスタムフォントを含むフォントの自動最適化
• 外部ネットワークへの要求を削除し、プライバシーとパフォーマンスを改善
• あらゆるフォントファイルに対する自動セルフホスティング機能を内蔵
• CSSのサイズ調整プロパティを使用して、レイアウトのずれを自動的にゼロに

Googleフォントを便利に使えて、ブラウザでアクセスする必要なんてない＼(^o^)／ﾔｯﾀ～

<Link>コンポーネントはデフォルトで<a>を含むようになったので

もういらないよ！٩(ˊᗜˋ*)و

静的なOGImageはよく不足したりスキップされてしまったりして維持が困難だったよね。

かといって動的OGImageは開発者個人に委ねるスタンスになったり

その場その場で計算がされたりするので困難で高価。

そこで新しくOgImageのライブラリを作っちゃいました ♪

５倍速くなったよ(*๓´╰╯`๓)♡

ちゃんと読みたい方はこちらをどうぞwww

高速になったっていうことだけは分かりました。

でも、

今まで十分高速だったし

どこまで高速を追い求めるんだろうかと

素人ながら不思議でたまらなくなりました。

今回のアップデートで

すごく楽しかったのは

同じようにアップデート作業をしているeasyさんがいたことです。

２月の時は私だけでした。

もしかしたら静かに作業をこなされていた方がいたかもしれないけど

情報交換はできない状態でした。

今回は

Twitter上で情報交換をしながら

ワイワイやれたのは本当に楽しかったです。

どんなところで詰まっているのかも

事前にキャッチすることができたので

自分がいざその場面になったとき

全然焦ることはなく

「あ〜例のあれね」

といった感じでした。

これからアップデートに取り掛かるeasyさんにも

すごく興味津々だし、

これから新たな改造をしようとしてるeasyさんにも

興味津々です。

楽しくて楽しくてたまらないので

いろんな方にもeasy-notion-blogを使ってもらえるような

キッカケ作りをしていきたいなと計画しています＼(^o^)／

詳しくまとまり次第ブログでお知らせしますね〜〜♪

ではまた(*๓´╰╯`๓)♡