⇧ シンプルにしようとしてくれるのは素晴らしいんですが、破壊的変更が無いのが利用者にとっては嬉しい気がしますな、自分はRuby on Railsを利用していませんが...
Next.jsのPages RouterとApp Routerと
React単独での利用が非推奨っぽいので、Next.jsを利用せざるを得ないことになったので、Next.jsを利用しようとしたところ、どうも、Next.jsの端境期に遭遇したようで、
- Pages Router
- App Router
の切り替えの時期に、Next.jsの入門をすることになった模様。
と言っても、アーキテクチャが分からんので何が変わったのかがサッパリ分かりませんと。
⇧ とのこと。
ネットの情報を漁った感じでは、
⇧ アーキテクチャの違いについての概念図のようなものは存在しないってことみたいね...
ブラックボックスにしてくれてますな...
ネットの情報によると、
⇧ Reactの場合は、上図のような全体像になるらしい。
ReactのRouterだと、
⇧ 上記サイト様によりますと、使い方が4種類あるらしく、
- Browser Router
- Hash Router
- Memory Router
- Static Router
が用意されているらしい。
話が脱線しましたが、
⇧ Next.jsで上がっている課題から推測するに、
- React単独
- React Router
- Next.js
- Pages Router
- App Router
といった感じで、React単独のRouterとNext.jsのRouterは全く別物と考えれば良いんですかね？
⇧ 何と言うか、
『Next.js is a React framework for building full-stack web applications. 』
とあるのに、React Routerと相容れなかったりと、なかなかの絶望感...
Reactの公式のドキュメントに見当たらないけど、
⇧ ReactのEcosystemが、Reactと密結合してしまっているということですかね？
Wikipediaによると、
React (リアクト)またはReact.js、ReactJS とは、ウェブブラウザで複雑なUIを容易に生成するためのフリーかつオープンソースなフロントエンドJavaScriptライブラリである。
特徴
主な特徴
Reactが提供する代表的な機能を以下に挙げる。
- 宣言的UI（テンプレーティング）: JSX
- データバインディング
- コンポーネント化: 関数コンポーネント
- 高効率レンダリング: 仮想DOM
一般的なイディオム
Reactは完全なアプリケーションフレームワークを提供しようとはしていない。Reactはユーザインタフェースを構築するために設計されており、故に、開発者がアプリケーションを構築する際に必要であると考えるかもしれない多くのツールは含まれていない。
⇧ とあり、React自体は、UIを提供することのみに特化しているという立ち位置らしく、本来であれば、その他の機能についてはReactの責任範囲外であると。
ちなみに、React Routerは、
React Router is a lightweight, fully-featured routing library for the React JavaScript library. React Router runs everywhere that React runs; on the web, on the server (using node.js), and on React Native.
⇧ とあり、
⇧「Remix」というWeb Frameworkを開発してる組織で開発されたものらしい。
なるほど、Reactの公式のドキュメントには、
- ReactはReact単独での利用は非推奨として、以下、いずれかとの併用を推奨
- Next.js
- Remix
- Gatsby
- Expo（ネイティブアプリ向け）
⇧ のような感じの説明があり、
- Next.js
- Pages Router
- App Router
- Rimix
- React Router
⇧ といった感じになるのか。
ネット上の情報が整理されてなさ過ぎて辛い...
Next.jsでPages RouterからApp Routerに代わったらしいが、結局どうすれば良いのか
とりあえず、Next.jsのRouterの話に焦点を絞ると、
⇧ 上記サイト様によりますと、
| No | 項目 | Pages Router | App Router |
|---|---|---|---|
| 1 | Node.jsバージョン | v18.17未満 | v18.17以上 |
| 2 | Next.jsバージョン | 13未満 | 13以上 |
| 3 | デフォルト | Client Component | Server Component |
| 4 | ルートレイアウト | pages/_app.tsxおよびpages/_document.tsx | app/layout.tsx |
| 5 | 各ページの起点ディレクトリ | pages/ | app/ |
| 6 | ファイル名の命名ルール | 特に決まりなし | page.js、page.ts、page.jsx、page.tsx |
⇧ といった違いが大きな部分になるのかな？
まぁ、分からん用語のオンパレードなんだが...
公式のドキュメントによると、
⇧「pages/_app.tsx」、「pages/_document.tsx」の内容を「app/layout.tsx」に移し終えたら、「pages」ディレクトリは削除することになるらしいが、前提として「App Router」への移行が完全に遂行されていることが確認できてから行うらしい。
何をもって、完全に移行できたとみなせば良いのかをハッキリさせて欲しいんだが...
とりあえずは、
⇧ メソッドとHTMLが混在するカオスな構成に慣れる必要があるということですか...
UIと処理は分離して欲しい気がするんだが...
エントリーポイントが不明だが、デバッグとかどうすれば良いのか
で、Routerとは少し話がズレるのだが、Next.jsでデバッグ実行とかしたい場合、どうすれば良いのか？
一応、公式のドキュメントによると、
⇧ 上記が正しいとすると、
| No | 項目 | CRA（Create React App） | Next.js（App Router） |
|---|---|---|---|
| 1 | エントリーポイント | src/index.tsx | app/page.tsx |
⇧ という感じになるんかね？
デバッグについては、
⇧ 上記サイト様によりますと、
- サーバーサイド
- クライアントサイド
の区別をしているようなのだけど、どうやって区別しているのか基準が分からん...
公式のドキュメントによると、
- The client refers to the browser on a user’s device that sends a request to a server for your application code. It then turns the response it receives from the server into an interface the user can interact with.
- The server refers to the computer in a data center that stores your application code, receives requests from a client, does some computation, and sends back an appropriate response.
https://nextjs.org/learn/react-foundations/server-and-client-components
⇧ という説明なのだけど、UIと処理がごちゃ混ぜになってるから、区別が付けようが無くない？
Vercelが公開している情報だと、
■Without React Server Compoenets
■With React Server Compoenets
⇧ そもそも、「Client Component」とは言わずに「Without React Server Components」と言っていたりするので、余計にわけが分からないことになっている...
ただ、
Server Actions: React’s first steps into mutability
Within the context of RSCs, Server Actions are functions that you define in an RSC on the server side that you can then pass across the server/client boundary. When a user interacts with your app on the client side, they can directly call Server Actions which will be executed securely on the server side.
https://vercel.com/blog/understanding-react-server-components
⇧ 上記の説明によると、
- React Server Component
「Server Action」を実装している
と言えそうなのですが、「Server Action」はと言うと、
Server Actions
Server Actions allow Client Components to call async functions executed on the server.
⇧ 安定してない、且つ、Reactのバージョン固定が必要とあって、甚だ不安しかないんだが...
When a Server Action is defined with the "use server" directive, your framework will automatically create a reference to the server function, and pass that reference to the Client Component.
⇧ 上記のような関数を実装しているコンポーネントを「React Server Component」と見なせばよいということなんですかね？
何やら、
この文を書いている時点で、React Server Componentsの使用を開始する方法は1つだけであり、それはNext.js 13.4以降で、最新の再設計された「App Router」を使用することです。
この新しい「React Server Components」パラダイムでは、すべてのコンポーネントが、デフォルトで、サーバー・コンポーネントとみなされます。クライアント・コンポーネントについては、「オプトイン」する必要があります。
⇧ とあり、Next.js 13.4からは、デフォルトだと全て「React Server Component」扱いとなるらしい。
ただ、
React Server Components
Server Components are a new type of Component that renders ahead of time, before bundling, in an environment separate from your client app or SSR server.
This separate environment is the “server” in React Server Components. Server Components can run once at build time on your CI server, or they can be run for each request using a web server.
⇧ React単独でも利用できそうではある。
う～む、Next.jsもファジーな部分が多過ぎて辛過ぎる...
どうも、昨今のフロントエンドの思想が理解できんのよね...
柔軟性を求めたが故に、複雑さが増しているのか分からんのだけど、アーキテクチャを図解で整理して欲しいですな...
あと、定義はハッキリさせて欲しいかな...
具体的な実装と定義が紐付かないから、何がOKで何がNGなのかがハッキリしないんよね...
ちなみに、
背景
Next.js に App Router が導入されてから1年近くが経ちました。しかし、未だに App Router を前提として設計のベストプラクティスが定まっておらず、身近なフロントエンドエンジニアはみな「まだプロダクトに取り入れるには考えることが多いよね」という共通認識のまま止まっているような気がしています。
⇧ まさかの本番環境では受け入れがたい説が...
なるほど、フロントエンドを生業とする方からしても、扱いに困る代物だったとは...
やはり、公式のドキュメントがイケてないってことに尽きるんですかね？
Next.jsは独自路線派、RemixはWeb標準に準拠する派
ネットの情報を漁った感じでは、
⇧ Next.jsは、Remixと比べた場合に、
- 「Web 標準」を準拠しないことが多いらしい
- バージョンアップにより不具合が起こる可能性が高い
- Vercel へのデプロイが前提
という懸念がある模様。
「Next.js」は、「Next.js」を利用する開発者を人柱にしてる傾向があるらしいのも、誠に遺憾である。
ただ、Remixにも、ドキュメントの情報量が少ないという難点がありますと。
とは言え、運用・保守のフェーズを考えると、バージョンアップにより不具合が起こる可能性が高い「Next.js」は、爆弾を抱えているような心境で精神衛生上好ましくない気はしますな。
何か「Next.js」ではなく「Remix」を利用した方が良さそうのかしら？
ちなみに、
⇧『Get good at Remix, get good at the web.』という哲学を掲げていたらしいのだけど、
⇧ バージョン 2系ではリンクだけ残っているが、遷移先のページが無くなっており、「Remix technical explanation」に遷移するようになっている。
ネット上の情報によると、
⇧ Remixも過去にやらかしてるっぽい...
フロントエンドのライブラリって破壊的変更が多過ぎる気がしていて、設計が適当なんじゃないか疑惑がありますな...
何と言うか、頻繫にリリースしなくても良いので、しっかり要件を固めて開発して欲しいですな...
あまりにも破壊的変更が多過ぎるからして、もし、アジャイルとかで開発を進めているんなら、ウォーターフォールでの開発にした方が良いんじゃないかね？
ライブラリの利用者（アプリケーション開発者）に負担させ過ぎなんよね...
う～む、結局、
- Next.js
- Remix
のどちらを利用すれば良いのか...
2024年5月時点の情報によると、
⇧ 上記のマトリックス表に、各々のJavaScriptフレームワークで用意されている機能がまとめられている。
フロントエンド、関わりたくないなぁ...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
