React 업데이트 노트 동반자

React의 새로운 주요 버전에 대한 업데이트 노트는 항상 믿을 수 없을 만큼 정보가 밀집되어 있으며 프레임워크 자체가 너무 광범위해서 항상 메모를 하고 참조 문서와 비교하여 변경된 내용과 이를 사용하는 방법을 파악하고, 업데이트 노트에서 설명하는 다양한 주요 개념이 실제로 내부적으로 어떻게 작동했는지 알아보세요. React는 매우 잘 문서화되어 있지만 업데이트 노트가 개념을 이해하는 데 항상 "충분"하지는 않습니다. 예를 들어 React 19 업데이트 노트에서 useOptimistic의 예는 실제로 후크가 작동하는 방식에 대해 혼란스럽고 실제로 약간 부정확하다는 것을 알았습니다.

React 19 변경 사항을 검토하면서 작성한 메모를 메모를 샅샅이 뒤지고 그 모든 의미를 파악하는 것을 두려워하는 모든 사람을 위한 동반자로 작성하기로 결정했습니다. 이제 시작하겠습니다.

액션 및 양식 처리/useActionState

첫 번째 주요 개선 사항은 양식 처리가 크게 개선되었다는 것입니다. React는 상용구를 제거하고 기본 HTML 형식과 더 잘 통합하기 위해 점차적으로 움직이고 있으며 새로운 useActionState는 이러한 추진의 일부입니다. 이는 오류 처리(현재 내장됨)를 개선하는 데 도움이 되고, 로딩 상태를 자동으로 추적하여 보류 상태에서 지속적으로 수동으로 코딩할 필요가 없도록 하며, 점진적인 향상에 대한 지원을 향상시킵니다.

useActionState에 대해 제공된 코드 예제가 꽤 혼란스럽다는 것을 알았습니다. 사실 이 코드 예제는 제가 이 기사를 쓰기 시작한 전체 이유입니다. 실제로 useActionState에는 두 부분이 있는데, 공간을 절약하기 위해 예시를 사용했지만 결과적으로 명확성이 크게 떨어졌습니다. useActionState는 양식 제출의 비동기 작업이 완료되는 시점을 추적하는 튜플을 반환하는 반면, 전달한 작업의 수정된 버전은 양식에 직접 전달됩니다. useActionState 자체는 두 가지 입력, 즉 비동기 formAction(호출 시 이전 상태와 양식 데이터를 인수로 수신함)과 초기 상태(null, 0 또는 변수일 수 있음)를 사용합니다.

양식이 아직 제출되지 않은 경우 이전 상태는initialState입니다. 양식이 이전에 제출된 경우 제출된 것이 무엇이든 상관없습니다. 서버 기능에서는 실제로 하이드레이션이 발생하기 전에 서버 응답을 표시할 수 있습니다. useActionState는 마지막으로 양식에서 수정하려는 고유한 페이지 URL이 포함된 문자열을 허용할 수 있습니다. 즉, 선택적 영구 링크 매개변수를 허용할 수도 있는데, 이는 점진적인 향상에 특히 유용합니다. 이는 JavaScript가 로드되기 전에 사용자가 양식을 제출하는 경우 탐색할 위치를 브라우저에 알려줍니다.

마지막으로 useActionState가 반환하는 튜플은 현재 상태(초기 렌더링 중에는 초기 상태 값임), 양식에 작업으로 전달할 수 있는 반응 수정된 formAction, 소품으로 버튼으로 구성된 배열입니다. 및 isPending 플래그/상태 저장 변수. 저는 React 팀이 어떤 다른 새로운 개발을 내놓을지 기대하고 있습니다. 이 개발이 특히 유용해 보이기 때문입니다.

React-DOM 업데이트

<양식> 행동

