孙云增的博客

JS 的 Number 类型精度问题我们知道，Java 语言中的长整型范围为 +2^63-1 ~ -2^63-1，而 JavaScript 的 Number 基本类型采用 64 位浮点型表示，为什么 JS 中整型的最大安全范围不是 +2^63-1 ~ -2^63-1 呢？ Java的 的长整型整数也是采用 64 位表示，除了第一位是符号位，剩下的 63 位都可以表示数字。 而 JavaScript 没有单独的整型类型 (Bigint 除外，且 Bigint 不能参与与 Number 类型的运算)，整型、浮点型都统一用 64 位浮点型来表示，采用的是 IEEE754 标准。 IEEE754 规定，64 位的浮点型中，第 1 位表示正负，2~12 位表示指数位 (实际存储的时候必须加上一个偏移值 1023)，剩下的 64 - 1- 11 = 52 位表示整数位，因为浮点数采用科学计数法，第一位固定是 1，可以不用表示，但是运算时会加上。 比如： 0 01111111011 0000000000000000000000000000000000000000000000000000 表示的就是 ...

使用 Promise.all 同时触发多个不互相依赖的异步请求对于互不依赖的多个Promise任务，可以使用 Promise.all 方法使这些方法并行执行，而不是串行执行，这样可以大量的节省任务执行时间。 举例 123456789101112131415161718192021222324252627282930313233343536373839function getData1(){ return new Promise((resolve, reject)=>{ setTimeout(()=>resolve(1), 10000); })}function getData2(){ return new Promise((resolve, reject)=>{ setTimeout(()=>resolve(2), 20000); })}async function oneByOneAsyncFunc(){ const start_time = new ...

命令模式命令模式中的命令（command）指的是一个执行某些特定事情的指令。 命令模式最常见的应用场景是：有时候需要向某些对象发送请求，但是并不知道请求的接收者是谁，也不知道被请求的操作是什么。此时希望用一种松耦合的方式来设计程序，使得请求发送者和请求接收者能够消除彼此之间的耦合关系。 例如前端开发分为界面开发以及代码逻辑开发两部分，界面开发的同学设计了一个刷新按钮，点击可以执行刷新操作。 1234<button id="refreshBtn">刷新</button><script>let refreshBth = document.getElementById('refreshBtn');</script> 但是这时候负责开发实际代码逻辑的同学由于业务比较复杂，因此还没来得及开发完成，此时界面开发的同学不知道如何调用实际的刷新操作。 此时可以利用命令模式，统一规定了命令的执行需要调用 execute 方法。 12345let setCommand = function(button, comman ...

单例模式js 程序中很多情况下只需要创建一个对象，例如全局缓存、widows 对象、线程池、以及界面中具备唯一性的窗口，此时需要利用单例模式来保证对象的唯一性。 使用代理实现 单一职原则 ，将创建单例的 DIV 与管理代理的代码分开。 123456789101112131415161718// 创建 DIV 逻辑CreateDiv = function(html){ this.html = html; this.init();}CreateDiv.prototype.init = function(){ const div = document.createElement('div'); div.innerHtml = this.html; document.body.appendChild(div);}SingletonProxy = (function(){ let instance = null; return function(html){ r ...

Index 组件中的 context 依赖Content 组件、Header 组件以及 ThemeSwitch 组件都是依赖于 Index 父组件的 context 属性，而 context 属性在 Index 组件中存在会导致 Index 依赖于额外的属性，扩展性不强。 因此我们需要提炼出一个淡出的组件 provider 来当作 Index 的父组件，来存储全局的 context 属性，实现 Index 组件与 context 属性的解耦。 构建 Provider 组件在 src/react-redux.js 文件中添加如下代码： 12345678910111213141516171819202122232425class Provider extends Component { static propTypes = { store: PropTypes.object, children: PropTypes.any } static childContextTypes = { sto ...

dispatch 的代理工作在 src/ThemeSwitch.js 中，ThemeSwitch 组件通过 store 的 dispatch 方法实现了数据的更改，这也导致了组件的强耦合。 我们的思路是让高阶组件 Connect 代替 ThemeSwitch 来实现 dispatch 功能，同时通过 props 将方法传递给 ThemeSwitch 组件。 修改 src/react-redux.js文件： 12345678910111213141516171819202122232425export const connect = (mapState2Props, mapDispatch2Props)=>(OriginComponent)=>{class Connect extends Component { componentWillMount(){ this._updateProps() } _updateProps(){ const {store} = ...

子组件直接利用 context 的问题第三节我们实现了子组件利用 context 属性，通过统一的修改方式对全局 state 进行修改，同时利用发布者-订阅者模式实现了数据更新的监听及界面重新渲染。 但是仍然存在两个问题： 子组件都是利用 context 属性来取得 store 对象，进而对全局状态 state 进行修改，这样会导致很多重复性代码。 每个子组件都依赖了 context 属性，导致子组件与父组件形成了强耦合，不利于组件的复用。例如，前面的 Context 组件需要父组件定义 context 属性，否则主题颜色将无法设置。 解决方法： 对于重复使用的代码，可以凝练提取出一个可复用的代码结构。这里可以通过高阶组件（或者装饰器模式）将 context 的控制与相关事件监听代理起来。 对于强耦合问题，可以通过设置 Pure Component，即在高阶组件内部的被装饰组件尽量设计成纯组件。纯组件是其状态仅依赖于父组件传入的 props 以及 自己的 state，对于外界依赖极低，因此复用性极高。 抽离出公共的逻辑代码我们可以设计一个 connect 函数，该函数的 ...

构建 createStore 函数实现 Redux 架构原理: 构造一个函数 createStore，该函数可以对全局变量的状态进行统一的管理。该函数传入一个全局 state 以及状态修改纯函数 reducer, reducer 定义了改变状态的逻辑并返回一个新的状态，为后面的动态渲染优化做准备。 在 src/index.js 中加入 createStore 函数 12345678910111213141516171819202122232425262728293031323334353637function createStore(reducer){ // 初始状态 let state = null // 定义发布者 const listeners = [] // 绑定订阅者 const subscribe = (listener)=>listeners.push(listener) // 获取 state const getState = ()=>state // 绑定处理函数 const dis ...

构建项目在命令行依次输入以下命令 12// 利用脚手架创建新项目npx create-react-app react-redux 12// 安装类型检查依赖npm install --save prop-types 创建文件安装好后在 src/ 目录下新增三个文件：Header.js、Content.js、ThemeSwitch.js。 修改 src/Header.js： 1234567891011121314import React, { Component } from 'react'import PropTypes from 'prop-types'class Header extends Component { render() { return ( <div> <h1>动手实现React-Redux</h1> </div> ) } ...

Redux架构Redux是一种前端架构，是由 Facebook 的 Flux 框架演变而来，但避开了 Flux 的复杂性。而 Flux 是一种模式而非正式框架，通过利用单项数据流补充React的组合视图组件。 Redux要解决的问题React的数据流是单项数据流，如果任何一个子组件依赖了父组件的状态，就需要将状态存储到父组件中进行状态提升。但假设该父组件又是另一组件的子组件且状态又由另一组件决定，那么状态又需提升至另一组件。层层的状态依赖非常麻烦。 React中可以通过设置 context属性实现全局变量的效果，任何该组件的子组件都可以读取到 context 属性；而一旦 context 属性改变，所有依赖 context 属性的组件都会更新。 并且所有能读取到 context 的组件都可以对该属性进行修改，如果在组件关系非常复杂，到处存在这种修改父组件 context 的逻辑，那么可能产生难以预测的后果。 因此 Redux 规范了修改全局属性 state 的方法，便于状态改变的维护与管理。 核心概念1. 单一数据源 整个应用的 state 被储存在一棵 object tree 中，并 ...