暂无个人介绍
react 中遇到的奇怪的问题,基本可以从两方面去思考:state 是否 immutable,以及是否形成了闭包。在 Hooks 陷阱中,分析了 hooks 的一些陷阱,其中已经提到了闭包的问题。而当 hooks 遇到 debounce 或者 throttle 等科里化函数的时候,外加一些 viewModel 抽象导致的变量依赖分散时,情况变得更为复杂和难以理解。本文以项目中遇到的实际案例为例子,
## 前言 react/redux 数据流已经是一个老生常谈的问题了,似乎现在谈已经失去了新鲜感。然而,深入理解 react/redux 数据流应该是一个专业 react 前端需要完全掌握的技能,如果未能充分理解,那么很多情况下,你并不知道你开发的应用是如何工作的,这很容易带来问题,从而影响项目的持续发展和可维护性。另一方面,随着 react hooks 和 react-redux 7.x 的发
## 什么是依赖注入 依赖注入是将一个对象所依赖的其他对象直接提供给这个对象,而不是在当前对象中直接构建这些依赖的对象。 ## 为什么要使用依赖注入 - 便于单元测试 - 解耦,统一管理被依赖对象的实例化,不用在类的内部创建被依赖对象 ## 如何实现依赖注入 ### Typescript 中的装饰器 Decorator 装饰器是一种特殊类型的声明,它能够被附
# ES6 iterator 和 generator ES6 引入了新的遍历数据的机制 Iterator 迭代器。它是一种接口,为各种不同的数据结构提供统一的访问机制。任何数据结构只要部署 Iterator 接口,就可以完成遍历操作(即依次处理该数据结构的所有成员)。基于 iterator 机制,es6 提供了很多新的操作符,例如 `for of` 以及解构、展开操作符等。 Gener
当我们学习 Javascript 中的 this 时,非常容易陷入一种困境,一种似懂非懂的困境。在某些情况下,我们看了一些文章和解释,将其应用到一些简单的情况,发现,嗯,确实这么运作了。而在另一些更为复杂的情况下,我们发现又懵逼了,什么情况?这篇文章的目的,就是要完全搞懂并掌握 Javascript 中的 this。为什么我们很难完全掌握 this?在我看来,原因是 this 的解释太过抽象,在理
我们经常能看到大量介绍前端如何进行性能优化的文章。然而很多文章只介绍了如何优化性能,却未能给出一个可计算,可采集的性能量化标准。甚至看到一些文章,在介绍自己做了优化后的性能时,提到页面加载速度提升了多少多少,但是当你去问他你怎么测量性能的时,却不能给出一个科学的、通用的方法。 其实,在进行性能优化前,首先需要确定性能衡量标准。前端性能大致分为两块,页面加载性能和页面渲染性能。页面加载性能指的
随着业务的快速发展,企业中后台的前端应用对于可用性和开发效率的要求越来越高。因此,我们开发了优酷中后台前端解决方案。该方案提供了开发中后台前端应用所需的框架、工具、组件和模板等。基于该方案,无论是前端、后端还是其它同学,可以快速搭建出优雅美观、简单易用的中后台前端应用。 > 系列文章 - [优酷中后台前端解决方案-总览](https://www.atatech.org/articles
Eslint 解决了代码格式检查的问题,同时,一些有用的提示能让我们发现 bug 和无用代码(如 `no-unused-vars, no-extra-bind, no-implicit-globals`)。但是,eslint 并不能自动帮我们美化代码,自动让代码风格统一,格式优美。EditorConfig 部分解决了这个问题,它解决了代码缩紧,行末不出现空格符等问题,但是对于统一整个代码的风格,这