여러분은 리액트에 대해 얼마나 알고 있나요? 반응에 관해 주의할 사항 요약

이 글에서는 주로 컨테이너 컴포넌트와 컴포넌트 속성, setState 비동기성 등 react에 대해 알아야 할 사항에 대해 설명합니다. 이 글을 함께 읽어볼까요

Container 컴포넌트와 Presentational 컴포넌트

컴포넌트 작성 시 React를 사용하면 구성 요소를 컨테이너 구성 요소와 프레젠테이션 구성 요소로 의식적으로 나누어야 구성 요소를 작성할 때 이 구성 요소가 어떤 역할을 담당해야 하는지 더 명확하게 알 수 있습니다.

컨테이너 구성 요소는 네트워크 요청 전송, 요청 데이터 처리, 처리된 데이터를 하위 구성 요소의 Props에 전달하는 등 비즈니스 프로세스 로직을 처리하는 역할을 담당합니다. 동시에 컨테이너 구성 요소는 소스 데이터의 메서드를 제공하고 이를 Props 형식으로 하위 구성 요소에 전달합니다. 하위 구성 요소의 상태 변경으로 인해 소스 데이터가 변경되면 하위 구성 요소는 이러한 변경 사항을 다음과 같이 동기화합니다. 컨테이너 구성 요소에서 제공하는 메서드를 호출합니다.

프리젠테이션 컴포넌트는 컴포넌트의 외관, 즉 컴포넌트가 어떻게 렌더링되는지를 담당하며 강한 응집력을 가지고 있습니다. 프리젠테이션 컴포넌트는 렌더링에 사용되는 컴포넌트 속성(Props)을 어떻게 가져오는지는 신경 쓰지 않습니다. 단지 이러한 Prop을 사용하여 컴포넌트를 렌더링하는 방법만 알면 됩니다. 속성을 얻는 방법은 컨테이너 구성 요소의 책임입니다. 프리젠테이션 컴포넌트의 상태 변경을 소스 데이터와 동기화해야 하는 경우 컨테이너 컴포넌트의 메소드를 호출해야 합니다. 이 메소드는 일반적으로 Props를 통해 프리젠테이션 컴포넌트에 전달됩니다.

예를 들어 Todo 프로젝트에는 Todo 구성 요소와 TodoList 구성 요소가 있습니다. Todo 구성 요소는 서버에서 할 일 목록을 가져온 후 전달되는 컨테이너 구성 요소입니다. 표시할 TodoList입니다. TodoList에 새 할일 항목을 생성한 후 TodoList의 Props를 통해 Todo 컴포넌트에 할일 항목을 저장하는 메소드를 호출하여 새 할일 항목을 서버에 동기화해야 합니다.

컨테이너 구성 요소와 프리젠테이션 구성 요소는 서로 중첩될 수 있습니다. 컨테이너 구성 요소는 여러 프리젠테이션 구성 요소를 포함할 수 있으며 프리젠테이션 그룹에는 컨테이너 구성 요소와 기타 프리젠테이션 구성 요소도 포함될 수 있습니다. 이러한 분업은 컴포넌트 렌더링과 직접적인 관련이 없는 로직을 중앙 집중화하여 컨테이너 컴포넌트를 담당하게 할 수 있으며, 프리젠테이션 컴포넌트는 컴포넌트의 렌더링 로직에만 집중하므로 프리젠테이션 컴포넌트를 재사용하기가 더 쉬워집니다. 매우 간단한 페이지의 경우 일반적으로 하나의 컨테이너 구성 요소만으로 충분하지만 담당 페이지의 경우 여러 컨테이너 구성 요소가 필요합니다. 그렇지 않으면 모든 비즈니스 논리가 하나의 컨테이너 구성 요소에서 처리되면 구성 요소가 매우 복잡해집니다. , 이 구성 요소에서 얻은 소스 데이터는 사용된 최종 디스플레이 구성 요소에 도달하기 전에 구성 요소 Prop의 여러 레이어를 통과해야 할 수도 있습니다.

Props, State 및 컴포넌트의 공통 속성

