AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

深入理解 react/redux 数据流并基于其优化前端性能

2019-12-03 387
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： ## 前言 react/redux 数据流已经是一个老生常谈的问题了，似乎现在谈已经失去了新鲜感。然而，深入理解 react/redux 数据流应该是一个专业 react 前端需要完全掌握的技能，如果未能充分理解，那么很多情况下，你并不知道你开发的应用是如何工作的，这很容易带来问题，从而影响项目的持续发展和可维护性。另一方面，随着 react hooks 和 react-redux 7.x 的发

前言

react/redux 数据流已经是一个老生常谈的问题了，似乎现在谈已经失去了新鲜感。然而，深入理解 react/redux 数据流应该是一个专业 react 前端需要完全掌握的技能，如果未能充分理解，那么很多情况下，你并不知道你开发的应用是如何工作的，这很容易带来问题，从而影响项目的持续发展和可维护性。另一方面，随着 react hooks 和 react-redux 7.x 的发布，在数据流方面又出现了一些新的知识点。react-redux 7.x 全面拥抱了 hooks，并且重新回到了基于 Subscriptions 的实现。这使得 react-redux 7.x 彻底解决了 6.x 的性能问题，甚至是所有 react-redux 版本中性能最好的。所以，是时候重新研究 react/redux 数据流，并基于其对我们应用的性能进行优化了。

react 数据流和渲染机制

基本 re-render 机制

<div onClick={() => this.setState({})}>
  {this.props.children}
</div>

// is equal to

React.createElement(
  'div', 
  {onClick: () => this.setState({})}, 
  this.props.children
)
  • 还有一种情况，Context api 导致的 re-render
    image.png

 不 re-render 的情况

If React sees the exact same element reference as last time, it bails out of re-renderin__g that child

在上方的例子中，其实已经提到了这条准则，我们来看一个 react-redux 中的实际例子：

const renderedChild = useMemo(() => {
  if (shouldHandleStateChanges) {
    return (
      <ContextToUse.Provider value={overriddenContextValue}>
        {renderedWrappedComponent}
      </ContextToUse.Provider>
    )
  }

  return renderedWrappedComponent
}, [ContextToUse, renderedWrappedComponent, overriddenContextValue])

return renderedChild

利用 useMemo，每次 store 中数据变化时，connect 了 store 的组件首先会计算 ContextToUse、renderedWrappedComponent、overriddenContextValue，看它们是否变了，如果没变，那么还是取上次渲染的 react element 的 reference，react 发现 react element 的 reference 没变，那么就不会对该组件进行 re-render。

  • PureComponent
  • React.memo
  • shouldComponentUpdate
  • React.useMemo

children 相关的 re-render 机制

组件内渲染 this.props.children 不 re-render

如前所述，如果子组件是 this.props.children, 父组件 re-render 不会导致子组件 re-render

children 属性变化导致 re-render

react 组件每次 re-render，如果它 render 中渲染的A组件包含有子组件，A组件的 children props 就会变化，从而导致 A 组件即使用 React.memo 优化后也会 re-render，例子：https://codesandbox.io/s/children-diff-re-render-mxx5g

const MainLayout = React.memo(props => {
  console.log("------render in MainLayout------");
  const prev = usePrevious(props);
  if (prev.children !== props.children) {
    console.log("children changed");
  }

  return (
    <div>
      <div>======== Main Layout =======</div>
      {props.children}
    </div>
  );
});

原因，和上方解释的原因相同，看非 jsx 的 react 代码：

class Hello extends React.Component {
  render() {
    return React.createElement("div", null, [
      React.createElement("div", null, "i am a div")
    ]);
  }
}

react key 和 diff 机制

  • Tree Diff 策略

    • 对树进行分层比较（dom 跨层级移动操作特别少）。
    • 对于同一层级的一组节点，它们可以通过唯一 id 进行区分。
    • 拥有相同类的两个组件将生成相似的树形结构，拥有不同类的两个组件将生成不同的树形结构。

