Develop Experience Trace
最近上手了 @tanstack/router 之后，一发而不可收拾，感觉其提供的开发体验非常棒。但在部署的时候，发现 @tanstack/start 还在 comming soon, 又切换回 Next.js 开发一个单页面。
使用其中一个的时候，总想着另一个框架好用的特性。记录两点，期望再次遇到的时候，不纠结，直接为场景用到最适配的方案。
使用 tanstack/router 的时候，想的 Next.js 的好#
parellel route，文档中提到了，但对应的内容是 TODO。
同样，对于弹层管理，使用 tanstack 的 route mask + outlet 能够较为清晰的划分职能，但是，携带者页面上下文的情况（进入了子路由），再通过 子路由切换 mask 内容，在一个路由上无法承载了。所以要划分清基于路由的 mask 可使用场景的边界。
这，让我原本设想的，一套路由打极大纵深的情况收敛了。
所以，还是可以设想一些应用场景。做出来交互，使用的。
使用 Next.js 的时候，想 tanstack/router 的好#
route 参数的 type-safe:
- 当前已有的路由的提示
- 当前路径路由的 params
- 自动标准化路由中 search 参数
只这一条，开发体验太重要了，为了处理路由入口页面 initial 过程中的参数，胶水代码很多。之前在公司项目中，为处理 search params 写了较多的前置处理逻辑。现在感觉太零散了，而 tanstack/router 的方案就足够整体。原本认可 Next.js， 是因为它足够原生，基本上直接使用浏览器原生的 API，当然，还有将此特色推行到极致的 remix。但这种特色下，开发体验太不顺畅了，很多方式逻辑都要调整。这样失去了在专门场景下，可以简化的空间。
好想把 tanstack router 的这一套路由 type-safe 逻辑，搞到 next.js 中。或者，作为抽象出通用的 type-safe 方案参考案例。
接下来，试一试 tanstack router + vinxi 的元框架的部署