開発体験を追跡
最近、@tanstack/router を使い始めてから、その便利さに魅了されています。ただ、@tanstack/start がまだ coming soon であることに気づき、Next.js に切り替えて単一ページを開発しました。
どちらかを使っているとき、常に他のフレームワークの使いやすい機能を考えてしまいます。2 つのポイントを記録して、再び出会ったときに迷わず、シーンに最適なソリューションを直接適用できるようにします。
tanstack/router を使用するとき、Next.js の良さを考える#
parellel route はドキュメントで言及されていますが、対応する内容は TODO です。
同様に、ポップアップ管理について、tanstack の route mask + outlet を使用すると、機能を明確に区別できますが、ページのコンテキストを持つ場合（サブルートに入る）、サブルートを切り替えても mask 内のコンテンツを 1 つのルートで保持できません。したがって、ルートベースの mask の使用シナリオの境界を明確に区別する必要があります。
これにより、最初に考えていた、深い階層のルートを持つシナリオが収束しました。
したがって、いくつかのアプリケーションシナリオを考えることができます。インタラクションを作成し、使用します。
Next.js を使用するとき、tanstack/router の良さを考える#
route パラメータの型安全性：
- 現在のルートのヒント
- 現在のパスのルートのパラメータ
- ルート内の検索パラメータの自動標準化
この 1 つだけでも、開発体験は非常に重要です。ルート入口ページの初期プロセス中にパラメータを処理するために、多くの接着剤コードが必要です。以前は会社のプロジェクトで、検索パラメータを処理するために多くの前処理ロジックを書いていました。今ではそれが非常に散らかっていると感じますが、tanstack/router のソリューションは十分に統合されています。元々Next.js を評価していたのは、それが十分にネイティブであり、基本的にブラウザのネイティブ API を直接使用しているからです。もちろん、この特徴を極限まで推し進めた remix もあります。しかし、この特徴の下では、開発体験が非常にスムーズではなく、多くの方法論を調整する必要があります。これにより、特定のシナリオで簡素化できるスペースが失われます。
tanstack router のこの型安全性ロジックを Next.js に取り込みたいと思います。または、汎用の型安全なソリューションの参考例として抽象化することも考えています。
次に、tanstack router + vinxi のメタフレームワークのデプロイを試してみます。