React 只会简单的考虑同层级节点的位置变换，而对于不同层级的节点，只有创建和删除操作。
React 官方建议不要进行 DOM 节点跨层级的操作。
在开发组件时，保持稳定的 DOM 结构会有助于性能的提升。例如，可以通过 CSS 隐藏或显示节点，而不是真的移除或添加 DOM 节点。

  • Component Diff 策略

    • 如果是同一类型的组件，按照原策略继续比较 virtual DOM tree。
    • 如果不是，则将该组件判断为 dirty component，从而替换整个组件下的所有子节点。
    • 对于同一类型的组件，有可能其 Virtual DOM 没有任何变化，如果能够确切的知道这点那可以节省大量的 diff 运算时间，因此 React 允许用户通过 shouldComponentUpdate() 来判断该组件是否需要进行 diff。

  • element diff 策略

    • 当节点处于同一层级时，React diff 提供了三种节点操作，分别为：INSERT_MARKUP（插入）、MOVE_EXISTING（移动）和 REMOVE_NODE（删除）。
    • React 通过设置唯一 key的策略，对 element diff 进行算法优化，避免频繁的删除和插入操作

react-redux 数据流

基本数据流实现分析

  • 注册监听，订阅事件 (在 create store & Provider 中)

    • create store -> new Subscription in Provider -> subscription.onStateChange = subscription.notifyNestedSubs -> subscription subscribe onStateChange listener to store，and set listeners （this.listeners = createListenerCollection()）

  • 发布事件

    • dispatch -> call store listeners -> call subscription.onStateChange (equal to subscription.notifyNestedSubs) ->

  • Connect

    • 订阅到最近 connect 的祖先组件或者 store 中，当被订阅者 notifyNestedSubs 时，将触发 checkForUpdates
    • 自上而下，基于组件层级的层层订阅逻辑
    • subscription.onStateChange = checkForUpdates
    • subscription.trySubscribe()
    • 注意下方的：this.parentSub.addNestedSub，将订阅到最近的 connect 祖先组件的 subscription 中或者订阅到 store 中
  • Subscription
trySubscribe() {
  if (!this.unsubscribe) {
    this.unsubscribe = this.parentSub
      ? this.parentSub.addNestedSub(this.handleChangeWrapper)
    : this.store.subscribe(this.handleChangeWrapper)

    this.listeners = createListenerCollection()
  }
}

Store

基本的 Store 模型：

function createStore(reducer) {
    var state;
    var listeners = []

    function getState() {
        return state
    }
    
    function subscribe(listener) {
        listeners.push(listener)
        return function unsubscribe() {
            var index = listeners.indexOf(listener)
            listeners.splice(index, 1)
        }
    }
    
    function dispatch(action) {
        state = reducer(state, action)
        listeners.forEach(listener => listener())
    }

    dispatch({})

    return { dispatch, subscribe, getState }
}

通过 subscirbe 方法注册监听，在 dispatch 时，直接触发所有监听器。处理组件是否真的需要更新的逻辑不在 store 中。

Provider

function Provider({ store, context, children }) {
  const contextValue = useMemo(() => {
    const subscription = new Subscription(store)
    subscription.onStateChange = subscription.notifyNestedSubs
    return {
      store,
      subscription
    }
  }, [store])

  const previousState = useMemo(() => store.getState(), [store])

  useEffect(() => {
    const { subscription } = contextValue
    subscription.trySubscribe()

    if (previousState !== store.getState()) {
      subscription.notifyNestedSubs()
    }
    return () => {
      subscription.tryUnsubscribe()
      subscription.onStateChange = null
    }
  }, [contextValue, previousState])

  const Context = context || ReactReduxContext

  return <Context.Provider value={contextValue}>{children}</Context.Provider>
}

