Skip to content

Refactor (packages/app/src/components/updater-action.ts): Function with many returns - #167

Open
jktakeshi wants to merge 2 commits into
CMU-313:mainfrom
jktakeshi:refactor-updater-action
Open

Refactor (packages/app/src/components/updater-action.ts): Function with many returns#167
jktakeshi wants to merge 2 commits into
CMU-313:mainfrom
jktakeshi:refactor-updater-action

Conversation

@jktakeshi

@jktakeshi jktakeshi commented Sep 8, 2026

Copy link
Copy Markdown

P1B: Starter Task: Refactoring PR

1. Issue

Link to the associated GitHub issue:
Issue #116

Full path to the refactored file: packages/app/src/components/updater-action.ts

What do you think this file does?
It converts updater states into UI labels and actions for checking or installing updates.

What is the scope of your refactoring within that file?
I refactored updaterAction() without changing useUpdaterAction(). I also expanded its unit tests and added the focused test to CI.

Which Qlty‑reported issue did you address?
updaterAction() had “Function with many returns (count = 7).”

packages/app/src/components/updater-action.ts
  7  Function with many returns (count = 7): updaterAction

       7  export function updaterAction(state: UpdaterState | undefined) {
       8    if (!state) return { label: "settings.updates.action.checkNow" as const }
       9    switch (state.status) {
      10      case "checking":
      11        return { label: "settings.updates.action.checking" as const }
      12      case "downloading":
          [hid 11 additional lines]

2. Refactoring

How did the specific issue you chose impact the codebase’s maintainability?
The switch contained repeated return values and required adding more control-flow branches for new states.

What changes did you make to resolve the issue?
I replaced the switch cases with a typed state-to-action lookup table and a single return statement. This resulted in only one return instead of the original 7.

How do your changes improve maintainability? Did you consider alternatives?
The table makes each state’s behavior visible in one place and ensures all statuses are covered. I considered simplifying the switch, but the lookup table removed more repetition, and I believe makes the code cleaner.

3. Validation

How did you validate that the change is correct?
I added nine unit tests covering undefined and every UpdaterState status; all passed locally, and coverage showed that the refactored updaterAction() lines were executed. The app typecheck and focused lint pass, Qlty no longer reports the smell, and the focused test is included in .github/workflows/test.yml.

Local lint and tests

Focused lint:
Local lint passing

Local updater-action tests:
Local tests passing

Attach a screenshot of the test coverage showing the lines were executed by the tests.
Updater action test coverage

Focused coverage for updaterAction(): all nine tests passed. The only uncovered lines, 27–51, belong to the unchanged useUpdaterAction() function; the refactored lines 7–24 were covered.

Attach a screenshot showing the tests that cover the change passing during CI
Updater action tests passing in CI

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.ts> showing fewer reported issues after the changes.

Before refactoring:
Qlty before refactoring

After refactoring:
Qlty after refactoring

Qlty reports no remaining smells in the selected file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant