GDYG https://gdyg.blog/ 一个分享和记录日常笔记的博客 Fri, 26 Jun 2026 09:12:38 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en-US All rights reserved 2026, GDYG <![CDATA[从零构建现代化DeFi资产管理面板：Next.js + Web3技术栈实战]]> https://gdyg.blog/article/defi-dashboard https://gdyg.blog/article/defi-dashboard Wed, 28 May 2025 00:00:00 GMT

从零构建现代化DeFi资产管理面板：Next.js + Web3技术栈实战

在Web3时代，如何构建一个既美观又实用的去中心化金融应用？本文将带你深入了解一个完整的DeFi Dashboard项目，从技术选型到实现细节，全面解析现代Web3应用的开发之道。

🎯 项目概览

在区块链技术日益成熟的今天，DeFi（去中心化金融）已经成为Web3生态中最重要的应用场景之一。然而，大多数用户在管理自己的数字资产时，往往需要在多个平台间切换，体验并不理想。
为了解决这个痛点，我们开发了一个现代化的DeFi资产管理面板，它不仅能够连接用户的钱包，还能实时显示真实的资产余额、交易记录和投资组合概览。

✨ 核心功能特性

  • 🔗 无缝钱包集成：支持MetaMask、WalletConnect等主流钱包
  • 💰 真实链上数据：直接从以太坊网络获取用户资产信息
  • 📊 智能投资组合分析：实时计算总资产价值和持仓分布
  • 📝 完整交易历史：展示ETH和ERC20代币的转账记录
  • 🌙 现代化UI设计：深色主题配合响应式布局
  • ⚡ 高性能数据获取：集成多个API确保数据准确性

🛠 技术架构深度解析

前端技术栈选择

为什么选择Next.js？

Next.js 15作为React的生产级框架，为我们提供了：
  1. 服务端渲染（SSR）：提升首屏加载速度和SEO表现
  1. API路由：内置API处理能力，便于集成第三方服务
  1. 自动代码分割：优化包体积，提升用户体验
  1. TypeScript原生支持：类型安全，减少运行时错误

Web3技术栈的精心选择

wagmi + RainbowKit组合是目前最优雅的Web3集成方案：
  • wagmi：提供React Hooks形式的Web3功能，类型安全且易于使用
  • RainbowKit：美观的钱包连接UI组件，支持多种钱包
  • viem：现代化的以太坊客户端库，性能优异

数据层架构设计

多源数据聚合策略

为了确保数据的准确性和可靠性，我们采用了多API源聚合的策略：

状态管理最佳实践

使用Zustand进行轻量级状态管理：

🔧 核心功能实现详解

1. 钱包连接与管理

钱包连接是Web3应用的入口，我们通过RainbowKit实现了优雅的连接体验：

2. 实时资产数据获取

通过集成多个API源，确保数据的准确性：

3. 交易记录展示

通过Etherscan API获取完整的交易历史：

🎨 UI/UX设计亮点

现代化深色主题

我们采用了现代化的深色主题设计。

响应式布局设计

通过Tailwind CSS的响应式工具类，确保在各种设备上都有良好的体验：

加载状态和错误处理

优雅的加载状态和错误处理提升用户体验：

🚀 性能优化策略

1. 数据缓存机制

2. 组件懒加载

3. API请求优化

🔒 安全性考虑

1. 只读权限设计

应用采用只读设计，只获取公开的区块链数据，不涉及私钥或签名操作：

2. 环境变量管理

敏感信息通过环境变量管理：

3. 输入验证和错误处理

📊 项目亮点与创新

1. 真实数据集成

与许多演示项目不同，我们的Dashboard展示的是真实的区块链数据，用户连接钱包后能看到实际的资产余额和交易记录。

2. 多API源聚合

通过整合Etherscan、Alchemy和CoinGecko等多个数据源，确保数据的准确性和可靠性。

3. 现代化技术栈

采用最新的Web3技术栈，代码结构清晰，易于维护和扩展。

4. 优秀的用户体验

从钱包连接到数据展示，每个环节都经过精心设计，提供流畅的用户体验。

🔮 路线图

短期计划

  • 🔄 支持更多ERC20代币
  • 📈 集成价格图表和历史数据
  • 🔄 添加DeFi协议集成（Uniswap、Compound等）
  • 📱 开发移动端原生应用

