React架构的演变-从同步到异步

最新推荐文章于 2023-03-15 22:08:23 发布
最新推荐文章于 2023-03-15 22:08:23 发布
阅读量328 收藏
点赞数
分类专栏： React 文章标签： react React更新机制
原文链接：https://juejin.im/post/6875681311500025869#heading-3
版权

React架构的演变-从同步到异步

为了加深对 React 更新机制的理解，本文转载于：
作者：Shenfq
链接：https://juejin.im/post/6875681311500025869

React 16 之所以要进行一次大的重构，是因为之前的版本中有一些不可避免的缺陷，一些更新操作需要由同步改为异步。

React 15 是如何进行一次 setState 更新的

import React from 'react'

class App extends React.Component {
  state = {
    val: 0
  }

  componentDidMount() {
    this.setState({
      val: this.state.val + 1
    })
    console.log('first setState', this.state)
    this.setState({
      val: this.state.val + 1
    })
    console.log('second setState', this.state)
    this.setState({
      val: this.state.val + 1
    }, () => {
      console.log('in callback', this.state)
    })
  }

	render() {
    return (
    	<div>val: {this.state.val}</div>
    )
  }
}

由于在 React 生命周期中 以及 React提供的事件流中 ，多次 setState 会被合并成一次，这里虽然连续进行了三次 setState，state.val 的值实际上只计算了一次。

结果是

// first setState => { val: 0 }
// second setState => { val: 0 }
// in callback => { val: 1 }

很多人称 setState 为异步操作，所以导致 setState 之后并不能获取到最新值，其实这个观点是错误的。

setState 是一次同步操作，只是每次操作之后并没有立即执行，而是将 setState 进行了缓存，mount 事件结束或者事件操作结束，才会拿出所有的 state 进行一次计算。

如果 setState 脱离了 React 的生命周期 或 React提供的事件流，setState 之后就能立即拿到更新结果

修改上面的代码，将 setState 放入 setTimeout 中，在下一个任务队列进行执行

import React from 'react'

class App extends React.Component {
  state = {
    val: 0
  }

  componentDidMount() {
    setTimeout(() => {
      this.setState({
        val: this.state.val + 1
      })
      console.log('first setState', this.state)
      this.setState({
        val: this.state.val + 1
      })
      console.log('second setState', this.state)
    })
  }

	render() {
    return (
    	<div>val: {this.state.val}</div>
    )
  }
}

根据执行结果可以看出，setState 之后就能立即看到 state.val 的值得变化

// first setState => { val: 1 }
// second setState => { val: 2 }

为了更加深入理解 setState，下面简单讲解一下React 15 中 setState 的更新逻辑，下面的代码是对源码的一些精简，并非完整逻辑。

旧版本 setState 源码简析

setState 的主要逻辑都在 ReactUpdateQueue 中实现，在调用 setState 后，并没有立即修改 state，而是将传入的参数放到了组件内部的 _pendingStateQueue 中，之后调用 enqueueUpdate 来进行更新操作。

// 对外暴露的 React.Component
function ReactComponent() {
  this.updater = ReactUpdateQueue
}

// setState 方法挂载在原型链上
ReactComponent.prototype.setState = function setState(partialState, callback) {
  // 调用 setState 后，会调用内部的 updater.enqueueSetState
  this.updater.enqueueSetState(this, partialState)
  if (callback) {
    this.updater.enqueueCallback(this, callback, 'setState')
  }
}

var ReactUpdateQueue = {
  enqueueSetState(component, partialState) {
    // 在组件的 _pendingStateQueue 上暂存新的 state
    if (!component._pendingStateQueue) {
      component._pendingStateQueue = []
    }
    var queue = component._pendingStateQueue
    queue.push(partialState)
    enqueueUpdate(component)
  },
  enqueueCallback(component, callback, callerName) {
    // 在组件的 _pendingCallbacks 上暂存 callback
    if (component._pendingCallbacks) {
      component._pendingCallbacks.push(callback)
    } else {
      component._pendingCallbacks = [callback]
    }
    enqueueUpdate(component)
  }
}