从以上代码可以看到，Provider 是对 react Context.Provider 的封装。Context.Provider 中的值 contextValue 为：

{
  store,
  subscription,
}

可以看到，当 store 中的 state change 的时候，将触发 notifyNestedSubs。但是，这些 nestedSubs 从哪里来呢？答案是下层组件在 Connect 时，在最近 connect 的祖先组件的 subscription 或者 store 中 addNestedSub。这里的逻辑即是上方提到的自上而下，基于组件层级的层层订阅逻辑。

Connect

下方是 Connect 实现的伪代码，并非真实实现：

function connect(mapStateToProps, mapDispatchToProps) {
  // It lets us inject component as the last step so people can use it as a decorator.
  // Generally you don't need to worry about it.
  return function (WrappedComponent) {
    // It returns a component
    return class extends React.Component {
      render() {
        return (
          // that renders your component
          <WrappedComponent
            {/* with its props  */}
            {...this.props}
            {/* and additional props calculated from Redux store */}
            {...mapStateToProps(store.getState(), this.props)}
            {...mapDispatchToProps(store.dispatch, this.props)}
          />
        )
      }
      
      componentDidMount() {
        // it remembers to subscribe to the store so it doesn't miss updates
        this.unsubscribe = store.subscribe(this.handleChange.bind(this))
      }
      
      componentWillUnmount() {
        // and unsubscribe later
        this.unsubscribe()
      }
    
      handleChange() {
        // and whenever the store state changes, it re-renders.
        this.forceUpdate()
      }
    }
  }
}

子在上方的简单模型中，在 store 中注册监听到 store 变化的回调函数，当 store 值变化时，将触发注册组件的 forceUpdate 方法，从而 re-render 组件。实际的实现中比这要复杂得多，也不是这种实现方式。不过，最基本的模型是如此的。这里涉及到一个问题，如何将 store 传递给对应的组件，前面的代码中其实已经看到，可以通过 Context 将 store 传递过去。
在实际实现中，要复杂得多，下方是实际 connect 函数，而 connect 大部分实现逻辑都封装在了 connectAdvanced 中。

function createConnect({
  connectHOC = connectAdvanced,
  mapStateToPropsFactories = defaultMapStateToPropsFactories,
  mapDispatchToPropsFactories = defaultMapDispatchToPropsFactories,
  mergePropsFactories = defaultMergePropsFactories,
  selectorFactory = defaultSelectorFactory
} = {}) {
  return function connect(
    mapStateToProps,
    mapDispatchToProps,
    mergeProps,
    {
      pure = true,
      areStatesEqual = strictEqual,
      areOwnPropsEqual = shallowEqual,
      areStatePropsEqual = shallowEqual,
      areMergedPropsEqual = shallowEqual,
      ...extraOptions
    } = {}
  ) {
    const initMapStateToProps = match(
      mapStateToProps,
      mapStateToPropsFactories,
      'mapStateToProps'
    )
    const initMapDispatchToProps = match(
      mapDispatchToProps,
      mapDispatchToPropsFactories,
      'mapDispatchToProps'
    )
    const initMergeProps = match(mergeProps, mergePropsFactories, 'mergeProps')

    return connectHOC(selectorFactory, {
      // used in error messages
      methodName: 'connect',

      // used to compute Connect's displayName from the wrapped component's displayName.
      getDisplayName: name => `Connect(${name})`,

      // if mapStateToProps is falsy, the Connect component doesn't subscribe to store state changes
      shouldHandleStateChanges: Boolean(mapStateToProps),

      // passed through to selectorFactory
      initMapStateToProps,
      initMapDispatchToProps,
      initMergeProps,
      pure,
      areStatesEqual,
      areOwnPropsEqual,
      areStatePropsEqual,
      areMergedPropsEqual,

      // any extra options args can override defaults of connect or connectAdvanced
      ...extraOptions
    })
  }
}

性能优化实现