长期愿景

  • 🤖 AI驱动的投资建议
  • 🔗 跨链资产管理
  • 📊 高级分析工具
  • 🛡️ 安全监控和风险评估

🎯 技术学习价值

这个项目对于想要学习Web3开发的开发者来说具有很高的学习价值：
  1. 完整的Web3技术栈：从前端到区块链集成的完整实现
  1. 真实项目经验：处理真实数据和用户场景
  1. 最佳实践示例：代码结构、错误处理、性能优化等
  1. 现代化开发流程：TypeScript、ESLint、自动化部署等

🚀 快速开始

想要体验或学习这个项目？只需几个简单步骤：

💡 结语

在Web3技术快速发展的今天，构建一个既实用又美观的DeFi应用需要综合考虑技术选型、用户体验、安全性等多个方面。这个DeFi Dashboard项目展示了如何使用现代化的技术栈来构建高质量的Web3应用。
无论你是Web3开发的新手还是经验丰富的开发者，这个项目都能为你提供有价值的参考和学习材料。让我们一起推动Web3生态的发展，构建更好的去中心化应用！
项目地址: [GitHub Repository] 在线演示: [Live Demo] 技术交流: 欢迎提交Issue和PR
如果这个项目对你有帮助，别忘了给个⭐️支持一下！
 
]]> <![CDATA[React中的TDD权威指南：编写保证成功的测试]]> https://gdyg.blog/article/tdd-react https://gdyg.blog/article/tdd-react Mon, 09 Sep 2024 00:00:00 GMT
了解如何使用测试驱动开发（TDD）来构建强大的react组件，本步骤指南可以确保您的代码可靠且可维护
 
想象一下可以使用安全网进行编码，可以在错误发生前捕获它们。这就是TDD的力量，在本文中，我们将深入探讨它是如何彻底改变你的开发流程的。在测试驱动开发中，开发人员在实际开发代码之前首先编写测试用例，使用TDD方法编写代码有一下几点好处：
  • 更改质量的代码：预先考虑测试可以使您更仔细的考虑需求和设计
  • 快速反馈：您可以获得即时验证，减少调试时间
  • 全面的测试覆盖范围：TDD确保您整个的代码库经过彻底测试
  • 重构信息：通过强大的测试套件，您可以自信的更改代码，而不必担心破坏代码
  • 动态文档：您的测试程序可以成为如何使用它的示例
 
TDD分为三个主要阶段：红色、绿色和重构。红色阶段意味着编写测试用例并观察它的失败。绿色阶段意味着编写最少的代码来实现通过测试用例。重构阶段意味着通过重构来改进代码，以获得更好的结构、可读性和可维护性，而不该变功能，同时确保测试用例仍然通过。我们将React中构建一个登录页面，并详细介绍这一过程，该项目的完整代码在此处找到。
 

先决条件

以下是本文总需要遵循的先决条件：
  • 了解JavaScript和React
  • 您选择的代码编辑器
 

启动一个新的React应用程序

  • 确保使用node -v和npm -v验证安装了Nodejs和npm
  • 使用npx create-react-app tddreact创建新的应用程序
  • 使用cd tddreact转到应用程序文件夹并使用npm start启动应用程序
  • 应用程序完全编译后，导航到lcoahost，你会看到应用程序已经加载完成
 

添加测试用例

如前所示，如果用使用测试驱动开发，首先要编写初始测试用例。
  • 在src下创建__test__文件夹，文件名为login.test.js
  • 接着添加你的第一个测试用例， 确保登录组件保持存在是基本的
  • 使用npm test运行测试用例，您将会看到如下的失败，这就是我们之前所说的红色阶段
notion image
  • 现在是时候添加登录组件并启用绿色阶段了
  • 在src/components下创建一个新文件，命名为Login.js，并添加如下代码：
  • 测试用例现在应该已经通过，并且您成功实施了从红色到绿色阶段的一个周期
notion image
 

添加我们的输入

在我们的登录页面上，用户应该能通过用户名和密码并单击登录按钮进行登录。
  • 添加测试用例，其中用户名和密码应该出现在我们的页面上
  • 您应该看到一些测试用例再次失败