이 React-dom 추가는 NextJS 및 폼 액션을 사용해 본 사람이라면 누구에게나 친숙할 것이며 Reac 팀은 폼 액션이 전성기를 맞이할 준비가 되었다고 판단한 것 같습니다. NextJS나 React 외에 다른 프레임워크에서 사용하지 않은 사람이라면 기본적으로 기본 양식 제출을 사용하여 React의 성능을 향상시키는 방법입니다. onClick 대신 action prop을 통해 기본 양식 제출을 전달할 수 있습니다. action 또는 formAction에 전달된 모든 함수는 자동으로 제출을 처리합니다. React는 제어되지 않은 양식 필드도 자동으로 재설정합니다. API를 통해 재설정하는 수동 옵션도 있습니다. React 팀은 또한 오류 경계와 함께 오류 처리를 통합했습니다. 대부분의 사람들이 NextJS에서 이 내용을 기억할 것이라고 가정하므로 이에 대해 너무 많이 이야기하지는 않겠습니다. 하지만 질문이 있는 사람이 있으면 후속 글을 작성할 수 있습니다.

useFormStatus 후크

이는 prop 드릴링이나 컨텍스트를 사용하지 않고도 양식에서 무슨 일이 일어나고 있는지 확인하는 데 도움이 되는 훌륭한 추가 기능입니다. prop 드릴을 사용하지 않는 이유를 묻는다면 코드를 유지 관리하고 수정하기 쉽게 유지하는 것과 관련이 있습니다. 컨텍스트의 경우, 컨텍스트를 과도하게 사용하면 성능 문제가 발생할 수 있습니다. 특정 컨텍스트를 구독하는 모든 구성 요소는 컨텍스트의 내용이 변경될 때마다 다시 렌더링되기 때문입니다. 따라서 코드를 정리하고 오류 가능성을 줄이며 앱 성능이 저하되는 것을 방지합니다.

후크는 네 가지 속성이 있는 개체를 반환합니다. 보류 중 - 보류 중인 제출이 있는지 알려주는 부울 데이터 - 상위 양식에서 제출한 데이터가 있는 formData 개체(활성 제출 또는 상위 양식이 없는 경우 null입니다. ), 메소드(get 또는 post) 및 액션 - action prop을 통해 전달되는 액션입니다.

Optimistic 후크 사용

낙관적 업데이트를 관리하는 새롭고 간단한 방법입니다. 낙관적 업데이트에 익숙하지 않다면 서버 측 업데이트가 발생하기 전에 클라이언트 측 디스플레이를 업데이트하는 것을 의미합니다. 마음에 드는 것이 있고 애니메이션이 재생되는 것을 보고 화면에 좋아요로 등록한 후 "실패했습니다"라는 토스트 오류를 ​​받은 적이 있다면 이는 낙관적 렌더링 때문입니다.

useOptimistic 후크는 낙관적으로 렌더링하려는 상태 저장 변수와 업데이트 함수(순수 함수, 즉 부작용이 없는 결정적 함수)를 허용합니다. 기본적으로 업데이트 함수는 상태에 대한 업데이트 소스를 검색하므로 일반적으로 formData.get('name')과 같습니다. 그런 다음 useOptimistic은 낙관적 상태와 addOptimistic 함수라는 두 가지 값을 반환합니다.

특히 사용 흐름과 관련하여 이에 대한 문서가 약간 약하다는 것을 알았습니다. 기본적으로 useOptimistic을 호출하고 낙관적 업데이트를 표시하려는 초기 상태와 업데이트 기능을 전달합니다. 새롭게 낙관적으로 강화된 상태 저장 값(optimisticState)과 낙관적으로 상태를 변경하는 함수라는 두 가지 함수가 제공됩니다. 사용자가 제출한 새 값이 있으면 문서에서 addOptimistic이라고 하는 두 번째 함수를 호출하고 사용자가 제출한 값을 전달합니다. 그런 다음 구성 요소에서 상태 저장 변수를 낙관적으로 렌더링할 때마다 낙관적으로 강화된 상태 저장 값을 전달합니다.