性能优化实现是 react-redux 的关键部分。我们都可以自己实现一个类似于 eventEmitter 的发布订阅类，并基于其解决 react 应用的发布订阅更新组件逻辑。然而，如果我们都自己写，那么需要自己解决性能、开发规范、各种边界情况等等各种问题。而 react-redux 存在的意义就是把这些问题统一解决了，它是社区开发者们花了大量时间的结晶，让我们无需再去担心那些问题，而是可以放心地使用其提供的 API。在其实现中，下面3个问题是我们需要关注的。

1. 每次 store 变动，都会触发根组件 setState 从而导致 re-render。我们知道当父组件 re-render 后一定会导致子组件 re-render 。然而，引入 react-redux 并没有这个副作用，这是如何处理的？

其实在 react-redux v6 中，需要关心这个问题，在 v6 中，每次 store 的变化会触发根组件的 re-render。但是根组件的子组件不应该 re-render。其实是用到了我们上文中提到的 this.props.children。避免了子组件 re-render。在 v7 中，其实不存在该问题，store 中值的变化不会触发根组件 Provider 的 re-render。

2. 不同的子组件，需要的只是 store 上的一部分数据，如何在 store 发生变化后，仅仅影响那些用到 store 变化部分 state 的组件？

首先，我们抛开 store，对于父组件传入的 props，基于 React.memo，只在 connect 后的组件被传入的 props 真的改变后才会重新获取组件，否则直接使用 memo 的元组件，无需任何 react 相关的渲染计算：

const Connect = pure ? React.memo(ConnectFunction) : ConnectFunction

ConnectFunction 是原组件被 connect 后返回的新组件，它的 props 来自于父组件的传入。所以，如果父组件传入的 props 没有变，那么 connect 后的组件将不会被父组件触发 re-render。相当于是 PureComponent。

那么 dispatch 导致的 store 中 state 的变化是如何影响 connect 后的组件的 re-render 的呢？被 connect 的组件最终是否要 re-render，取决于被 connect 组件被传入的 props 是否变了。所以，关键点在于计算被 connect 组件最终被传入的 props。关键函数为：

function createChildSelector(store) {
  return selectorFactory(store.dispatch, selectorFactoryOptions)
}

const childPropsSelector = useMemo(() => {
  return createChildSelector(store)
}, [store])

// 非 store 更新导致的重新计算
const actualChildProps = usePureOnlyMemo(() => {
  if (
    childPropsFromStoreUpdate.current &&
    wrapperProps === lastWrapperProps.current
  ) {
    return childPropsFromStoreUpdate.current
  }
  return childPropsSelector(store.getState(), wrapperProps)
}, [store, previousStateUpdateResult, wrapperProps])

// store 更新导致的重新计算
newChildProps = childPropsSelector(
  latestStoreState,
  lastWrapperProps.current
)

关键点就在于 selectorFactory 的实现：

export function pureFinalPropsSelectorFactory(
  mapStateToProps,
  mapDispatchToProps,
  mergeProps,
  dispatch,
  { areStatesEqual, areOwnPropsEqual, areStatePropsEqual }
) {
  let hasRunAtLeastOnce = false
  let state
  let ownProps
  let stateProps
  let dispatchProps
  let mergedProps

  function handleFirstCall(firstState, firstOwnProps) {...}

  function handleNewPropsAndNewState() {
    stateProps = mapStateToProps(state, ownProps)

    if (mapDispatchToProps.dependsOnOwnProps)
      dispatchProps = mapDispatchToProps(dispatch, ownProps)

    mergedProps = mergeProps(stateProps, dispatchProps, ownProps)
    return mergedProps
  }

  function handleNewProps() {...}

  function handleNewState() {...}

  function handleSubsequentCalls(nextState, nextOwnProps) {
    const propsChanged = !areOwnPropsEqual(nextOwnProps, ownProps)
    const stateChanged = !areStatesEqual(nextState, state)
    state = nextState
    ownProps = nextOwnProps

    if (propsChanged && stateChanged) return handleNewPropsAndNewState()
    if (propsChanged) return handleNewProps()
    if (stateChanged) return handleNewState()
    return mergedProps
  }

  return function pureFinalPropsSelector(nextState, nextOwnProps) {
    return hasRunAtLeastOnce
      ? handleSubsequentCalls(nextState, nextOwnProps)
      : handleFirstCall(nextState, nextOwnProps)
  }
}

