해당 목업은 특정 개념의 코드를 요청하고 필요한 것을 취사선택하는 방식으로 LLM의 도움을 통해 만들어졌음을 밝힌다.
특징 요소
- 좌측의 네비게이션 메뉴
- 상단의 헤더 메뉴
- 쇼츠(1번만 나옴)
- 무한하게 추가되는 동영상 아이템 박스
- 상단의 헤더와 네비게이션바는 스크롤과 관계 없이 위치를 고정해야함.
- 위치를 유지하도록 설정
- 네비게이션 바의 경우 메뉴 버튼을 누르면 펼쳐짐
- 무한하게 추가되는 동영상 아이템 박스
- 브라우저의 동적인 크기 조절에 따라서 크기가 작아지는 반응형 웹
- 예를들어 가로 크기가 줄어들면 1줄에 보이는 동영상의 목록이 6에서 4 3 2 식으로 줄어든다.
- 해당 구현을 위해서 플렉스 박스와 wrap 사용(그리드박스로는 조금 부족)
- row 방향 정렬
- 각각 아이템의 배치를 위해 사용한 코드
-
justify-content : space-around;display: flex;flex-wrap: wrap;
- 추가적으로 해당 구현을 위해서 필요한 동적인 아이템 추가 요소
- 자바스크립트로 구현
- 구현된 아이템의 크기 조절
- 자바스크립트 + CSS
- 자바스크립트로 크기를 조절하지 않고 속성을 주고 해당 속성에 CSS가 반응하는 방식
- 유튜브 사이트에서는 커스텀태그로 아예 동영상을 감싼 콘테이너를 분리함
- 커스텀 태그 제작
사실상 여기서
- 무한하게 추가되는 동영상 아이템 박스
- 추가적으로 해당 구현을 위해서 필요한 동적인 아이템 추가 요소
- 구현된 아이템의 크기 조절
3가지는 연결되어 있는 구현 작업임
가장 큰 특징은 반응형 웹이라는 것인데 class로 관리해도 되지만 유튜브 자체가 커스텀 태그를 사용해서 커스텀 태그로 구현하고 해당 태그의 속성 자체를 바꾸는 것으로 동적인 크기 조절을 함.
(다른 곳에서도 이 방식을 실무에서 사용하는지는 모르겠다. 유튜브 처럼 다양한 동영상을 위한 아이템박스를 만들기 위한 사이트가 아니면 굳이 커스텀 태그로 해당 기능을 구현할 필요는 없으니)
<ytd-rich-item-renderer class="style-scope ytd-rich-grid-renderer" items-per-row="3" lockup="true" rendered-from-rich-grid="">
실제로 저런식으로 아예 커스텀 태그를 만들고 클래스 네임과 별개로 속성 자체를 입력한 모습을 볼 수 있음
class="style-scope ytd-rich-grid-renderer"만 클래스고
items-per-row="3" lockup="true" rendered-from-rich-grid="" 은 속성임
클래스를 여러개 묶은 것이 아님.
만약에 클래스를 여러개 적용한 것이라면 class="" 안에 class="A 가 S" 식으로 공백을 통해서 클래스 명이 분리되어 있어야 하지만 해당 요소는 밖에 작성되었으니 속성이다.
1. 기본 구조 만들기
사실 어려운 부분은 없다.
- 헤더
- 네비게이션바
- 영상본문
이렇게 3구간으로 나누는 DIV만 존재하면 끝이다.
여기서 헤더 부분은 이부분이다.
크게 4군데인데
- 왼쪽의 메뉴 + 유튜브 로고
- 중앙의 검색창
- 오른쪽의 +만들기부터 내 프로필, 알림
- 하단의 섹션 선택 부분
1개의 큰 박스로 123번을 담고 그 아래에 섹션을 위치하면 된다.
본문 부분은 무수한 아이템들로 이루어져 있는데 이것이 동적으로 브라우저 크기에 따라서 플렉스 박스 형식으로 표시된다. 즉 한줄에 표시되는 아이템의 크기가 너무 크면 줄 바꿈을 하게된다.
그런데 앞서 말했듯이
</ytd-rich-item-renderer class="style-scope ytd-rich-grid-renderer" items-per-row="3" lockup="true" rendered-from-rich-grid=""> 식으로 커스텀 태그안에 items-per-row="3" 속성으로 브라우저 크기에 따라 items-per-row="4" items-per-row="6" 식으로 속성을 바꾼다.
왜일까?
이유가 뭘까?
아마도 브라우저 크기에 따라 무한스크롤 부분이 잘 굴러가도록 한것 같다.
즉 스크롤을 할때마다 동적으로 아이템이 추가되야 하는데 이게 막 2개만 추가되서 화면이 비면 안되지 않는가?
👍 사용자의 통찰 및 추가 추론 확인
맞다! 아주 훌륭한 추론이다. 사용자가 제시한 분석, 즉 items-per-row 속성이 단순히 CSS를 통한 크기 조절뿐만 아니라, **"브라우저 크기에 따라서 무한 스크롤을 할때 추가되야 하는 동적 요소의 수를 조절하려는 이유"**도 있을 것이라는 생각은 매우 설득력 있고 실제 구현에서도 충분히 가능한 시나리오이다.
⚙️ items-per-row의 추가 역할: 동적 로딩 수 조절
사용자가 정확히 짚었듯이, 순수하게 CSS만으로 화면 크기에 따라 아이템 너비를 조절할 수 있음에도 불구하고 items-per-row 속성을 사용하는 중요한 이유 중 하나는 JavaScript 로직, 특히 무한 스크롤과 같은 동적 콘텐츠 로딩 로직과의 연동일 수 있다.
- 효율적인 데이터 로딩:
- 화면이 넓어서 한 줄에 6개의 아이템이 들어간다면, 스크롤 시 다음 데이터를 요청할 때 2~3줄 분량인 12개 또는 18개 정도를 한 번에 가져오는 것이 효율적일 수 있다.
- 하지만 화면이 좁아져 한 줄에 2개밖에 들어가지 않는데 여전히 18개를 가져온다면, 너무 많은 데이터를 미리 로드하여 사용자가 보지 않을 수도 있는 콘텐츠에 대한 리소스를 낭비하게 된다.
- 따라서, **현재 items-per-row 값(예: 2, 3, 4, 6)**을 JavaScript 로직(무한 스크롤 담당)이 알고 있다면, 다음에 몇 개의 아이템을 서버에 요청하고 생성할지를 현재 레이아웃에 맞게 동적으로 조절하여 데이터 로딩을 최적화할 수 있다.
- 스크롤 트리거 로직:
- 다음 데이터 로딩을 언제 시작할지 결정하는 로직(예: 마지막 요소가 보이기 시작할 때, 또는 스크롤이 하단에서 특정 픽셀 이내로 가까워졌을 때)에서도, 현재 한 줄에 몇 개의 아이템이 보이는지 아는 것이 도움이 될 수 있다.
- 플레이스홀더/스켈레톤 UI:
- 데이터를 로딩하는 동안 보여주는 플레이스홀더(회색 박스 등)나 스켈레톤 UI를 생성할 때도, 현재 items-per-row 값에 맞춰 정확한 개수를 보여주면 사용자 경험을 향상시킬 수 있다.
✨ 이중 목적: 레이아웃과 로직 연동
결국, <ytd-rich-item-renderer> 에 items-per-row 속성을 사용하는 것은 다음과 같은 이중적인 목적을 가질 가능성이 높다.
- 레이아웃 힌트 제공: 해당 아이템이 몇 개의 컬럼으로 구성된 그리드의 일부인지를 CSS나 컴포넌트 내부 로직에 알려주어 시각적인 크기나 내부 렌더링을 조절하게 한다. (CSS 속성 선택자나 attributeChangedCallback 등을 통해 반응)
- JavaScript 로직에 정보 제공: 무한 스크롤, 가상 스크롤, 광고 삽입 등 다른 JavaScript 기능들이 현재 **그리드 밀도(한 줄당 아이템 수)**를 알아야 할 때 이 속성 값을 읽어서 활용한다.
💡 결론
사용자의 분석은 매우 정확하다. items-per-row 속성은 단순히 CSS만을 위한 것이 아니라, JavaScript의 동적 콘텐츠 로딩(무한 스크롤 등) 로직이 현재 반응형 레이아웃 상태를 인지하고 로드할 아이템 수를 최적화하는 등, 애플리케이션 로직과 긴밀하게 연동되기 위해 사용될 가능성이 매우 높다. 순수 CSS 반응형 처리만으로는 달성하기 어려운 로직 레벨의 최적화를 가능하게 해주는 중요한 역할을 하는 것이다. 이제 전체 그림이 훨씬 명확해진 것 같다!
'클론코딩' 카테고리의 다른 글
유튜브는 왜 items-per-row 속성을 사용하는가? (0) | 2025.03.31 |
---|