notion image
  • 按照如下所示更改登录组件的返回方式，您应该能看到失败的测试用例通过
 

添加登录逻辑

现在您可以添加实际的登录逻辑。
  • 为简单起见，当用户未输入用户名和密码进行点击登录按钮登录时，应显示一条错误消息。当用户输入用户名和密码进行登录时，不应显示错误消息。相反，显示欢迎消息，例如“欢迎John Doe”。可以通过以下测试将测试用例添加到测试文件中来捕获这些要求。
  • 这应该会导致测试用例失败，如果测试程序尚未运行，请执行npm test运行它们。让我们在组件中实现此功能并通过测试用例。更新登录组件代码以添加缺少的功能，如下所示：
  • 对于大多数场景，登录组件应该通知父组件已登录。让我们添加一些测试用例来实现此功能，添加测试用例后，验证您的终端是否有失败的测试用例。
  • 让我们在登录组件中实现此功能，更新Login组件以接收onLogin函数并更新handleSubmit， 如下所示：
  • 恭喜，登录组件已经实现，所有测试用例也通过。
notion image
 

将登录组件集成到应用程序中

  • create-react-app将样板代码添加到App.js中，我们必须先将App.js原始的代码给去掉，如果您看到App.test.js文件，也将其删除。
  • 再次，我们将首先为App组件添加测试用例，首先在__test__文件夹下创建App.test.js文件
  • 您可以从这些测试用例中获得关键见解：
    • 应用程序包含登录组件，登录成功后，需要像isLoggedIn变量来指示登录状态
    • 用户登录成功后，您需要变更次变量并有条件的显示文本信息
    • 您正在模拟登录组件，这很重要。因为您不希望应用程序组件的单元测试用例测试登录组件
  • 使用所描述的功能实现应用程序组件。将以下代码添加到App.js中
  • 现在所有的测试用例都应该通过，使用npm start启动应用程序，您应该在localhost看到以下内容
notion image
 

增强我们的应用程序

您已经达到了TDD的关键时刻 - 重构阶段。登录组件的样式非常简单，让我们通过添加样式代码并更新登录组件的方式来增强它。
  • 在Login.js的旁边新建一个login.css的文件，并添加如下代码：
  • 更新登录组件的渲染方法以使用样式。另外，在顶部倒入样式文件，以下是更新后的Login.js文件
  • 确保所有测试用例仍然通过npm test输出
  • 使用npm start再次启动应用程序，我们的页面将会变成下面这样
notion image
 

未来的增强功能

我们已经达到了本文的目标，但您的旅程不应该就此停止。我建议进一步增强该项目以继续实践TDD。以下是您可以进行的一些增强功能：
  • 高级验证：对用户名和密码进行更复杂的验证规则，例如密码强度检测和邮件格式验证
  • 代码覆盖率分析：将代码覆盖率工具添加到应用程序中，这将提供对单元测试代码覆盖率百分比的深入了解，并帮助您识别为经过测试的代码行和功能
  • 持续集成CI：设置CI管道，以便在将代码更改推送到仓库时自动运行测试并生成覆盖率报告
 

结论

在本指南中，我们逐步了解了如何通过测试驱动开发TDD来构建React登录页面，通过测试开始并通过红色绿色重构循环，我们创建了一个可靠的、经过充分测试的组件。TDD可能需要一些时间来适应，但在质量和可维护性方面的影响时巨大的。拥抱TDD将是您更有信心的处理复杂的项目。
 
 
原文链接
The Definitive Guide to TDD in React - DZone
Learn how to build robust React components using Test-Driven Development (TDD). This step-by-step guide ensures your code is reliable and maintainable.
The Definitive Guide to TDD in React - DZone
https://dzone.com/articles/the-definitive-guide-to-tdd-in-react-writing-tests
The Definitive Guide to TDD in React - DZone
]]> <![CDATA[前端技术脑图]]> https://gdyg.blog/article/front-end-tech https://gdyg.blog/article/front-end-tech Mon, 29 Apr 2024 00:00:00 GMT
notion image
 
]]> <![CDATA[微服务是你正确的选择吗]]> https://gdyg.blog/article/micro-services https://gdyg.blog/article/micro-services Mon, 09 Sep 2024 00:00:00 GMT
微服务已经成员一种变革性的架构风格, 本文旨在全面了解微服务、它们的优势以及它们何时成为你正确的选择。
 
