feat(ZMSKVR-1084): service variant description

[ChristianVierthaler]

Pull Request Checklist (Feature Branch to next):

• Ich habe die neuesten Änderungen aus dem next Branch in meinen Feature-Branch gemergt.
• Das Code-Review wurde abgeschlossen.
• Fachliche Tests wurden durchgeführt und sind abgeschlossen.

Summary by CodeRabbit

• New Features

  • Service finder and appointment summary now show contextual hint text for certain variant options (variants 1–3) to aid selection.

• Improvements

  • Hints are localized so guidance appears in the current language.
  • Appointment summary formatting: removed an extra trailing colon after the appointment type label for cleaner display.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Added VARIANTS_WITH_HINTS and exported getVariantHint in zmscitizenview/src/utils/Constants.ts; wired getVariantHint into ServiceFinder.vue and AppointmentSummary.vue to pass or render conditional hint text for certain variant IDs, and removed a trailing colon from an appointment type label. No other logic changes.

Changes

Cohort / File(s)	Summary
Constants helper zmscitizenview/src/utils/Constants.ts	Added exported VARIANTS_WITH_HINTS = [1, 2, 3] as const and exported getVariantHint(variantId, t) which returns t(\locationVariantText.${variantId}`)whenvariantIdis in that list, otherwiseundefined`.
Variant radio button hints zmscitizenview/src/components/Appointment/ServiceFinder.vue	Imported getVariantHint from @/utils/Constants and added :hint="getVariantHint(variant.variantId, t)" to muc-radio-button instances for variants. No other control-flow or logic changes.
Appointment summary rendering zmscitizenview/src/components/Appointment/AppointmentSummary.vue	Imported getVariantHint and VARIANTS_WITH_HINTS from @/utils/Constants; added conditional branch rendering a hint paragraph using getVariantHint(variantId, t) for variants in VARIANTS_WITH_HINTS, and removed the trailing colon from the bold appointment type label in that branch.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Verify VARIANTS_WITH_HINTS values and as const typing match intended usage.
• Confirm getVariantHint(variantId, t) signature and return type align with component calls.
• Ensure localization keys locationVariantText.<id> exist for referenced IDs.
• Check muc-radio-button accepts and displays the hint prop as expected.
• Review the AppointmentSummary template change for layout/text consistency after colon removal.

Poem

I hop through commits in moonlit code,
I tuck soft hints where variants go,
For IDs one, two, three I hum,
A tiny note with every drum,
A rabbit's cheer for changes small 🐇✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The pull request title 'feat(ZMSKVR-1084): service variant description' clearly summarizes the main change: adding service variant descriptions/hints as a feature.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feature-zmskvr-1084-service-variant-description

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

zmscitizenview/src/components/Appointment/ServiceFinder.vue (1)

70-74: Consider extracting variant IDs to a named constant.

The inline array [1, 2, 3] uses magic numbers without explaining their significance. Extracting them to a named constant would improve maintainability and make the intent clearer.

For example, at the top of the script section:

const VARIANTS_WITH_LOCATION_HINTS = [1, 2, 3] as const;

Then update the condition:

           :hint="
-            [1, 2, 3].includes(variant.variantId)
+            VARIANTS_WITH_LOCATION_HINTS.includes(variant.variantId)
               ? t(`locationVariantText.${variant.variantId}`)
               : undefined
           "

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 15f232c and e470d04.

📒 Files selected for processing (1)

• zmscitizenview/src/components/Appointment/ServiceFinder.vue (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*

⚙️ CodeRabbit configuration file

**/*: Apply the following Clean Code guidelines to all files, as summarized by wojteklu's Clean Code gist:

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules

1. Keep configurable data at high levels.
2. Prefer polymorphism to if/else or switch/case.
3. Separate multi-threading code.
4. Prevent over-configurability.
5. Use dependency injection.
6. Follow Law of Demeter. A class should know only its direct dependencies.

Understandability tips

1. Be consistent. If you do something a certain way, do all similar things in the same way.
2. Use explanatory variables.
3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
4. Prefer dedicated value objects to primitive type.
5. Avoid logical dependency. Don't write methods which works correctly depending on something else in the same class.
6. Avoid negative conditionals.

Names rules

1. Choose descriptive and unambiguous names.
2. Make meaningful distinction.
3. Use pronounceable names.
4. Use searchable names.
5. Replace magic numbers with named constants.
6. Avoid encodings. Don't append prefixes or type information.

Functions rules

1. Small.
2. Do one thing.
3. Use descriptive names.
4. Prefer fewer arguments.
5. Have no side effects.
6. Don't use flag arguments. Split method into several independent methods that can b...

Files:

• zmscitizenview/src/components/Appointment/ServiceFinder.vue

🔇 Additional comments (1)

zmscitizenview/src/components/Appointment/ServiceFinder.vue (1)

70-74: Translation keys for locationVariantText variants 1, 2, and 3 are properly defined.

The required translation keys exist in both zmscitizenview/src/utils/en-US.json and zmscitizenview/src/utils/de-DE.json with appropriate localized text for each variant. No action needed for this concern.

Consider extracting the magic numbers [1, 2, 3] to a named constant for improved maintainability and clarity.

Likely an incorrect or invalid review comment.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

zmscitizenview/src/components/Appointment/AppointmentSummary.vue (1)

319-322: Fix Prettier formatting for the import statement.

The pipeline indicates Prettier formatting issues. The multi-line import has inconsistent spacing.

-import { 
-  getServiceBaseURL,
-  getVariantHint,
- } from "@/utils/Constants";
+import { getServiceBaseURL, getVariantHint } from "@/utils/Constants";

Alternatively, run prettier --write to auto-fix formatting across the file.

zmscitizenview/src/utils/Constants.ts (1)

68-72: Address Prettier formatting warning.

The pipeline reports Prettier formatting issues. Run prettier --write on this file to ensure consistent formatting.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 17b398b and 467bac2.

📒 Files selected for processing (3)

• zmscitizenview/src/components/Appointment/AppointmentSummary.vue (2 hunks)
• zmscitizenview/src/components/Appointment/ServiceFinder.vue (2 hunks)
• zmscitizenview/src/utils/Constants.ts (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• zmscitizenview/src/components/Appointment/ServiceFinder.vue

🧰 Additional context used

📓 Path-based instructions (2)

**/*

⚙️ CodeRabbit configuration file

**/*: Apply the following Clean Code guidelines to all files, as summarized by wojteklu's Clean Code gist:

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules

1. Keep configurable data at high levels.
2. Prefer polymorphism to if/else or switch/case.
3. Separate multi-threading code.
4. Prevent over-configurability.
5. Use dependency injection.
6. Follow Law of Demeter. A class should know only its direct dependencies.

Understandability tips

1. Be consistent. If you do something a certain way, do all similar things in the same way.
2. Use explanatory variables.
3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
4. Prefer dedicated value objects to primitive type.
5. Avoid logical dependency. Don't write methods which works correctly depending on something else in the same class.
6. Avoid negative conditionals.

Names rules

1. Choose descriptive and unambiguous names.
2. Make meaningful distinction.
3. Use pronounceable names.
4. Use searchable names.
5. Replace magic numbers with named constants.
6. Avoid encodings. Don't append prefixes or type information.

Functions rules

1. Small.
2. Do one thing.
3. Use descriptive names.
4. Prefer fewer arguments.
5. Have no side effects.
6. Don't use flag arguments. Split method into several independent methods that can b...

Files:

• zmscitizenview/src/utils/Constants.ts
• zmscitizenview/src/components/Appointment/AppointmentSummary.vue

**/*.{js,jsx,ts,tsx}

⚙️ CodeRabbit configuration file

**/*.{js,jsx,ts,tsx}: Flag any usage of console.log() as it should be replaced with proper logging or removed:

1. For development: console.debug()
2. For production: Remove console.log() statements or use structured logging
3. For errors: Use error console.error()

Example replacement:

// Instead of:
console.log('User data:', userData);

// Use:
console.debug('Processing user data', { userData });
// or for development only:
Remove the console.log entirely

Flag specific logging violations:

1. console.log(), console.debug(), console.warn() usage (except console.error in catch blocks)
2. Any debug output that should use proper logging frameworks

Example replacements:

// Instead of:
console.log('User data:', userData);
console.debug('Processing...');

// Use:
// Remove console.log entirely or use proper logging
// Only console.error in catch blocks is acceptable
try {
  processData(userData);
} catch (error) {
  console.error('Processing failed:', error);
}

Flag JavaScript security and UX issues:

1. alert(), confirm(), prompt() usage (poor UX)
2. eval() usage (security risk)
3. innerHTML with user input (XSS risk)
4. Unfiltered user input in DOM manipulation

Example replacements:

// Instead of:
alert('Error occurred');
eval(userInput);

// Use:
// Use proper error handling and UI components
this.showErrorNotification('Error occurred');
// Avoid eval() entirely

Flag TODO/FIXME comments that indicate technical debt:

1. TODO comments without clear action items
2. FIXME comments indicating broken functionality
3. HACK comments indicating temporary workarounds
4. XXX comments indicating problematic code

These should be converted to proper issues or addressed:

// Instead of:
// TODO: fix this later
// FIXME: this is broken

// Use:
// Create proper issue and reference it
// @see Issue #123: Refactor validation logic

Flag code complexity issues:

1. Functions longer than 50 lines
2. Deep nesting (...

Files:

• zmscitizenview/src/utils/Constants.ts

🪛 GitHub Actions: Frontend Build

zmscitizenview/src/utils/Constants.ts

[warning] 1-1: Prettier formatting issues detected. Run 'prettier --write' to fix.

zmscitizenview/src/components/Appointment/AppointmentSummary.vue

[warning] 1-1: Prettier formatting issues detected. Run 'prettier --write' to fix.

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)

• GitHub Check: Analyze (actions)
• GitHub Check: Analyze (javascript-typescript)
• GitHub Check: call-php-unit-tests / zmsapi-test
• GitHub Check: call-php-unit-tests / zmsclient-test
• GitHub Check: call-zmsautomation-tests / zmsapiautomation

🔇 Additional comments (1)

zmscitizenview/src/utils/Constants.ts (1)

67-72: LGTM - Clean helper implementation.

The VARIANTS_WITH_LOCATION_HINTS constant with as const provides type safety, and getVariantHint is a focused single-purpose helper. The undefined return for non-matching IDs works well with Vue's :hint binding (undefined hints are not displayed).

One minor consideration: Array.prototype.includes() on a readonly tuple [1, 2, 3] as const will type-check variantId: number correctly in modern TypeScript, but if stricter typing is desired later, you could cast or use a type predicate.