<?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>Pixel的思考 on OnionTalk</title><link>https://hateonion.me/zh/categories/pixel%E7%9A%84%E6%80%9D%E8%80%83/</link><description>Recent content in Pixel的思考 on OnionTalk</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Thu, 14 Oct 2021 14:53:16 +0800</lastBuildDate><atom:link href="https://hateonion.me/zh/categories/pixel%E7%9A%84%E6%80%9D%E8%80%83/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>浏览器跨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>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>使用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>