enqueueUpdate 首先会通过 batchingStrategy.isBatchingUpdates 判断当前是否在更新流程中，如果不在更新流程中，会调用 batchingStrategy.batchedUpdates() 进行更新。如果在流程中，会将待更新的组件放入 dirtyComponents 中进行缓存。

var dirtyComponents = []
function enqueueUpdate(component) {
  if (!batchingStrategy.isBatchingUpdates) {
    // 开始进行批量更新
    batchingStrategy.batchedUpdates(enqueueUpdate, component)
    return
  }
  // 如果在更新流程，则将组件放入脏组件队列，表示组件待更新
  dirtyComponents.push(component)
}

batchingStrategy 是 React 进行批处理的一种策略，改策略的实现基于 Transaction，虽然名字和数据库事务一样，但是做的事情却不一样

class ReactDefaultBatchingStrategyTrancaction extends Transaction {
  constructor() {
    this.reinitializeTransaction()
  }

  getTransactionWrappers() {
    return [
      {
        initialize: () => {},
        close: ReactUpdates.flushBatchedUpdates.bind(ReactUpdates),
      },
      {
        initialize: () => {},
        close: () => {
          ReactDefaultBatchingStrategyTrancaction.isBatchingUpdates = false
        },
      },
    ]
  }
}

var transaction = new ReactDefaultBatchingStrategyTrancaction()

var batchingStrategy = {
  // 判断是否在更新流程中
  isBatchingUpdates: false,
  // 开始进行批量更新
  batchedUpdates(callback, component) {
    // 获取之前的更新状态
    var alreadyBatchingUpdates = ReactDefaultBatchingStrategyTrancaction.isBatchingUpdates
    // 将更新状态改为 true
    ReactDefaultBatchingStrategyTrancaction.isBatchingUpdates = true
    if (alreadyBatchingUpdates) {
      // 如果已经在更新状态中，等待之前的更新结束
      return callback(callback, component)
    } else {
      // 进行更新
      return transaction.perform(callback, null, component)
    }
  },
}

Transaction 通过 perform 方法启动，然后通过扩展的 getTransactionWrappers 获取一个数组，该数组内存在多个 wrapper 对象，每个对象包含两个属性：initilize、close。perform 会先调用所有的 wrapper.initialize ，然后调用传入的回调，最后调用所有的 wrapper.close。

class Transaction {
  reinitializeTransaction() {
    this.transactionWrappers = this.getTransactionWrappers()
  }

  perform(method, scope, ...param) {
    this.initializeAll(0)
    var ret = method.call(scope, ...param)
    this.closeAll(0)
    return ret
  }

  initializeAll(startIndex) {
    var transactionWrappers = this.transactionWrappers
    for (var i = startIndex; i < transactionWrappers.length; i++) {
      var wrapper = transactionWrappers[i]
      wrapper.initialize.call(this)
    }
  }

  closeAll(startIndex) {
    var transactionWrappers = this.transactionWrappers
    for (var i = startIndex; i < transactionWrappers.length; i++) {
      var wrapper = transactionWrappers[i]
      wrapper.close.call(this)
    }
  }
}

其执行流程如下

/*
*                       wrappers (injected at creation time)
*                                      +        +
*                                      |        |
*                    +-----------------|--------|--------------+
*                    |                 v        |              |
*                    |      +---------------+   |              |
*                    |   +--|    wrapper1   |---|----+         |
*                    |   |  +---------------+   v    |         |
*                    |   |          +-------------+  |         |
*                    |   |     +----|   wrapper2  |--------+   |
*                    |   |     |    +-------------+  |     |   |
*                    |   |     |                     |     |   |
*                    |   v     v                     v     v   | wrapper
*                    | +---+ +---+   +---------+   +---+ +---+ | invariants
* perform(anyMethod) | |   | |   |   |         |   |   | |   | | maintained
* +----------------->|-|---|-|---|-->|anyMethod|---|---|-|---|-|-------->
*                    | |   | |   |   |         |   |   | |   | |
*                    | |   | |   |   |         |   |   | |   | |
*                    | |   | |   |   |         |   |   | |   | |
*                    | +---+ +---+   +---------+   +---+ +---+ |
*                    |  initialize                    close    |
*                    +-----------------------------------------+
*/

