こんにちは。
今回は、前回に引き続く「next.js 13 で個人開発」シリーズになります。
今回でフロントエンドの開発が大体終わったので、
実際に個人で開発するのにnext.js 13は向いていたか。
もっとこうすれば良かった！
などの反省点なども含めて
個人の主観でまとめていこうと思います！
next.js 13は個人開発に向いていたか？
next.js 13は、
2023/5くらいに正式リリースがされて、
日本語のドキュメントも少ない中、
next.js 13を選んでよかったかという点ですね。
これは、YESです！！！
まぁどうしてかっていうと、
正直もうchatGPTが出てきて、
Browse with Bingなどのブラウジング機能や、
urlを投げて英語のDocを日本語で理解して説明なども
もう出来ちゃうので、
あんまり不便感じなかったですね。
難しいDocよりも
分かるまでひたすら質問投げた方が、
本質的な理解も出来て、
個人的にはとても充実しました！！！！
僕は、1か月課金して、
GPT４を使っていましたが、
やっぱりこれは課金して正解です。
gpt3.5は1問１答になっている感じで
あまり話し相手って感じではないのに対して
gpt4はもうとんでもメンターと友達になっちゃった！！
ってレベルです。
月20ドルとかだったので、
試しに課金することも検討してみてください。
next.js 13は、フレームワークとしても優秀
次は、個人開発のしやすさ
について書いていきます。
next.js 13での開発はやりやすかったか？
ですね。
答えはYESです！！！
(今回の開発であまり不便さを感じなかったので、
YESばかりになるかな)
僕は以前は、
CS(コンピューターサイエンス)から勉強していたので、
reactやnext.jsなどのフレームワーク
を使わないで作ることの方が多かったのですが、
今回かなり大きなアプリケーションに挑戦して、
だいぶコンポーネントのありがたさを
受けることが出来ました。
ページ遷移時に必要なデータのみをとってくる。
(以下記事参照)
これの効率を高めるために、
わりとコンポーネントは分けて書いたのですが、
これが最終調整やデバック時に効いて効いて。
それこそ、
ページ１でもページ２でも
同じコンポーネントにpropsを渡しているだけの場合、
変更するのはそのコンポーネントだけでいいわけだから、
最終的に、
やっぱここ変えたい。
って言うとき一発なんですよね。
まぁこれらは、
vue.jsとかほかのフレームワークでも言えそうなので、
next.js 13に限った話で行くと、
まず、
ページ遷移速度。
速い！！！！！
キャッシュやLinkコンポーネント
(以下参照)
これらの恩恵もあってか、
即座にページ遷移できることもあって、
あまりロードの苦は感じないですね。
開発もやりやすい。
あとは、
Appルーターから変わった、
ディレクトリ構造やlayout.tsxでしょうか。
ディレクトリ構造は、
言ったしまえばフォルダが増えて、
整理しやすくなったと感じます。
layout.tsxも含め、
直感的に整理しやすいのかなぁと感じました。
next.js 13 こうした方がもっと良かった点(反省点)
ここからは、
実際に使ってみての反省点について考えていきます。
最初の段階で共通のコンポーネントをもっと洗い出しておきべきだった
これは、
他のサイトでも言われていて、
意識していましたが、できなかった点です。
next.js 13からlayout.tsxなどもでてきて、
よりコンポーネントの重複は避ける方向性になっていると思います。
なので例えば、
homeページ以下で全てのページにページタイトルを付ける予定
などが最初から分かっていれば、
layout.tsxで構成してもっと
無駄を省けたと思います。
コンポーネント自体もどこまで細分化するの？
と意味が分からなくなってしまいそうですが、
次に全く同じ構成を書くことがあるか？
を自分に問い、
少しでもその可能性がある場合は
分割することをお勧めします。
そのうえコンポーネントを使うと
設計もしやすくなります。
あらかじめ、
containerを作ったら、
中にはこれらを置こうと
先にコメントなどを打っておけば、
スムーズに進めやすかったです。
ということで、
最初の段階で、
layout.tsxに使うような、
全体で被っているようなコンポーネントは？
を問いかけることですね。
最初にコンポーネント戦略を立てた方がいいです。
高さなどはできるだけ値で指定する
僕は最初の方で、
flexBoxの大枠をflex-growなどで伸ばしていましたが、
これは～vhなどの値で設定した方がよさそうだと思いました。
そうでないと、
子要素ではwidth: 100%;
などといった値が効かなくなるなど
不具合が起きますから。
単位はremとpxの使い分け
remはh1タグへの相対値なので、
メディアクエリなどが楽にできます。
対してpxは絶対値なので、
小さな数を扱うとき
2pxとか
を扱うときは楽に設計できると思います。
紙やマインドマップで書き出すこと
最初の段階でアイデアや、
ページのレイアウト構成に至るまで、
イメージを言語化。
marginなども含め、数値化まで行えると
後の動きが楽になると思います。
ここからは、
自分用の備忘録ですが、
どんなコンセプトをもって
今回は開発したのかを書いておきます
今回のフロントエンドの開発コンセプト
レンダリング速度を上げる技術選定
自分で０から始めたこの計画ですが、
作りたいアプリの特性上、
レンダリング速度の速いことが前提だったので、
next.js によるSSRの恩恵を受けたかった。
開発時点であまり日本語Docのでていないものを選んだ
chatGPTが出てきて、
開発速度の向上が予測されます。
けれど、
その分学習する内容は多く、
どんな立場の人でも手を出せるようになりました。
なので、
どうせなら未開拓分野を自分で開拓してみて、
どこまでやれるのかという実験もしてみたかったのが本音です。
結果、
chatGPTは現在の情報に対応させること、
リアルタイムのweb上のデータをもとに会話ができるので
十分に個人開発はできると思います。
基本どういうディレクトリ構造が主流なのか。
どうゆう書き方がベストプラクティスなのかも聞けます。
が、実際にもっと効率が良い方法やノウハウは
ｘや人と話すなど、
いろんな窓口を持っておく必要がありますね。
DRY(Don’t Repeat Your Self：繰り返しを避けること)原則
手間はできるだけ省きたいのと、
構成をわかりやすくしたいために
コンポーネントをわかりやすく管理する事を目指しました。
おかげで、
小さなころ、
レゴブロックで城を作るのに似た感情を覚えました。
作りやすかったです。
が、まだまだ使いこなせていない気がします。
コードの見やすさ
コードを見やすくしたいというのがあり、
saasを使いました。
初めての記述でしたが、
もうcssには戻れません。
使いやすい。
コメント