Props와 State의 개념은 매우 명확합니다. 컴포넌트의 공통 속성은 컴포넌트에서 바로 아래에 마운트되는 속성을 나타냅니다. 실제로 Props와 State도 구성 요소의 두 가지 공통 속성입니다. 왜냐하면 this.props와 this.state를 통해 직접 가져올 수 있기 때문입니다. 그렇다면 어떤 시나리오에서 Props, State 및 기타 구성 요소의 공통 속성을 사용해야 할까요?

Props와 State는 모두 구성 요소 렌더링에 사용됩니다. 즉, 구성 요소의 최종 모습은 구성 요소의 Prop과 State에 따라 달라집니다. Properties 및 State가 변경되면 구성 요소의 렌더링 방법이 트리거됩니다. 그러나 둘 사이에는 차이점이 있습니다. Props는 상위 구성 요소에서 전달되는 읽기 전용 데이터인 반면 State는 구성 요소 자체에 의해 유지되는 상태이며 변경 가능합니다. 상태는 Prop의 변경에 따라 변경될 수 있습니다. 구성 요소에 다른 속성이 필요하고 이 속성이 구성 요소 렌더링과 관련이 없는 경우(즉, 렌더링 메서드에서 사용되지 않음) 이 속성은 구성 요소의 상태입니다.

예를 들어 구성 요소에 타이머가 필요하고 몇 초마다 구성 요소의 상태를 변경하는 경우 this.timer 속성을 정의하여 구성 요소WillUnmount 시 타이머를 지울 수 있습니다. (자세한 내용을 알고 싶으면 PHP 중국어 웹사이트React Reference Manual 칼럼을 참고하세요.)

setState asyncronicity

React 공식 웹사이트에서는 this.state와 this.props의 업데이트가 비동기적일 수 있다고 언급했으며, React는 성능상의 이유로 여러 setState 호출이 하나의 State 업데이트로 병합되었습니다. 따라서 다음 상태를 계산하기 위해 this.props 및 this.state의 값에 의존하지 마십시오. 공식 웹사이트의 코드 예제 인용:

// Wrong
this.setState({
  counter: this.state.counter + this.props.increment,
});

이 작업을 수행해야 하는 경우 함수를 매개 변수로 사용하는 다른 setState 메서드를 사용할 수 있습니다. 이 함수의 첫 번째 매개 변수는 이전 State이고 두 번째 매개 변수는 최신 매개 변수입니다. 소품을 받았습니다. 아래와 같이:

// Correctthis.setState(function(prevState, props) {
  return {
    counter: prevState.counter + props.increment
  };
});

在调用setState之后，也不能立即使用this.state获取最新状态，因为这时的state很可能还没有被更新，要想保证获取到的state是最新的state，可以在componentDidUpdate中获取this.state。也可以使用带用回调函数参数版本的setStatesetState(stateChange, [callback])，回调函数中的this.state会保证是最新的state。

componentWillReceiveProps

当组件的属性可能发生变化时，这个方法会被调用。这里说可能，是因为父组件render方法每次被调用时，子组件的这个方法都会被调用（子组件第一次初始化时除外），但并不一定每次子组件的属性都会发生变化。如果组件的State需要根据Props的变化而变化，那么这个方法就是最适合这个这个逻辑的地方。例如当Props变化时，组件的State需要重置，就可以在这个方法中调用this.setState()来重置状态。需要注意，在这个方法中调用this.setState()并不会重新触发componentWillReceiveProps的调用，也不会导致render方法被触发两次。一般情况下，接收到新Props会触发一次render，调用this.setState也会触发一次render，但在componentWillReceiveProps中调用this.setState，React会把原本需要的两次render，合并成一次。

shouldComponentUpdate

这个方法常作为优化React性能使用。当shouldComponentUpdate返回false时，组件本次的render方法不会被触发。可以通过在这个方法中比较前后两次state或者props，根据实际业务场景决定是否需要触发render方法。