我们简化一下代码，再重新看一下 setState 的流程

// 1. 调用 Component.setState
ReactComponent.prototype.setState = function (partialState) {
  this.updater.enqueueSetState(this, partialState);
};

// 2. 调用 ReactUpdateQueue.enqueueSetState，将 state 值放到 _pendingStateQueue 进行缓存
var ReactUpdateQueue = {
  enqueueSetState(component, partialState) {
    var queue = component._pendingStateQueue || (component._pendingStateQueue = []);
    queue.push(partialState);
    enqueueUpdate(component);
  }
}

// 3. 判断是否在更新过程中，如果不在就进行更新
var dirtyComponents = [];
function enqueueUpdate(component) {
  // 如果之前没有更新，此时的 isBatchingUpdates 肯定是 false
  if (!batchingStrategy.isBatchingUpdates) {
    // 调用 batchingStrategy.batchedUpdates 进行更新
    batchingStrategy.batchedUpdates(enqueueUpdate, component);
    return;
  }
  dirtyComponents.push(component);
}

// 4. 进行更新，更新逻辑放入事务中进行处理
var batchingStrategy = {
  isBatchingUpdates: false,
  // 注意：此时的 callback 为 enqueueUpdate 
  batchedUpdates: function (callback, component) {
    var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates;
    ReactDefaultBatchingStrategy.isBatchingUpdates = true;
    if (alreadyBatchingUpdates) {
      // 如果已经在更新状态中，重新调用 enqueueUpdate，将 component 放入 dirtyComponents
      return callback(callback, component);
    } else {
      // 进行事务操作
      return transaction.perform(callback, null, component);
    }
  }
};

启动事务可以拆分成三步来看：

  1. 先执行 wrapper 的initialize，此时的 initialize 都是一些空函数，可以直接跳过；
  2. 然后执行 callback （也就是 enqueueUpdate），执行 enqueueUpdate 时，由于已经进入了更新状态，batchingStrategy.isBatchingUpdates 被修改成了 true，所以最后还是会把 component 放入脏组件队列，等待更新；
  3. 后面执行两个 close 方法，第一个方法的 flushBatchedUpdates 是用来进行组件更新的，第二个方法用来修改更新状态，表示更新已经结束。
getTransactionWrappers () {
  return [
    {
      initialize: () => {},
      close: ReactUpdates.flushBatchedUpdates.bind(ReactUpdates)
    },
    {
      initialize: () => {},
      close: () => {
        ReactDefaultBatchingStrategy.isBatchingUpdates = false;
      }
    }
  ]
}

flushBatchedUpdates 里面会取出所有的脏组件队列进行 diff，最后更新到 DOM。

function flushBatchedUpdates() {
  if (dirtyComponents.length) {
    runBatchedUpdates()
  }
}

function runBatchedUpdates() {
  // 省略一些去重和排序的操作
  for (var i = 0; i < dirtyComponents.length; i++) {
    var component = dirtyComponents[i]
    // 判断组件是否需要更新，然后进行 diff 操作，最后更细 DOM
    ReactReconciler.performUpdateIfNecessary(component)
  }
}

performUpdateIfNecessary() 会调用 Component.updateComponent()，在 updateComponent 中，会从 _pendingStateQueue 中取出所有的值来更新。

// 获取最新的 state
_processPendingState() {
  var inst = this._instance
  var queue = this._pendingStateQueue

  var nextState = {
    ...inst.state
  }

  for (var i = 0; i<queue.length; i++) {
    var partial = queue[i]
    Object.assign(nextState, typeof partial === 'function' ? partial(inst, nextState) : partial)
  }

  return nextState
}

