브라우저가 화면 전환 애니메이션을 대신 처리해주는 View Transitions API를 소개하고, 직접 구현했을 때와 비교해 보여주는 글이다. 썸네일 목록에서 항목을 고르면 메인 영역이 바뀌는 시나리오를 두 방식으로 짜 코드 분량과 신경 쓸 지점의 차이를 드러낸다. 기본 전환 위에 슬라이드 효과를 얹는 방법까지 이어진다.
핵심 포인트- 라이브러리 없이 전환을 직접 만들면 요소 탐색과 레퍼런스 확보, 키프레임 적용을 손으로 해야 한다.
- 순서가 있는 애니메이션은 종료 이벤트를 듣거나 딜레이를 명시해야 해서 개수가 늘수록 복잡도가 급증한다.
- startViewTransition 안에서 상태를 바꾸면 그것만으로 페이드 전환이 붙는다.
- 브라우저가 상태 변경 전후 화면을 캡처해 교차로 보여주는 방식이라 중간 상태를 직접 관리할 필요가 없다.
- 캡처된 화면은 view-transition 계열 가상 요소로 만들어져 CSS로 접근할 수 있다.
- 글 작성 시점 기준 표준이 아닌 실험적 API로 크로미움 계열 111 버전대에서만 동작한다.
상세 정리- 직접 구현의 부담: DOM을 파고들어 대상 요소를 찾거나 클래스를 붙이고 레퍼런스를 구한 뒤 키프레임을 적용해야 한다.
- 순차 처리의 부담: A가 끝나고 B가 시작하는 형태라면 종료 이벤트를 듣거나 딜레이를 걸어야 하고, 그런 애니메이션이 많아질수록 감당이 안 돼 아예 포기하는 경우도 있다.
- 예제 시나리오: 큰 메인 썸네일과 작은 썸네일 목록이 있고 목록에서 고르면 메인이 그 항목으로 바뀐다.
- API 적용 코드: 클릭 핸들러에서 startViewTransition을 부르고 그 콜백 안에서 상태를 갱신하는 것이 전부다.
- 비교 코드 1: 직접 구현하면 현재 항목과 미래 항목을 따로 상태로 두고 두 영역을 미리 렌더링해야 한다.
- 비교 코드 2: 한쪽은 투명도를 0으로, 다른 쪽은 1로 애니메이션하고 지속 시간에 맞춘 타임아웃에서 상태를 정리하고 스타일도 되돌려야 한다.
- 비교의 범위: 그 코드도 메인 영역만 다룬 것이며 곁의 목록까지 전환하려면 코드가 더 늘어난다.
- 직접 구현의 위험: 전환이 끝나는 시점에 요소가 교체되면서 저사양 기기에서 깜빡일 수 있고, 타임아웃으로 종료 시점을 맞추면 타이밍 문제가 생길 수 있다.
- 동작 원리 1: startViewTransition이 실행되면 상태가 바뀌기 전 화면을 캡처한다.
- 동작 원리 2: 상태가 바뀐 뒤의 화면도 캡처한다.
- 동작 원리 3: 두 화면을 페이드로 교차해 보여주며 이 기본 애니메이션은 브라우저가 제공하므로 따로 정의하지 않아도 된다.
- 생성되는 구조: 캡처 결과는 view-transition 가상 요소 아래에 group, image-pair, old, new 순으로 자식을 갖는 형태로 만들어지며 기본 이름은 root다.
- 확장 가능성에 대한 견해: 지금은 캡처 이미지를 old와 new로 단순 비교하지만 앞으로 텍스트나 이미지 시퀀스 지원도 기대해볼 만하다고 밝힌다.
- 커스텀 전환: 기본 페이드가 밋밋하다고 보고 텍스트 영역에 슬라이드를 얹기로 한다.
- 커스텀 방법 1: 나갈 때와 들어올 때의 키프레임을 각각 정의한다. 투명도와 가로 이동을 함께 준다.
- 커스텀 방법 2: 개별 전환에 이름을 붙이려면 해당 요소의 CSS에 view-transition-name을 지정한다.
- 커스텀 방법 3: 이름을 붙이면 그 이름으로 된 group과 image-pair, old, new 가상 요소가 root와 별도로 생성된다.
- 커스텀 방법 4: old와 new 가상 요소에 각각 애니메이션 이름을 지정해 나가는 쪽과 들어오는 쪽 효과를 다르게 줄 수 있다.
왜 읽나화면 전환 효과를 손으로 만들다 타이밍과 중간 상태 관리에 지친 적이 있다면, 브라우저가 그 부분을 대신 맡는 방식과 그 위에 커스텀을 얹는 지점을 확인할 수 있다.