전반적으로 저는 낙관적 업데이트를 수행하는 보다 표준화된 방식을 정말 좋아합니다. 이전에 NextJS에서 캐싱하고 낙관적 업데이트를 수행하는 데 문제가 있었기 때문에 낙관적 업데이트를 생성하는 표준화된 방식이 훌륭하며 이것이 가능할 것이라고 확신합니다. NextJS가 아직 버블링되지 않은 경우 버블링하세요.

사용 API

이것은 매우 밀도가 높은 API이며, React가 페이지를 렌더링하는 동안 리소스에 액세스하는 완전히 새로운 방법입니다. 사용된 정확한 표현은 "렌더링에서 리소스 읽기"입니다. 그렇다면 구체적으로 무엇을 위한 것인가요? 이 새로운 API를 사용하여 조건 또는 루프 내부의 구성 요소 정보에 액세스할 수 있습니다. 이것이 왜 유용한지 잘 모른다면 React의 렌더링 프로세스가 작동하는 방식과 관련이 있습니다. React/react-fibre는 매번 동일한 순서로 모든 것을 렌더링하는 데 의존하므로 일반적으로 렌더링 프로세스 중에 대부분의 후크에 액세스할 수 없습니다. 더 명확하게 말하면 상태는 실제로 후크가 호출되는 순서에 따라 추적되므로 후크가 예측할 수 없는 순서로 호출되면 렌더링 버그가 발생하게 됩니다. 좋은 예는 사용자의 로그인 여부에 따라 테마 컨텍스트에 액세스하는 것입니다.

그렇다면 이것이 왜 중요한 발전일까요? 이는 실제로 필요한 경우에만 정보/데이터를 로드할 수 있음을 의미합니다. 사용자가 실제로 로그인한 경우에만 특수 테마에 대한 CSS를 로드합니다. 데이터는 직렬화 가능해야 합니다. 이는 실제로 이미 실행 중인 동안 서버 구성 요소에서 클라이언트 구성 요소로 약속을 보낼 수 있음을 의미합니다. 즉, 폭포수 요청이 적고 자동으로 병렬 처리됩니다. 서버 구성 요소에서 작업할 때 실제로 데이터 가져오기에 사용하는 것보다 async/await를 사용하는 것을 선호해야 한다는 점은 주목할 가치가 있습니다. 이는 async/await가 중단된 부분부터 정확히 렌더링을 재개하는 반면 사용은 전체 다시 렌더링을 트리거하기 때문입니다. 데이터가 해결된 후의 구성요소입니다. 물론, 이 변경 사항은 실제로 사용을 잘못 구성할 경우 워터폴 요청의 새로운 잠재적 소스가 있다는 의미이기도 합니다.

정말 중요한 점 중 하나는 try/catch 블록에서 "use" API를 사용할 수 없다는 것입니다. 이는 "use"가 Promise와 함께 호출될 때 자동으로 반응 서스펜스 경계를 ​​사용하기 때문입니다. try/catch 블록은 오류가 발생하면 실제로 React에 도달하기 전에 JS 수준에서 실행이 중지되어 기능이 중단되므로 반응 수준에 도달하는 것을 방지합니다. 다른 후크와 마찬가지로 특정 구성 요소나 기능의 최상위 범위에 있어야 합니다(역시 렌더링 순서로 인해).

따라서 '사용'의 실제 목적은 상황에 액세스하여 조건부로 렌더링하고 실제로 필요한 경우에만 데이터를 가져오도록 돕는 것입니다. 이는 반응을 조금 덜 난해하게 만들고, 조건부 데이터 가져오기를 단순화하고, 개발 경험을 개선하고, 성능을 한꺼번에 향상시키는 또 다른 단계입니다. 테마 지정과 같은 작업을 수행하는 방법을 다시 배우려면 경험이 많은 React 개발자가 필요하지만, 이를 통해 새로운 사용자가 프레임워크에 훨씬 더 쉽게 접근할 수 있게 된다는 점은 항상 훌륭합니다.

