<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>OnionTalk</title><link>https://hateonion.me/zh/</link><description>Recent content on OnionTalk</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Fri, 21 Aug 2026 20:00:00 +1000</lastBuildDate><atom:link href="https://hateonion.me/zh/index.xml" rel="self" type="application/rss+xml"/><item><title>RxJS入门指南</title><link>https://hateonion.me/zh/posts/19jul16/</link><pubDate>Wed, 17 Jul 2019 22:08:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/19jul16/</guid><description>RxJS是ReactiveX在JavaScript上的一个派生。ReactiveX是一个应用的比较广泛的响应式编程框架，这个框架很好的应用了Observer Pattern（观察者模式），让异步编程变得简单且清晰。本文会带大家对RxJS有一个初步的入门。</description></item><item><title>层叠上下文和层叠顺序</title><link>https://hateonion.me/zh/posts/19oct11/</link><pubDate>Fri, 11 Oct 2019 22:49:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/19oct11/</guid><description>在日常开发中，我们经常会遇到元素需要被遮盖的场景。在这种场景下绝大多数前端开发的第一反应是使用z-index来设定元素的层叠关系，但是在一些情况下z-index并不是会如果我们预期那样正常工作。究其背后的原因，就不得不引入我们今天要聊的层叠上下文（stacking context）。</description></item><item><title>图片懒加载从简单到复杂</title><link>https://hateonion.me/zh/posts/19jan30/</link><pubDate>Wed, 30 Jan 2019 22:53:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/19jan30/</guid><description>图片懒加载是一个很重要的前端性能优化手段。这篇文章将从懒加载的最简单场景开始介绍，逐步增加复杂度，希望能讲清楚常见的图片懒加载场景及在该场景下对应的解决办法。</description></item><item><title>Js中的防抖与节流</title><link>https://hateonion.me/zh/posts/19jan02/</link><pubDate>Wed, 02 Jan 2019 23:14:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/19jan02/</guid><description>防抖(debounce)和节流(throttle)两词其实并非计算机领域的原生词语。追根溯源，防抖一词来自于弱电领域，指代的是消除外界对于开关扰动的技术。而节流来自于流体力学，指代的是限定流体流量的一种技术。由于JavaScript拥有事件驱动的特性，为避免事件频繁触发导致性能的损耗，防抖和节流这两种技术在JavaScript中亦被广泛应用。</description></item><item><title>Deep In React（五）setState中的黑魔法</title><link>https://hateonion.me/zh/posts/19jan14/</link><pubDate>Mon, 14 Jan 2019 22:57:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/19jan14/</guid><description>在React官方文档中有这么一句话React does not guarantee that the state changes are applied immediately。在我最开始使用React的时候，我只是简单的把这句话当做React这个框架的约束，但是随着使用的深入，setState这个函数也让我觉得越来越神秘。在这篇文章中，我将通过反思自己在使用react中遇到的关于setState的一些问题，深入react源码，分析setState这个函数。</description></item><item><title>重学前端学习笔记(1)--Js类型</title><link>https://hateonion.me/zh/posts/19aug26/</link><pubDate>Mon, 26 Aug 2019 13:45:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/19aug26/</guid><description>winter老师的重学前端真的是一门很好的课程，看了第一课，收获颇多，填了很多Js类型的坑，总结如下。</description></item><item><title>git中的二分查找– git bisect</title><link>https://hateonion.me/zh/posts/18dec24/</link><pubDate>Mon, 24 Dec 2018 13:45:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/18dec24/</guid><description>二分查找是一种大家都熟悉的算法。这种算法由于套路非常的清晰，在程序开发中被广泛使用。很常见的一个例子就是使用二分查找去进行程序的debug，逐步缩小代码区间最终确定问题。循着这个思路，在多人合作的场景下，如果某次你pull代码之后发现某些代码不能工作了，你也可以通过二分查找的方式找出出问题的commit。而git bisect就是git内置的二分查找命令。</description></item><item><title>使用yeoman创建属于你自己的脚手架</title><link>https://hateonion.me/zh/posts/18dec17/</link><pubDate>Mon, 17 Dec 2018 00:00:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/18dec17/</guid><description>现代前端开发，由于构建工具的大规模使用，项目的配置趋于日渐复杂。很多时候你只是需要快速编写一个简单的demo，但是你首先需要做的可能是花费不少的时间搭建一整套的前端工具链。为了解决这个问题，社区创造出了不少比较成熟的脚手架或者boilerplate来让开发者快速搭建项目。但是如果你想快速的定制化属于你自己的脚手架，今天要聊的yeoman可能是一个不错的选择。</description></item><item><title>Shift Left：把时间花在编码之前</title><link>https://hateonion.me/zh/posts/shift-left/</link><pubDate>Fri, 21 Aug 2026 20:00:00 +1000</pubDate><guid>https://hateonion.me/zh/posts/shift-left/</guid><description>Coding Agent 彻底改变了编码的方式，同时改变了我每天的工作流</description></item><item><title>人也需要 Context Engineering</title><link>https://hateonion.me/zh/posts/human-context-engineering/</link><pubDate>Sat, 16 May 2026 20:00:00 +1000</pubDate><guid>https://hateonion.me/zh/posts/human-context-engineering/</guid><description>AI 让开始一件事变得很容易，也让注意力、判断力和收尾能力变得更稀缺。</description></item><item><title>Harness Engineering</title><link>https://hateonion.me/zh/posts/harness-engineering/</link><pubDate>Tue, 14 Apr 2026 20:00:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/harness-engineering/</guid><description>当工具足够强大的时候，真正难的反而是把事情做简单。</description></item><item><title>保持节奏</title><link>https://hateonion.me/zh/posts/keep-pace/</link><pubDate>Wed, 25 Mar 2026 20:00:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/keep-pace/</guid><description>问题的关键并不在于你能冲得多快，而在于你能以同样的节奏走多远。</description></item><item><title>保持专注</title><link>https://hateonion.me/zh/posts/keep-focus/</link><pubDate>Sun, 15 Mar 2026 20:00:00 +0800</pubDate><guid>https://hateonion.me/zh/posts/keep-focus/</guid><description>在信息流和 AI 工具不断争夺注意力的时代，专注是一种稀缺而重要的能力。</description></item><item><title>2021年回顾</title><link>https://hateonion.me/zh/posts/22jan30/</link><pubDate>Sun, 30 Jan 2022 15:59:16 +0800</pubDate><guid>https://hateonion.me/zh/posts/22jan30/</guid><description>我是一个比较传统的人，更习惯把农历新年当作新的一年开始。说是 2021 年回顾，其实更多的是牛年的回顾。一年，说长也不长，说短也不短，感觉非常的快，但是确实又发生了很多的事情。</description></item><item><title>浏览器跨tab通信的几种办法</title><link>https://hateonion.me/zh/posts/21oct14/</link><pubDate>Thu, 14 Oct 2021 14:53:16 +0800</pubDate><guid>https://hateonion.me/zh/posts/21oct14/</guid><description>跨tab通信需求常见于一些有大量内容需要浏览或操作（比如博客或者CMS系统），同时需要保持数据一致性的场景。这些场景大部分可以引入后端服务，通过轮询等方式保持多个tab间的数据一致。本文介绍的是在不引入后端服务的情况下，通过纯前端的方案，来进行跨tab通信</description></item><item><title>持续部署新法宝 - Github Actions</title><link>https://hateonion.me/zh/posts/20feb22/</link><pubDate>Sat, 22 Feb 2020 19:21:14 +0800</pubDate><guid>https://hateonion.me/zh/posts/20feb22/</guid><description>最近，我把我的博客部署从 Travis 迁移到了 Github Actions。在迁移过程中，我发现 Github Actions 是一个非常强大且有趣的工具。这篇文章就和大家简单分享一下这个工具。</description></item><item><title>分类</title><link>https://hateonion.me/zh/categories/</link><pubDate>Thu, 17 Oct 2019 22:07:44 +0800</pubDate><guid>https://hateonion.me/zh/categories/</guid><description/></item><item><title>Deep In React (四) stack reconciliation</title><link>https://hateonion.me/zh/posts/8104/</link><pubDate>Sun, 18 Nov 2018 23:51:13 +0000</pubDate><guid>https://hateonion.me/zh/posts/8104/</guid><description>在前一篇文章中我们谈到了DOM diff的基石，Internal Instance。同时我们也留下了一些悬而未解解的问题，比如Internal Instance到底有什么更进一步的应用。在这篇文章中，我们来了解一下基于Internal Instance的stack reconciliation(DOM Diff算法)</description></item><item><title>Deep In React (三）Internal Instance</title><link>https://hateonion.me/zh/posts/457c/</link><pubDate>Mon, 12 Nov 2018 16:54:01 +0000</pubDate><guid>https://hateonion.me/zh/posts/457c/</guid><description>在上一篇文章中我们谈到了React的递归式渲染这个名词，那么一个React element经过了怎样的变化最后映射成了对应的DOM结构，Reacte element又是怎样在DOM树中挂载/卸载的？这篇文章会带你一探究竟。</description></item><item><title>Deep In React (二) Component,Element和渲染</title><link>https://hateonion.me/zh/posts/8e61/</link><pubDate>Thu, 01 Nov 2018 22:26:08 +0000</pubDate><guid>https://hateonion.me/zh/posts/8e61/</guid><description>在上一篇文章中，我们谈到了如何从应用层面优化React的性能，在随后的几篇文章中，我们将深入React的底层实现，仔细分析一下为什么React会有如此高的性能。在介绍React底层的reconciliation算法之前，我们需要先了解一些先导知识。</description></item><item><title>Deep In React (一) 高性能React组件</title><link>https://hateonion.me/zh/posts/3980/</link><pubDate>Wed, 17 Oct 2018 22:11:16 +0000</pubDate><guid>https://hateonion.me/zh/posts/3980/</guid><description>React在推向社区之初, 一个备受社区欢迎的点就是React的优秀的性能。得益于React出色的架构, React相比于传统的方式确实快很多。但是在实际开发中也存在着很多React性能的陷阱。虽然我们绝大多数时候其实不需要过于关心React的性能问题，但是当需要提升性能时，我们也会有一些很好的切入点去做这件事情.</description></item><item><title>使用Typescript给JavaScript做静态类型检查</title><link>https://hateonion.me/zh/posts/aeb8/</link><pubDate>Sun, 14 Oct 2018 21:54:53 +0000</pubDate><guid>https://hateonion.me/zh/posts/aeb8/</guid><description>TypeScript，作为JavaScript的超集，给JavaScript带来了强类型这个非常强大的特性，给前端的开发以及重构带来了很大的便利性。但是，即使TypeScript现在已经可以直接使用用JavaScript编写的模块了，有很多遗留项目想要立马迁移到TypeScript也并非易事。但是好消息是，TypeScript在2.3版本引入了Js Type Checking，从此，不需要任何对于已有代码的侵入，你也可以很好的享受TypeScript带来的一些特性了。</description></item><item><title>使用Yarn Workspace管理多project repo</title><link>https://hateonion.me/zh/posts/b2b0/</link><pubDate>Tue, 25 Sep 2018 21:35:00 +0000</pubDate><guid>https://hateonion.me/zh/posts/b2b0/</guid><description>node的包管理方式和js社区重复造轮子的坏习惯一直为人所诟病。Yarn的横空出世很好的解决了单个package.json之下依赖重复的问题。对于多个package.json的项目，有没有办法解决呢？答案是Yes，Yarn workspace能很好的帮你做到这一点。</description></item><item><title>使用Jest进行Javascript单元测试</title><link>https://hateonion.me/zh/posts/ba0/</link><pubDate>Wed, 18 Jul 2018 12:41:11 +0000</pubDate><guid>https://hateonion.me/zh/posts/ba0/</guid><description>有人觉得，单元测试这玩意儿一直是个玄学，尤其是前端的单元测试。后端单元测试至少还能起到验证业务逻辑的作用，但是在传统的 Web 项目中，前端的主要作用只是简单的输出页面 UI，并附加一些命令式的交互绑定。总而言之，前端既难以测试(因为绝大多数命令式的代码和 DOM 强绑定，很难使用单元测试独立出来)，又没有太大的必要去测试。 但是随着技术的发展，类似 React、Angular 这种大型的 UI 框架如雨后春笋般冒出来并且被越来越多的人开发者所接受。打开一个最近流行的前端项目，你会发现前端项目的复杂度已大大超过以前，前端也开始承担越来越多的业务逻辑。于此同时，由于大型 UI 框架的使用，前端代码也变得越来越声明式，意味着其可测性变得越来越好。重新审视我们的前端单元测试，我们会发现其重要程度已经不亚于后端的单元测试。 说到前端测试框架，市面上其实已经有了 Jasmine/Mocha 这种成熟的测试框架，但是今天我们更多的来聊聊 Jest。</description></item></channel></rss>