Migration Guide
This guide covers the process of migrating components from UI1 (decentraland-ui) to UI2 (decentraland-ui2).
When to Migrate
Migrations can start for three valid reasons:
1. Technical Improvement
You want to migrate a component for:
Better theming support
Improved TypeScript types
Consistency with other UI2 components
Performance optimization
Accessibility improvements
2. Updating a Component
A UI1 component needs to be updated
There is no UI2 equivalent yet
Requirement: Create it in UI2 first, then use it
3. Project Needs
The component will be used in a new or existing project
There is time available to migrate it properly
Project resources allow for thorough migration
Do not migrate components "just because." Each migration should have a clear business or technical justification.
Migration Process
Step 1: Planning
Before starting the migration:
Identify dependencies
What other components does it use?
What projects currently use it?
Are there any breaking changes planned?
Review current usage
How many projects use this component?
What props are most commonly used?
Are there any known issues?
Define scope
Will this be a 1:1 migration?
Are there planned improvements?
What's the timeline?
Step 2: Create UI2 Component
Follow the Custom Components guide for UI2 candidate components.
Requirements:
Use object syntax for styled-components
Use only theme values (no arbitrary values)
Add comprehensive Storybook stories
Write complete tests
Document all props and behaviors
Example structure:
Step 3: Maintain Compatibility
The UI2 component MUST expose the same props and behaviors as the UI1 version.
Same Props
Backward Compatible Changes
If you need to change or add props:
First, add the new props to UI1 as optional
Then, migrate UI1 consumers to use the new props
Finally, create the UI2 component with the new API
Step 4: Deprecate UI1 Component
Add a deprecation notice to the UI1 component:
Step 5: Gradual Adoption
Don't force immediate migration. Allow gradual adoption:
Publish UI2 component
Document migration path
Update new projects to use UI2
Migrate existing projects opportunistically
Plan eventual UI1 removal (with notice)
Migration Examples
Example 1: Simple Component
Migrating a basic Card component:
UI1 Version
UI2 Version
Example 2: Component with Variants
Migrating a Button with variants:
UI1 Version
UI2 Version
Migration Checklist
Use this checklist for each component migration:
Planning Phase
Implementation Phase
Deprecation Phase
Adoption Phase
Common Migration Patterns
CSS to Styled Components
Class Names to Props
Fixed Values to Theme
Breaking Changes
Sometimes breaking changes are necessary. Handle them carefully:
When Breaking Changes Are Acceptable
Security fixes
Critical bugs
Major version updates
Removing deprecated features (with notice)
How to Handle Breaking Changes
Announce early - Communicate changes well in advance
Provide migration path - Document how to update
Version bump - Follow semantic versioning
Deprecation period - Give time to migrate
Codemods - Provide automated migration tools if possible
Example: Removing Deprecated Props
Testing Migration
Ensure migrated components work correctly:
Visual Regression Testing
Compare UI1 and UI2 components visually:
Behavioral Testing
Ensure props work the same way:
Documentation Updates
After migration, update documentation:
Update UI1 Component Docs
Create UI2 Component Docs
Next Steps
Review Custom Components for creating UI2 components
See Styling & Theming for styling standards
Check Process Overview for the complete workflow
Last updated