새로운 React Dom 정적 API

이 두 가지 새로운 정적 API인 prerender 및 prerenderToNodeStream은 모두 SSR(서버 측 렌더링)에 사용되는 renderToString을 개선한 것입니다. 이러한 새로운 개선 사항은 renderToString을 사용하여 SSG(정적 사이트 생성)를 수행하기 위한 것입니다. 콘텐츠 청크가 사용 가능해지면 이를 전송할 수 있는 기존 스트리밍 SSR과 달리, 이러한 새로운 API는 최종 HTML을 생성하기 전에 모든 데이터가 로드될 때까지 특별히 기다립니다. Node.js 스트림 및 웹 스트림과 같은 최신 스트리밍 환경과 원활하게 작동하도록 설계되었지만 의도적으로 부분 콘텐츠 스트리밍을 지원하지 않습니다. 대신 빌드 시 완전하고 완전히 로드된 페이지를 얻을 수 있도록 보장합니다. 이는 데이터가 사용 가능해지면 사전 렌더링된 사이트를 보내는 기존 스트리밍 SSR 방법과 다릅니다.

우리는 이미 NextJS와 같이 React를 기반으로 SSG 지원 프레임워크를 구축했지만 이는 SSG에 대한 React의 기본 기능이 되도록 의도되었습니다. SSG가 있는 프레임워크는 renderToString을 사용한 다음 이를 중심으로 자체적인 복잡한 데이터 가져오기 조정을 구축했습니다. 이는 사용자가 스스로 생성하기가 매우 어려웠으며 이러한 프레임워크는 이를 위해 매우 복잡한 파이프라인을 사용했습니다. 이러한 새로운 방법의 기능은 본질적으로 정적 HTML 생성 중에 데이터를 로드할 수 있도록 하는 것입니다. SSG에 익숙하지 않은 경우 SSG는 기본적으로 빌드 시 모든 것을 렌더링하며 의심할 여지 없이 페이지를 렌더링하는 가장 빠른 방법입니다. 사용자 요청에 따라 페이지를 렌더링하기 때문에 Vercel에 배포하거나 매우 복잡한 배포 프로세스가 필요한 Next와 같은 기능을 사용하고 싶지 않은 사람들을 위해 이러한 종류의 기능을 제공하는 것이 좋습니다.

서버 구성 요소

최신 버전의 NextJS를 사용한 사람에게는 React 서버 구성 요소의 개념이 새로운 것이 아니지만, 아직 사용해 본 적이 없는 사람에게는 서버 구성 요소가 데이터 가져오기에 대한 새로운 패러다임입니다. 솔직히 서버 구성 요소(및 서버 작업)의 개념은 전체 기사 자체에 해당하지만 개념을 간단히 요약하면 서버 구성 요소는 javascript가 로드된 후에도 클라이언트에 전송되기 전에 항상 서버에서 렌더링됩니다. 이는 후속 렌더링이 서버 측에서 수행됨을 의미합니다.

이러한 구성 요소의 주요 장점은 보안 및 데이터 가져오기입니다. 서버 구성 요소 내부에서 데이터를 요청하면 요청 정보가 클라이언트 측에 표시되지 않고 응답만 표시되므로 훨씬 더 안전합니다. API, 엔드포인트 등은 클라이언트 측에서 액세스할 수 없습니다. 또한 해당 작업에 대한 자바스크립트가 클라이언트로 전송되지 않으므로 번들 크기가 줄어듭니다. 또한 서버에서 메모리나 계산 집약적인 작업을 실행하여 성능이 떨어지는 시스템에서 렌더링 부담을 줄일 수 있습니다. 또한 순차적 데이터 가져오기가 데이터베이스에 더 가까운 시스템에서 수행될 수 있기 때문에 클라이언트 측 워터폴이 줄어들지만, 물론 개발자가 테스트 브라우저 개발자의 쉬운 요청 정보에 액세스할 수 없기 때문에 완전히 새로운 서버 측 워터폴이 발생할 가능성도 열립니다. 도구를 사용하고 OpenTelemetry 수집기 및 뷰어와 같은 도구를 사용하여 검사해야 합니다. 마지막으로 서버 구성 요소는 점진적인 향상에도 적합합니다.