export default function finalPropsSelectorFactory(
  dispatch,
  { initMapStateToProps, initMapDispatchToProps, initMergeProps, ...options }
) {
  const mapStateToProps = initMapStateToProps(dispatch, options)
  const mapDispatchToProps = initMapDispatchToProps(dispatch, options)
  const mergeProps = initMergeProps(dispatch, options)

  if (process.env.NODE_ENV !== 'production') {
    verifySubselectors(
      mapStateToProps,
      mapDispatchToProps,
      mergeProps,
      options.displayName
    )
  }

  const selectorFactory = options.pure
    ? pureFinalPropsSelectorFactory
    : impureFinalPropsSelectorFactory

  return selectorFactory(
    mapStateToProps,
    mapDispatchToProps,
    mergeProps,
    dispatch,
    options
  )
}

可以看到，最终通过 mapStateToProps、mapDispatchToProps、mergeProps 计算得到最终的 props。
根据 props 是否变了，决定是否要触发组件 re-render。所以，在写 mapStateToProps 时，一定要按需从 store 的 state 中取需要的 state map 到 props 中，否则每次 dispatch 都可能导致 re-render。

if (newChildProps === lastChildProps.current) {
  // 直接通知下层 connect 的组件去执行订阅事件，本组件不触发 re-render
  if (!renderIsScheduled.current) {
    notifyNestedSubs() 
  }
} else {
  lastChildProps.current = newChildProps
  childPropsFromStoreUpdate.current = newChildProps
  renderIsScheduled.current = true

  // 通过 setState 来 re-render
  forceComponentUpdateDispatch({
    type: 'STORE_UPDATED',
    payload: {
      error
    }
  })
}
const renderedWrappedComponent = useMemo(
  () => <WrappedComponent {...actualChildProps} ref={forwardedRef} />,
  [forwardedRef, WrappedComponent, actualChildProps]
)

对于被 connect wrapped 的组件，需要在 forwardedRef, WrappedComponent, actualChildProps 有更新时，才会重新计算触发 re-render，这样又能对性能进一步优化。

const renderedChild = useMemo(() => {
  if (shouldHandleStateChanges) {
    return (
      <ContextToUse.Provider value={overriddenContextValue}>
        {renderedWrappedComponent}
      </ContextToUse.Provider>
    )
  }

  return renderedWrappedComponent
}, [ContextToUse, renderedWrappedComponent, overriddenContextValue])

return renderedChild

最后是前面提过的，最终渲染的 Child，也用 useMemo 进行性能优化。

3. 如何保障 connect 后的组件在 store 变化时，按组件层级顺序渲染？

react-redux 实现了自上而下的订阅逻辑。处于低层的组件会订阅到最近的 connect 了 store 的父组件 Subscriptions 实例。而当触发 re-render 时，父组件将先被触发，如果需要 re-render，将先触发父组件的 setState（useReducer），之后，当父组件渲染完成才在 useLayoutEffect 中触发子组件的回调事件。如果父组件不需要 re-render，那么直接触发子组件回调事件。这样，保证了组件是按层级顺序渲染的。

Components higher in the tree always subscribe to the store before their children do
image.png

代码：

