# 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.