React 튜토리얼: 구성 요소, 후크 및 성능
게시 됨: 2022-03-11React 튜토리얼의 첫 번째 부분에서 지적했듯이 React를 시작하는 것은 상대적으로 쉽습니다. Create React App(CRA)을 사용하여 시작하고 새 프로젝트를 시작하고 개발을 시작합니다. 슬프게도, 특히 React를 처음 접하는 경우 시간이 지남에 따라 코드를 유지 관리하기가 다소 어려워지는 상황에 직면할 수 있습니다. 구성 요소가 불필요하게 커지거나 구성 요소일 수 있지만 구성 요소가 아닌 요소로 끝날 수 있으므로 결국 여기저기서 반복적인 코드를 작성할 수 있습니다.
그것이 바로 React 개발 솔루션에 대해 생각하기 시작함으로써 React 여정을 시작하려고 노력해야 하는 곳입니다.
새로운 앱, 나중에 React 애플리케이션으로 변환해야 하는 새로운 디자인에 접근할 때마다 먼저 스케치에 어떤 구성 요소가 포함될지, 스케치를 더 쉽게 관리할 수 있도록 스케치를 분리하는 방법, 어떤 요소가 반복적(또는 최소한 그들의 행동). "미래에 유용할" 수 있는 코드를 추가하지 않도록 하십시오. 유혹적일 수 있지만 미래는 오지 않을 수 있으며 구성 가능한 옵션이 많이 있는 추가 일반 기능/구성 요소를 유지하게 될 것입니다.
또한 구성 요소가 2-3 창 높이보다 길면 나중에 읽기 쉽기 때문에 가능한 경우 분리할 가치가 있습니다.
React의 제어된 구성 요소와 제어되지 않는 구성 요소
대부분의 응용 프로그램에는 입력이 필요하고 사용자와의 상호 작용 형식이 필요하여 사용자가 무언가를 입력하고, 파일을 업로드하고, 필드를 선택하는 등의 작업을 수행할 수 있습니다. React는 제어된 구성 요소와 제어되지 않는 구성 요소라는 두 가지 별개의 방식으로 사용자 상호 작용을 처리합니다.
제어된 구성 요소의 값은 이름에서 알 수 있듯이 사용자와 상호 작용하는 요소에 값을 제공하여 React에 의해 제어되는 반면 제어되지 않는 요소는 값 속성을 얻지 못합니다. 그 덕분에 우리는 React 상태가 되는 단일 소스를 가지고 있으므로 화면에서 보고 있는 것과 현재 상태에 있는 것 사이에 불일치가 없습니다. 개발자는 상태를 변경하는 양식과의 사용자 상호 작용에 응답하는 함수를 전달해야 합니다.
class ControlledInput extends React.Component { state = { value: "" }; onChange = (e) => this.setState({ value: e.target.value }); render() { return ( <input value={this.state.value} onChange={this.onChange}/> ); } }제어되지 않는 React 구성 요소에서는 값이 어떻게 변경되는지 신경 쓰지 않지만 정확한 값을 알고 싶다면 ref를 통해 액세스하면 됩니다.
class UncontrolledInput extends React.Component { input = React.createRef(); getValue = () => { console.log(this.input.current.value); }; render() { return ( <input ref={this.input}/> ); } } 그렇다면 언제 어떤 것을 사용해야 할까요? 대부분의 경우 제어된 구성 요소가 필요한 방법이지만 몇 가지 예외가 있습니다. 예를 들어, React에서 제어되지 않는 구성 요소를 사용해야 하는 한 가지 경우는 값이 읽기 전용이고 프로그래밍 방식으로 설정할 수 없기 때문에(사용자 상호 작용이 필요함) file 유형 입력입니다. 또한 제어된 구성 요소가 더 읽기 쉽고 작업하기 쉽다는 것을 알았습니다. 제어된 구성 요소에 대한 유효성 검사는 다시 렌더링을 기반으로 하며 상태가 변경될 수 있으며 입력에 문제가 있음(예: 형식 또는 비어 있음)이 있음을 쉽게 나타낼 수 있습니다.
참조
우리는 이미 refs 에 대해 언급했는데, 이는 16.8에서 후크가 나타날 때까지 클래스 구성 요소에서 사용할 수 있었던 특수 기능입니다.
참조는 참조를 통해 개발자에게 React 구성 요소 또는 DOM 요소(ref를 첨부하는 유형에 따라 다름)에 대한 액세스 권한을 부여할 수 있습니다. 코드를 읽기가 조금 더 어렵게 만들고 위에서 아래로 데이터 흐름을 끊기 때문에 이러한 코드를 피하고 필수 시나리오에서만 사용하는 것이 좋습니다. 그러나 특히 DOM 요소에서 필요한 경우가 있습니다(예: 프로그래밍 방식으로 포커스 변경). React 컴포넌트 요소에 첨부할 때 참조하는 컴포넌트 내에서 자유롭게 메소드를 사용할 수 있습니다. 그러나 더 나은 처리 방법이 있으므로 이 관행은 피해야 합니다(예: 상태를 높이고 기능을 상위 구성 요소로 이동).
또한 Refs에는 세 가지 다른 방법이 있습니다.
- 문자열 리터럴(레거시 및 피해야 함)을 사용하여
- ref 속성에 설정되어 있는 콜백 함수를 사용하여,
- ref를
React.createRef()로 생성하고 클래스 속성에 바인딩하고 이를 통해 액세스합니다(참조는 componentDidMount 수명 주기에서 사용할 수 있음에 유의).
마지막으로 참조가 전달되지 않고 현재 구성 요소에서 더 깊은 참조 요소에 액세스하려는 경우가 있습니다(예: 내부 <input> DOM 요소가 있는 <Button> 구성 요소가 있고 지금 바로 <Row> 구성 요소에 있고 DOM 포커스 기능을 입력하기 위해 액세스하려는 행 구성 요소에서 forwardRef 를 사용합니다.
참조가 전달되지 않는 한 가지 경우는 구성 요소에 사용되는 고차 구성 요소 가 있는 경우입니다. 그 이유는 ref 가 prop 이 아니므로( key 와 유사) 전달되지 않기 때문에 충분히 이해할 수 있습니다. HOC에 의해 래핑되는 구성 요소 대신 HOC 를 참조합니다. 이러한 경우 props와 refs를 인수로 사용하는 React.forwardRef 를 사용할 수 있습니다. 그러면 prop 에 할당되고 액세스하려는 구성 요소로 전달될 수 있습니다.
function withNewReference(Component) { class Hoc extends React.Component { render() { const {forwardedRef, ...props} = this.props; return <Component ref={forwardedRef} {...props}/>; } } return React.forwardRef((props, ref) => { return <Hoc {...props} forwardedRef={ref} />; }); }오차 경계
일이 복잡할수록 문제가 발생할 확률이 높아집니다. 이것이 오류 경계 가 React의 일부인 이유입니다. 그래서 그들은 어떻게 작동합니까?
문제가 발생하고 상위 항목에 오류 경계가 없으면 전체 React 앱이 실패하게 됩니다. 사용자를 오도하고 잘못된 정보를 표시하는 것보다 정보를 표시하지 않는 것이 좋지만 반드시 전체 애플리케이션이 충돌하고 흰색 화면을 표시해야 한다는 의미는 아닙니다. 오류 경계를 사용하면 사용할 수 있는 유연성이 추가됩니다. 전체 앱에서 하나를 사용하고 오류 메시지를 표시하거나, 일부 위젯에서 사용하고 단순히 표시하지 않거나, 대신 해당 위젯 대신 소량의 정보를 표시할 수 있습니다.
일부 이벤트 또는 호출을 처리하기 위해 작성하는 명령형 코드가 아니라 선언적 코드의 문제에 관한 것임을 기억하십시오. 이러한 경우에도 일반 try/catch 접근 방식을 사용해야 합니다.
오류 경계는 또한 componentDidCatch 수명 주기 메서드에서 사용하는 오류 로거 에 정보를 보낼 수 있는 곳입니다.
class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } componentDidCatch(error, info) { logToErrorLogger(error, info); } render() { if (this.state.hasError) { return <div>Help, something went wrong.</div>; } return this.props.children; } }고차 부품
HOC(Higher Order Components) 는 React에서 자주 언급되며 매우 인기 있는 패턴으로 아마도 사용하거나 이미 사용했을 것입니다. HOC에 익숙하다면 많은 라이브러리에서 withNavigation, connect, withRouter 를 보았을 것입니다.
HOC는 구성 요소를 인수로 사용하고 HOC 래퍼가 없는 구성 요소와 비교하여 확장된 기능을 가진 새 구성 요소를 반환하는 함수일 뿐입니다. 덕분에 구성 요소를 향상시킬 수 있는 쉽게 확장 가능한 기능(예: 탐색 액세스)을 얻을 수 있습니다. HOC는 또한 우리가 가진 것에 따라 호출되는 몇 가지 형식을 취할 수 있습니다. 유일한 인수는 항상 구성 요소여야 하지만 추가 인수를 취할 수 있습니다. 일부 옵션 또는 connect 와 같이 먼저 나중에 함수를 반환하는 구성으로 함수를 호출합니다. 인수 구성 요소를 취하고 HOC를 반환합니다.
추가할 수 있고 피해야 할 몇 가지 사항이 있습니다.
- 래퍼 HOC 기능에 대한 표시 이름을 추가합니다(따라서 HOC 구성 요소 표시 이름을 변경하여 실제로 HOC임을 알 수 있습니다).
- 렌더 메서드 내에서 HOC를 사용하지 마십시오. 항상 다시 마운트하고 현재 상태를 잃어버리기 때문에 새로운 HOC 구성 요소를 만드는 대신 이미 그 내부에서 향상된 구성 요소를 사용하고 있어야 합니다.
- 정적 메서드는 복사되지 않으므로 새로 생성된 HOC 내부에 정적 메서드를 포함하려면 직접 복사해야 합니다.
- 언급된 Refs 는 전달되지 않으므로 이러한 문제를 해결하려면 앞서 언급한 대로
React.forwardRef를 사용하십시오.
export function importantHoc() { return (Component) => class extends React.Component { importantFunction = () => { console.log("Very Important Function"); }; render() { return ( <Component {...this.props} importantFunction={this.importantFunction} /> ); } }; }스타일링
스타일링이 반드시 React 자체와 관련이 있는 것은 아니지만 여러 가지 이유로 언급할 가치가 있습니다.
우선, 일반 CSS/인라인 스타일이 여기에 정상적으로 적용되며 CSS의 클래스 이름을 className 속성에 추가하기만 하면 올바르게 작동합니다. 인라인 스타일은 일반 HTML 스타일과 약간 다릅니다. 문자열은 스타일과 함께 전달되는 것이 아니라 각각에 대해 올바른 값을 가진 객체로 전달됩니다. 스타일 속성도 camelCased이므로 border-radius는 borderRadius 등이 됩니다.
React는 최근 CRA에 통합된 CSS 모듈과 같이 React뿐만 아니라 일반화된 몇 가지 솔루션을 대중화한 것 같습니다. 여기서 name.modules.css 를 가져오고 속성과 같은 클래스를 사용하여 구성 요소의 스타일을 지정할 수 있습니다(일부 IDE , 예를 들어 WebStorm에는 사용 가능한 이름을 알려주는 자동 완성 기능도 있습니다.
React에서도 인기 있는 또 다른 솔루션은 CSS-in-JS(예: emotion 라이브러리)입니다. 다시 말하지만 CSS 모듈과 감정(또는 일반적으로 CSS-in-JS)은 React 에만 국한되지 않습니다 .
React의 후크
Hooks 는 재작성 이후 React에서 가장 기다려온 추가 기능일 것입니다. 제품이 과대 광고에 부합합니까? 내 관점에서 보면 그렇습니다. 그들은 정말 훌륭한 기능이기 때문입니다. 기본적으로 다음과 같은 새로운 기회를 열어주는 기능입니다.
- 예를 들어 로컬 상태나 참조를 가질 수 없기 때문에 사용했던 많은
class구성 요소를 제거할 수 있으므로 구성 요소에 대한 코드가 더 읽기 쉽게 보입니다. - 동일한 효과에 대해 더 적은 코드를 사용할 수 있습니다.
- 예를 들어 react-testing-library를 사용하여 기능에 대해 생각하고 테스트하기 쉽게 만듭니다.
- 또한 매개변수를 사용할 수 있으며 하나의 결과는 다른 후크에서 쉽게 사용할 수 있습니다(예:
useState의setStateinuseEffect). - 축소자에게 약간 더 문제가 되는 경향이 있는 클래스보다 축소합니다.
- 다른 문제를 해결하도록 설계되었음에도 불구하고 새로운 문제를 도입한 앱에서 HOC를 제거하고 소품 패턴을 렌더링할 수 있습니다.
- 숙련된 React 개발자라면 누구나 맞춤 제작할 수 있습니다.
기본적으로 포함된 React hooks는 거의 없습니다. 세 가지 기본 요소는 useState , useEffect 및 useContext 입니다. useRef 및 useMemo 와 같은 몇 가지 추가 항목도 있지만 지금은 기본 사항에 중점을 둘 것입니다.
useState 를 살펴보고 이를 사용하여 간단한 카운터의 예를 만들어 보겠습니다. 어떻게 작동합니까? 음, 기본적으로 전체 구성은 정말 간단하고 다음과 같습니다.
export function Counter() { const [counter, setCounter] = React.useState(0); return ( <div> {counter} <button onClick={() => setCounter(counter + 1)}>+</button> </div> ); }; 이것은 initialState (값)로 호출되고 두 개의 요소가 포함된 배열을 반환합니다. 배열 분해 할당 덕분에 이러한 요소에 변수를 즉시 할당할 수 있습니다. 첫 번째는 항상 업데이트 후 마지막 상태이고 다른 하나는 값을 업데이트하는 데 사용할 함수입니다. 오히려 쉬워 보이지 않나요?
또한 이러한 구성 요소는 과거에 Stateless 기능 구성 요소라고 불렸기 때문에 위와 같은 상태를 가질 수 있으므로 이러한 이름은 더 이상 적절하지 않습니다. 따라서 클래스 구성 요소 와 함수 구성 요소의 이름은 적어도 16.8.0부터 실제로 수행하는 작업과 더 일치하는 것 같습니다.
업데이트 함수(이 경우 setCounter )는 이전 값을 다음 형식의 인수로 사용하는 함수로도 사용할 수 있습니다.
<button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button> 그러나 얕은 병합을 수행하는 this.setState 클래스 구성 요소와 달리 함수(이 경우 setCounter )를 설정하면 대신 전체 상태를 재정의합니다.
또한 initialState 는 단순한 값이 아니라 함수일 수도 있습니다. 이 기능은 구성 요소의 초기 렌더링 중에만 실행되고 그 후에는 더 이상 호출되지 않기 때문에 고유한 이점이 있습니다.
const [counter, setCounter] = useState(() => calculateComplexInitialValue()); 마지막으로, 현재 상태( counter )에서 바로 그 순간에 가졌던 것과 똑같은 값으로 setCounter 를 사용하려는 경우 구성 요소는 다시 렌더링 되지 않습니다 .
반면에 useEffect 는 구독, API 호출, 타이머 또는 유용하다고 생각할 수 있는 거의 모든 기능 구성 요소에 부작용을 추가하는 것입니다. useEffect 에 전달할 모든 함수는 렌더링 후에 실행되며, 함수의 두 번째 인수로 다시 실행해야 하는 속성 변경 사항에 대한 제한을 추가하지 않는 한 모든 렌더링 후에 실행됩니다. 마운트 시에만 실행하고 마운트 해제 시 정리하려면 빈 배열만 전달하면 됩니다.
const fetchApi = async () => { const value = await fetch("https://jsonplaceholder.typicode.com/todos/1"); console.log(await value.json()); }; export function Counter() { const [counter, setCounter] = useState(0); useEffect(() => { fetchApi(); }, []); return ( <div> {counter} <button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button> </div> ); }; 위의 코드는 두 번째 인수로 빈 배열로 인해 한 번만 실행됩니다. 기본적으로 이런 경우 componentDidMount 와 비슷하지만 조금 더 늦게 실행됩니다. 브라우저 페인트 전에 호출되는 유사한 후크를 useLayoutEffect 를 사용하지만 이러한 업데이트는 useEffect 와 달리 동기적으로 적용됩니다.
useContext 는 액세스 권한을 얻고자 하는 컨텍스트( createContext 함수에 의해 반환된 객체)를 제공하고 그 대가로 해당 컨텍스트에 대한 값을 제공하기 때문에 이해하기 가장 쉬운 것 같습니다.
const context = useContext(Context);마지막으로 자신만의 후크를 작성하려면 다음과 같이 작성하면 됩니다.
function useWindowWidth() { let [windowWidth, setWindowWidth] = useState(window.innerWidth); function handleResize() { setWindowWidth(window.innerWidth); } useEffect(() => { window.addEventListener('resize', handleResize); return () => window.removeEventListener('resize', handleResize); }, []); return windowWidth; } 기본적으로 우리는 초기 값 창 너비로 할당하는 일반 useState 후크를 사용하고 있습니다. 그런 다음 useEffect, 에서 각 창 크기 조정에서 handleResize 를 트리거하는 리스너를 추가합니다. 또한 구성 요소가 마운트 해제된 후에도 지웁니다( useEffect 의 반환 참조). 쉬운?
참고: 모든 후크에서 단어 사용 이 중요합니다. 예를 들어 일반 JS 함수에서 후크를 호출하는 것과 같이 사용자가 나쁜 일을 하고 있지 않은지 여부를 React가 확인할 수 있기 때문에 사용됩니다.
유형 확인
Flow와 TypeScript가 옵션이 되기 전에 React에는 자체 props 검사가 있었습니다.
PropTypes는 React 구성 요소에서 수신한 속성(props)을 확인하고 우리가 가진 것과 일치하는지 확인합니다. 다른 상황이 발생할 때마다(예: 배열 대신 객체) 콘솔에 경고가 표시됩니다. PropTypes는 성능에 미치는 영향과 앞서 언급한 콘솔 경고로 인해 개발 모드에서만 확인된다는 점에 유의하는 것이 중요합니다.
React 15.5부터 PropTypes는 별도로 설치해야 하는 다른 패키지에 있습니다. 속성이 정의되지 않은 경우 사용되는 defaultProps 와 결합하여 propTypes (놀라움)라는 정적 속성의 속성을 따라 선언됩니다( undefined 가 유일한 경우임). DefaultProps는 PropTypes와 관련이 없지만 PropTypes로 인해 나타날 수 있는 몇 가지 경고를 해결할 수 있습니다.
다른 두 가지 옵션은 Flow와 TypeScript이며 요즘에는 훨씬 더 인기가 있습니다(특히 TypeScript).
- TypeScript 는 Microsoft에서 개발한 JavaScript의 유형이 지정된 상위 집합으로, 앱이 실행되기 전에 오류를 확인할 수 있으며 개발을 위한 우수한 자동 완성 기능을 제공합니다. 또한 리팩토링을 크게 향상시킵니다. 입력된 언어에 대한 광범위한 경험이 있는 Microsoft 지원으로 인해 다소 안전한 선택이기도 합니다.
- Flow 는 TypeScript와 달리 언어가 아닙니다. JavaScript용 정적 유형 검사기이므로 언어보다 JavaScript에 포함하는 도구에 더 가깝습니다. Flow의 전체 아이디어는 TypeScript가 제공하는 것과 매우 유사합니다. 유형을 추가할 수 있으므로 코드를 실행하기 전에 버그가 발생할 가능성이 줄어듭니다. TypeScript와 마찬가지로 Flow는 이제 처음부터 CRA(Create React App)에서 지원됩니다.
개인적으로 TypeScript는 특히 자동 완성에서 더 빠르고(실제로 즉각적) Flow에서 약간 느린 것처럼 보입니다. 개인적으로 사용하는 WebStorm과 같은 IDE는 Flow와의 통합을 위해 CLI를 사용합니다. 그러나 파일의 시작 부분에 // @flow 를 추가하여 유형 검사를 시작하기만 하면 파일에 선택적 사용을 통합하는 것이 훨씬 더 쉬워 보입니다. 또한 내가 말할 수 있는 바에 따르면 TypeScript는 결국 Flow와의 전투에서 승리한 것 같습니다. 지금은 훨씬 더 인기가 있고 가장 인기 있는 라이브러리 중 일부는 Flow에서 TypeScript로 리팩토링되고 있습니다.
Reason(Facebook에서 개발하고 React 커뮤니티에서 인기를 얻고 있음), Kotlin(JetBrains에서 개발한 언어) 등과 같은 공식 문서에서도 언급된 몇 가지 옵션이 더 있습니다.
분명히 프론트 엔드 개발자의 경우 가장 쉬운 접근 방식은 Kotlin 또는 F#으로 전환하는 대신 Flow 및 TypeScript를 사용하여 시작하는 것입니다. 그러나 프론트엔드로 전환하는 백엔드 개발자의 경우 실제로 시작하기가 더 쉬울 수 있습니다.
생산 및 반응 성능
프로덕션 모드에서 해야 할 가장 기본적이고 분명한 변경은 UglifyJsPlugin DefinePlugin 추가하는 것입니다. CRA의 경우 npm run build ( react-scripts build 를 실행할 것입니다)를 사용하는 것만큼 간단합니다. Brunch와 같은 다른 빌드 도구를 사용할 수 있으므로 Webpack과 CRA가 유일한 옵션은 아닙니다. 이것은 일반적으로 공식 React 문서 또는 특정 도구에 대한 문서와 같은 공식 문서에서 다룹니다. 모드가 올바르게 설정되었는지 확인하기 위해 React 개발자 도구를 사용할 수 있습니다. 이 도구는 사용 중인 빌드의 종류(프로덕션 vs. 개발)를 알려줍니다. 앞서 언급한 단계를 수행하면 React에서 오는 확인 및 경고 없이 애플리케이션이 실행되고 번들 자체도 최소화됩니다.
React 앱에서 할 수 있는 몇 가지 작업이 더 있습니다. 빌드된 JS 파일로 무엇을 합니까? 크기가 비교적 작은 경우 "bundle.js"로 시작하거나 "vendor + bundle" 또는 "vendor + 가장 작은 필수 부품 + 필요할 때 가져오기"와 같은 작업을 수행할 수 있습니다. 이것은 매우 큰 앱을 처리하고 처음부터 모든 것을 가져올 필요가 없을 때 유용합니다. 사용되지도 않는 기본 번들에 일부 JavaScript 코드를 번들로 포함하면 단순히 번들 크기가 증가하고 처음에 앱 로드가 느려집니다.
공급업체 번들은 라이브러리 버전이 오랫동안(만약 있다면) 변경되지 않을 수 있다는 것을 깨닫고 동결할 계획이라면 유용할 수 있습니다. 또한 더 큰 파일은 gzip으로 압축하는 것이 더 좋으므로 분리하여 얻는 이점이 때로는 가치가 없을 수도 있습니다. 파일 크기에 따라 다르며 때로는 직접 시도해야 할 수도 있습니다.
코드 분할
코드 분할은 여기에 제안된 것보다 더 많은 방식으로 나타날 수 있지만 CRA 및 React 자체에서 사용할 수 있는 것에 집중합시다. 기본적으로 코드를 다른 청크로 분할하기 위해 Webpack 덕분에 작동하는 import() 를 사용할 수 있습니다( import 자체는 현재 단계 3의 제안이므로 아직 언어 표준의 일부가 아닙니다). Webpack은 import 를 볼 때마다 이 단계에서 코드 분할을 시작해야 하며 이를 기본 번들(가져오기 내부에 있는 코드)에 포함할 수 없다는 것을 알게 됩니다.
이제 import() 가 필요한 React.lazy() 와 연결할 수 있으며 해당 위치에 렌더링해야 하는 구성 요소가 포함된 파일 경로가 있습니다. 다음으로 가져온 구성 요소가 로드될 때까지 해당 위치에 다른 구성 요소를 표시하는 React.suspense() 를 사용할 수 있습니다. 궁금해 할 수 있습니다. 단일 구성 요소를 가져오는 경우 왜 필요할까요?
React.lazy() 는 우리가 import() 하는 구성 요소를 표시하지만 import() 는 단일 구성 요소보다 더 큰 청크를 가져올 수 있으므로 그렇지 않습니다. 예를 들어, 특정 구성 요소에는 견인되는 다른 라이브러리, 더 많은 코드 등이 있을 수 있으므로 하나의 파일이 필요하지 않습니다. 더 많은 파일이 함께 번들로 제공될 수 있습니다. 마지막으로 우리가 가져오려는 구성 요소에 문제가 있는 경우(예: 네트워크 오류가 있는 경우) 대체 역할을 할 ErrorBoundary (오류 경계 섹션에서 코드를 찾을 수 있음)에서 모든 것을 래핑할 수 있습니다.
import ErrorBoundary from './ErrorBoundary'; const ComponentOne = React.lazy(() => import('./ComponentOne')); function MyComponent() { return ( <ErrorBoundary> <React.Suspense fallback={<div>Loading...</div>}> <ComponentOne/> </React.Suspense> </ErrorBoundary> ); } 이것은 기본적인 예이지만 분명히 더 많은 작업을 수행할 수 있습니다. 동적 경로 분할을 위해 import 및 React.lazy 를 사용할 수 있습니다(예: admin 대 일반 사용자, 또는 많은 것을 가져오는 정말 큰 경로). React.lazy 는 현재 기본 내보내기만 지원하며 서버 측 렌더링은 지원하지 않습니다.
반응 코드 성능
성능과 관련하여 React 애플리케이션이 지연되는 경우 문제를 파악하는 데 도움이 되는 두 가지 도구가 있습니다.
첫 번째는 Chrome 성능 탭으로, 각 구성 요소(예: 마운트, 업데이트)에 어떤 일이 발생하는지 알려줍니다. 덕분에 성능 문제 문제를 나타내는 구성 요소를 식별한 다음 최적화할 수 있어야 합니다.
다른 옵션은 React 16.5+에서 사용할 수 있게 된 DevTools Profiler를 사용하는 것이며 shouldComponentUpdate(또는 이 튜토리얼의 1부에서 설명된 PureComponent)의 협력으로 일부 중요한 구성 요소의 성능을 향상시킬 수 있습니다.
분명히 일부 이벤트(예: 스크롤)를 디바운싱하고 애니메이션에 주의(높이를 변경하고 애니메이션을 적용하는 대신 변형 사용) 등과 같은 웹에 대한 기본 모범 사례를 사용하는 것이 최적입니다. 모범 사례를 사용하는 것은 매우 쉽게 간과될 수 있습니다. 특히 React를 이제 막 이해하려는 경우에는 더욱 그렇습니다.
2019년 및 그 이후의 React 상태
개인적으로 React의 미래에 대해 논의한다면 그다지 걱정하지 않을 것입니다. 내 관점에서 React는 2019년 이후에도 왕좌를 유지하는 데 문제가 없을 것입니다.
React는 많은 커뮤니티가 지지하는 강력한 입지를 가지고 있어 폐위되기 어려울 것입니다. React 커뮤니티는 훌륭하고 아이디어가 부족하지 않으며 핵심 팀은 React를 개선하고 새로운 기능을 추가하고 오래된 문제를 수정하기 위해 지속적으로 노력하고 있습니다. React도 거대한 회사의 지원을 받고 있지만 라이선스 문제는 사라졌습니다. 바로 지금 MIT 라이선스입니다.
예, 변경되거나 개선될 것으로 예상되는 몇 가지 사항이 있습니다. 예를 들어, React를 조금 더 작게 만들거나(언급된 조치 중 하나는 합성 이벤트를 제거하는 것입니다) className 을 class. 물론 이러한 사소한 변경으로도 브라우저 호환성에 영향을 미치는 등의 문제가 발생할 수 있습니다. 개인적으로 WebComponent가 오늘날 React에서 자주 사용되는 일부 기능을 보강할 수 있기 때문에 WebComponent가 더 많은 인기를 얻게 되면 어떤 일이 벌어질지 궁금합니다. 나는 그들이 완전한 대안이 될 것이라고 믿지는 않지만 그들이 서로를 훌륭하게 보완할 수 있다고 믿습니다.
단기적으로는 후크가 방금 React에 왔습니다. 이는 React에서 재작성이 발생한 이후 가장 큰 변화일 것입니다. 이는 많은 가능성을 열어주고 추가 기능 구성 요소를 향상시킬 것이기 때문입니다.
마지막으로 제가 가장 최근에 하고 있는 작업인 React Native가 있습니다. 저에게는 지난 몇 년 동안 많은 변화가 있었던 훌륭한 기술입니다. React Native는 핵심 재작성 중이며 이는 React 재작성과 유사한 방식으로 수행되어야 합니다(모두 내부적이며 개발자를 위해 변경되거나 거의 변경되지 않아야 함). 비동기 렌더링, 네이티브와 JavaScript 간의 더 빠르고 가벼운 브리지 등.
React 생태계에서 기대할 수 있는 것이 많지만, 후크(모바일을 좋아하는 사람이라면 React Native) 업데이트는 아마도 2019년에 보게 될 가장 중요한 변경 사항일 것입니다.