partial hydration과 islands architecture

hydration 공부 이어서 ㄱㄱ

hydration 정리 링크 :
https://velog.io/@hongihongi60/hydration

partial hydration과 islands architecture에 대해서 공부!

========================================

partial hydration

partial hydration은 페이지 전체를 한번에 hydration 하지 않고 필요한 부분만 선택적으로 hydration 하는 방식임

예를들어

헤더 텍스트
검색창
소개문구
좋아요 버튼

이렇게 있으면 헤더 텍스트, 소개문구는 그냥 html로 두고 동적인 부분인 검색창과 좋아요 버튼에만 js를 붙여주는거임

성능에 유리하다는 장점이 있지만 어느 부분만 hydrate할지 나누는 설계가 좀 복잡하다는 단점이 있음

근데 나의 궁금증
hydration 개념을 처음 접할때 본 예시가 이거였음

<h1> hello world!</h1>
<Count />

그렇다면, h1은 그냥 정적으로 쓰였는데 이게 partial hydration 아닌가?



핵심은 html에 정적인 요소가 섞여있냐는게 아니라 js 프레임워크가 어느 범위를 hydrate하느냐에 달려있음.

일반 hydration은 h1이 상태가 없어도 이 DOM도 자기 트리의 일부로 보고 연결함.

즉, 일반 hydration은 서버가 전체 html을 보내고 클라이언트에서 루트 전체를 다시 연결함.

반면 partial hydration은 서버가 전체 html을 보내고 클라이언트에서 정말 필요한 부분만 따로 hydrate하는거임

일반 hydrate 느낌 :

function App() {
  return (
    <>
      <h1>hello world!</h1>
      <Count />
    </>
  );
}

hydrateRoot(document.getElementById('root'), <App />);

Partial hydrate 느낌 :

<h1>hello world!</h1>
<div id="count-island"><button>0</button></div>

hydrateRoot(document.getElementById('count-island'), <Count />);

즉 일반 hydration은 보통 하나의 큰 루트 트리를 기준으로 hydrate하고, partial hydration은 필요한 DOM 구역만 별도 루트로 잡아 hydrate함.

hydrateRoot(document.getElementById('count-root'), <Count />);
hydrateRoot(document.getElementById('comment-root'), <Comments />);

아이디로만 찾아야하는건 아니고 data-* 속성이나 클래스명이나 다른 셀렉터를 써도 됨
아래와 같이 :

const el = document.querySelector('[data-island="count"]');
hydrateRoot(el, <Count />);

islands architecture

Partial hydration과 묶여서 많이 나오는 개념이라고 함

<header>로고</header>
<article>본문</article>
<ProductSlider />
<LikeButton />
<footer>푸터</footer>

페이지가 이런 식이라고 치면, header, article, footer가 정적 Html이고 ProductSlider, LikeButton이 js가 필요한 부분임

islands architecture는 ProductSlider, LikeButton를 각각 island(섬)으로 보는 아키텍쳐임.

partial hydration는 부분적으로 hydrate하는 ‘전략’이라면, islands architecture는 부분 hydrate가 잘되도록 페이지를 조각내는 ‘구조’임 


큰 위젯 하나만 부분적으로 hydrate하면 partial hydration 예시로 보기 좋고, 작은 interactive 구역 여러 개를 독립적으로 hydrate하면 islands architecture 예시로 보기 좋음.

예시를 보면

*partial hydration

<header>정적 헤더</header>
<section>정적 배너</section>
<section>
  <div id="commerce-widget"></div>
</section>
<section>정적 안내</section>
<footer>정적 푸터</footer>

hydrateRoot(document.getElementById('commerce-widget'), <CommerceWidget />);

function CommerceWidget() {
  return (
    <>
      <RecommendProducts />
      <FlashSaleTimer />
      <RecentlyViewed />
    </>
  );
}

*partial hydration, islands architecture

<header>정적 헤더</header>
<section>정적 배너</section>
<section>
  <div id="recommend-product"></div>
  <div id="flash-sale-timer"></div>
  <div id="recently-viewed"></div>
</section>
<section>정적 안내</section>
<footer>정적 푸터</footer>

hydrateRoot(document.getElementById('recommend-product'), <RecommendProducts />);
hydrateRoot(document.getElementById('flash-sale-timer'), <FlashSaleTimer />);
hydrateRoot(document.getElementById('recently-viewed'), <RecentlyViewed />);

한가지 의문.
partial hydration / islands architecture가 hydration보다 무조건 좋은가?

그건 아닐 수 있다.

정적인 내용이 많고 동적인 부분이 조금만 있는 페이지면 partial hydration / islands architecture가 적합하지만 화면 전체가 상태 변화로 촘촘하게 연결되어있는 페이지라면 굳이? 일수있다.

partial hydration / islands architecture 👍 : 블로그, 뉴스, 문서 페이지 / 회사 소개 페이지 / 마케팅 랜딩 페이지 / 쇼핑몰 상품 상세 페이지 / 콘텐츠 중심 페이지 -> 대부분 읽기용 정적 콘텐츠이면서 일부만 상호작용 필요할 때

그냥 hydration 👍 : 대시보드, 관리자페이지, 복잡한 폼 화면, 실시간 상태가 자주 바뀜, 컴포넌트끼리 상태공유가 많을 때

partial hydration / islands architecture가 적합하지 않은 페이지에서 사용하게되면, 설계가 더 복잡해짐, 상태공유가 귀찮아짐, 프레임워크가 잘 받쳐주지않으면 구현난이도 올라간다. 이에 더해 성능 이득이 그닥 크지도 않음.

오늘의 교훈 적재적소가 중요하다