마이그레이션 가이드
이 가이드는 UI1 (decentraland-ui)에서 UI2 (decentraland-ui2).
마이그레이션할 시기
마이그레이션은 다음 세 가지 정당한 이유로 시작할 수 있습니다:
1. 기술적 개선
다음과 같은 이유로 컴포넌트를 마이그레이션하려는 경우:
더 나은 테마 지원
향상된 TypeScript 타입
다른 UI2 컴포넌트와의 일관성
성능 최적화
접근성 향상
2. 컴포넌트 업데이트
UI1 컴포넌트를 업데이트해야 하는 경우
아직 UI2에 대응하는 버전이 없습니다
요구 사항: 먼저 UI2에 만든 다음 사용하세요
3. 프로젝트 요구 사항
이 컴포넌트는 새 프로젝트 또는 기존 프로젝트에서 사용됩니다
적절하게 마이그레이션할 시간이 있습니다
프로젝트 리소스로 충분히 마이그레이션할 수 있습니다
마이그레이션 프로세스
1단계: 계획
마이그레이션을 시작하기 전에:
의존성 식별
어떤 다른 컴포넌트를 사용하나요?
현재 어떤 프로젝트에서 사용하나요?
예정된 Breaking Change가 있나요?
현재 사용 현황 검토
이 컴포넌트를 사용하는 프로젝트가 몇 개인가요?
가장 자주 사용되는 props는 무엇인가요?
알려진 이슈가 있나요?
범위 정의
이것은 1:1 마이그레이션인가요?
예정된 개선 사항이 있나요?
일정은 어떻게 되나요?
2단계: UI2 컴포넌트 생성
다음 내용을 따르세요 커스텀 컴포넌트 UI2 후보 컴포넌트용 가이드.
요구 사항:
styled-components에는 객체 구문을 사용하세요
theme 값만 사용하세요(임의 값 사용 금지)
포괄적인 Storybook 스토리를 추가하세요
완전한 테스트를 작성하세요
모든 props와 동작을 문서화하세요
예시 구조:
3단계: 호환성 유지
UI2 컴포넌트는 반드시 UI1 버전과 동일한 props와 동작을 제공해야 합니다.
동일한 Props
하위 호환 변경
props를 변경하거나 추가해야 한다면:
먼저, 새 props를 UI1에 선택적으로 추가하세요
그다음, UI1 사용처가 새 props를 사용하도록 마이그레이션하세요
마지막으로, 새 API로 UI2 컴포넌트를 만드세요
4단계: UI1 컴포넌트 폐기 예고
UI1 컴포넌트에 폐기 예고를 추가하세요:
5단계: 점진적 도입
즉시 마이그레이션을 강요하지 마세요. 점진적 도입을 허용하세요:
배포 UI2 컴포넌트
문서화 마이그레이션 경로
업데이트 새 프로젝트가 UI2를 사용하도록
마이그레이션 기존 프로젝트를 기회가 있을 때마다
계획 향후 UI1 제거 계획(사전 고지 포함)
마이그레이션 예시
예시 1: 단순 컴포넌트
기본 Card 컴포넌트:
UI1 버전
UI2 버전
예시 2: 변형이 있는 컴포넌트
마이그레이션하는 Button 변형이 있는:
UI1 버전
UI2 버전
마이그레이션 체크리스트
각 컴포넌트 마이그레이션마다 이 체크리스트를 사용하세요:
계획 단계
구현 단계
폐기 예고 단계
도입 단계
일반적인 마이그레이션 패턴
CSS에서 Styled Components로
클래스 이름에서 Props로
고정 값에서 Theme로
Breaking Change
때로는 Breaking Change가 필요합니다. 신중하게 처리하세요:
Breaking Change가 허용되는 경우
보안 수정
치명적 버그
주 버전 업데이트
폐기된 기능 제거(사전 고지 포함)
Breaking Change 처리 방법
조기에 공지 - 변경 사항을 충분히 미리 전달하세요
마이그레이션 경로 제공 - 업데이트 방법을 문서화하세요
버전 증가 - 시맨틱 버저닝을 따르세요
폐기 예고 기간 - 마이그레이션할 시간을 주세요
코드모드 - 가능하다면 자동 마이그레이션 도구를 제공하세요
예시: 폐기된 props 제거
마이그레이션 테스트
마이그레이션된 컴포넌트가 올바르게 동작하는지 확인하세요:
비주얼 리그레션 테스트
UI1과 UI2 컴포넌트를 시각적으로 비교하세요:
동작 테스트
props가 동일하게 동작하는지 확인하세요:
문서 업데이트
마이그레이션 후 문서를 업데이트하세요:
UI1 컴포넌트 문서 업데이트
UI2 컴포넌트 문서 생성
다음 단계
검토 커스텀 컴포넌트 UI2 컴포넌트 생성용
참고 스타일링 및 테마 적용 스타일링 표준용
확인 프로세스 개요 전체 워크플로용
마지막 업데이트