Custom Components

We distinguish between two types of custom components, each with different processes and expectations.

Component Types

A) Project-Specific Custom Components

Components built for a specific project or screen, not intended for reuse across other projects.

Examples:

  • A Box with special layout used within one project

  • A Card variant with bespoke layout for one project's screens

  • Project-specific data visualizations

  • One-off layout components

When to use:

  • Component solves a problem unique to one project

  • Unlikely to be needed in other projects

  • Too specific to generalize

B) UI2 Candidate Components

Components intended for reuse across multiple projects and products.

Examples:

  • Navbar - Site-wide navigation

  • UserMenu - User account menu

  • Standardized Modal dialogs

  • Components being migrated from UI1

When to use:

  • Component will be used in multiple projects

  • Represents a common Decentraland pattern

  • Replaces or extends a UI1 component


Project-Specific Components

Requirements

Use MUI as Base

MUST extend existing MUI components whenever possible:

Don't fork or duplicate patterns that MUI already covers:

  • Use Card instead of creating a custom box with shadows

  • Use Button instead of creating a styled anchor

  • Use TextField instead of creating a custom input

  • Extend Dialog instead of creating a custom modal

Theme Values Only

MUST use values from the UI2 theme:

No arbitrary values allowed:

  • Colors: Use theme.palette or dclColors

  • Spacing: Use theme.spacing(n)

  • Border radius: Use theme.shape.borderRadius

  • Typography: Use theme.typography variants

  • Breakpoints: Use theme.breakpoints helpers

States and Accessibility

MUST define and implement all interactive states:

MUST implement basic accessibility:**

  • Keyboard navigation - Focusable and operable with keyboard

  • Focus indicators - Visible focus states

  • ARIA labels - Where text isn't visible

  • Semantic HTML - Use appropriate elements

  • Color contrast - Meet WCAG AA standards

Example: Project-Specific Component


UI2 Candidate Components

Components that will be shared across projects require higher standards and more thorough documentation.

Requirements

Theme Alignment

MUST rely exclusively on UI2 theme values:

Storybook Coverage

MUST add comprehensive Storybook stories:

Required coverage:

  1. All props and variants

    • Every prop combination

    • All size variants

    • All color variants

  2. All states

    • Idle/default

    • Loading

    • Error

    • Disabled

    • Hover (via pseudo states addon)

    • Focus (via pseudo states addon)

  3. Interactions

    • Click handlers

    • Form submissions

    • Keyboard navigation

  4. Color schemes

    • Light mode

    • Dark mode

  5. Responsive behavior

    • Key breakpoints (xs, md, lg)

    • Document behavior at each breakpoint

Example Storybook file:

Component Structure

UI2 candidate components SHOULD follow this structure:

Documentation Requirements

MUST include in component README:

  1. Purpose - What problem does this solve?

  2. Usage - How to use the component

  3. Props - All props with types and descriptions

  4. Examples - Common use cases

  5. Accessibility - Keyboard support, ARIA labels

  6. Theming - Which theme values it uses

  7. Migration notes - If replacing a UI1 component

Example README:

Testing Requirements

MUST include tests for:

  • Prop rendering

  • User interactions

  • Accessibility features

  • Responsive behavior

  • Error states


Decision Matrix

Use this to decide which type of component to create:

Question
Project-Specific
UI2 Candidate

Will other projects use this?

No

Yes

Does UI1 have an equivalent?

N/A

Probably

Needs Storybook documentation?

No

Yes

Needs comprehensive tests?

Basic

Extensive

Design review required?

Project-level

UI2-level

Can use project-specific patterns?

Yes

No

Must work in all themes?

No

Yes


Approval Process

Project-Specific Components

  1. Code review by project maintainer

  2. Verify theme compliance

  3. Test in project context

  4. Merge when approved

UI2 Candidate Components

  1. Design review and approval

  2. Technical design review

  3. Implementation

  4. Storybook stories

  5. Comprehensive tests

  6. Accessibility review

  7. Code review

  8. PR to UI2 repository

  9. Version and publish

  10. Update dependent projects


Best Practices

Composition Over Customization

Progressive Enhancement

Start simple and add features as needed:

  1. Basic version with core functionality

  2. Add responsive behavior

  3. Add accessibility features

  4. Add advanced interactions

  5. Optimize performance

Documentation First

Before writing code:

  1. Write component README

  2. Define props interface

  3. List required states

  4. Plan Storybook stories

  5. Then implement


Next Steps

Last updated