design-to-code

Design to Code

When converting design mockups/screenshots into front-end code, strictly follow the three-phase order below; do not skip steps.

Phase 1: Layout Skeleton Analysis

Look only at the spatial division; ignore the specific content.

1. Identify the overall direction of the page (vertical flow / horizontal columns / mixed)
2. Split the regions layer by layer from outside to inside, and annotate each region's:
   • Arrangement direction (vertical / horizontal)
   • Nesting hierarchy relationship
3. Output the layout skeleton as a mermaid tree diagram, for example:

graph TD
    PageRoot["页面根容器 (纵向)"]
    PageRoot --> ZoneA["区域A"]
    PageRoot --> ZoneB["区域B"]
    PageRoot --> ZoneC["区域C (卡片容器)"]
    ZoneC --> ZoneC1["区域C1"]
    ZoneC --> ZoneC2["区域C2"]
    ZoneC --> ZoneC3["区域C3"]

1. Output the template pseudocode of the layout skeleton (only div and class, no business content)
2. Wait for the user to confirm the layout before proceeding to Phase 2

Phase 2: Element Filling

In the confirmed layout skeleton, fill in specific UI elements region by region:

1. Referring to the design mockup, list the required UI elements for each region (Tabs, tables, buttons, input boxes, etc.)
2. Determine whether to use components already in the project or bkui-vue base components
3. Fill component tags and attributes into the template skeleton
4. Write the corresponding script logic (data definitions, Props, Emits, etc.)
5. Write the corresponding style styles

Phase 3: Interaction Integration

Once the layout and elements are in place, add the interaction logic:

1. Event binding (click, input, toggle, etc.)
2. Data requests (API calls, parameter passing)
3. State linkage (refresh data on Tab switch, search filtering, pagination, etc.)
4. Route navigation (link clicks, page navigation)

CSS Class Naming Conventions

Naming Format

Use - -connected BEM style, with the format block-name-element-name。

Allowed:

• db-config-page
• db-config-page-header
• db-config-page-primary-tabs
• db-config-content-table-area

Forbidden:

• Single word:header、toolbar、content
• Double underscore:db-config-page__header
• Underscore:db_config_page
• Camel case:dbConfigPage
• Any symbol other than - any symbol other than

Naming Principles

• Each class must contain at least two semantic word groups connected by - connected semantic word groups
• Class names should be fully readable and understandable without relying on parent context
• The Block level uses a page/module prefix to ensure uniqueness

Style Writing Conventions

Forbid &__ concatenation

All child selectors must write the complete class name; it is forbidden to use & concatenation to generate classes.

// 禁止
.db-config-page {
  &__header { }
  &__tabs { }
}

// 禁止
.db-config-page {
  &-header { }
  &-tabs { }
}

Correct Usage

Nest the complete child class within the parent selector, keeping it consistent with the DOM hierarchy:

.db-config-page {
  .db-config-page-header { }

  .db-config-page-primary-tabs { }

  .db-config-page-content {
    .db-config-page-secondary-tabs { }

    .db-config-page-toolbar { }

    .db-config-page-table-area { }
  }
}

Completion Checklist

• Phase 1 layout skeleton has been output and confirmed by the user
• Phase 2 elements have been filled into the corresponding regions
• Phase 3 interaction logic has been integrated
• All class names have at least two semantic word groups, connected only by - connect
• No single-word classes, no __, no &__ concatenation
• In style nesting, all child selectors are complete class names
• The layout structure is consistent with the spatial division of the design mockup