서버 구성 요소에는 제한 사항 목록도 함께 제공됩니다. 로컬 브라우저 API(로컬 저장소, 창 등)를 사용할 수 없고, 반응 후크가 다르게 작동하며, 상태에 의존하거나 사용할 수 없으며, 이벤트 핸들러를 사용하지 않으므로 구성 요소에 대한 사용자 상호 작용이 확실히 적습니다. 기본적으로 이 패러다임을 서버 구성 요소의 데이터 가져오기, 클라이언트 구성 요소의 상호 작용으로 생각하세요.

서버 구성 요소를 처음 접하는 사람을 위한 가장 중요한 주의 사항은 해당 구성 요소를 클라이언트 구성 요소로 가져올 수 없다는 것입니다. 그렇게 하면 오류가 발생합니다(일부 데이터 가져오기를 추가했다고 가정). 왜냐하면 컴파일러가 다음을 처리하도록 하기 때문입니다. 서버 구성 요소를 클라이언트 구성 요소로 사용합니다. 서버 구성요소를 클라이언트 구성요소에 전달하려면 {children} 소품을 통해 전달해야 합니다.

서버 작업

이것들은 제품과 기능을 구축하는 방법에 많은 영향을 미치는 또 다른 복잡한 주제이며, 이 주제는 약 1년 동안 NextJS에도 있었습니다. 서버 액션은 파일 상단에 '서버 사용'을 입력하여 선언하고 해당 서버 함수에 대한 직접 참조를 전달한 다음 클라이언트 구성 요소 내부에서 호출할 수 있습니다.

어떤 수준에서는 개념적으로 RPC(원격 프로시저 호출)와 유사합니다. 둘 다 클라이언트에서 서버측 기능을 호출할 수 있게 하고 클라이언트-서버 상호 작용의 복잡성을 추상화하며 직렬화 및 역직렬화를 처리하지만 알아야 할 몇 가지 주요 차이점이 있습니다. 서버 작업의 주요 이점은 React의 점진적인 향상과 함께 작동하고, 클라이언트/서버 경계에서 유형 안전성을 강화하고, 성능 최적화(점진적 향상과 관련)가 내장되어 있으며, React 생태계와 보다 원활하게 통합된다는 것입니다. 기본 제공 보류 상태를 제공하고 기본 양식 제출과 자동으로 통합된다는 점입니다.

이미 유형 안전성과 일부 성능 최적화 기능을 갖춘 gRPC와 같은 최신 RPC에 대해 이야기할 때 서버 작업의 주요 장점은 일반적으로 내장된 양식 처리 및 점진적인 향상으로 귀결되지만 중요하게도 작동합니다. 반응 서스펜스와 오류 경계가 있습니다. 가장 중요한 것은 gRPC에 대해 별도의 서버를 설정할 필요가 없기 때문에 배포가 훨씬 더 간단하다는 것입니다. 따라서 이는 소규모 프로젝트에 절대적으로 더 이상적입니다. 그러나 대규모 프로젝트의 경우 gRPC가 훨씬 더 바람직하다고 볼 수 있습니다. 백엔드 언어 등의 측면에서 더 많은 유연성을 제공합니다.

제공자로서의 상황

이는 본질적으로 구문을 단순화하여 일반적으로 React가 훨씬 더 깔끔하고 선언적인 구문을 갖도록 돕습니다. 솔직히 말해서 "좋아요"라는 말 외에는 할 말이 별로 없습니다.

Ref를 Prop으로 사용하고 Refs를 정리하는 함수

