分类 : 技术向 共 35 篇文章
作为互联网基础设施的基石之一，DNS 也是最脆弱的环节之一。在项目从上线、运营维护的整个生命周期中，DNS 记录的变更和管理是不可避免的。传统上，DNS 记录的管理往往依赖于域名注册商或 DNS 服务商提供的 控制平面，操作不直观、不可复现、容易出错、难以追溯、没有自动化。基础设施即代码（Infrastructure as Code, IaC）无疑为脆弱的 DNS 记录管理给出了一个方向。 2001 年 4 月 IETF 通过的 RFC3089 中所描述的 Fake IP，是四层代理分流场景下 性能相对最佳、体验相对最好、实现相对最简单的「最佳实践」。相比之下，Real IP 模式下为了尽可能接近 Fake IP 的性能、体验，需要大量额外配置、付出更多的代价。 对于全新的 React 项目来说，一开始就使用 Next.js、Remix、Shopify Hydrogen、Gatsby 等 React 元框架（Meta Framework）是最正确的选择，这些元框架替你解决了路由、数据加载、服务端渲染（SSR）、全静态页面导出（SSG）、边缘计算、打包器和编译器配置。然而，如果你需要迁移现有的、纯客户端渲染（Client-side Rendering）的项目到 React、或者从其他打包器（如 Vite 或 Parcel）迁移走时，即使在 2024 年，webpack 仍然不失为一种选择。 使用过 React 构建应用的开发者对 React Context 一定不会陌生。在 React 的世界中，相比于把 prop 不断透传给下一层子组件（prop-drilling），React Context 可以更优雅地自上而下将数据从父组件传递到深层级的子组件、并确保数据在不同子组件之间保持一致。不过，Context 绝不是仅属于 React，在 JavaScript 中 Context 一样可以大展拳脚。 更新（重新渲染）是 React 的重要特性 —— 当用户与应用交互的时候，React 需要重新渲染、更新 UI，以响应用户的输入。但是，React 为什么会重新渲染呢？如果不知道 React 为什么会重新渲染，我们如何才能避免额外的重新渲染呢？ React 是一个由 Facebook 开源的、可以在任意平台上构建 UI 的 JavaScript 库。在 React 中，一个常见的 Pattern 是使用 useEffect 搭配 useState 发送请求、将状态从 API（React 外部）同步到 React 内部、用于渲染 UI，这篇文章恰恰在向你介绍为什么你不应该直接这么做。 距离上一篇文章发布已有四个月了，是时候写几篇文章给博客除草了。上一次我介绍了我如何迁移、重构了我的博客的架构，这次我想来谈谈我在重构中优化和打磨访客体验时解决的一个问题。 我的博客优化之旅 在咕咕了一整年、只发布了三篇文章（其中两篇还是译文）之后，我决定还是稍微花一点时间好好折腾一下自己的博客，以 React 作为抓手，通过 Next.js 和 Hexo 深度共建，对标 Gatsby，打通静态 HTML 与用户交互之间的垂直领域屏障，实现多维矩阵闭环，为个人博客赋能（咳咳咳），然后水出 2022 年第一篇文章（逃） 我们正生活在一个「Any application that can be written in JavaScript, will eventually be written in JavaScript」的时代。作为一门兼具动态性和简单性的语言，JavaScript 已经占领了客户端、服务端，甚至在机器学习中也占据一席之地；不可避免的，异步执行也逐渐成为这门语言不可缺少的一部分。... 和其它 Linux 的 DE 一样，macOS 也支持在「系统偏好设置」中设置 HTTP 代理、HTTPS 代理，但是 macOS 并不会在终端（Terminal、iTerm）的 shell 中自动生效系统代理配置。为了方便日常使用，我决定好好研究一下 macOS 的系统代理。
1/4
下一页 
