[GH-ISSUE #447] [Feature]: Refactor Printer Status #276

New issue

Closed

opened 2026-05-06 12:27:49 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

2026-05-06 12:27:49 +02:00

Owner

Originally created by @aneopsy on GitHub (Feb 19, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/447

Originally assigned to: @maziggy on GitHub.

Problem or Use Case

To improve type safety and reduce the risk of bugs, I propose replacing the string type on PrinterStatus.status with a union type of its known values (e.g. 'RUNNING' , 'IDLE' , 'FAILED', 'PAUSE' 'PRINTING'). This ensures only valid states can be assigned, catching typos and invalid values at compile time rather than at runtime.

Pros:

If you typo 'RUNING', the compiler will flag it as an error
Autocomplete will suggest 'RUNNING' | 'IDLE' | 'PRINTING' | 'FAILED' | 'PAUSE'
A switch statement will warn you if you forget to handle a case

Proposed Solution

Alternatives Considered

No response

Feature Category

Monitoring & Stats

Priority

Nice to have

Mockups or Examples

No response

Contribution

I would be willing to help implement this feature

Checklist

I have searched existing issues to ensure this feature hasn't already been requested

Originally created by @aneopsy on GitHub (Feb 19, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/447 Originally assigned to: @maziggy on GitHub. ### Problem or Use Case To improve type safety and reduce the risk of bugs, I propose replacing the string type on PrinterStatus.status with a union type of its known values (e.g. 'RUNNING' , 'IDLE' , 'FAILED', 'PAUSE' 'PRINTING'). This ensures only valid states can be assigned, catching typos and invalid values at compile time rather than at runtime. Pros: - If you typo 'RUNING', the compiler will flag it as an error - Autocomplete will suggest 'RUNNING' | 'IDLE' | 'PRINTING' | 'FAILED' | 'PAUSE' - A switch statement will warn you if you forget to handle a case ### Proposed Solution . ### Alternatives Considered _No response_ ### Feature Category Monitoring & Stats ### Priority Nice to have ### Mockups or Examples _No response_ ### Contribution - [x] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested

BreizhHardware

2026-05-06 12:27:49 +02:00

closed this issue
added the
enhancement
label

BreizhHardware commented

2026-05-06 12:27:50 +02:00

Author

Owner

@aneopsy commented on GitHub (Feb 19, 2026):

in PrinterPage.tsx

const isPrintingWithObjects = (status?.state === 'RUNNING' || status?.state === 'PAUSE' || status?.state === 'PAUSED') && (status?.printable_objects_count ?? 0) >= 2;

disabled={!(status.state === 'RUNNING' || status.state === 'PAUSE' || status.state === 'PAUSED') || (status.printable_objects_count ?? 0) < 2 || !hasPermission('printers:control')}

const isPaused = status.state === 'PAUSED' || status.state === 'PAUSE';

Looking at the code above, the state can be either 'PAUSE' or 'PAUSED', but the switch statement below only handles 'PAUSE', it doesn't catch 'PAUSED', which falls through to the default case and is displayed as "Idle". What is the intended difference between PAUSE and PAUSED, or should they be treated the same?

  switch (state) {
    case 'RUNNING':
      return 'Printing';
    case 'PAUSE':
      return 'Paused';
    case 'FINISH':
      return 'Finished';
    case 'FAILED':
      return 'Failed';
    case 'IDLE':
      return 'Idle';
    default:
      return state ? state.charAt(0) + state.slice(1).toLowerCase() : 'Idle';
  }
```

@aneopsy commented on GitHub (Feb 19, 2026): in PrinterPage.tsx ```ts const isPrintingWithObjects = (status?.state === 'RUNNING' || status?.state === 'PAUSE' || status?.state === 'PAUSED') && (status?.printable_objects_count ?? 0) >= 2; disabled={!(status.state === 'RUNNING' || status.state === 'PAUSE' || status.state === 'PAUSED') || (status.printable_objects_count ?? 0) < 2 || !hasPermission('printers:control')} const isPaused = status.state === 'PAUSED' || status.state === 'PAUSE'; ``` Looking at the code above, the state can be either 'PAUSE' or 'PAUSED', but the switch statement below only handles 'PAUSE', it doesn't catch 'PAUSED', which falls through to the default case and is displayed as "Idle". What is the intended difference between PAUSE and PAUSED, or should they be treated the same? ```` ts switch (state) { case 'RUNNING': return 'Printing'; case 'PAUSE': return 'Paused'; case 'FINISH': return 'Finished'; case 'FAILED': return 'Failed'; case 'IDLE': return 'Idle'; default: return state ? state.charAt(0) + state.slice(1).toLowerCase() : 'Idle'; } ```

BreizhHardware commented

2026-05-06 12:27:50 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 19, 2026):

You're right that PAUSED is dead code — the printer only ever sends PAUSE via MQTT gcode_state.

Cleaned this up in 0.2.1b:

Removed all PAUSED checks from 4 frontend files and 2 backend files
The valid states remain IDLE, RUNNING, PAUSE, FINISH, FAILED (as reported by MQTT)

Regarding the full union type refactoring — since there are only 5 well-known states coming from MQTT and they're already consistent now, I'm skipping the type alias for now to keep things simple. Happy to revisit if the codebase grows more state checks.

@maziggy commented on GitHub (Feb 19, 2026): You're right that PAUSED is dead code — the printer only ever sends PAUSE via MQTT gcode_state. Cleaned this up in 0.2.1b: - Removed all PAUSED checks from 4 frontend files and 2 backend files - The valid states remain IDLE, RUNNING, PAUSE, FINISH, FAILED (as reported by MQTT) Regarding the full union type refactoring — since there are only 5 well-known states coming from MQTT and they're already consistent now, I'm skipping the type alias for now to keep things simple. Happy to revisit if the codebase grows more state checks.

BreizhHardware referenced this issue

2026-05-06 12:34:21 +02:00

[PR #280] [CLOSED] Fix/queue item expired #985