product_control_client/docs/superpowers/specs/2026-03-26-coal-feeding-lay...

7.4 KiB

coalFeeding.vue Right Panel Layout Redesign

Overview

This design updates the right-side data presentation area in src/views/coalFeeding.vue. The current implementation uses a large HTML <table> to render the unit comparison area. The new implementation will remove <table> entirely and replace it with ordinary block elements while preserving the existing row-and-column visual structure.

The redesign will follow the confirmed "path 2" approach:

  • Keep the current business fields and interaction logic unchanged.
  • Rebuild the right-side layout as a column-oriented block structure.
  • Split each unit column into reusable visual sections.
  • Preserve the current visual alignment, colors, and row semantics.

Goals

  • Remove the <table> layout from the right-side unit display area.
  • Preserve the current visual feeling of a multi-column industrial control panel.
  • Render the layout as:
    • one fixed parameter label column
    • multiple unit columns rendered with ordinary elements
  • Split each unit column into five ordered sections:
    1. upper block: four time-setting rows + middle-side motors + accumulated runtime
    2. 2-side temperature
    3. car number
    4. 1-side temperature
    5. lower block: four independent time-setting rows + return-side motors + accumulated runtime
  • Keep existing click, drag-and-drop, and auto/manual behaviors working.

Non-Goals

  • Do not switch the page to the new backend unit -> equipments -> role_points structure in this change.
  • Do not refactor WebSocket payload handling in this change.
  • Do not alter the current business meanings of fields such as tmyxsds, tempera2, dianji, or dianji2.
  • Do not split logic into separate Vue files unless needed later; this change stays inside coalFeeding.vue.

Current State

The current right panel is rendered as a long <table> with:

  • a left sticky parameter-name column
  • repeated v-for cells for each unit
  • an upper group of rows before 2-side temperature
  • a middle section for temperatures and car number
  • a lower group of rows after 1-side temperature

This structure visually works, but it is difficult to reshape into two explicit per-column blocks because the DOM is organized by rows, not by columns.

Chosen Approach

Use a block-based, column-oriented layout.

The new structure will be:

  • outer right-panel container
  • left parameter column
  • horizontally scrollable unit-column area
  • each unit rendered as one column card-like container

Each unit column will render these sections in order:

  1. Upper block
    • 投煤运行时间设定 -> tmyxsds
    • 投煤停止时间设定 -> tmtzsds
    • 投煤累积时间设定 -> tmljsds
    • 布料运行时间设定 -> blyxsds
    • 中间侧 -> dianji
    • 投煤累积时间 -> tmljsjs
  2. 2侧温度 -> tempera2
  3. 车位号 -> carNumber
  4. 1侧温度 -> tempera1
  5. Lower block
    • 投煤运行时间设定 -> tmyxsdx
    • 投煤停止时间设定 -> tmtzsdx
    • 投煤累积时间设定 -> tmljsdx
    • 布料运行时间设定 -> blyxsdx
    • 回车侧 -> dianji2
    • 投煤累积时间 -> tmljsjx

Data Mapping

This change keeps the existing dataList shape unchanged.

Upper block mapping:

  • tmyxsds
  • tmtzsds
  • tmljsds
  • blyxsds
  • dianji
  • tmljsjs

Middle display mapping:

  • tempera2
  • carNumber
  • tempera1

Lower block mapping:

  • tmyxsdx
  • tmtzsdx
  • tmljsdx
  • blyxsdx
  • dianji2
  • tmljsjx

Interaction Preservation

The redesign must preserve the current interactions:

  • Time-setting fields:
    • show plain text when item.statusAuto === true
    • show <input> when item.statusAuto === false
  • Middle-side motor controls continue to use dianji
  • Return-side motor controls continue to use dianji2
  • Motor click actions continue to call toggleDjStop(...)
  • Temperature drop targets keep current DOM id rules so point binding logic continues to work:
    • tempera2_unit...
    • tempera1_unit...
  • Existing drag/drop handlers stay in place for the fields already using them
  • Unit-level manual/auto toggle controls under the panel remain unchanged

Rendering Structure

The template will be reorganized into these conceptual pieces:

  • parameter label column
    • contains every row label in display order
  • unit columns container
    • renders one column per dataList item
  • unit column header
    • shows the unit name badge
  • upper section container
    • renders upper time rows, motor row, and accumulated runtime row
  • middle temperature section
    • renders 2-side temperature, car number, and 1-side temperature
  • lower section container
    • renders lower time rows, return-side motor row, and accumulated runtime row

Repeated visual blocks inside the unit column will be reduced into small render patterns:

  • time item block
  • motor group block
  • temperature/car display block

These can remain inline in the same file as repeated template fragments or lightweight helper loops.

Layout and Styling

The new layout will use ordinary block elements instead of table semantics:

  • display: flex for the main horizontal layout
  • fixed-width parameter label column
  • horizontally scrollable unit column strip
  • each unit column with a consistent minimum width
  • each row item with controlled height and border styling

Visual continuity requirements:

  • preserve row alignment between label column and unit columns
  • preserve the current gray/white parameter rows
  • preserve the blue motor-area styling
  • preserve the orange temperature styling
  • preserve the highlighted car-number styling
  • preserve the general dense control-panel appearance

To avoid layout drift after removing table semantics:

  • shared row-height classes will be introduced for standard rows
  • motor rows will use a dedicated fixed-height style
  • upper and lower section wrappers will provide clear grouping without breaking alignment

Risks and Mitigations

Risk 1: alignment drift after removing <table>

Mitigation:

  • define explicit heights for standard rows
  • define explicit height for motor rows
  • keep label column and unit columns rendered in the same vertical order

Risk 2: drag/drop regressions on temperature fields

Mitigation:

  • preserve the existing id naming convention for temperature targets
  • keep existing drop handlers on the same business elements

Risk 3: motor interactions change unintentionally

Mitigation:

  • reuse current click handler calls and existing state fields
  • only move markup; do not alter motor state logic during this change

Risk 4: template becomes harder to read

Mitigation:

  • group markup by column section instead of one giant table body
  • use repeated rendering patterns for time blocks and motor groups

Testing Plan

After implementation, verify:

  • the right panel renders without <table>
  • horizontal scrolling still works for the unit columns
  • label column and unit columns remain aligned
  • upper and lower blocks are visually distinct inside each unit column
  • auto/manual display behavior still works for time fields
  • motor click interactions still work
  • temperature drop targets still accept drag-and-drop
  • existing settings section below the panel still renders correctly

Open Constraints

  • The page still uses the current local dataList structure.
  • Future work may migrate the page to the new backend unit/equipment structure, but that is intentionally out of scope here.
  • The current project directory is not a Git repository, so this design document cannot be committed from the current workspace state.