이전에는 참조를 정리하려면 구성 요소 내부에서 null 검사를 수행해야 했고, 다소 불확실한 시간에 참조가 정리되었습니다. React는 구성 요소가 마운트 해제될 때 null로 참조 콜백을 호출하므로 연결 및 분리 사례를 모두 명시적으로 처리해야 합니다. 새로운 참조 구문의 장점은 결정적 정리입니다. 즉, 참조 정리가 언제 발생하는지(마운트 해제 시) 정확히 알 수 있으므로 이제 외부 리소스 및 타사 라이브러리로 작업하는 것이 훨씬 쉬워졌습니다. 새로운 접근 방식을 사용하면 정리 함수를 직접 반환할 수 있습니다. TypeScript 통합에는 정리 기능에 대한 모호성을 피하기 위해 명시적인 return 문이 필요합니다.

useEffect와 동일한 패턴이기 때문에 구현 방식이 정말 마음에 듭니다. 프레임워크 전체에서 일관성을 유지하는 것이 좋습니다. 내 생각에 이 새로운 참조 정리는 WebGL 컨텍스트와 기타 무거운 리소스에 특히 유용할 뿐만 아니라 기본 JS 메서드를 사용하여 추가된 DOM 이벤트 리스너를 처리하는 데에도 유용할 것이라고 생각합니다. 이전에는 React가 정리 시 dom 요소에 대한 참조를 제거했기 때문입니다. 하지만 그렇게 하면 연결된 구성 요소에 대한 참조가 손실되었기 때문에 이벤트 리스너를 제거하는 것이 훨씬 더 복잡해집니다. . 결과적으로 요소 외부에 참조를 저장해야 했고 복잡성이 추가되었습니다. 이제 해당 반환 함수 내부의 참조에 대한 액세스를 유지하므로 구성 요소의 반환 함수 내부에서 이벤트 리스너를 제거할 수 있습니다. 이는 또한 React가 정리 함수를 사용할 때 더 이상 null로 ref를 호출하지 않기 때문에 대부분의 상황에서 더 이상 null 사례에 대해 걱정할 필요가 없음을 의미합니다. 정리 기능 자체가 해당 기능을 대체하여 코드를 더욱 깔끔하고 예측 가능하게 만듭니다.

useDeferredValue

useDeferredValue 후크의 목적은 응답성이 뛰어난 사용자 인터페이스를 유지하면서 계산 비용이 많이 드는 작업을 관리하는 것입니다. 이는 백그라운드에서 새 데이터를 계산하거나 가져오는 동안 구성 요소가 이전 "부실" 값을 표시하도록 허용하여 이를 수행합니다. 일반적인 사용 사례는 사용자가 입력할 때 결과를 표시하는 검색 기능입니다. 지연하지 않고 키를 누를 때마다 값비싼 검색 작업이 실행되어 입력이 느리게 느껴질 수 있습니다. useDeferredValue를 사용하면 새 검색 결과를 계산하는 동안 이전 검색 결과를 표시하여 인터페이스의 반응성을 유지할 수 있습니다.

이 새로운 추가 기능은 이 후크의 초기 로딩 동작에 대한 중요한 개선 사항입니다. 이전에는 첫 번째 렌더링에서 useDeferredValue에 전달된 모든 값을 즉시 사용하여 시작 시 비용이 많이 드는 계산을 트리거할 가능성이 있었습니다. 새 버전에서는 백그라운드에서 더 비싼 값을 처리하면서 즉시 표시되는 간단한 초기 값(예: 빈 문자열)을 제공할 수 있습니다. 즉, 안전한 기본값으로 사용자에게 즉각적인 피드백을 표시한 다음 비용이 많이 드는 계산이 완료되면 실제 데이터로 업데이트할 수 있습니다. 본질적으로 이는 성능 향상을 위해 useDeferredValue를 더욱 향상시킵니다.

문서 메타데이터 추가

이러한 새로운 변경 사항은 실제 구성 요소 내부에 다양한 메타데이터 태그를 추가하기 위한 것입니다. ,

위 내용은 React 업데이트 노트 동반자의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!