updateComponent(prevParentElement, nextParentElement) {
  var inst = this._instance
  var prevProps = prevParentElement.props
  var nextProps = nextParentElement.props
  var nextState = _processPendingState()
  var shouldUpdate = !shallowEqual(prevProps, nextProps) || !shallowEqual(inst.state, nextState)
  if (shouldUpdate) {
    // diff、update DOM
  } else {
    inst.props = nextProps
    inst.state = nextState
  }
  // 后续的操作包括判断组件是否需要更新、diff、更新到 DOM
}

setState 合并原因

按照上面讲解的逻辑，setState 的时候，batchingStrategy.isBatchingUpdates 为 false 会开启一个事务，将组件放入脏组件队列，最后进行更新操作，而且这里都是同步操作。

那么按照这个逻辑，setState 之后，我们可以立即拿到最新的 state。

然而，事实并非如此，在 React 的生命周期及其事件流中，batchingStrategy.isBatchingUpdates 的值早就被修改成了 true

见下图
React 生命周期
React 事件流
在组件 mount 和事件调用的时候，都会调用 batchedUpdates，这个时候已经开始了事务，所以只要不脱离 React，不管多少次 setState 都会把其组件放入脏组件队列等待更新。一旦脱离 React 的管理，比如 SetTimeout 中，setState 立马变成单打独斗。

Concurrent 模式

React 16 引入的 Fiber 架构，就是为了后续的异步渲染能力做铺垫，虽然架构已经转换，但是异步的渲染能力并没有正式上线。

Concurrent 模式是 React 的新功能，可帮助应用保持响应，并根据用户的设备性能和网速进行适当的调整。

除了 Concurrent 模式，React 还提供了另外两个模式， Legacy 模式依旧是同步更新的方式，可以认为和旧版本保持一致的兼容模式，而 Blocking 模式是一个过渡版本。

Concurrent 模式说白就是让组件更新异步化，切分时间片，渲染之前的调度、diff、更新都只在指定时间片进行，如果超时就暂停放到下个时间片进行，中途给浏览器一个喘息的时间。

浏览器是单线程，它将 GUI 描绘，时间器处理，事件处理，JS 执行，远程资源加载统统放在一起。当做某件事，只有将它做完才能做下一件事。如果有足够的时间，浏览器是会对我们的代码进行编译优化（JIT）及进行热代码优化，一些 DOM 操作，内部也会对 reflow 进行处理。reflow 是一个性能黑洞，很可能让页面的大多数元素进行重新布局。

浏览器的运作流程: 渲染 -> tasks -> 渲染 -> tasks -> 渲染 -> ....

这些 tasks 中有些我们可控，有些不可控，比如 setTimeout 什么时候执行不好说，它总是不准时；资源加载时间不可控。但一些JS我们可以控制，让它们分派执行，tasks的时长不宜过长，这样浏览器就有时间优化 JS 代码与修正 reflow ！

总结一句，就是让浏览器休息好，浏览器就能跑得更快。

– by 司徒正美 《React Fiber架构》

在这里插入图片描述

如何使用

虽然很多文章都在介绍 Concurrent 模式，但是这个能力并没有真正上线，想要使用只能安装实验版本。也可以直接通过这个 cdn ：unpkg.com/browse/reac… 。

npm install react@experimental react-dom@experimental

如果要开启 Concurrent 模式，不能使用之前的 ReactDOM.render，需要替换成 ReactDOM.createRoot，而在实验版本中，由于API不够稳定，需要通过 ReactDOM.unstable_createRoot 来启用 Concurrent 模式。

import ReactDOM from 'react-dom'
import App from './App'

ReactDOM.unstable_createRoot(document.getElementById('root')).render(<App></App>)

setState 合并更新

还记得之前 React15 的案例中，setTimeout 中进行 setState ，state.val 的值会立即发生变化。同样的代码，我们拿到 Concurrent 模式下运行一次。

