即刻App年轻人的同好社区
下载
置顶
30 133
悄悄发布下～
Chatbox
25 11
18 10
收到了一杯感谢咖啡😋😋。话说我自己都快忘记写过的这个工具了，但我所有Golang项目都会用到，用过的人也都说好用。我觉得好工具就是这样，够简单、够靠谱，以至于让人忽略它的存在。 github.com
28 01
Chatbox官网的第一版（左）完全是AI生成的，现在最新的第二版（右）是50%人工+50%AI。你更喜欢哪个版本？😁😁 chatboxai.app
5 40
Next.js 最新的 App Router 真的是个大坑。我在周末项目里深度使用后，感觉简直是浪费时间。其实我对新技术是很包容的，但我认为 App Router 带来新特性和开发者代价完全不成正比。
我是一个后端工程师，写前端不多，可能下面很多前端概念的理解有误，希望得到指正。
在框架交互上，最新的 App Router 和原来的 Page Router（也就是 /pages 的方式）完全不一样，可以说是两套完全不同的开发框架。而且 App Router 的成熟度和原来的完全无法比。大家看到后面就能理解我说的话了。
首先，满仓库的 /xx/page.tsx 就不吐槽了，毕竟文件路径的改动已经是最容易接受的了。
让人头疼的是不能随便在组件里使用各类钩子，比如 useRef、useEffect，必须要把整个组件标记 “use client”，但这样组件将在客户端渲染，自然就没办法享受到 SSR 的好处了。这非常不方便，有时候我只想加个很简单的 useEffect，却会直接影响到整个组件的服务端渲染，于是每次我都要把小小的 useEffect 代码抽象成一个无意义的空组件来规避这个问题。
蹩脚的导航库。next/router 似乎被遗弃了，最新的 next/navigation 非常难用。几乎所有的方法都有使用限制，比如获取当前路径的 useParams 只能在 "client component" 中使用。如果我要在 SSR 环节获取当前路径，我只能在 Page 的参数里获得，然后一层层不断传递到下面的组件。试试 Context？同样只能在 “client component” 中使用，也是没办法用在 SSR 环节。那些状态库应该也是如此。
上面说的我在情绪上还能接受，但下面的真的让我无法理解了。
无声的灾难。我在 client component 中使用了 Next.js 框架的一个 useSearchParams 方法。我只是希望获得一个很简单常见的 URL Query 参数。我非常小心地为组件标记了 “use client”，没有任何报错，看上去一切顺利；我还谨慎地在控制台检查了渲染后的 html 资源，没有问题。线上也没有任何问题，我终于又放心了一点。但是我还是谨慎地检查了渲染后的 html 资源，然后我特喵地发现整个页面变成客户端渲染了！报错也没有，开发环境也正常，上线后才出现问题，这我就无法理解了。如果我没有发现这一点，网站的 SEO 就全毁了。话说如果不是为了 SEO，为了服务端渲染，我还用个锤子 Next.js！
我查了半天资料，才知道使用 useSearchParams 方法的组件，外面必须再套一层 <Suspense>，为 “streaming render” 做一层手动标记，否则渲染行为会扩散到整个页面，让整个页面变成客户端渲染……
另外无法理解的是 i18n 的噩梦。在我原来的印象里，我只要在 next.config.js 里配好 i18n 选项，就能基本完成多语言的路由。但我后来发现，App Router 的 i18n 完全是另外一套和原来根本不兼容的玩意儿。
App Router 的 i18n 文档特别简短，让人有种框架搞定一切的错觉，实际上完全相反，而是开发者必须自己搞定一切。App Router 可以说是没有提供任何 i18n 的路由功能，你必须通过 middleware.ts 自行实现。Next.js 只提供了一个非常简陋的 middleware 示例，看上去能工作，但最后发现它根本不靠谱。
如果你和我一样，即配置了 middleware，也配置了 next.config.js，那么你要浪费很多时间才能弄明白这两者根本无法一起工作。文档并没有讲清楚这一点。同时 <Link locale="" /> 这种原来最常见的语言切换导航，在 App Router 官方示例下也是无法工作的。
另一场无声的灾难。我在最后才发现，官方示例的 middleware 会把 sitemap.xml、robots.txt 重定向到 404，简直又是场 SEO 灾难。不得不吐槽一句，不是为了 SEO，我 SSR 个锤子。
如果 App Router 的新特性能够覆盖它所有不成熟的缺点，那么我还是能够认可的，但它似乎没有做到这一点。App Router 一切翻天覆地的变化都是为了 RSC（React Server Components），这个特性让浏览器可以“流式加载”服务端已经渲染好的组件，主要解决的是页面需要加载全部 JS 后用户才能交互的问题。比起原来用 useEffect 异步加载的优化方案，RSC 可以减少一些文件大小。这些都是官方介绍的优势，但我认为这些优势的代价太高了，原因如下：
首先很多业务的页面交互根本就不复杂，比如 landing page、博客之类的 CMS。我能想象到需要 RSC 的地方，可能是那些复杂的管理后台和在线应用，但这些地方用原来的 useEffect 异步加载也能解决问题。即使有充足的理由选择 RSC，要实现理论效果，你也需要花很大力气用 <Suspense /> 充分且正确的进行模块分割。最后，虽然你得到了一个“流式渲染”的初始页面，但你的页面依然需要加载那些服务器已经执行过的 JS 代码来实现翻页之类的常规操作……
因此总体来看，我认为目前直接采用 App Router 这种不那么成熟的方案，在新特性收益和开发者代价上根本就不划算。也许未来的发展会改变我的想法，也许我的想法也是错的……但我也在前端圈子里见识了太多过度设计和优化……
我是一个后端工程师，写前端不多，可能下面很多前端概念的理解有误，希望得到指正。
在框架交互上，最新的 App Router 和原来的 Page Router（也就是 /pages 的方式）完全不一样，可以说是两套完全不同的开发框架。而且 App Router 的成熟度和原来的完全无法比。大家看到后面就能理解我说的话了。
首先，满仓库的 /xx/page.tsx 就不吐槽了，毕竟文件路径的改动已经是最容易接受的了。
让人头疼的是不能随便在组件里使用各类钩子，比如 useRef、useEffect，必须要把整个组件标记 “use client”，但这样组件将在客户端渲染，自然就没办法享受到 SSR 的好处了。这非常不方便，有时候我只想加个很简单的 useEffect，却会直接影响到整个组件的服务端渲染，于是每次我都要把小小的 useEffect 代码抽象成一个无意义的空组件来规避这个问题。
蹩脚的导航库。next/router 似乎被遗弃了，最新的 next/navigation 非常难用。几乎所有的方法都有使用限制，比如获取当前路径的 useParams 只能在 "client component" 中使用。如果我要在 SSR 环节获取当前路径，我只能在 Page 的参数里获得，然后一层层不断传递到下面的组件。试试 Context？同样只能在 “client component” 中使用，也是没办法用在 SSR 环节。那些状态库应该也是如此。
上面说的我在情绪上还能接受，但下面的真的让我无法理解了。
无声的灾难。我在 client component 中使用了 Next.js 框架的一个 useSearchParams 方法。我只是希望获得一个很简单常见的 URL Query 参数。我非常小心地为组件标记了 “use client”，没有任何报错，看上去一切顺利；我还谨慎地在控制台检查了渲染后的 html 资源，没有问题。线上也没有任何问题，我终于又放心了一点。但是我还是谨慎地检查了渲染后的 html 资源，然后我特喵地发现整个页面变成客户端渲染了！报错也没有，开发环境也正常，上线后才出现问题，这我就无法理解了。如果我没有发现这一点，网站的 SEO 就全毁了。话说如果不是为了 SEO，为了服务端渲染，我还用个锤子 Next.js！
我查了半天资料，才知道使用 useSearchParams 方法的组件，外面必须再套一层 <Suspense>，为 “streaming render” 做一层手动标记，否则渲染行为会扩散到整个页面，让整个页面变成客户端渲染……
另外无法理解的是 i18n 的噩梦。在我原来的印象里，我只要在 next.config.js 里配好 i18n 选项，就能基本完成多语言的路由。但我后来发现，App Router 的 i18n 完全是另外一套和原来根本不兼容的玩意儿。
App Router 的 i18n 文档特别简短，让人有种框架搞定一切的错觉，实际上完全相反，而是开发者必须自己搞定一切。App Router 可以说是没有提供任何 i18n 的路由功能，你必须通过 middleware.ts 自行实现。Next.js 只提供了一个非常简陋的 middleware 示例，看上去能工作，但最后发现它根本不靠谱。
如果你和我一样，即配置了 middleware，也配置了 next.config.js，那么你要浪费很多时间才能弄明白这两者根本无法一起工作。文档并没有讲清楚这一点。同时 <Link locale="" /> 这种原来最常见的语言切换导航，在 App Router 官方示例下也是无法工作的。
另一场无声的灾难。我在最后才发现，官方示例的 middleware 会把 sitemap.xml、robots.txt 重定向到 404，简直又是场 SEO 灾难。不得不吐槽一句，不是为了 SEO，我 SSR 个锤子。
如果 App Router 的新特性能够覆盖它所有不成熟的缺点，那么我还是能够认可的，但它似乎没有做到这一点。App Router 一切翻天覆地的变化都是为了 RSC（React Server Components），这个特性让浏览器可以“流式加载”服务端已经渲染好的组件，主要解决的是页面需要加载全部 JS 后用户才能交互的问题。比起原来用 useEffect 异步加载的优化方案，RSC 可以减少一些文件大小。这些都是官方介绍的优势，但我认为这些优势的代价太高了，原因如下：
首先很多业务的页面交互根本就不复杂，比如 landing page、博客之类的 CMS。我能想象到需要 RSC 的地方，可能是那些复杂的管理后台和在线应用，但这些地方用原来的 useEffect 异步加载也能解决问题。即使有充足的理由选择 RSC，要实现理论效果，你也需要花很大力气用 <Suspense /> 充分且正确的进行模块分割。最后，虽然你得到了一个“流式渲染”的初始页面，但你的页面依然需要加载那些服务器已经执行过的 JS 代码来实现翻页之类的常规操作……
因此总体来看，我认为目前直接采用 App Router 这种不那么成熟的方案，在新特性收益和开发者代价上根本就不划算。也许未来的发展会改变我的想法，也许我的想法也是错的……但我也在前端圈子里见识了太多过度设计和优化……
12 92