// 被 connect 的组件自己 new 一个 subscription
const [subscription, notifyNestedSubs] = useMemo(() => {
  if (!shouldHandleStateChanges) return NO_SUBSCRIPTION_ARRAY

  const subscription = new Subscription(
    store,
    didStoreComeFromProps ? null : contextValue.subscription
  )

  const notifyNestedSubs = subscription.notifyNestedSubs.bind(
    subscription
  )

  return [subscription, notifyNestedSubs]
}, [store, didStoreComeFromProps, contextValue])

// 替换掉原先的 subscription，用该组件自己 new 出来的 subscription
const overriddenContextValue = useMemo(() => {
  if (didStoreComeFromProps) {
    return contextValue
  }

  return {
    ...contextValue,
    subscription
  }
}, [didStoreComeFromProps, contextValue, subscription])

// 如果 childProps 没变，该组件不触发 re-render，直接通知下层 connect 组件
if (newChildProps === lastChildProps.current) {
  if (!renderIsScheduled.current) {
    notifyNestedSubs()
  }
} else {
  lastChildProps.current = newChildProps
  childPropsFromStoreUpdate.current = newChildProps
  renderIsScheduled.current = true

  forceComponentUpdateDispatch({
    type: 'STORE_UPDATED',
    payload: {
      error
    }
  })
}

// 注册到最近的 connect 祖先组件的 subscription 中或 store 中
subscription.onStateChange = checkForUpdates
subscription.trySubscribe()

// 在 connect 后的组件添加 ContextToUse.Provider，以及更新 context 的 value 值，
// 使得下层组件从它这里获取 context，从而使得下层组件的事件订阅到该组件的 subscription 中
const renderedChild = useMemo(() => {
  if (shouldHandleStateChanges) {
    return (
      <ContextToUse.Provider value={overriddenContextValue}>
        {renderedWrappedComponent}
      </ContextToUse.Provider>
    )
  }

  return renderedWrappedComponent
}, [ContextToUse, renderedWrappedComponent, overriddenContextValue])

return renderedChild

react-redux 5、6、7 数据流对比

详细对比见 https://github.com/reduxjs/react-redux/issues/1177#issuecomment-468959889。这里不重复了。这个例子有助于我们理解嵌套的 connect 后的组件的 re-render 的详细流程。

dva 对 redux 数据流的封装

loading state 的添加

antd 的 CongfigProvider

image.png

antd 的 ConfigProvider 是基于 react context api 的封装，在其实现中，每次 ConfigProvider re-render 会导致 context provider 中的 value 变化，从而导致订阅了 ConfigProvider 的组件都 re-render。
context 导致 re-render 对比例子：
bug：https://codesandbox.io/s/unstated-next-with-memo-9k4rb
fix：https://codesandbox.io/s/unstated-next-with-memo-fix-stpjw

性能优化

  1. Context api 的性能其实比 redux 要差，所以 ConfigProvider 的优化也是十分要紧的，将 antd 的 ConfigProvider 往上层提，避免组件 re-render 导致 ConfigProvider re-render 从而导致所有订阅了 ConfigProvider 的 antd 组件 re-render
  2. redux 很快，但是不恰当使用，将使你的应用非常的慢：https://react-redux.js.org/api/connect image.png
  3. connect 包装后的组件相当于 PureComponent，此时父组件传 props 给 connect 后的子组件时，尽量不要传子组件不会用到的属性，因为如果这些属性变了也会导致子组件的 re-render，而如果不传不必要的属性，则能避免这些不必要的 re-render
  4. 恰当地使用 PureComponent 或 React.memo，避免不必要的 re-render，优化性能。但是，如果你确定你的组件在每次父组件 re-render 或者组件自身调用 setState 时都要 re-render，此时可以不用 PureComponent 或 React.memo，在一些情况下 PureComponent 可能会引起不想要的结果
  5. 不需要修改全局 store 的操作，例如发送数据请求给该组件自己用，可以不调用 dispatch，彻底避免掉 redux 的工作，这里涉及到 dva 对 dispatch 请求的封装，会修改 store 中的 loading state，导致订阅了该属性的组件被 re-render
  6. React 官方建议不要进行 DOM 节点跨层级的操作。在开发组件时，保持稳定的 DOM 结构会有助于性能的提升。例如，可以通过 CSS 隐藏或显示节点，而不是真的移除或添加 DOM 节点。