import React from 'react'

class App extends React.Component {
  state = { val: 0 }
  componentDidMount() {
    setTimeout(() => {
      // 第一次调用
      this.setState({ val: this.state.val + 1 })
      console.log('first setState', this.state)
  
      // 第二次调用
      this.setState({ val: this.state.val + 1 })
      console.log('second setState', this.state)
      
      this.setState({ val: this.state.val + 1 }, () => {
        console.log(this.state)
      })
    })
  }
  render() {
    return <div> val: { this.state.val } </div>
  }
}

export default App

结果是

// first setState => { val: 0 }
// second setState => { val: 0 }
// in callback => { val: 1 }

说明在 Concurrent 模式下，即使脱离了 React 的生命周期，setState 依旧能够合并更新（前提是在同一个时间切片中运行，下文会有提及）。主要原因是 Concurrent 模式下，真正的更新操作被移到了下一个事件队列中，类似于 Vue 的 nextTick。

更新机制变更

我们修改一下 demo，然后看下点击按钮之后的调用栈。

import React from 'react';

class App extends React.Component {
  state = { val: 0 }
  clickBtn() {
    this.setState({ val: this.state.val + 1 });
  }
  render() {
    return (<div>
      <button onClick={() => {this.clickBtn()}}>click add</button>
      <div>val: { this.state.val }</div>
    </div>)
  }
}

export default App;

onClick 触发后，进行 setState 操作，然后调用 enqueueState 方法，到这里看起来好像和之前的模式一样，但是后面的操作基本都变了，因为 React 16 中已经没有了事务一说。

Component.setState() => enqueueState() => scheduleUpdate() => scheduleCallback() => requestHostCallback(flushWork) => postMessage()

真正的异步化逻辑就在 requestHostCallback 、 postMessage 里面，这是 React 内部自己实现的一个调度器：github.com/facebook/re…

function unstable_scheduleCallback(priorityLevel, calback) {
  var currentTime = getCurrentTime()
  var startTime = currentTime + delay
  var newTask = {
    id: taskIdCounter++,
    startTime: startTime,           // 任务开始时间
    expirationTime: expirationTime, // 任务终止时间
    priorityLevel: priorityLevel,   // 调度优先级
    callback: callback,             // 回调函数
  };
  if (startTime > currentTime) {
    // 超时处理，将任务放到 taskQueue，下一个时间片执行
    // 源码中其实是 timerQueue，后续会有个操作将 timerQueue 的 task 转移到 taskQueue
  	push(taskQueue, newTask)
  } else {
    requestHostCallback(flushWork)
  }
  return newTask
}

requestHostCallback 的实现依赖于 MessageChannel，但是 MessageChannel 在这里并不是做消息通信用的，而是利用它的异步能力，给浏览器一个喘息的机会。说起 MessageChannel，Vue 2.5 的 nextTick 也有使用，但是 2.6 发布时又取消了。

MessageChannel 会暴露两个对象，port1 和 port2，port1 发送的消息能被 port2 接收，同样 port2 发送的消息也能被 port1 接收，只是接收消息的时机会放到下一个 macroTask 中。

var { port1, port2 } = new MessageChannel()
// port1 接收 port2 的消息
port1.onmessage = function (msg) { console.log('MessageChannel exec') }
// port2 发送消息
port2.postMessage(null)

new Promise(r => r()).then(() => console.log('promise exec'))
setTimeout(() => console.log('setTimeout exec'))

console.log('start run')

执行结果为

// start run
// promise exec
// MessageChannnel exec
// setTimeout exec

可以看到，port1 接收消息的时机比 Promise 所在的 microTask 要晚，但是早于 setTimeout。React 利用这个能力，给了浏览器一个喘息的时间，不至于被饿死。

还是回到代码层面，看看 React 是如何利用 MessageChannel 的。

var isMessageLoopRunning = false // 更新状态
var scheduledHostCallback = null // 全局的回调
var channel = new MessageChannel()
var port = channel.port2