notion image

微服务的基础知识

微服务的核心是一种小型独立服务，具有明确定义的目标，这些服务共同构成了一个完整的生态系统，共同实现更大的目标，同时保持自主性，微服务的独立性使其能够独立开发、部署和扩展。
 

微服务与整体式（Microservices vs Monolishs）

微服务和整体式架构的争论仍在进行中，了解它们的差异性至关重要。
  • 分离的上下文：微服务是围绕特定的业务功能设计的，允许更集中和模块化的开发。相比之下，单体应用将整个内容捆绑到单个仓库下。
  • 技术灵活性：每个微服务都可以选择最适合其用途的技术栈，这与单体式应用不同，单体式应用通常局限于单个技术栈，
  • 风险管理：部署微服务的风险可能较低，因为对一项微服务的更改不会影响到其他的服务。但是整体式应用的一个小更改可能会影响到整体系统。
  • 团队组织：微服务可以使团队围绕单个服务进行组织，从而促进所有权和问责制。整体式应用通常需要查看复杂的的代码仓库，这使得分离职责变得困难。
  • 初始复杂性：由于需要明确的边界和基础设施来实现服务间通信，因此微服务开始也许会很复杂，另一方面，整体式应用可能更容易启动，丹随着它们的增长可能会变得笨拙。
notion image

何时使用微服务架构

微服务在以下情况下适合使用：
  • 扩展团队：当多个团队需要同时处理系统的不同部分时
  • 明确定义的上下文：当业务区域或上下文被明确划分时
  • 成熟的交付流程：具有已建立CI/CD的管道和测试框架的组织
  • 技术成熟度：具有管理分布式系统复杂性的专业知识的团队
  • 选择可扩展性：当只有系统的部分需要扩展时
  • 技术多样性：当系统的各个地方需要不同的技术来实现最佳的性能时
 

何时使用整体式架构

某些情况下，整体式架构仍然具有相关性和优势：
  • 概念验证（POC）：快速迭代和验证，无需多个服务的开销
  • 新项目：当域不完全了解并且预期内会发生快速变化时
  • 简化治理：更易于管理和实现技术和实践的一致性
  • 易于招聘和培训：使用统一的代码库可以让开发人员更快的上手项目
  • 共享库：更轻松的在单个代码库中共享和维护公共库
 

从整体式架构迁移到微服务架构

从整体式架构过度到微服务架构需要仔细规划：
  • 分离式上下文（DDD）：使用域驱动设计来识别和分离上下文
  • 避免过大力度：确保服务足够大，可以独立管理，但不要太精细
  • 依赖项管理：避免创建服务之间紧密耦合的分布式单体应用
  • 数据库迁移：规划数据库如何迁移并确保数据的一致性和完整性
  • 使用事件：使用事件驱动架构来实现更好的解藕
  • 数据复制：必要时不要回避复制数据
  • 最终一致性：接收最终一致性而不是立即一致性
  • 成熟的CI/CD：确保强大的CI/CD、测试和环境管理
  • 从小处入手：使用Strangler模式从不太重要的域开始，逐步替换整体式架构的某些部分
 

微服务的特征

成功的微服务具备以下几种特征：
  • 通过服务进行组件化：每个服务都是一个负责特定功能的组件
  • 业务一致：服务围绕业务功能进行组织，并由跨职能团队进行管理
  • 产品心态：将每一项服务都视为一个产品，注重之后的迭代和持续改进
  • 智能端点，哑管道（Smart Endpoints, Dumb Pipes）：服务通过简单的直接消息进行通信，无需中介
  • 去中心化治理：团队选择最好的技术并建立明确的通信制度
  • 分散式数据管理：允许多个数据库，并仔细管理数据重复
  • 基础设施自动化：自动化基础设施以处理分布式服务的复杂性
  • 为故障而设计：构建能够优雅处理故障的弹性系统
  • 进化设计：设计服务可进行独立的更换和升级

结论

微服务架构提供了一种强大的方法来构建可扩展可维护的系统，特别是对于复杂不断变更的业务需求，但是，它们也带来的复杂性，需要技术成熟度和仔细规划，了解何时如何使用微服务而不是整体式架构可以对您的项目成功产生重大的影响
 
