分类: library

umi-hooks、hox

这篇文章仅整理蚂蚁金服的 umi-hooks、hox 的大致实现原理,以说明 react-hooks 的探索空间和实践场景。循着蚂蚁金服体验技术部的足迹,自觉很能开拓眼界和思路。 umi-hooksuseAsyncuseAsync 用于处理异步请求,它支持的功能点包含暂停、撤销、重启、轮询。 在实现上,umi-hooks 首先构造 Timer 类以定时器方式执行指定函数,timer.stop、ti

library一句话

yargs[猜测]首先注册命令及其选项,再解析用户输入,执行命令。 同类库:command, command-bin。

react-router

react-router基于 history 创建的 history 对象、以及 create-react-context 为上下游组件传递 context 数据,上游的 Router 组件用于监听地址栏的变更,随后将 history 对象以及当前的 state.location 信息写入 context;下游的 Route 组件通过工具函数 matchPath 判断 location.pathn

history

history 库基于 html5 的 history 接口,用于操控和观察浏览器地址栏的变更。本文分为两部分:介绍 html5 的 history 接口;再介绍 history 库的实现。 history 接口为实现浏览器地址栏变更,又不至使页面刷新,html 提供了 history.pushState(state, title, url) 方法。该方法结合 ajax 请求一起使用,就可以实现地

mobx使用探微

前言写作这篇文章的起因是我有感于实际项目中所遇到的问题。因此,这篇文章只算是摸索的产物,远未臻于完美。在这里,我谨期望阅读这篇文章的同学能够见仁见智,各洒江海。 我所遇到的问题,总结如下: 项目采用分层设计,pages 为视图层,stores 为模型层,services 为服务层。从某种意义上讲,代码是按功能单元进行划分的,而不是业务单元。需要分别从 pages, stores, service

mobx源码分析(二) 订阅响应式数据

前言处理问题有两种方式,从一般到具体,或者从具体到一般。在写作这两篇文章时,我选择了后者,一是因为我在写作这篇文章的过程中才逐渐摸清 mobx 的设计和实现,二是因为我自身尚不具备足够的积淀,能站在更高的抽象维度对问题的一般面加以思索。上一篇文章对各种数据结构的处理无疑都是具体的,本文将介入如何抽象 observable,即对上一篇文章中的公有特征 reportObserved, reportCh

mobx源码分析(一) 构造响应式数据

思想实验在开篇之初,我们先作一番思想实验。借助于形象化思维,通过类比的方式,那样会更容易理解 mobx 的实现。 视线折回到明代,水患侵扰了淳安县境,治理地方水务的官员把这情况上报给知县海瑞,海瑞又上报总督胡宗宪,而胡宗宪呢,他派出快马,向京师呈报奏章,吁请内阁早日筹备赈灾的粮食。与此同时,东厂番子早已把眼线布满全国,不等内阁向嘉靖奏报,嘉靖早已知晓了千里之外的动向。当我们把这环节牵涉到的各级官员

react-redux源码分析

概述react-redux 类库的意义是将 redux 状态注入到组件中,且在状态更新时驱动组件重绘。在这个类库的设计和实现上,需要面临两个问题:如何将 store 中缓存的状态注入到组件中;在状态更新时,如何驱动组件重绘。 对于第一个问题,react-redux 解决手法也极为简单且常见。通过顶层 Provider 容器接受 store 作为 props,再将 store 作为 context

redux源码分析

前言为使页面组件和业务逻辑解耦,前端相继涌现出 MVC(Model-View-Controller)、MVP(Model-View-Presenter)、 MVVM(Model-View-ViewModel) 模式。在双向数据流的实现中,同一个 View 可能会触发多个 Model 的更新,并间接引起另一个 View 的刷新,使得状态变更的线索及影响变得错综复杂。redux 延续了 flux 架构