channel.port1.onmessage = function() {
  if (scheduledHostCallback !== null) {
    var currentTime = getCurrentTime()
    // 重置超时时间
    deadline = currentTime + yieldInterval
    var hasTimeRemaining = true
    // 执行callback
    var hasMoreWork = scheduledHostCallback(hasTimeRemaining, currentTime)
    if (!hasMoreWork) {
      // 已经没有任务了，修改状态
      isMessageLoopRunning = false
      scheduledHostCallback = null
    } else {
      // 还有任务，放入下个任务队列执行，给浏览器喘息的机会
      port.postMessage(null)
    }
  } else {
    isMessageLoopRunning = false
  }
}

requestHostCallback = function (callback) {
  // 将 callback 挂载到 scheduledHostCallback
  scheduledHostCallback = callback
  if (!isMessageLoopRunning) {
    isMessageLoopRunning = true
    // 推送消息，下个队列调用 callback
    port.postMessage(null)
  }
}

再看看之前传入的 callback（flushWork），调用 workLoop，取出 taskQueue 中的任务执行。

// 精简了相当多的代码
function flushWork(hasTimeRemaining, initialTime) {
  var currentTime = initialTime
  // scheduleCallback 进行了 taskQueue 的 push 操作
  // 这里是获取之前时间片未进行的操作
  currentTask = peek(taskQueue)
  while (currentTask !== null) {
    if (currentTask.expirationTime > currentTime) {
      // 超时需要中断任务
      break
    }

    currentTask.callback() // 执行任务回调
    currentTime = getCurrentTime() // 重置当前时间
    currentTask = peek(taskQueue)
  }

  // 如果当前任务不为空，表明是超时中断，返回true
  if (currentTask !== null) {
    return true
  } else {
    return false
  }
}

可以看出，React 通过 expirationTime 来判断是否超时，如果超时就把任务放到后面来执行。所以，异步模型中 setTimeout 里面进行 setState，只要当前时间片没有结束（currentTime 小于 expirationTime），依旧可以将多个 setState 合并成一个。

接下来我们再做一个实验，在 setTimeout 中连续进行 500 次的 setState，看看最后生效的次数

import React from 'react'

class App extends React.Component {
  state = { val: 0 }
  clickBtn() {
    for (let i = 0; i < 500; i++) {
      setTimeout(() => {
        this.setState({ val: this.state.val + 1 })
      })
    }
  }
  render() {
    return (<div>
      <button onClick={() => {this.clickBtn()}}>click add</button>
      <div>val: { this.state.val }</div>
    </div>)
  }
}

export default App

先看看同步模式下：

在这里插入图片描述

再看看异步模式下：
在这里插入图片描述
最后 setState 的次数是 81 次，表明这里的操作在 81 个时间片下进行的，每个时间片更新了一次，同一个时间片中的 setState 会进行合并。

