文章主要探讨了在使用 React 进行服务端渲染时可能遇到的“重渲染”问题，特别是在生产环境下可能会出现的一些意料之外的行为。作者通过分享个人经历，揭示了对 React 服务端渲染过程中的一些误解，并提供了避免这些问题的解决方案。
关键点列表：
1. 💡 开发环境下一切正常，但生产环境中博客底部出现了意外行为，暗示了 React 组件在错误的位置渲染的问题。
2. 🌐 作者发现自己对 React 在服务端渲染环境中的工作方式有根本性的误解，这是许多 React 开发者共有的误区。
3. 🚀 文章举例说明了可能导致渲染问题的代码，指出了许多开发者可能忽视的问题点。
4. 📚 介绍了 Gatsby 和 Next.js 等框架与传统客户端 React 应用的区别，以及服务端渲染（SSR）和客户端渲染的概念。
5. 🎯 提到了静态站点生成（SSG）的概念，解释了它是如何在构建时生成 HTML 文档，以加快 React 应用的加载速度。
6. 🔄 探讨了“水合”（hydration）过程，即客户端 JavaScript 如何构建页面并与服务端渲染的 HTML 文档进行比较。
7. ❗️ 强调了在服务端渲染和客户端“水合”过程中保持 DOM 结构一致性的重要性，以避免渲染不匹配的问题。
8. 🛠 提供了一种解决方案，通过使用 `useEffect` 钩子和 `hasMounted` 状态来管理动态内容的渲染，确保在客户端渲染完成后正确显示内容。
9. 📈 分享了“两阶段渲染”（two-pass rendering）的概念，以及如何通过客户端状态管理来处理动态数据。
#前端 #React #服务端组件
https://www.joshwcomeau.com/react/the-perils-of-rehydration/
中文版：
https://sorrycc.com/danger-rehydration/
关键点列表：
1. 💡 开发环境下一切正常，但生产环境中博客底部出现了意外行为，暗示了 React 组件在错误的位置渲染的问题。
2. 🌐 作者发现自己对 React 在服务端渲染环境中的工作方式有根本性的误解，这是许多 React 开发者共有的误区。
3. 🚀 文章举例说明了可能导致渲染问题的代码，指出了许多开发者可能忽视的问题点。
4. 📚 介绍了 Gatsby 和 Next.js 等框架与传统客户端 React 应用的区别，以及服务端渲染（SSR）和客户端渲染的概念。
5. 🎯 提到了静态站点生成（SSG）的概念，解释了它是如何在构建时生成 HTML 文档，以加快 React 应用的加载速度。
6. 🔄 探讨了“水合”（hydration）过程，即客户端 JavaScript 如何构建页面并与服务端渲染的 HTML 文档进行比较。
7. ❗️ 强调了在服务端渲染和客户端“水合”过程中保持 DOM 结构一致性的重要性，以避免渲染不匹配的问题。
8. 🛠 提供了一种解决方案，通过使用 `useEffect` 钩子和 `hasMounted` 状态来管理动态内容的渲染，确保在客户端渲染完成后正确显示内容。
9. 📈 分享了“两阶段渲染”（two-pass rendering）的概念，以及如何通过客户端状态管理来处理动态数据。
#前端 #React #服务端组件
https://www.joshwcomeau.com/react/the-perils-of-rehydration/
中文版：
https://sorrycc.com/danger-rehydration/
Joshwcomeau
The Perils of Hydration: Understanding how server-side rendering really works in React • Josh W. Comeau
A surprisingly-common misconception can lead to big rendering issues that are difficult to debug. This deep-dive tutorial examines how React and Gatsby can be used to pre-render content, and how we can work around the constraints to build dynamic, personalized…
2024 React Conf - 2024 年 5 月 15 日至 16 日
免费在线直播，聆听 React 团队、你最喜爱的社区成员以及新面孔的分享。
与 Joe、Mofei、Sathya 和 Lauren 一起登上舞台。
与社区分享你独特的视角、经历和热情。
演讲嘉宾：
Joe Savona, Meta 工程师
Mofei Zhang, Meta 工程师
Lauren Tan, Meta 工程师
Sathya Gunasekaran, Meta 工程师
Riccardo Cipolleschi, Meta 工程师
Nicola Corti, Meta 工程师
#React #前端
https://conf.react.dev/
免费在线直播，聆听 React 团队、你最喜爱的社区成员以及新面孔的分享。
与 Joe、Mofei、Sathya 和 Lauren 一起登上舞台。
与社区分享你独特的视角、经历和热情。
演讲嘉宾：
Joe Savona, Meta 工程师
Mofei Zhang, Meta 工程师
Lauren Tan, Meta 工程师
Sathya Gunasekaran, Meta 工程师
Riccardo Cipolleschi, Meta 工程师
Nicola Corti, Meta 工程师
#React #前端
https://conf.react.dev/
conf.react.dev
React Conf 2025 | October 7-8 | Henderson, Nevada & online | Join us!
《HTMX vs React：完整比较》
详细比较了 HTMX 和 React ，两种前端开发技术的不同点。文中讨论了 HTMX 的目标是直接在 HTML 中提供现代浏览器交互性，而无需 JavaScript，这一点与 React 有着显著不同。
总览 ：
- HTMX 发展迅速，在 2023 JavaScript 星光大奖“前端框架”类别中获得第二名。
- HTMX 项目在 GitHub 上获超过 20,000 星，入选 GitHub Accelerator。
比较 ：
- HTMX 由 Big Sky Software 开发，以 HTML 为基础，致力于简化开发流程。
- React 由 Meta 开发，并以 JSX 为基础，提供了一个基于组件的全功能 UI JavaScript 库。
性能 & 特性 ：
- HTMX 专注于简约性，轻量级（2.9 kB），而 React 较为重量级（6.4 kB）但功能全面，适用于大型应用。
- HTMX 着力于通过自定义属性来简化 AJAX 请求等操作，React 则提供了一系列高级特性，包括状态管理和钩子。
社区 & 生态系统 ：
- HTMX 拥有一个正在增长的小型社区，而 React 拥有市场上最大的社区及丰富的生态系统。
HTMX 的主要优势 ：
- 使用特殊 HTML 属性而无需写 JavaScript。
- 对现有 HTML 页面具有高度的集成性。
- 对于简单交互的项目来说是轻量级和高效的选择。
- 适合后端开发者提供交互式 HTML 页面。
React 的主要优势 ：
- 结构化 UI 的可重用组件使得网站的维护和重用变得简单。
- 适合构建提供丰富用户体验和处理复杂状态的单页应用程序。
- 吸引了大型团队跨项目共享 UI 组件。
这篇文章为开发者提供了在两个库之间做出明智选择的见解，并指出 HTMX 并非要取代 React，它们各有适用场景并可以共存。
#前端 #React #HTMX
https://semaphoreci.com/blog/htmx-react
详细比较了 HTMX 和 React ，两种前端开发技术的不同点。文中讨论了 HTMX 的目标是直接在 HTML 中提供现代浏览器交互性，而无需 JavaScript，这一点与 React 有着显著不同。
总览 ：
- HTMX 发展迅速，在 2023 JavaScript 星光大奖“前端框架”类别中获得第二名。
- HTMX 项目在 GitHub 上获超过 20,000 星，入选 GitHub Accelerator。
比较 ：
- HTMX 由 Big Sky Software 开发，以 HTML 为基础，致力于简化开发流程。
- React 由 Meta 开发，并以 JSX 为基础，提供了一个基于组件的全功能 UI JavaScript 库。
性能 & 特性 ：
- HTMX 专注于简约性，轻量级（2.9 kB），而 React 较为重量级（6.4 kB）但功能全面，适用于大型应用。
- HTMX 着力于通过自定义属性来简化 AJAX 请求等操作，React 则提供了一系列高级特性，包括状态管理和钩子。
社区 & 生态系统 ：
- HTMX 拥有一个正在增长的小型社区，而 React 拥有市场上最大的社区及丰富的生态系统。
HTMX 的主要优势 ：
- 使用特殊 HTML 属性而无需写 JavaScript。
- 对现有 HTML 页面具有高度的集成性。
- 对于简单交互的项目来说是轻量级和高效的选择。
- 适合后端开发者提供交互式 HTML 页面。
React 的主要优势 ：
- 结构化 UI 的可重用组件使得网站的维护和重用变得简单。
- 适合构建提供丰富用户体验和处理复杂状态的单页应用程序。
- 吸引了大型团队跨项目共享 UI 组件。
这篇文章为开发者提供了在两个库之间做出明智选择的见解，并指出 HTMX 并非要取代 React，它们各有适用场景并可以共存。
#前端 #React #HTMX
https://semaphoreci.com/blog/htmx-react
Semaphore
HTMX vs React: A Complete Comparison - Semaphore
This guide compares HTMX and React, covering origins, features, performance, community, and functionality differences.
❤1
《JavaScript 按需加载：Qwik 如何不同于 React 的 Hydration》
作者 Paul Scanlon 探讨了 Qwik 的恢复性（resumability），这是 Qwik 解决客户端 JavaScript 问题的方法，并详细解释了它与 React 的不同。
文章主要内容 ：
- 客户端 JavaScript 面临的问题和 Qwik 的解决方案。
- React 的 Hydration（客户端重新活化）如何工作，通过类比“倒下多余的啤酒”来解释 React 常导致的浪费。
- Qwik 通过询问用户需求然后精准提供服务的方式，类比于在酒吧根据顾客需求逐个提供啤酒，说明了 Qwik 的恢复性工作方式。
- Qwik 的 JavaScript 按需加载与其恢复性原则，以及如何实现仅在需要时才加载代码段，从而优化应用性能。
- 介绍了 Qwik 的 Service Worker 如何改进应用代码加载。
- 提供了一个实例，说明了 Qwik 是如何智能加载必要的代码段并提高性能的。
Qwik 的特点 ：
- 更精细的 JavaScript 代码切分，可生成更小的代码块。
- 恢复性原则，确保只有用户需要时才加载和执行特定的代码。
- 强调使用 Service Worker 来提高应用性能，减少主线程的负担。
React 的挑战 ：
- 重现全部应用状态使用时间长、带宽高。
- 客户端激活（Hydration）可能导致不必要的复杂度和性能问题。
Qwik vs React ：
- Qwik 专注于仅在必要时加载交互性的 JavaScript，而 React 的应用通常在加载时就需要所有 JavaScript。
- Qwik 以性能优化为核心，而 React 需要在代码切分和懒加载技术上多费工夫。
最终思考 ：
- 通过恢复性原则，Qwik 提供了一个节省资源和提升用户体验的方法，仅加载和执行必要的代码。
- Qwik 正在改变开发者构建交互式 web 应用的思维模式，使其变得更加智能和高效。
这篇文章向开发者提供了一个不同于常规 React 应用激活方法的新思路，即 Qwik 的恢复性，并深挖了它如何有效地减少不必要的加载和执行，从而提高性能和用户体验。
#前端 #Qwik #React
https://thenewstack.io/javascript-on-demand-how-qwik-differs-from-react-hydration/
作者 Paul Scanlon 探讨了 Qwik 的恢复性（resumability），这是 Qwik 解决客户端 JavaScript 问题的方法，并详细解释了它与 React 的不同。
文章主要内容 ：
- 客户端 JavaScript 面临的问题和 Qwik 的解决方案。
- React 的 Hydration（客户端重新活化）如何工作，通过类比“倒下多余的啤酒”来解释 React 常导致的浪费。
- Qwik 通过询问用户需求然后精准提供服务的方式，类比于在酒吧根据顾客需求逐个提供啤酒，说明了 Qwik 的恢复性工作方式。
- Qwik 的 JavaScript 按需加载与其恢复性原则，以及如何实现仅在需要时才加载代码段，从而优化应用性能。
- 介绍了 Qwik 的 Service Worker 如何改进应用代码加载。
- 提供了一个实例，说明了 Qwik 是如何智能加载必要的代码段并提高性能的。
Qwik 的特点 ：
- 更精细的 JavaScript 代码切分，可生成更小的代码块。
- 恢复性原则，确保只有用户需要时才加载和执行特定的代码。
- 强调使用 Service Worker 来提高应用性能，减少主线程的负担。
React 的挑战 ：
- 重现全部应用状态使用时间长、带宽高。
- 客户端激活（Hydration）可能导致不必要的复杂度和性能问题。
Qwik vs React ：
- Qwik 专注于仅在必要时加载交互性的 JavaScript，而 React 的应用通常在加载时就需要所有 JavaScript。
- Qwik 以性能优化为核心，而 React 需要在代码切分和懒加载技术上多费工夫。
最终思考 ：
- 通过恢复性原则，Qwik 提供了一个节省资源和提升用户体验的方法，仅加载和执行必要的代码。
- Qwik 正在改变开发者构建交互式 web 应用的思维模式，使其变得更加智能和高效。
这篇文章向开发者提供了一个不同于常规 React 应用激活方法的新思路，即 Qwik 的恢复性，并深挖了它如何有效地减少不必要的加载和执行，从而提高性能和用户体验。
#前端 #Qwik #React
https://thenewstack.io/javascript-on-demand-how-qwik-differs-from-react-hydration/
The New Stack
JavaScript on Demand: How Qwik Differs From React Hydration
Paul Scanlon explains resumability, Qwik’s approach to solving the beastly client-side JavaScript problem, and how it differs from React.
React Server Components （RSC）是一个对 React 生态系统至关重要的新变化，它为解决客户端渲染（CSR）和服务端渲染（SSR）的问题提出了新的解决方案，以下是其概要：
React 渲染的进化和挑战
1. React 经历了十年的不断进化，每个版本都引入新概念、优化和有时的范式转移。
2. RSC 是自 React hooks 以来最显著的变化之一，社区对此反应不一。
客户端渲染（CSR）的优点与挑战
1. CSR 是构建单页应用（SPA）的标准方法，其中浏览器下载、解析和执行 JavaScript，然后渲染内容。
2. CSR 存在 SEO 不友好和初始加载时间长的问题，对于互联网连接慢的用户尤为明显。
服务端渲染（SSR）的优点与挑战
1. 为克服 CSR 的问题，开发者采用 SSR，页面内容在服务器渲染后发送至浏览器，提升初始加载时间和 SEO。
2. 但 SSR 存在不足，如无法进行“暂停渲染”和完整的页面 JavaScript 必须在客户端加载。
为 SSR 引入的 Suspense
React 18 引入 Suspense for SSR，通过 <Suspense> 组件实现 HTML 的服务器流式传输和客户端的选择性水合（hydration）。
HTML 服务器流式传输
利用 <Suspense> ，服务器不必等待数据准备就绪即可开始向客户端流式传输HTML。
客户端选择性水合
1. <Suspense> 允许在某些部分的代码载入并执行之后，逐渐使页面区块变得可以交互。
影响与优化
1. RSC 在首次页面加载、首次内容绘制（FCP）和 SEO 方面带来显著改进。
2. 允许服务器端的渲染结果缓存，在不同请求间重复利用，减少每次请求的渲染和数据获取需求。
RSC 的挑战
1. RSC 仍需下载整个网页的代码，引发问题：用户是否确实需要下载那么多数据？
2. 所有 React 组件都必须在客户端进行水合，即使它们不需要交互。
3. 很多工作仍在用户设备上执行，对不够强大的设备而言可能有性能问题。
RSC 架构细节
1. 使用“use client”指令来标记客户端组件，“use server”指令来标记可从客户端调用的服务端函数。
2. React 应用通过 RSC 架构利用客户端和服务器渲染的最佳特性，同时使用统一的语言、框架和一致的 API。
#前端 #React #RSC
https://www.builder.io/blog/why-react-server-components
React 渲染的进化和挑战
1. React 经历了十年的不断进化，每个版本都引入新概念、优化和有时的范式转移。
2. RSC 是自 React hooks 以来最显著的变化之一，社区对此反应不一。
客户端渲染（CSR）的优点与挑战
1. CSR 是构建单页应用（SPA）的标准方法，其中浏览器下载、解析和执行 JavaScript，然后渲染内容。
2. CSR 存在 SEO 不友好和初始加载时间长的问题，对于互联网连接慢的用户尤为明显。
服务端渲染（SSR）的优点与挑战
1. 为克服 CSR 的问题，开发者采用 SSR，页面内容在服务器渲染后发送至浏览器，提升初始加载时间和 SEO。
2. 但 SSR 存在不足，如无法进行“暂停渲染”和完整的页面 JavaScript 必须在客户端加载。
为 SSR 引入的 Suspense
React 18 引入 Suspense for SSR，通过 <Suspense> 组件实现 HTML 的服务器流式传输和客户端的选择性水合（hydration）。
HTML 服务器流式传输
利用 <Suspense> ，服务器不必等待数据准备就绪即可开始向客户端流式传输HTML。
客户端选择性水合
1. <Suspense> 允许在某些部分的代码载入并执行之后，逐渐使页面区块变得可以交互。
影响与优化
1. RSC 在首次页面加载、首次内容绘制（FCP）和 SEO 方面带来显著改进。
2. 允许服务器端的渲染结果缓存，在不同请求间重复利用，减少每次请求的渲染和数据获取需求。
RSC 的挑战
1. RSC 仍需下载整个网页的代码，引发问题：用户是否确实需要下载那么多数据？
2. 所有 React 组件都必须在客户端进行水合，即使它们不需要交互。
3. 很多工作仍在用户设备上执行，对不够强大的设备而言可能有性能问题。
RSC 架构细节
1. 使用“use client”指令来标记客户端组件，“use server”指令来标记可从客户端调用的服务端函数。
2. React 应用通过 RSC 架构利用客户端和服务器渲染的最佳特性，同时使用统一的语言、框架和一致的 API。
#前端 #React #RSC
https://www.builder.io/blog/why-react-server-components
Builder.io
What are React Server Components? Understanding the Future of React Apps
Learn what are React Server Components (RSC) and how they leverage both server and client strengths, optimize efficiency, load times, and interactivity.
❤3
Million Dev 宣布 Million Lint 进入公开测试阶段，它是一个 VSCode 扩展，旨在维持 React 网站的快速性能。Million Lint 能够识别代码中可能导致性能下降的部分，并提供优化建议。
#React #前端 #性能优化
https://million.dev/blog/lint
#React #前端 #性能优化
https://million.dev/blog/lint
RedwoodJS Bighorn 预览版带来了对 React Server Components (RSC) 和服务器端渲染 (SSR) 的支持，这将大大改变使用 Redwood 构建应用程序的方式。Tobbe 和他的团队自 2023 年 7 月以来一直在努力开发 RSC，并已经做好了让大家试用并反馈的准备。文章中将通过一个从 GraphQL 转移到 RSC 的示范应用程序，说明要进行的改动实际上非常少。
转向 RSC 的主要原因是，尽管 Redwood 一开始全力支持 GraphQL，但发现从零开始使用 GraphQL 在早期就会带来相当大的心理和逻辑负担。并且，在快速调整大型应用程序的结构同时保持敏捷性方面，GraphQL 可能并不是最佳选择。
关于 GraphQL，存在以下担忧：
- 开发者生产力：作为一项必须掌握的新技术，GraphQL 在项目开始时增加了很多额外的开销。
- 安全性：当暴露 GraphQL API 时，需要认真考虑如何保护数据访问的安全性。
- 性能：GraphQL 实现可能很容易陷入 N+1 问题，查询周期问题和查询深度限制。
因此，Redwood 决定默认使用 RSC，它现在将是框架中的默认设置。Redwood 仍然支持 GraphQL，并且将提供一个简单的设置命令，以便在开发到一定阶段后，如果想要使用 GraphQL 或想要提供 API 给其他人，你可以轻松地将其加入到应用程序中。
RSC 改变了我们对基于 React 的 Web 应用程序的理解。它通过剔除传统红木应用程序中数据流动中的一些步骤，简化了流程。没有了单独的 “api” 服务器，只有一个“web”服务器负责返回初始的 JS 文件，处理 RSC 组件和数据的请求。
文章还详细介绍了将传统 Redwood 应用迁移到使用 RSC 所需的改变。对于 RedwoodJS 构建的经典应用程序的服务器单元（如 Cell），你只需更改一个函数，即用 data() 函数替换 GraphQL 查询。这个 data() 函数返回的任何内容都会提供给 <Success> 组件。
关于 RSC 的 "Flight" 格式，它不是返回给浏览器的 HTML，而是一种 React 称为 Flight 的纯文本格式。它有点像 JSON 中的 JSX，React（在客户端）知道如何将其转换回 HTML 并更新 DOM。
对于那些将服务移到 web/src/services 但位置尚未确定的应用程序，Redwood 团队正在考虑将它们放置在与 web 同级的 db 或 data 目录下。此外，该版本暂时还无法支持 RSC，因为 dev server 尚不兼容 RSC，因此每次代码更改后都需要从头开始构建和服务应用程序。
#前端 #React
https://redwoodjs.com/blog/rsc-now-in-redwoodjs
转向 RSC 的主要原因是，尽管 Redwood 一开始全力支持 GraphQL，但发现从零开始使用 GraphQL 在早期就会带来相当大的心理和逻辑负担。并且，在快速调整大型应用程序的结构同时保持敏捷性方面，GraphQL 可能并不是最佳选择。
关于 GraphQL，存在以下担忧：
- 开发者生产力：作为一项必须掌握的新技术，GraphQL 在项目开始时增加了很多额外的开销。
- 安全性：当暴露 GraphQL API 时，需要认真考虑如何保护数据访问的安全性。
- 性能：GraphQL 实现可能很容易陷入 N+1 问题，查询周期问题和查询深度限制。
因此，Redwood 决定默认使用 RSC，它现在将是框架中的默认设置。Redwood 仍然支持 GraphQL，并且将提供一个简单的设置命令，以便在开发到一定阶段后，如果想要使用 GraphQL 或想要提供 API 给其他人，你可以轻松地将其加入到应用程序中。
RSC 改变了我们对基于 React 的 Web 应用程序的理解。它通过剔除传统红木应用程序中数据流动中的一些步骤，简化了流程。没有了单独的 “api” 服务器，只有一个“web”服务器负责返回初始的 JS 文件，处理 RSC 组件和数据的请求。
文章还详细介绍了将传统 Redwood 应用迁移到使用 RSC 所需的改变。对于 RedwoodJS 构建的经典应用程序的服务器单元（如 Cell），你只需更改一个函数，即用 data() 函数替换 GraphQL 查询。这个 data() 函数返回的任何内容都会提供给 <Success> 组件。
关于 RSC 的 "Flight" 格式，它不是返回给浏览器的 HTML，而是一种 React 称为 Flight 的纯文本格式。它有点像 JSON 中的 JSX，React（在客户端）知道如何将其转换回 HTML 并更新 DOM。
对于那些将服务移到 web/src/services 但位置尚未确定的应用程序，Redwood 团队正在考虑将它们放置在与 web 同级的 db 或 data 目录下。此外，该版本暂时还无法支持 RSC，因为 dev server 尚不兼容 RSC，因此每次代码更改后都需要从头开始构建和服务应用程序。
#前端 #React
https://redwoodjs.com/blog/rsc-now-in-redwoodjs
❤1
10 种方法来更好地组织和设计 React 应用程序，以提高代码的可维护性和可扩展性。
其中第 6 点个人不是很认同，在一个庞大的项目过渡使用绝对路径的话会导致各个业务模块之间耦合严重、互相引用等问题（不同版本间的开发人员能力问题），完全靠人来遵守，如果想单独重构某个模块将会变得非常痛苦。🤣
1. 按领域责任分组组件：避免仅按技术角色分组，而应按页面或模块的领域责任组织文件和文件夹。
2. 将组件放入文件夹：对于复杂组件，应将其子组件组织到单独的文件夹中。
3. 使用绝对路径：使用绝对路径可以简化项目导航和维护，特别是在项目规模扩大时。
4. 使用公共模块：避免在项目中不同位置散布通用工具和组件，应集中存储以提高管理和重用性。
5. 抽象外部库和模块：通过自定义组件包装第三方库或模块，以保持应用内一致的 API 并简化未来的替换工作。
6. 管理模块/页面间的依赖关系：集中常用资源到共享的公共模块中，减少代码重复，明确模块和页面的依赖。
7. 保持代码靠近使用地点（LoB）：根据行为局部性原则，将代码组织得更接近其在应用中的使用位置，以提高可
读性和可维护性。
8. 小心使用工具函数：工具函数应保持纯净和特定目的，避免与业务逻辑混合，以提高可重用性。
9. 小心处理业务逻辑：避免将业务逻辑直接集成到 UI 组件中，应使用自定义钩子将业务逻辑与 UI 分离。
10. 固定依赖版本：在 package.json 中指定确切的依赖版本，而不是使用版本范围，以确保项目中使用的是完全相同的包版本。
#React
https://thetshaped.dev/p/10-ways-organize-and-design-react-application
其中第 6 点个人不是很认同，在一个庞大的项目过渡使用绝对路径的话会导致各个业务模块之间耦合严重、互相引用等问题（不同版本间的开发人员能力问题），完全靠人来遵守，如果想单独重构某个模块将会变得非常痛苦。🤣
1. 按领域责任分组组件：避免仅按技术角色分组，而应按页面或模块的领域责任组织文件和文件夹。
2. 将组件放入文件夹：对于复杂组件，应将其子组件组织到单独的文件夹中。
3. 使用绝对路径：使用绝对路径可以简化项目导航和维护，特别是在项目规模扩大时。
4. 使用公共模块：避免在项目中不同位置散布通用工具和组件，应集中存储以提高管理和重用性。
5. 抽象外部库和模块：通过自定义组件包装第三方库或模块，以保持应用内一致的 API 并简化未来的替换工作。
6. 管理模块/页面间的依赖关系：集中常用资源到共享的公共模块中，减少代码重复，明确模块和页面的依赖。
7. 保持代码靠近使用地点（LoB）：根据行为局部性原则，将代码组织得更接近其在应用中的使用位置，以提高可
读性和可维护性。
8. 小心使用工具函数：工具函数应保持纯净和特定目的，避免与业务逻辑混合，以提高可重用性。
9. 小心处理业务逻辑：避免将业务逻辑直接集成到 UI 组件中，应使用自定义钩子将业务逻辑与 UI 分离。
10. 固定依赖版本：在 package.json 中指定确切的依赖版本，而不是使用版本范围，以确保项目中使用的是完全相同的包版本。
#React
https://thetshaped.dev/p/10-ways-organize-and-design-react-application
thetshaped.dev
10 ways to better organize and design your React Application
Learn how to make your React App scale.
如果不是 React，那会是什么？以下是作者个人观点：
在前端开发领域，React 框架正面临越来越多的质疑。Alex Russell 明确指出，React 作为遗留技术，已不再适应现代网络应用的需求。他强调，现代前端开发应重视工程学的勇气，而非依赖不同的工具。React 及其相关的现代前端框架，如 Angular，往往导致性能和可访问性问题，特别是在 React 基础的应用中。
Russell 认为，服务器端代码可以完全成本化，性能和可用性由组织控制，而客户端代码则充满不确定性，因此，有效的策略是减少发送的代码量，优先使用 HTML 和 CSS 而非 JavaScript。他建议，对于大多数网站而言，单页应用（SPA）架构并非必需，应避免使用 React 等框架。
Russell 还提到，对于需要客户端渲染的项目，可以通过客观的比较测试来确定替代技术。他推荐了一系列现代框架，如 Svelte、Lit、FAST、Solid 等，这些框架在初始成本上较低，但仍需严格控制客户端负载和复杂性。
在决策过程中，Russell 强调以用户为中心的重要性。他认为，技术决策应基于用户需求和实际数据，而非流行趋势或框架主义的教条。他提倡使用实际的用户数据来指导技术选择，如通过 RUM 数据和实验室测试结果来衡量系统性能。
Russell 进一步指出，React 的所谓“现代”特性，如虚拟 DOM，实际上从未带来性能上的优势。相反，它引入了额外的工作量和复杂性。他批评 React 文化中的一些做法，如 CSS-in-JS，认为这些做法增加了项目的复杂性和成本。
最后，Russell 建议，对于新项目，应完全禁止使用 React。他鼓励技术领导和管理者基于用户的实际体验和业务目标来选择技术，而不是盲目追随行业标准。通过这种方式，可以避免不必要的技术债务，提高产品的质量和市场竞争力。
#React #前端 #框架
https://infrequently.org/2024/11/if-not-react-then-what/
在前端开发领域，React 框架正面临越来越多的质疑。Alex Russell 明确指出，React 作为遗留技术，已不再适应现代网络应用的需求。他强调，现代前端开发应重视工程学的勇气，而非依赖不同的工具。React 及其相关的现代前端框架，如 Angular，往往导致性能和可访问性问题，特别是在 React 基础的应用中。
Russell 认为，服务器端代码可以完全成本化，性能和可用性由组织控制，而客户端代码则充满不确定性，因此，有效的策略是减少发送的代码量，优先使用 HTML 和 CSS 而非 JavaScript。他建议，对于大多数网站而言，单页应用（SPA）架构并非必需，应避免使用 React 等框架。
Russell 还提到，对于需要客户端渲染的项目，可以通过客观的比较测试来确定替代技术。他推荐了一系列现代框架，如 Svelte、Lit、FAST、Solid 等，这些框架在初始成本上较低，但仍需严格控制客户端负载和复杂性。
在决策过程中，Russell 强调以用户为中心的重要性。他认为，技术决策应基于用户需求和实际数据，而非流行趋势或框架主义的教条。他提倡使用实际的用户数据来指导技术选择，如通过 RUM 数据和实验室测试结果来衡量系统性能。
Russell 进一步指出，React 的所谓“现代”特性，如虚拟 DOM，实际上从未带来性能上的优势。相反，它引入了额外的工作量和复杂性。他批评 React 文化中的一些做法，如 CSS-in-JS，认为这些做法增加了项目的复杂性和成本。
最后，Russell 建议，对于新项目，应完全禁止使用 React。他鼓励技术领导和管理者基于用户的实际体验和业务目标来选择技术，而不是盲目追随行业标准。通过这种方式，可以避免不必要的技术债务，提高产品的质量和市场竞争力。
#React #前端 #框架
https://infrequently.org/2024/11/if-not-react-then-what/
Infrequently Noted
If Not React, Then What?
Over the past decade, my work has centred on partnering with teams to build ambitious products for the web across both desktop and mobile. This has provided a ring-side seat to a sweeping variety of teams, products, and technology stacks across more than…
Eduardo Rodriguez 分享了他为何决定放弃 React，转而选择 Go+HTMX+Templ 作为个人项目的开发技术栈。React 生态系统中的依赖管理让他感到疲惫，尤其是在处理 React 包的更新时，频繁的 API 破坏性变更迫使他不得不花费大量时间重构代码。尽管他希望保持依赖的最新状态以避免安全漏洞，但这些更新并没有给他的 webapp 带来实质性的好处，反而造成了更多的工作量。
Rodriguez 并不是反对开源维护者的工作，但他质疑为何 React 应用中的核心组件需要如此频繁地破坏 API，尤其是在没有带来明显好处的情况下。如果目标是维护一个快乐的用户群体，那么尊重用户宝贵的时间应该是一个重要的优先事项。
由于个人时间有限，他更愿意将时间投入到开发新功能或启动新项目上，而不是处理依赖更新。对于需要最小维护的产品，他建议远离 JavaScript 生态系统。
Rodrigized 认为 Go+HTMX+Templ 能够让他专注于功能交付，同时不需要忽视一般的依赖和安全更新。他赞扬 Go 语言的稳定性，包括其标准库和语言规范。因此，他决定将 Go+HTMX+Templ 作为未来个人项目的首选技术栈。
#React
https://blog.erodriguez.de/dependency-management-fatigue-or-why-i-forever-ditched-react-for-go-htmx-templ/
Rodriguez 并不是反对开源维护者的工作，但他质疑为何 React 应用中的核心组件需要如此频繁地破坏 API，尤其是在没有带来明显好处的情况下。如果目标是维护一个快乐的用户群体，那么尊重用户宝贵的时间应该是一个重要的优先事项。
由于个人时间有限，他更愿意将时间投入到开发新功能或启动新项目上，而不是处理依赖更新。对于需要最小维护的产品，他建议远离 JavaScript 生态系统。
Rodrigized 认为 Go+HTMX+Templ 能够让他专注于功能交付，同时不需要忽视一般的依赖和安全更新。他赞扬 Go 语言的稳定性，包括其标准库和语言规范。因此，他决定将 Go+HTMX+Templ 作为未来个人项目的首选技术栈。
#React
https://blog.erodriguez.de/dependency-management-fatigue-or-why-i-forever-ditched-react-for-go-htmx-templ/
Eduardo Rodriguez
Dependency management fatigue, or why I forever ditched React for Go+HTMX+Templ
After getting to work on some personal projects using Go+HTMX+Templ this year, I have decided to give up on using React on any personal projects.
You can actually find a lot of compelling arguments for ditching React in favor of HTMX in the essays found in…
You can actually find a lot of compelling arguments for ditching React in favor of HTMX in the essays found in…
👍3