React Hooks는 6년 전에 출시되었지만 오늘날까지도 선임 React 엔지니어들조차도 오류가 발생하는 것을 볼 수 있습니다. 최신 버전의 React 문서에서 핵심 팀은 useEffect의 잘못된 사용 사례를 가르치기 위해 많은 노력을 기울였으나 실제 프로젝트에서는 오류가 계속 발생합니다.
이번 게시물에서는 다른 접근 방식을 시도해 보겠습니다. React와 파생의 관계를 이해하고 이를 더 많이 사용해야 하는 이유를 살펴보겠습니다.
React는 완전히 반응하지는 않지만 결국 앱을 만드는 개발자에게는 그다지 중요하지 않습니다. 여기서 차이점은 React가 따르는 대략적인 접근 방식으로 인해 상태 전환으로 인해 발생한 변경 사항을 실제로 식별하기 위해 다시 렌더링해야 한다는 것입니다.
그러므로 다음과 같은 간단한 React 구성요소를 생각해 보세요.
function Example() { const [count, setCount] = useState(0) const text = `count is ${count}`; return ( <button onClick={() => setCount((count) => count + 1)}> {text} </button> ); }
카운트 상태를 변경하면 setCount를 호출하여 상태 값을 업데이트하고 다시 렌더링을 예약합니다. 좋아요, React는 이 컴포넌트를 다시 호출하여 다시 렌더링할 것입니다. 지금 이 순간 React에게 렌더에서 무엇이 바뀌었는지 묻는다면 뭐라고 대답해야 할까요?
아마도 겸손한 “모르겠다”.
React는 다른 세분화된 반응 라이브러리처럼 종속성을 관리하는 복잡한 데이터 구조로 상태를 추적하지 않습니다. React는 컴포넌트를 다시 호출해야 합니다. 이 새로운 호출에서 생성된 카운트 상수는 새로운 값을 가지며 그 위에는 문자열을 사용하여 새 상수를 생성합니다. 예를 들어 카운트 값이 1로 변경된 경우 “count is 1”입니다.
그런 다음 JSX는 한 번의 변경으로 구조를 생성하고 버튼 내부 텍스트는 “count is 1”이 아니며 React는 조정 프로세스를 수행하고 이 변경 사항을 식별하여 실제 DOM에 적용합니다. 당연하죠?
이때 React에게 무엇이 바뀌었는지 물어보면 아마도 “Example 컴포넌트의 버튼 텍스트”라고 대답할 것입니다.
잠깐, 텍스트 상수는 어떻습니까? 그것도 바뀌었는데, 그것이 만든 v-dom(이 용어의 문제점을 알지만 일반적으로 이렇게 부르는 방식) 구조가 왜 중요한가요?
React의 경우 내부적으로 생성한 변수와 상수는 중요하지 않습니다. 중요한 것은 상태가 변경된 다음 구성 요소 호출이 반환된다는 것입니다.
중간 부분은 모두 뷰 구조를 만드는 과정의 일부입니다. 물론 이 모든 데이터는 반환 JSX에 영향을 미칠 수 있으며, 이것이 React 모델의 핵심이며, 구성 요소 호출의 결과를 고려하고 이에 따라 뷰에 따라 DOM을 업데이트합니다.
아마도 React 모델의 단순화를 다음과 같이 보셨을 것입니다.
function Example() { const [count, setCount] = useState(0) const text = `count is ${count}`; return ( <button onClick={() => setCount((count) => count + 1)}> {text} </button> ); }
상태 기능의 결과로 봅니다. 이 경우 뷰는 상태에 따라 변경되는 파생물입니다. 따라서 이 용어와 내부 구성 요소 데이터에 대해서는 React는 파생 기계입니다.
구성 요소 내부에 생성한 모든 변수와 상수는 구성 요소 호출 중에도 그대로 유지됩니다. 위에서 사용한 예제에서는 예제 구성 요소를 다시 렌더링할 때마다 새로운 상수 텍스트가 생성되었습니다. 일부 소품이나 상태를 기반으로 새 값이 필요한 경우 계산에서 해당 상태와 소품을 사용하여 새 변수를 생성합니다.
React 문서의 예를 들어보겠습니다.
view= f(state)
여기에는 몇 가지 문제가 있습니다. 우선 국가의 성격입니다.
앱에 이런 지역 상태가 필요한 이유는 무엇인가요? 데이터를 유지하고 사용자가 이를 변경할 수 있도록 합니다. fullName 상태는 사용자가 아니라 useEffect에 의해 변경됩니다. 새로운 가치를 창출하기 위해 다른 상태를 사용하고 있습니다. 다시 말하지만, React에서는 구성 요소 내부에서 생성하는 모든 변수와 상수가 상태와 소품을 사용하여 해당 값을 계산할 수 있습니다. 파생, React의 기본 동작.
이 예에는 런타임과 관련된 또 다른 문제가 있습니다. 이 경우 첫 번째 렌더링에서 fullName 값은 빈 문자열이 됩니다. React는 이 구성 요소의 JSX를 반환하여 UI에 렌더링하고 브라우저 페인팅 프로세스를 따른 다음 구성 요소의 useEffects를 호출합니다. 이 순간 새로운 재렌더링을 예약하는 setfullName 호출이 발생합니다. React는 이제 전체 이름을 Taylor Swift로 사용하여 구성 요소를 다시 호출한 다음 새 텍스트 값으로 UI를 업데이트합니다.
런타임 측면에서 2개의 렌더링을 수행하고 있는데 그 중 하나는 잘못된 데이터로 불필요한 렌더링입니다. 사용자에게는 값이 비어 있고 시각적인 버그로 보일 수 있기 때문에 성능과 안정성 측면에서 더 나쁩니다.
따라서 React 파생 모델에 따라 간단히 다음과 같이 변경할 수 있습니다.
function Form() { const [firstName, setFirstName] = useState('Taylor'); const [lastName, setLastName] = useState('Swift'); // ? Avoid: redundant state and unnecessary Effect const [fullName, setFullName] = useState(''); useEffect(() => { setFullName(firstName + ' ' + lastName); }, [firstName, lastName]); //... return <span>{fullName}</span>; }
이제 렌더링은 1개뿐이므로 불필요한 렌더링은 방지됩니다. 그리고 파생을 사용하는 것만으로는 효과를 사용하지 않을 것입니다. 최신 버전의 상태 값을 사용하여 다시 렌더링할 때마다 업데이트됩니다.
맞습니다. 이 경우에는 useMemo를 사용하여 useEffect에 사용했던 것과 동일한 종속성 배열을 추가하면 됩니다. React의 메모이제이션 모델은 기본 동작, 즉 모든 재렌더링에서 새로운 파생물을 생성하는 것을 피하는 방법일 뿐입니다. useMemo를 사용하면 상태와 소품을 수동으로 추적하고 일부가 변경된 경우 파생물을 다시 생성하면 됩니다.
useEffect는 값 변경 시 외부 동기화에 필요합니다. UI 개발에서는 이것이 의미가 있는 드문 경우가 거의 없습니다. 일반적으로 서버 API 호출과 같은 외부 변경은 사용자 작업에서 발생하기 때문입니다(그런데 사용자 인터페이스를 만들고 있습니다). 이는 useEffect가 아닌 이벤트 핸들러에서 발생합니다.
useEffect를 사용하여 상태를 업데이트하는 경우 파생을 사용하여 동일한 업데이트를 수행하여 앞에서 언급한 모든 문제를 피할 수 있습니다.
파생이 작동하지 않거나, 몇 안 되는 특정 사례 중 하나에 해당하거나, 국가의 설계나 솔루션 자체에 문제가 있는 경우. 문제는 없지만 이런 경우에는 컴포넌트를 검토하여 향후 컴포넌트 코드 문제를 피하는 것이 좋습니다.
이것이 React 파생의 기본이지만 여기에는 빠진 것이 있습니다.
간단한 GET 요청과 같이 일부 상태를 매개변수로 사용하고 상태가 변경될 때마다 다시 계산해야 하는 비동기식 파생을 수행해야 하는 경우 어떻게 되나요?
다음 포스팅 주제입니다.
또 봐요!
위 내용은 당신은 React의 파생을 모릅니다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!