블로그 구성을 보여주는 예제 글입니다.
웹사이트를 만들 때 모든 화면에 같은 양의 JavaScript가 필요하지는 않습니다. 소개 문장과 기술 글은 HTML만으로도 충분히 읽을 수 있습니다. 반면 사용자가 값을 바꾸는 차트나 버튼에는 상태와 이벤트가 필요합니다.
Astro의 아일랜드 아키텍처는 이 차이를 출발점으로 삼습니다. 페이지의 대부분은 정적으로 만들고, 상호작용이 필요한 작은 부분만 클라이언트에서 동작하게 합니다.
페이지 전체보다 작은 단위로
블로그 글은 제목, 본문, 코드 예제, 데모로 이루어져 있다고 생각해 봅시다. 본문을 읽는 데는 프레임워크 런타임이 필요하지 않습니다. 데모만 작은 아일랜드로 분리하면 읽기 화면과 상호작용의 책임도 자연스럽게 나뉩니다.
먼저 HTML로 의미를 전달하고, 사용자가 조작하는 부분에만 동작을 더합니다.
Astro 컴포넌트 안에서 프레임워크 컴포넌트를 불러와 사용하는 모습은 다음과 같습니다.
---
import Counter from '../components/Counter.tsx';
---
<article>
<h1>작은 카운터 실험</h1>
<p>본문은 정적인 HTML로 전달됩니다.</p>
<Counter client:visible />
</article>client:visible은 컴포넌트가 화면에 보일 때 클라이언트 동작을 준비합니다. 반대로 처음부터 바로 조작해야 하는 컨트롤에는 client:load를 사용할 수 있습니다.
경계를 정하는 기준
좋은 경계는 파일 크기보다 역할에서 나옵니다. 한 아일랜드가 자신의 상태와 사용자 입력을 함께 소유하면 변경의 영향도 그 안에 머물기 쉽습니다.
함께 움직이는 상태를 묶기
기간 선택 버튼과 차트는 같은 데이터를 바라봅니다. 두 요소를 서로 다른 아일랜드로 나누면 상태를 공유할 별도 통로가 필요합니다. 이런 경우 하나의 컴포넌트 안에서 관리하는 편이 이해하기 쉽습니다.
읽기 경험을 먼저 만들기
데이터를 그래프로만 보여주지 않고 표로도 제공하면 스크립트가 준비되기 전에도 의미가 남습니다. 키보드와 보조 기술을 사용하는 사람에게도 도움이 됩니다.
이 블로그에 적용한 방식
이 사이트의 글 목록과 본문은 Astro가 정적으로 렌더링합니다. 검색은 제목과 요약에 대한 작은 브라우저 스크립트로 처리하고, Lab의 차트와 모션은 각각 독립적인 아일랜드로 구성했습니다.
이 방식의 핵심은 도구의 수가 아니라 책임의 크기입니다. 읽는 경험은 단순하게 유지하고, 실험이 필요한 곳에만 상태를 배치합니다.