参考文献

文章标签：
JavaScript
前端开发
API
算法
开发者
关键词：
react前端
React Native前端
优化前端
React Native redux
React Native优化
过客匆匆_
目录
相关文章
土木林森
|
11天前
|
前端开发 JavaScript 开发者
颠覆传统：React框架如何引领前端开发的革命性变革
【10月更文挑战第32天】本文以问答形式探讨了React框架的特性和应用。React是一款由Facebook推出的JavaScript库，以其虚拟DOM机制和组件化设计，成为构建高性能单页面应用的理想选择。文章介绍了如何开始一个React项目、组件化思想的体现、性能优化方法、表单处理及路由实现等内容，帮助开发者更好地理解和使用React。
土木林森
38 9
龙大吉
|
5天前
|
编解码 前端开发 JavaScript
从入门到精通：揭秘前端开发中那些不为人知的优化秘籍！
前端开发是充满无限可能的领域，从初学者到资深专家，每个人都追求更快、更稳定、更用户体验友好的网页。本文介绍了四大优化秘籍：1. HTML的精简与语义化；2. CSS的优雅与高效；3. JavaScript的精简与异步加载；4. 图片与资源的优化。通过这些方法，可以显著提升网页性能和用户体验。
龙大吉
13 3
土木林森
|
15天前
|
缓存 前端开发 JavaScript
前端性能优化：Webpack与Babel的进阶配置与优化策略
【10月更文挑战第28天】在现代Web开发中，Webpack和Babel是不可或缺的工具，分别负责模块打包和ES6+代码转换。本文探讨了它们的进阶配置与优化策略，包括Webpack的代码压缩、缓存优化和代码分割，以及Babel的按需引入polyfill和目标浏览器设置。通过这些优化，可以显著提升应用的加载速度和运行效率，从而改善用户体验。
土木林森
35 6
土木林森
|
16天前
|
缓存 监控 前端开发
前端工程化：Webpack与Gulp的构建工具选择与配置优化
【10月更文挑战第26天】前端工程化是现代Web开发的重要趋势，通过将前端代码视为工程来管理，提高了开发效率和质量。本文详细对比了Webpack和Gulp两大主流构建工具的选择与配置优化，并提供了具体示例代码。Webpack擅长模块化打包和资源管理，而Gulp则在任务编写和自动化构建方面更具灵活性。两者各有优势，需根据项目需求进行选择和优化。
土木林森
47 7
土木林森
|
15天前
|
前端开发 JavaScript Android开发
前端框架趋势：React Native在跨平台开发中的优势与挑战
【10月更文挑战第27天】React Native 是跨平台开发领域的佼佼者，凭借其独特的跨平台能力和高效的开发体验，成为许多开发者的首选。本文探讨了 React Native 的优势与挑战，包括跨平台开发能力、原生组件渲染、性能优化及调试复杂性等问题，并通过代码示例展示了其实际应用。
土木林森
44 2
土木林森
|
16天前
|
缓存 前端开发 JavaScript
前端工程化：Webpack与Gulp的构建工具选择与配置优化
【10月更文挑战第27天】在现代前端开发中，构建工具的选择对项目的效率和可维护性至关重要。本文比较了Webpack和Gulp两个流行的构建工具，介绍了它们的特点和适用场景，并提供了配置优化的最佳实践。Webpack适合大型模块化项目，Gulp则适用于快速自动化构建流程。通过合理的配置优化，可以显著提升构建效率和性能。
土木林森
29 2
土木林森
|
17天前
|
前端开发 JavaScript 开发者
“揭秘React Hooks的神秘面纱：如何掌握这些改变游戏规则的超能力以打造无敌前端应用”
【10月更文挑战第25天】React Hooks 自 2018 年推出以来，已成为 React 功能组件的重要组成部分。本文全面解析了 React Hooks 的核心概念，包括 `useState` 和 `useEffect` 的使用方法，并提供了最佳实践，如避免过度使用 Hooks、保持 Hooks 调用顺序一致、使用 `useReducer` 管理复杂状态逻辑、自定义 Hooks 封装复用逻辑等，帮助开发者更高效地使用 Hooks，构建健壮且易于维护的 React 应用。
土木林森
28 2
G0518
|
3天前
|
缓存 前端开发 JavaScript
前端性能优化：让你的网站更快、更流畅
前端性能优化：让你的网站更快、更流畅
G0518
11 0
土木林森
|
16天前
|
前端开发 Android开发 开发者
前端框架趋势：React Native在跨平台开发中的优势与挑战
【10月更文挑战第26天】近年来，React Native凭借其跨平台开发能力在移动应用开发领域迅速崛起。本文将探讨React Native的优势与挑战，并通过示例代码展示其应用实践。React Native允许开发者使用同一套代码库同时构建iOS和Android应用，提高开发效率，降低维护成本。它具备接近原生应用的性能和用户体验，但也面临平台差异、原生功能支持和第三方库兼容性等挑战。
土木林森
28 0
一缕微风绕指柔
|
1月前
|
前端开发 JavaScript 开发者
深入理解React Hooks：提升前端开发效率的关键
【10月更文挑战第5天】深入理解React Hooks：提升前端开发效率的关键
一缕微风绕指柔
50 0