原文链接
Are Microservices the Right Choice for You?
Microservices have emerged as a transformative architectural style. As I delve deeper into software...
Are Microservices the Right Choice for You?
https://dev.to/v1eira/are-microservices-the-right-choice-for-you-3l6j
Are Microservices the Right Choice for You?
]]> <![CDATA[React 19 RC更新指南]]> https://gdyg.blog/article/react-19-rc https://gdyg.blog/article/react-19-rc Tue, 13 Aug 2024 00:00:00 GMT

📝 React 19更新特性：

  • 删除已经弃用的API,  propTypes 和 defaultProps
    • 自行选择迁移到TypeScript或者其他类型检查工具
    • 类组件将继续支持 defaultProps，因为没有 ES6 替代方案。
  • 删除了refs字符串引用
    • 删除了模块模式工厂
      • 这种模式很少使用，支持它会导致 React 比必要的稍大和慢。在 React 19 中，我们将删除对模块模式工厂的支持，您需要迁移到常规函数：
    • 删除了React.createFactory
      • 在 JSX 得到广泛支持之前，使用 createFactory 很常见，但现在很少使用，可以用 JSX 替换。在 React 19 中，我们将删除 createFactory，您需要迁移到 JSX：
    • Actions
      • React 应用程序中的一个常见用例是执行数据突变，然后更新状态作为响应。例如，当用户提交表单以更改其姓名时，您将发出 API 请求，然后处理响应。过去，您需要手动处理挂起状态、错误、乐观更新和顺序请求。
      • 在 React 19 中，我们添加了对在转换中使用异步函数的支持，以自动处理挂起状态、错误、表单和乐观更新。
      • 例如，您可以使用useTransition来为您处理挂起状态：
      • 异步转换将立即将isPending状态设置为 true，发出异步请求，并在任何转换后将isPending切换为 false。这使您可以在数据更改时保持当前 UI 的响应能力和交互性。
      • React 19 构建在 Actions 之上，引入了useOptimistic来管理乐观更新，并引入了一个新的钩子React.useActionState来处理 Actions 的常见情况。在react-dom中，我们添加<form>操作来自动管理表单，并useFormStatus来支持表单中操作的常见情况。
    • 新hooks: useActionState ，删除了useFromState hooks
      • useActionState接受一个函数（“Action”），并返回一个包装的 Action 来调用。这是有效的，因为动作是组合的。当调用包装的 Action 时， useActionState将返回 Action 的最后结果作为data ，并将 Action 的挂起状态返回为pending
      • Actions 还与 React 19 的react-dom的新<form>功能集成。我们添加了对传递函数作为<form> 、 <input>和<button>元素的action和formAction属性的支持，以自动提交带有 Actions 的表单：
      • 当<form>操作成功时，React 将自动重置不受控制组件的表单。如果需要手动重置<form> ，可以调用新的requestFormReset React DOM API。
    • 新hooks: useFormStatus
      • 在设计系统中，通常会编写需要访问其所在<form>信息的设计组件，而无需将 props 深入到组件。这可以通过 Context 来完成，但为了使常见情况更容易，我们添加了一个新的钩子useFormStatus ：
      • useFormStatus读取父级<form>的状态，就好像该表单是上下文提供程序一样。
    • 新hooks: useOptimistic
      • 执行数据突变时的另一种常见 UI 模式是在异步请求正在进行时乐观地显示最终状态。在 React 19 中，我们添加了一个名为useOptimistic的新钩子，以简化此操作：
      • 当updateName请求正在进行时， useOptimistic钩子将立即渲染optimisticName 。当更新完成或出错时，React 会自动切换回currentName值。
    • 新API: use
      • 在 React 19 中，我们引入了一个新的 API 来读取渲染中的资源： use
      • 例如，您可以use读取 Promise，React 将 Suspend 直到 Promise 解析， 也可以读取Context，简化了Context的操作，同时use可以在if或者循环语句中使用
    • 简化了Ref和Context
      • 组件之间传递ref时不再通过forwardRef, 而是将ref作为props值进行传递
        • Context包装组件时不再需要使用Provider包装组件, 直接通过Context包装组件即可
          • ref支持清理函数
            • 当组件卸载时，React 将调用从ref回调返回的清理函数。这适用于 DOM 引用、类组件的引用和useImperativeHandle 。
          • useDeferredValue初始值
            • 我们为useDeferredValue添加了一个initialValue选项：
            • 当提供了initialValue时， useDeferredValue会将其作为组件初始渲染的value返回，并使用返回的deferredValue在后台安排重新渲染。
          • 对文档元数据的支持
            • 在 HTML 中，文档元数据标记（例如<title> 、 <link>和<meta>被保留放置在文档的<head>部分中。在 React 中，决定哪些元数据适合应用程序的组件可能距离渲染<head>的位置很远，或者 React 根本不渲染<head> 。在过去，这些元素需要手动插入到效果中，或者通过像react-helmet这样的库插入，并且在服务器渲染React应用程序时需要仔细处理。
            • 当 React 渲染此组件时，它将看到<title> <link>和<meta>标记，并自动将它们提升到文档的<head>部分。通过原生支持这些元数据标签，我们能够确保它们与仅限客户端的应用程序、流式 SSR 和服务器组件配合使用。
          • 支持样式表
            • 外部链接的样式表 ( <link rel="stylesheet" href="..."> ) 和内联样式表 ( <style>...</style> )，由于样式的原因，需要在 DOM 中仔细定位优先规则。构建允许组件内可组合性的样式表功能很困难，因此用户通常最终要么加载远离可能依赖于它们的组件的所有样式，要么使用封装这种复杂性的样式库。
            • 在 React 19 中，我们正在解决这种复杂性，并提供对客户端并发渲染和服务器上流式渲染的更深入集成，并内置对样式表的支持。如果你告诉 React 样式表的precedence ，它将管理 DOM 中样式表的插入顺序，并确保在显示依赖于这些样式规则的内容之前加载样式表（如果是外部的）。
            • 在服务器端渲染期间，React 将在<head>中包含样式表，这确保浏览器在加载之前不会绘制。如果样式表是在我们开始流式传输之后才发现的，React 将确保在显示依赖于该样式表的 Suspense 边界的内容之前将样式表插入到客户端上的<head>中。
            • 在客户端渲染期间，React 将等待新渲染的样式表加载，然后再提交渲染。如果您从应用程序中的多个位置渲染此组件，React 将仅在文档中包含一次样式表：
            • 对于习惯于手动加载样式表的用户来说，这是一个将这些样式表与依赖于它们的组件一起定位的机会，从而可以更好地进行本地推理，并更轻松地确保您只加载实际依赖的样式表。
            • 样式库和与捆绑器的样式集成也可以采用此新功能，因此即使您不直接渲染自己的样式表，您仍然可以受益，因为您的工具升级为使用此功能。
          • 支持异步脚本
            • 在 HTML 中，普通脚本 ( <script src="..."> ) 和延迟脚本 ( <script defer="" src="..."> ) 按文档顺序加载，这使得在深层渲染这些类型的脚本你的组件树具有挑战性。但是，异步脚本 ( <script async="" src="..."> ) 将以任意顺序加载。
            • 在 React 19 中，我们对异步脚本提供了更好的支持，允许您在组件树中的任何位置、实际依赖于脚本的组件内渲染它们，而无需管理重新定位和重复数据删除脚本实例。
            • 在所有渲染环境中，异步脚本都会被去重，这样即使脚本由多个不同的组件渲染，React 也只会加载并执行一次脚本。
            • 在服务器端渲染中，异步脚本将包含在<head>中，并优先于阻止绘制的更关键资源（例如样式表、字体和图像预加载）。
          • 支持预加载资源
            • 在初始文档加载和客户端更新期间，告诉浏览器可能需要尽早加载的资源可能会对页面性能产生巨大影响。
            • React 19 包含许多用于加载和预加载浏览器资源的新 API，以便尽可能轻松地构建不受低效资源加载阻碍的出色体验。
            • 这些 API 可用于通过将字体等其他资源的发现移出样式表加载来优化初始页面加载。他们还可以通过预取预期导航使用的资源列表，然后在单击甚至悬停时急切地预加载这些资源，从而加快客户端更新速度。
          • 与第三方脚本和扩展的兼容性
            • 我们改进了水合作用，以考虑第三方脚本和浏览器扩展。
            • 水合时，如果客户端渲染的元素与服务器 HTML 中找到的元素不匹配，React 将强制客户端重新渲染以修复内容。以前，如果由第三方脚本或浏览器扩展插入元素，则会触发不匹配错误和客户端渲染。
            • 在 React 19 中， <head>和<body>中的意外标签将被跳过，避免不匹配错误。如果 React 由于不相关的水合作用不匹配而需要重新渲染整个文档，它将保留由第三方脚本和浏览器扩展插入的样式表。
          • 更好的错误报告
            • 我们改进了 React 19 中的错误处理，以消除重复并提供处理捕获和未捕获错误的选项。例如，当渲染中出现错误并被错误边界捕获时，以前的 React 会抛出错误两次（一次是针对原始错误，然后在无法自动恢复后再次抛出），然后调用console.error并提供有关错误位置的信息发生。
            • 在 React 19 中，我们记录一个错误，其中包含所有错误信息：
            • 此外，我们添加了两个新的根选项来补充onRecoverableError ：
              • createRoot 和 hydrateRoot 添加了用于自定义错误处理的新方法
                • 如果没有自定义错误处理的方法，react默认会做出相应的处理方式：
                  • 未捕获的错误：未被错误边界捕获的错误将报告给 window.reportError。
                  • 捕获的错误：由错误边界捕获的错误将报告给 console.error。
                  • onRecoverableError ：抛出错误时调用并自动恢复。
          • 反应服务器组件(RSC)
            • 服务器组件是一个新选项，允许在捆绑之前在与客户端应用程序或 SSR 服务器分开的环境中提前渲染组件。这个单独的环境是 React Server Components 中的“服务器”。服务器组件可以在构建时在 CI 服务器上运行一次，也可以使用 Web 服务器针对每个请求运行。
            • 服务器操作允许客户端组件调用在服务器上执行的异步函数。
            • 服务器操作可以在服务器组件中创建并作为属性传递给客户端组件，也可以在客户端组件中导入和使用。
           
          ]]>                     <![CDATA[CSS 伪类和伪元素]]> https://gdyg.blog/article/css-class https://gdyg.blog/article/css-class Wed, 25 Apr 2018 00:00:00 GMT

          📝 介绍

          伪元素（Pseudo-elements）和伪类（Pseudo-classes）是 CSS 中的两个重要概念，用于向文档中的元素添加特定的样式或效果，而无需修改 HTML 结构。它们允许开发者选择文档中某些特定的状态或位置，并对其应用样式。

          1. 伪元素（Pseudo-elements）：

          伪元素允许开发者在元素的内容之前或之后插入虚拟的元素，并为其应用样式。伪元素以双冒号::开头，常见的伪元素包括::before和::after。

          2. 伪类（Pseudo-classes）：

          伪类允许开发者选择元素的特定状态或位置，并为其应用样式。伪类以冒号:开头，常见的伪类包括:hover（悬停状态）、:active（活动状态）、:focus（聚焦状态）、:first-child（第一个子元素）等。

          🤗 总结归纳

          区别：

          • 伪元素是在元素的内容之前或之后插入的虚拟元素，可用于创建一些额外的装饰或图标等。
          • 伪类是根据元素的特定状态或位置选择元素，并为其应用样式，常用于响应用户的操作或页面结构的特定位置。
          总的来说，伪元素和伪类都是在不修改 HTML 结构的情况下为元素添加样式的强大工具，能够实现丰富的效果和交互体验。深入理解和熟练运用伪元素和伪类可以提高 CSS 的灵活性和可维护性。

          📎 参考文章

          伪类和伪元素 - 学习 Web 开发 | MDN
          下一组我们将了解的选择器被称为伪类和伪元素。这一类选择器的数量众多，通常用于很明确的目的。一旦你了解了如何使用它们，你便可以通过查阅列表来寻找合适的那一项以完成你想要的选择。与之前一样，每个选择器相关的 MDN 页面都将帮助你了解各浏览器的支持情况。
          伪类和伪元素 - 学习 Web 开发 | MDN
          https://developer.mozilla.org/zh-CN/docs/Learn/CSS/Building_blocks/Selectors/Pseudo-classes_and_pseudo-elements
          伪类和伪元素 - 学习 Web 开发 | MDN
          ]]>