react-slick 대안: 무엇을 만들었는지에 따라 이전하세요
react-slick은 jQuery 시대의 slick 캐러셀을 React로 포팅한 것입니다. 여전히 동작은 하지만, 아키텍처가 훅보다 이전 세대이고, 릴리스가 뜸하며, 모든 빌드에 별도의 CSS 파일을 끌고 들어옵니다. 올바른 대체재는 기능보다 여러분의 사용 방식이 두 진영 중 어디에 속하는지에 더 좌우됩니다.
| react-slick | Embla | Swiper | react-horizontal-scrolling-menu | |
|---|---|---|---|---|
| 이것은 무엇인가 | jQuery slick의 React 포트 | 헤드리스 캐러셀 엔진 | 완전한 슬라이더 프레임워크 | 네이티브 스크롤 기반 스크롤 메뉴 |
| 유지보수 | 뜸함 | 활발함 | 활발함 | 2018년부터 활발함 |
| 번들 (min+gzip) | ≈15 kB + slick CSS | ≈8 kB | ≈40 kB | ≈5.7 kB |
| 별도 CSS 파일 필요 | 필요 (2개) | 불필요 | 필요 (코어) | 1개, 또는 shadcn 아이템을 통한 Tailwind |
| 슬라이드 시맨틱 (스냅, 점, 페이드) | 있음 | 있음 | 있음 | 없음 — 의도적으로 |
| 클릭 가능한 항목의 행 | centerMode로 억지로 구현 | 엔진 위에 직접 구현 | 결을 거슬러 설정 | 핵심 사용 사례 |
크기는 대략적인 코어 기준입니다. 마지막 열은 이 사이트 자체의 라이브러리입니다 — 표는 이를 숨기지 않고 그대로 밝힙니다.
진영 1: 진짜 캐러셀이었던 경우
히어로 슬라이더, 이미지 갤러리, 후기 로테이터 등 slick의 점, 페이드, 자동재생이 디자인을 지탱하던 모든 곳. 진짜 캐러셀 엔진으로 이전하세요:
- Embla — 모든 것을 직접 스타일링하고 작은 헤드리스 코어를 원한다면. 정신적으로 "현대화된 slick"에 가장 가깝습니다.
- Swiper — slick의 기능 목록을 많이 활용했다면. slick의 모든 기능에는 대개 더 나은 Swiper 대응 기능이 있습니다.
slidesToShow/slidesToScroll은 Embla의 slidesInView/slidesToScroll 또는 Swiper의 slidesPerView/slidesPerGroup에 대응시키고, 화살표 위치를 잡는 CSS 오버라이드는 삭제해도 됩니다 — 두 후계자 모두 직접 버튼을 렌더링할 수 있게 해줍니다.
진영 2: centerMode를 뒤집어쓴 내비게이션이었던 경우
또 다른 slick 설치 사례는 조용한 쪽입니다: 카테고리, 로고, 날짜, 필터의 행을, slick이 이미 번들에 들어 있다는 이유만으로 centerMode, focusOnSelect, variableWidth로 캐러셀처럼 억지로 구부린 경우입니다. 신호는 여러분이 싸워야 했던 것들입니다: 드래그 후에 발생하는 클릭, 엉뚱한 타이밍의 화살표, 측정할 수 없던 항목, 원치 않던 스냅.
그 행은 사실 메뉴였습니다. react-horizontal-scrolling-menu는 centerMode가 흉내 내던 세 가지를 — 클릭한 항목을 중앙 정렬하고, 드래그 지원과 함께 네이티브로 스크롤하며, 어떤 항목이 보이는지 알려주는 것을 — 슬라이더 엔진 없이 ≈5.7 kB로 해냅니다. 가장 흔한 두 가지 형태는 스크롤 탭과 카테고리 레일 페이지에서 확인하세요.
어느 진영이든: 마이그레이션은 보기보다 작습니다
slick의 API 표면은 넓지만, 실제 설정을 감사해보면 빠르게 줄어듭니다: 대부분의 프로젝트는 손에 꼽을 정도의 prop만 사용합니다. 실제로 설정한 것들을 나열하고, 각 사용처가 어느 진영에 속하는지 판단한 뒤, 인스턴스 단위로 이전하세요 — 두 진영은 종종 하나의 코드베이스 안에 공존하며, 둘이 반드시 같은 라이브러리로 귀결되어야 한다는 규칙은 없습니다.