热门文章

最新文章

  • 1
    React适合开发什么类型的应用？
  • 2
    #yyds干货盘点 【React工作记录三十一】dva.js初识
  • 3
    【TypeScript技术专栏】TypeScript与React的完美结合
  • 4
    #yyds干货盘点 react笔记之完成Counter组件
  • 5
    react-native-easy-app 详解与使用之（三） View，Text，Image，Flatlist
  • 6
    React-Native 爬坑
  • 7
    照着官方文档学习react
  • 8
    React Native-组件的引用
  • 9
    【REACT NATIVE 系列教程之二】创建自定义组件&&导入与使用示例
  • 10
    一段探索React自建内部构造的旅程
  • 1
    告别‘老司机’时代，AJAX与Fetch API让你的前端与Python后端无缝对接！
    59
  • 2
    现代前端开发中的响应式设计原则与实践
    90
  • 3
    现代前端开发中的响应式设计实践与优化
    60
  • 4
    前端框架与库 - Vue.js基础：模板语法、数据绑定
    134
  • 5
    前端项目部署问题总结
    65
  • 6
    前端框架与库 - React生命周期与Hooks
    50
  • 7
    前端性能优化都有那些方案 ？
    73
  • 8
    高级前端常见的面试题？
    101
  • 9
    前端框架与库 - React基础：组件、Props、State
    71
  • 10
    技术心得：前端点击按钮，导入excel文件，上传到后台，excel接收和更新数据
    52

    • 相关课程

    更多
  • Ajax 前端开发入门与实战
  • React 入门与实战
  • React 入门教程开发文档
  • 零基础学前端HTML+CSS
  • 前端开发CSS基础
  • 前端开发框架Bootstrap使用教程

    • 相关电子书

    更多
  • 利用编译将 Vue 组件转成 React 组件
  • React Native 全量化实践
  • React在大型后台管理项目中的工程实践

    • 相关实验场景

    更多
  • 前端开发基础3：CSS3常见显示属性
  • 前端开发基础6：Node.js和LESS预编译工具
  • 前端开发基础2：VS Code和Edge的联动开发
  • 前端开发基础1：前端开发环境的安装和配置
    • 下一篇
    阿里云OSS设置跨域访问