深入浅出 -- 系统架构之单体到分布式架构的演变
xiaoli8748的专栏
04-04 1563
同时，就算部署业务程序的机器损坏，也不会丢失系统数据，在一定程度上也提升了系统的抗风险性。显然，这种方式虽然成本低，数据交换快，但并不能支撑太大的访问量，当流量增大时，系统很可能因为CPU、内存、带宽、磁盘等各因素出现性能问题，而一旦遇到瓶颈，为了保证系统正常运行，集“前端、后端、运维、测试、售后……以数据库为例，数据库由于并发影响，读取数据越来越慢，所以阻塞在后端服务中等待数据返回的请求越来越多，入站流量远大于出站流量，长此以往，后端服务线程数超负荷，系统再次出现响应缓慢、无返回等严重事故。
前端面试题整理6-react
loveX001的博客
02-25 613
抹平浏览器差异，实现更好的跨平台。避免垃圾回收，React 引入事件池，在事件池中获取或释放事件对象，避免频繁地去创建和销毁。方便事件统一管理和事务机制。为了解决跨浏览器兼容性问题，React会将浏览器原生事件（）封装为合成事件（）传入设置的事件处理器中。这里的合成事件提供了与原生事件相同的接口，不过它们屏蔽了底层浏览器的细节差异，保证了行为的一致性。另外有意思的是，React并没有直接将事件附着到子元素上，而是以单一事件监听器的方式将所有的事件发送到顶层进行处理。这样React在更新DOM。
react 合并数组_【第 25 期】React 架构的演变 从同步到异步（一）
weixin_39907762的博客
12-11 136
正文开始~写这篇文章的目的，主要是想弄懂 React 最新的 fiber 架构到底是什么东西，但是看了网上的很多文章，要不模棱两可，要不就是一顿复制粘贴，根本看不懂，于是开始认真钻研源码。钻研过程中，发现我想得太简单了，React 源码的复杂程度远超我的想象，于是打算分几个模块了剖析，今天先讲一讲 React 的更新策略从同步变为异步的演变过程。从 setState 说起React 16...
React组件复用的发展史
grooyo的博客
10-03 309
通过自定义Hook，可以将组件逻辑提取到可重用的函数中。现在假设聊天应用中有一个联系人列表，当用户在线时把名字设置为绿色。我们可以把类似的逻辑复制并粘贴到{当我们想在两个函数之间共享逻辑时，我们会把它提取到第三个函数中。而组件和Hook都是函数，所以同样也适用这种方式。自定义Hook是一个函数，其名称以“use”开头，函数内部可以调用其它的Hook.}}})}所以，之前的和{这段代码等价于原来的示例代码吗？等价，它的工作方式完全一样。
React中将async 同步调用接口变成异步调用
yasuifi的博客
05-25 896
useEffect(async () => { const fn1 = (() => { return new Promise(resolve => { const msg = '11'; setTimeout(() => { console.log(msg, '11'); resolve(msg) }, 2000); }).then(res => { ...
同步模式向异步模式的转换
weixin_34228387的博客
08-23 421
近期由于工作的需要，一直在重构服务器，其中，做得最多的，就是把服务器的架构模式从同步改为异步模式。 先简单的介绍下同步和异步两个概念： 同步模式：服务器在发送请求时，阻塞等待请求的响应； 优点：实现简单，同步接收数据，方便做各种统计和服务器的切换。缺点：服务不平稳，容易受到冲击，造成雪崩； 异步模式：服务器发送请求...
React-ES6 Promise的用法，async/await异步处理同步化
qk
11-06 913
Promise
React性讲座深度解析：React架构演变与关键技术
从文件的标题和描述来看，本次React性讲座草稿深入探讨了React框架中的关键概念和潜在缺陷，以及如何通过响应式编程原理来改进这些缺陷。内容主要围绕组件设计、性能优化、数据流处理等前端开发的核心议题。随着...
深入解析Backbone到React-Redux的技术演变
2015年1月21日，ReactLondon 上的演讲“从骨干到React-Redux”是关于如何将 Backone.js 的架构和概念与 React 和 Redux 结合起来，从而创建一个现代的、基于组件的前端应用架构。这次演讲扩展了如何利用这些工具来...
Web应用数据流演变：从手动到自动化的变迁
描述中的“时间从左到右”暗示了数据流向的时间线，而“箭头从依赖性指向依赖性”则强调了数据流向中的依赖关系，即数据流向是基于组件或模块间依赖关系而设计的。 ### 标签知识点解析 标签中列出的关键词“react,...
PureMVC解析
Peter的博客
12-25 4229
PureMVC框架的目标很明确，即把程序分为低耦合的三层：Model、View和Controller。它们合称为PureMVC框架的核心，由Facade统一管理。关于它的核心层，我们不需要管太多，只需要记得下面几点就可以了： 一、Model保存对Proxy对象的引用，Proxy负责操作数据模型，与远程服务通信存取数据。 二、View保存对Mediator对象的引用。由Mediator对象来操作具体的视图组件（View Component，例如Flex的DataGr...
第十三篇：ReactDOM.render 是如何串联渲染链路的？（上）
越陌度阡
11-04 645
由于 ReactDOM.render 的内容比较多，所以这里拆分了上中下三讲来讲解。 在上一讲，我们站在宏观角度对 Fiber 的架构分层和迭代动机有了充分的把握。从本讲开始，我们将以首次渲染为切入点，拆解 Fiber 架构下 ReactDOM.render 所触发的渲染链路，结合源码理解整个链路中所涉及的初始化、render 和 commit 等过程。 ReactDOM.render 调用栈的逻辑分层 开篇先给到你一个简单的 React AppDemo： import React from "r
react多个网络请求_React 中请求远程数据的四种方法
weixin_39949607的博客
12-19 810
react是一个专注的组件库。因此，它对如何请求远程数据没有什么建议。如果要通过HTTP请求数据并将其发送到Web API，可以考虑下面四种方法。内联写法集中管理自定义Hookreact-query/swr注意：在本文中，我将使用 fetch 进行 HTTP 调用，但是这些模式也适用于 Axios 之类的替代方法。另外，如果你使用的是 GraphQ L，还可以考虑使用 Apollo 之...
[通明境 · React架构]通俗地讲React，优雅地理解React
MyWay
03-15 527
[1.1万字] (=^▽^=)React源码并非洪水猛兽，知道方法，就可以很轻易地驯服它。文章基于最新的React源码进行调试及阅读，通俗地讲解React
react源码阅读3 update与updateQueue
tangding12的博客
04-01 649
react-dom后续updateContainer部分。阅读React包的源码版本为16.8.6。   在上一章节中我们看到了react-dom中render函数的逻辑是给传入的React组件创建了一个fiberRoot对象，用于标识它是整个应用的起点，上面拥有很多应用更新相关的表示符。然后创建对应的fiber给fiberRoot节点，fiber对象是每一个ReactElement都拥有的节点，...
生命周期 用户可以操作dom_React 生命周期的打怪升级之路
weixin_39777464的博客
11-26 161
号外号外！走过路过千万不要错过！截止目前为止 React 已经发布了 v16.12.0 版本, React 生命周期也是日常开发低头不见，抬头见的狗子，可惜狗子它变了。改变原因v16.3 版本之前， React 中的更新操作是同步的，这可能会导致性能问题。举个例子，假如有一个庞大的模块里面嵌套超级多的组件，一旦最顶部的 render 方法执行了，然后依次执行组件的 render 方法，直到最底层组...
react同步方法_深入 React 的 setState 机制
weixin_42465140的博客
01-30 1276
本文在我的 Github博客 https://github.com/Jacky-Summer/personal-blog 同步更新前言本篇写的 setState(涉及源码部分)是针对 React15 版本，即是没有 Fiber 介入的；为了方便看和写，所以选择旧版本，Fiber 写起来有点难，先留着将会写。setState 在 React 15 的原理能理解，16 版本的也是大同小异。虽...
react umi-request 一套统一的网络请求和错误处理方案
yellow757的博客
07-21 7971
参考文档：https://github.com/umijs/umi-request/blob/master/README_zh-CN.md#%E9%94%99%E8%AF%AF%E5%A4%84%E7%90%86 importrequest,{extend}from'umi-request'; import{message}from'antd'; import{history}from'umi'; consterrorHandler=(error:an...
11-05-react组件的生命周期
ange997的博客
10-30 239
问：react.js中的核心是什么？ 答：组件。 问：react中组件的核心是什么？ 答：状态 组件的生命周期。 生命周期函数： 又叫钩子函数，一个组件从出生到死亡，这个过程会自动地调用一个函数，这个函数我们叫钩子函数，又叫生命周期函数。 旧版生命周期函数 React v16.0前的生命周期 initalizaion 初始化 使用constructor()来完成初始化 setup props and state 设置组件初始化属性 和 状态 static defaultProps = { //
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值