React提供了一个React.PureComponent组件，这个组件重写了shouldComponentUpdate，会对前后两次的state和props进行浅比较，如何不一致，才会返回true，触发后续的render方法。这里的浅比较指，只会对state和props的第一级属性进行比较（使用!==），这满足一般的使用场景。如果你的组件继承了React.PureComponent，但在setState时，传入的state是直接修改的原有state对象，就会因为依然满足浅比较的条件，而不会重新触发render方法，导致最终DOM和state不一致。例如state={books: ['A','B']}，在setState时，使用this.setState({name: this.state.books.push('C')})直接修改books对象，这样虽然books内容发生了修改，但因为对象引用并没有变化，所以依然满足浅比较条件，不会触发render方法。

一般情况下，让shouldComponentUpdate返回默认的true是不会有太大问题的。虽然这样可能导致一些不必要的render方法被调用，但render方法直接操作的是虚拟DOM，只要虚拟DOM没有发生变化，并不会导致实体DOM的修改。而JS慢是慢在实体DOM的修改上。只要你的render方法不是很复杂，多调用几次render方法并不会带来多大的性能开销。

render

父组件每次render方法被调用，或者组件自己每次调用setState方法，都会触发组件的render方法（前提是shouldComponentUpdate使用默认行为，总是返回true）。那么组件每次render，是不是都会导致实体DOM的重新创建呢？答案是，不是！

React之所以比直接操作DOM的JS库快，原因是React在实体DOM之上，抽象出一层虚拟DOM，render方法执行后，得到的是虚拟DOM，React 会把组将当前的虚拟DOM结构和前一次的虚拟DOM结构做比较，只有存在差异性，React才会把差异的内容同步到实体DOM上。如果两次render后的虚拟DOM结构保持一致，并不会触发实体DOM的修改。

React速度快的原因，还有一个是它出色的Diff算法。标准的比较两棵树的Diff算法的时间复杂是 O(n3) 。而React基于非常符合实际场景的两个假设，就将Diff算法的时间复杂度降到了接近O(n)。这两个假设是：

<li>

如果两个组件或元素类型不同，那么他们就是完全不同的树，不需要再比较他们的子节点。例如，<article></article>和<comment></comment>将产生是两个完全的树状结构；<p>children</p>和<p>children</p>也是两个完全不同的树。这种情况下，组件会被完全重建，旧的DOM节点被销毁，组件经历componentWillUnmount()，然后重新创建一棵新树， 组件经历 componentWillMount() 和  componentDidMount()。

<li>

可以为组件或元素设置key属性，key用来标识这个组件或元素。key不需要全局唯一，只需要在兄弟组件或兄弟元素间保证唯一性就可以。key常用到集合（List）元素中。例如：

<ul><li key=&#39;a&#39;>Book A</li><li key=&#39;b&#39;>Book B</li></ul>

当在第一个位置插入一条记录Book C 时，

<ul><li key=&#39;c&#39;>Book C</li><li key=&#39;a&#39;>Book A</li><li key=&#39;b&#39;>Book B</li></ul>

由于有key的标识，React知道此时新增了一条记录，会创建一个新的<li>元素，并把它插入到列表中的第一个位置。如果没有设置key，React并不知道是新增了一条记录，还是原来的两条记录完全替换成新的三条记录，或者其他更加复杂的修改场景。React需要自上而下的比较每一条记录，这样每次比较节点都不同，所以需要修改两次节点，然后再新增一个节点，效率明显要差很多。

这里同时揭露了另一个问题，不要使用元素在集合中的索引值作为key，因为一旦集合中元素顺序发生改变，就可能导致大量的key失效，进而引起大量的修改操作。

如何发送网络请求

当我们需要从服务器获取数据时，我们应该在组件的哪一个生命周期方法中发送网络请求呢？React官网上提到，可以在componentDidMount中发送网络请求，这也是一般情况下的最佳实践。有些人也会把发送网络请求放在componentWillMount中，并且认为这个方法先于componentDidMount调用，所以可以更快地获取数据。个人认为，这种使用方法一般也是没有问题的，但在一些场景下会出现问题，比如需要在服务器端渲染时，componentWillMount会被调用两次，一次是在Server端，一次是在Client端。可参考这篇文章。

本篇文章到这就结束了（想看更多就到PHP中文网React使用手册栏目中学习），有问题的可以在下方留言提问。

위 내용은 여러분은 리액트에 대해 얼마나 알고 있나요? 반응에 관해 주의할 사항 요약의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!