React 19 메이저 업데이트 무엇이 바뀌는가?
React 19 이전
React의 기본 컨셉은 Code Layer -> React Layer -> Browser Layer
16.8에서 Functional 컴포넌트는 항상 렌더링된 값을 UI에 보여줌
-> 사용자는 더 이상 UI와 데이터 간 동기화를 생각하지 않아도 됨
-> 데이터 업데이트를 UI에 알려야함 -> State = User Interaction으로 발생한 데이터 변화
Thinking about state : state도 생명주기를 가지고, 독립적인 생명 주기를 보장
독립적인 state 데이터 조작 API = React Hooks
useSuspense 는 독립적인 데이터로 관리가 안됨
useCatch, useProvider, useShouldComponentUpdate 역시 독립적으로 데이터를 관리하는 것이 아니므로 리액트 훅이 아님
16.8에서는 무엇을을 해결함 (render()내부에 모두 넣는 것으로)
18에서는 언제와 어디서를 해결하고자 했음.
모든 데이터 update가 즉시 이루어져야 하는가?
-> 언제 알릴 지 React가 선택권을 쥐고 있으면, 필요한 UI 먼저 업데이트 할 수 있다.
리액트 18부터는 덜 중요한 부분 잠시 끊고, 중요한거부터 처리하고 후속작업을 해줌
-> React 18의 의의 = React Layer는 독립된 스케쥴링을 한다.
Suspense :
렌더링 중 Stop 이 걸려 가까운 Suspense가 처리함 (마치 try-catch-throwd의 관계)
실제 React 내부에서는 Ping을 통해 렌더링을 시도해달라 요청함.
Automatic Batching도 같은 원리 -> setState를 한번에 처리
18 미만에서는 따로따로 setState를 처리했는데,
18부터는 setState를 잠깐 기다려서 모아놓은 다음에 한번에 렌더링
- 마이크로 태스크 큐가 끝날때
- 혹은 이벤트 루프가 다음 스테이트로 넘어갈 때
Two React 패러다임의 부상
UI = f(state, data)
각 컴포넌트가 실행되어야 하는 곳은 다름 (클라이언트 or 서버)
-> state가 없는 컴포넌트는 client에서 다룰 필요가 없다. -> 보다 최적화 가능 -> 코드가 줄어듬
-> data가 없는 컴포넌트는 server에서 다룰 필요가 없다.
React 19는 어떤 점이 달라질까
2-1. Server Component에 대한 본격적 지원
- SC는 서버에서만 실행되는 C로 실제 client에 코드가 전달되지 않는다.
- Server Component는 DB, 파일, 다른 서버 등 Server-side recourse에 접근할 수 있다.
- SC는 Server-side resource에 따라 변경 된다.
- server상태가 바귀어도 client의 상태를 보존할 수 있어야 한다.
즉 Sc는 db와 통신하고, Suspense와 합쳐지면 최적화 + 최적의 UI를 보여줄 수 있다.
Suspense로 감싸면 서로의 동작이 서로에게 영향을 주지 못한다.
Client -> Server로 소통하는 Server Action(Form)도 준비중.
이에 따라 새로운 React Hooks도 도입
useFormState, useFormStatus, useOptimistic 등…
2-3. Asset Loading
유저의 관점에서, css, 폰트, 이미지도 모두 UI다
18이하에서는 React 렌더링과 Asset을 가져오는 차이로 UI 불균형이 생김
React-Helmet으로 처리 가능하지만, 이제 react자체로 처리가능
실제 스태틱하게 빌드시 index.html의 head에 들어감 (nextjs는 자동으로 해줌)
2-4. Resource Hints도 이제 React내부에서 사용가능
Resource Hints : 어떤 걸 미리 다운받을지 연결해놓는거. -> 사용성과 UI 개선시키는 기능
Dns-prefetch를 react와 통합하여 할 수 있음.
prefetchDNS 사용가능 (import {prefetchDNS} from ‘react-dom’)
preconnect는 미리 서버와 연결까지 함 ->더 빠르게 resource를 들고 올 수 있음
tcp가 그렇게 짧지 않음 적으면 50ms 길면 1초
Tcp, tls handshake 시 약 200ms ~ 300ms 더나아가 몇초까지도 가능
Preload = Preconnect + 리소스까지
특정 Resource가 쓰일 것이 확실하면 preload는 좋은 선택지
2-5. 웹 컴포넌트에 대한 지원은 공지되어 있지만, 아직 명확한 건 없음
React나 다른 프레임워크 없이도 Component를 만들 수 있음.
실제로 Github와 같은 서비스에선 Web Components를 적극 활용 중. 다만 브라우저 적으로 뭔가 지원이 있지는 않음 그래서 소극적
2-6. The ‘use’ hook
서버 컴포넌트는 hooks를 사용하지 못하고, 사용할 일도 없음.
Client component에서는 async한 컴포넌트를 사용하지 않음.
Use hook을 사용하면 비동기 함수도 동기적으로 활용할 수 있음.
Use 문법은 await과 비슷
Use 문법은 Promise, Context면 모두 활용가능
useSuspenseQuery 는 react-query와 굉장히 유사
2-7. Goodbye, Forward Ref!
React는 렌더링과 상관없는 값을 가리키기 위한 ref(reference)란 개념이 있음.
React 18까지는 ForwardRef로 특수한 형태로 ref로 접근해야 했음.
Class Componet 내 ref의 값은 prop 내 고유한 값이 있기 때문
정확히는 Class의 instance인지 여부를 담고 있음
근데 이제 Functional component 쓰고, function은 instance란 개념이 없으므로 필요가 없음.
그래서, react 19는 forwardRef란 개념이 없음.
2-8. react-Compiler(React Forget)
알아서 Auto-Memoization을 지원할 계획이었음. ( react memo, useMemo, useCallback)
하지만 아직 불안정한지 잘 안쓰고 잇음
하지만 Instagram 웹페이지에서는 시험 적용되어있음
- 우리는 다가오는 업데이트를 어떻게 준비해야할까?
직접 써보기 & 공식 블로그와 공식 채널로 정보 수집 & Blog Driven Knowledge는 하지 말자 (velog, tistory 너무 좋아하지 마라!)
철학은 변하지 않는다.
코드 레이어 -> 리액트 레이어 -> 리액트 내부 스케줄러가 결정 -> 브라우저 레이어로 가는 흐름은 바뀌지 않을것
