体验 @tanstack/router 发现它不简单 —— 帮我给 Next.js ‘祛魅’了。
此前我觉得 Next.js 非常成熟了，从 fullstack 的设计上，无能出其右了。但阅读 @tanstack/router 的文档，感觉世界依然很开阔。
文档中给了 stackblitz 例子，非常全面。但直到我真的实践项目代码和页面的时候，想找最佳实践范例的时候，才知道它提供的例子是多好。
上次感受到 example 好，是 n 年前看到 webpack 官方仓库有 examples，next.js 有 examples，plasmo 有 examples，有非常多的 with-xxx 示例。
这次感觉到 example 好，是因为一直以来想找一些 realworld 的项目，具体实践。其一满足平时接收到的说法，各种场景都很常见，那就应该有一个例子可以收束全部的场景。
开始写代码遇到的困难
我开始实践，感受到的困难是，两个技术结合的时候，似乎非常灵活，我选不出来最好的方式，用最基础的方式结合了（在一个文件中，把相应的胶水代码都粘好），接下来好想还有无尽的优化，比如要频繁使用的代码抽取公共file，保持单例复用。有多了几层传入参数的位置，要做好划分。这就成了我事先想不到的，或者，接触到之后，会陷入其中的工作。最期望找到一个最佳实践。
现在，我还没看完就感受到的最佳实践它来了。
一起来看 Ktichen Sink Example
功能体验
-
一个演示参数的控制面板，深得我心。全都是直接影响脚手架，页面切换表现的关键参数。
-
场景列表：
- 基础：登录/未登录，layout，lazy，nested router
- 隐藏基础：url 参数对应的 store 逻辑；param 序列化；param -> deps -> loader 处理
- 交互：路由的 loader pending 状态处理；Created 状态处理
- 深层交互：链接预加载
代码细节 —— 技术点结合方式
阅读一遍，类似把官方文档的内容复述一遍，但内容是自己创建和表达的。不省略，不直接复制，就是有收获的。
- auth
加载顺序 - beforeLoad 中添加跳转逻辑；
添加 context， 用于依赖注入，避免子路由中频繁导入，所以 context 也要克制，避免加入巨大的 chunk；
从 api 设计上，事件周期环节分层，根据要兼顾的场景拆分。理论上可自由无限扩充，但极为克制且成功的，才能成为能流行的框架
遗留问题：login 按钮的 loading 如何处理？同样还有 logout 的？登录成功后，调用 invalidate，依赖 loader 中检测已经登录，跳转到登录后默认界面的逻辑
- layout
- 基于文件名或文件夹 _layout 前缀，或 _layout.route.tsx
- 此处，把常规的 `` == `./index` 细分了，变为 [ `` == `/route` | `../[文件夹同名文件]` , `/` == `/index` ]
- data-loader with @tanstack/query
我的简单设想 —— 在组件代码中，添加 useQuery, 与常规使用无异。
打破设想 —— 自带的 loader 与这个不相符，也无法把 query 的状态传到当前的 router 中，另外 context 是一个统一的 inject 位置，没有给每一层 router 划分独立空间。
kitchen-sink 的做法：将 queryClient 放置到 context 中，loader 中使用 queryClient 的 ensureQueryData，组件中，使用 useQuery 设置相同的 option，获取同一份数据。 - data-loader 的状态处理
提供了<MatchRoute />组件，有点儿不符合我的直觉。其参数是 filter 参数，导致我以为是 settle 参数。我的习惯一般是使用 useXXX 判断。但这里提供了组件，通过函数式的 children 方式响应变化。 - dataMutation within @tanstack/query
与 @tanstack/query 的 useMutation 一致，没有结合使用的新用法。
第一遍已经读完。祛魅一部分。现在，实践一部分，看看是否有不清楚的。如果有，就再继续记录。
