Replace legacy FC/GUI singletons with independent Pinia stores (single source of truth)

[Erics1337]

Is your feature request related to a problem? Please describe

Summary

Recent work (for example, PR #4781) migrated the GPS tab UI from jQuery to Vue and introduced Pinia stores that currently proxy legacy global singletons (FC, GUI, CONFIGURATOR, etc.) via computed getters and setters. This issue tracks the follow-up migration to make Pinia the authoritative, independent single source of truth (SSoT), remove the legacy singletons, and centralize side effects (MSP, persistence) inside Pinia actions.

Motivation

• Cleaner architecture and separation of concerns
• More predictable and robust reactivity (avoid subtle proxy edge cases)
• Easier unit testing and component isolation
• Simplified future development and reduced long-term technical debt

Goals

• Create independent Pinia stores for core domains (flight controller, GPS, connection, navigation, dialogs, sensors, features, etc.)
• Ensure UI components read from and write to Pinia directly
• Provide a deterministic hydration and sync adapter to stage migration from legacy singletons to Pinia
• Centralize MSP, network, and persistence logic inside Pinia actions
• Remove legacy singletons when safe

Describe the solution you'd like

Stores and APIs

Implement dedicated Pinia stores per domain with stable public APIs:

• flightControllerStore
  • state: { config, gpsConfig, gpsData, features, compassConfig, sensorData, ... }
  • actions: load(), save(), poll(), hydrateFromLegacy(), plus focused actions like loadGpsConfig() and saveGpsConfig()
• connectionStore
  • state + actions to manage connection lifecycle, port info, reconnect flow, etc.
• navigationStore, dialogStore, gpsStore (map UI state), featuresStore, etc.

Hydration strategy

• Add explicit store.hydrateFromLegacy(legacySource) actions that copy a snapshot of legacy singletons into Pinia on app start or on-demand (for example, tab mount).
• Keep hydration deterministic and explicit (no implicit copying).

Synchronization adapter (migration bridge)

• Implement a central adapter module that handles write-through from Pinia to legacy singletons during the transition.
• The adapter is the only code path that writes to legacy singletons.
• Pinia actions call the adapter when necessary.
• Debounce and throttle adapter writes for high-frequency updates.
• Expose a small API, for example:
  • syncToLegacy(storeName, changes)
  • syncFromLegacy(...) (optional, when needed)

Centralize side effects

• Move MSP calls, persistence (mspHelper), and long-running polling or intervals into store actions so components remain pure consumers.
• Example:
  • flightControllerStore.actions.loadGpsConfig() and saveGpsConfig() wrap MSP.promise calls.

Migration workflow (incremental)

• New Vue components and new work read from Pinia only.
• Legacy code can keep read-only access for a transition window.
• Writes funnel through Pinia actions, which use the adapter so legacy code sees updates.
• Migrate one tab fully to Pinia-first (GPS is a strong candidate after PR Migrate GPS tab to Vue component #4781), validate behavior, then migrate remaining tabs in small PRs.
• After most call sites (for example, >90%) use Pinia, flip authoritative direction: Pinia becomes SSoT and the adapter stops writing back.
• Remove legacy singletons and proxy code after verification.

Testing, observability, and ergonomics

• Unit tests for store actions and adapter behavior
• Integration tests for MSP and polling flows, plus map and telemetry behavior
• Optional migration logging to detect stale-access patterns during transition
• Document store public APIs and a migration guide
• Use PR labels like pinia-migration to track progress

Describe alternatives you've considered

Keep proxying legacy singletons (status quo)

• Pros: lowest short-term risk, fastest for UI shipping, minimal churn
• Cons: preserves technical debt, continued coupling to globals, fragile reactive behavior, harder to test
• Verdict: acceptable short term, not a long-term solution

Event bus or message-passing bridge

• Pros: decouples without immediate singleton replacement
• Cons: harder to reason about state, higher race risk, still not a clean SSoT
• Verdict: useful for one-off cases, not ideal for full migration

Convert legacy singletons to reactive wrappers

• Pros: minimal refactor, existing singleton usage remains
• Cons: global source of truth persists, legacy coupling remains, removal becomes harder
• Verdict: short-term mitigation only

One big Pinia-first rewrite

• Pros: fastest path to clean end state
• Cons: very high risk, massive PRs, difficult review and QA
• Verdict: too risky, prefer incremental

Switch state managers (Vuex or custom)

• Pros: potentially fits constraints if Pinia cannot
• Cons: unnecessary overhead since Pinia is already adopted and appropriate
• Verdict: stick with Pinia

Proposed migration plan (incremental, low-risk)

1. Accept current Vue and Pinia migrations that proxy legacy singletons (surface changes)
2. Create independent Pinia stores with stable public APIs per domain
3. Add explicit hydrateFromLegacy(legacySource) actions per store
4. Implement a centralized synchronization adapter (Pinia ↔ legacy) with debouncing and throttling
5. Move MSP and network write logic into Pinia actions (no direct MSP calls from components)
6. Migrate one tab fully to Pinia-first (GPS first) and verify behavior
7. Migrate remaining Vue tabs to Pinia-first in small PRs (one tab per PR)
8. Migrate legacy tabs incrementally to read from Pinia (or mount Vue equivalents)
9. Flip authoritative direction: Pinia becomes SSoT, disable adapter write-backs
10. Remove legacy singletons and proxy code
11. Full regression testing and QA across supported platforms (desktop, PWA, Android native)

Implementation details and best practices

• Store actions own side effects; components are pure
• Hydration is explicit (hydrateFromLegacy()), deterministic, and discoverable
• Single-writer policy: Pinia actions are canonical writer, adapter forwards only during migration
• Debounce expensive writes and high-frequency polling; centralize intervals inside stores
• Add unit tests for actions and integration tests for MSP and polling flows
• Document store APIs and migration steps for contributors

Acceptance criteria

• New Vue components and migrated tabs read from and write to Pinia stores
• MSP, network, and persistence side effects are centralized in store actions
• Legacy non-Vue code continues to function during migration via the adapter
• No regressions in telemetry, map behavior, or configuration persistence
• Migration checklist completed and documented
• Legacy singleton accessors removed and tests updated

Risks and mitigations

• Race conditions (legacy vs Pinia): single-writer policy, debounced adapter, explicit sync points
• Large scope: small per-tab PRs and staged rollout
• Performance impact: throttling and centralizing polling and sync
• Map and UI regressions: focused QA for map, telemetry, and config persistence on all supported platforms

Suggested metadata

• Labels: refactor, tech-debt, pinia, vue, pinia-migration
• Assignees: pick an owner (for example, haslinghuis or Erics1337)
• Milestone: next maintenance release or dedicated state-migration milestone
• Estimated effort: medium to large (multiple small PRs over a few sprints)

Checklist

• Create a migration tracking epic or milestone (for example, "Pinia SSoT migration")
• Design Pinia store public APIs for each domain (state, getters, actions)
• Implement hydrateFromLegacy(legacySource) for each store
• Implement a centralized synchronization adapter (Pinia ↔ legacy) with debouncing and throttling
• Move MSP and network write logic into Pinia actions (avoid direct MSP calls from components)
• Migrate one tab fully to Pinia-first and verify behavior (GPS tab first candidate)
• Add unit tests for new store actions and integration tests for polling and MSP flows
• Migrate remaining Vue tabs to Pinia-first in small PRs (one tab per PR recommended)
• Migrate legacy tabs incrementally to read from Pinia (or mount Vue equivalents)
• Flip authoritative direction: make Pinia the SSoT and disable write-backs to legacy singletons
• Remove legacy singleton proxies and delete legacy singleton modules
• Full regression testing and QA across platforms (desktop, PWA, Android native)
• Update contributor documentation (how to use Pinia stores and migration strategy)

Other information

No response

[haslinghuis]

IMO in general as migrated tabs work beside legacy tabs

• migrate remaining tabs using Vue and Pinia stores
• remove remaining jQuery event handlers (like in main.js)
• remove remaining legacy code
• further improvements

[haslinghuis]

Remaining tabs:

• cli
• failsafe
• firmware_flasher
• led_strip
• motors
• osd
• pid_tuning
• power
• receiver
• sensors
• setup
• transponder
• vtx

[haslinghuis]

@coderabbitai see #4800 (comment). Create a new github issue report for tracking already migrated and remaining tabs and add guidance on migration details for further development (like the use of Pinia, integrating CSS).

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# Fetch the specific comment content
gh api repos/betaflight/betaflight-configurator/issues/comments/3761733148 --jq '.body'

echo "---SEPARATOR---"

# Find all Vue tab components in src/components/tabs/
fd -e vue . src/components/tabs/ 2>/dev/null || echo "No Vue tabs found yet"

echo "---SEPARATOR---"

# Find legacy JS tabs in src/js/tabs/
fd -e js . src/js/tabs/ 2>/dev/null | head -20

echo "---SEPARATOR---"

# Check if there's existing migration documentation
fd -e md . | xargs grep -l "migration" 2>/dev/null | head -5

Length of output: 1085

---

🏁 Script executed:

#!/bin/bash

# Check one migrated tab to understand the structure and patterns
echo "=== Example: PortsTab.vue structure ==="
head -100 src/components/tabs/PortsTab.vue

echo -e "\n=== Check Pinia store usage ==="
fd -e js -e vue . src/stores/ | head -10

echo -e "\n=== Check if there's a migration pattern in recent PRs ==="
gh pr list --state merged --limit 10 --json number,title,labels | jq '.[] | select(.title | test("migrate|vue|tab"; "i")) | {number, title}'

echo -e "\n=== Check for CSS/SCSS files in components ==="
fd -e scss -e css . src/components/tabs/ | head -5

Length of output: 6035

---

🏁 Script executed:

#!/bin/bash

# Check the FC store structure as an example
echo "=== Pinia FC Store Example ==="
head -80 src/stores/fc.js

echo -e "\n=== Check CSS integration pattern ==="
# Look at a legacy tab CSS
ls -la src/js/tabs/*.css 2>/dev/null | head -5

echo -e "\n=== Check how CSS is imported in migrated tabs ==="
grep -n "style" src/components/tabs/PortsTab.vue | head -3

echo -e "\n=== Count migrated vs legacy tabs ==="
echo "Migrated Vue tabs: $(fd -e vue . src/components/tabs/ | wc -l)"
echo "Legacy JS tabs: $(fd -e js . src/js/tabs/ | wc -l)"

Length of output: 2457

---

🏁 Script executed:

#!/bin/bash

# Create the GitHub issue with tracking and migration guidance
gh issue create \
  --title "Track Vue/Pinia Tab Migration Progress" \
  --label "enhancement,documentation" \
  --assignee "haslinghuis" \
  --body "## Overview

This issue tracks the ongoing migration of legacy JavaScript tabs to Vue 3 with Pinia state management. The goal is to modernize the codebase by converting all tabs to use Vue components with proper state management while maintaining feature parity.

**Related:** `#4800`

---

## Migration Status

### ✅ Migrated Tabs (13)

- [x] Auxiliary (PR `#4801`)
- [x] Backups
- [x] Configuration (Pinia refactor in PR `#4799`)
- [x] GPS
- [x] Help
- [x] Landing
- [x] Logging
- [x] Onboard Logging (PR `#4805`)
- [x] Options
- [x] Ports
- [x] Servos
- [x] User Profile

### 🔄 Remaining Legacy Tabs (13)

- [ ] CLI
- [ ] Failsafe
- [ ] Firmware Flasher
- [ ] LED Strip
- [ ] Motors
- [ ] OSD
- [ ] PID Tuning
- [ ] Power
- [ ] Receiver
- [ ] Sensors
- [ ] Setup
- [ ] Transponder
- [ ] VTX

---

## Migration Guidelines

### File Structure

1. **Create Vue component**: \`src/components/tabs/[TabName]Tab.vue\`
2. **Extend BaseTab**: Import and use \`<BaseTab tab-name=\"...\">\` wrapper
3. **Organize legacy assets**: Keep corresponding CSS/HTML in \`src/js/tabs/\` until fully migrated

### Component Structure

\`\`\`vue
<template>
    <BaseTab tab-name=\"example\">
        <div class=\"content_wrapper\">
            <div class=\"tab_title\" v-html=\"\$t('tabExample')\"></div>
            <WikiButton docUrl=\"example\" />
            <!-- Tab content here -->
        </div>
    </BaseTab>
</template>

<script setup>
import { ref, computed, onMounted } from 'vue';
import { useFlightControllerStore } from '@/stores/fc';
import BaseTab from './BaseTab.vue';
import WikiButton from '@/components/elements/WikiButton.vue';

const fcStore = useFlightControllerStore();
// Component logic here
</script>

<style scoped>
/* Tab-specific styles */
</style>
\`\`\`

### Pinia Store Integration

1. **Use existing stores** where applicable:
   - \`src/stores/fc.js\` - Flight controller data (FC.CONFIG, FC.GPS_CONFIG, etc.)
   - \`src/stores/connection.js\` - Connection state
   - \`src/stores/navigation.js\` - Tab navigation
   - \`src/stores/dialog.js\` - Dialog management
   - \`src/stores/debug.js\` - Debug utilities

2. **Access FC data via store**:
   \`\`\`javascript
   import { useFlightControllerStore } from '@/stores/fc';
   
   const fcStore = useFlightControllerStore();
   const config = computed(() => fcStore.config);
   \`\`\`

3. **Create new stores** if needed for tab-specific state that should be shared

### CSS Integration

1. **Use scoped styles**: Add \`<style scoped>\` section in Vue component
2. **Import legacy CSS** during transition: Can reference existing CSS from \`src/js/tabs/\`
3. **Gradually inline styles**: Move CSS rules into component \`<style scoped>\` block
4. **Remove legacy CSS**: Clean up old CSS files after migration is complete

### State Management Best Practices

1. **Reactive data**: Use \`ref()\` for primitive values, \`reactive()\` for objects
2. **Computed properties**: Use \`computed()\` for derived state
3. **Legacy FC object**: Access via Pinia store computed properties (FC is already reactive)
4. **MSP calls**: Use existing MSP infrastructure, ensure proper error handling

### Translation (i18n)

1. **Use \$t() helper**: \`v-html=\"\$t('translationKey')\"\` or \`{{ \$t('key') }}\`
2. **Update locales**: Add new keys to \`locales/en/messages.json\` (English only)
3. **Existing keys**: Reuse translation keys from legacy tabs where possible

### Important Migration Rules

1. **Feature parity first**: Migrate existing functionality without adding new features (per learning f6c16d6c-8b7e-4d43-80b5-dd01361ab753)
2. **No new error handling**: Unless required for Vue migration to function properly
3. **Test thoroughly**: Ensure migrated tab works alongside legacy tabs
4. **One tab per PR**: Keep PRs focused on single tab migration
5. **Static IDs**: Safe to use in shared components since only one tab is active at a time (per learning b9d465e0-49bc-4323-80a7-973ea7e3fdb9)

### Common Patterns to Migrate

1. **jQuery event handlers** → Vue event handlers (\`@click\`, \`@change\`, etc.)
2. **jQuery DOM manipulation** → Vue template bindings (\`v-model\`, \`v-for\`, \`v-if\`)
3. **Global state in tab** → Pinia store or component state
4. **Inline scripts** → \`<script setup>\` composition API
5. **String templates** → Vue template syntax

### Testing Checklist

- [ ] Tab loads without errors
- [ ] All UI elements render correctly
- [ ] MSP communication works (read/write)
- [ ] Save/apply functionality works
- [ ] Tab switching doesn't break state
- [ ] Translation keys display correctly
- [ ] Styles match legacy tab appearance
- [ ] Legacy tabs still work (no regression)

---

## Post-Migration Cleanup Tasks

Once all tabs are migrated:

1. Remove remaining jQuery event handlers (e.g., in main.js)
2. Clean up legacy tab files in \`src/js/tabs/\`
3. Remove unused legacy code and dependencies
4. Further improvements and optimizations

---

## Resources

- **Base Tab Component**: \`src/components/tabs/BaseTab.vue\`
- **Example Migrated Tabs**: PortsTab.vue, ConfigurationTab.vue, GpsTab.vue
- **Pinia Stores**: \`src/stores/\`
- **Legacy Tabs**: \`src/js/tabs/\`
- **Recent Migration PRs**: `#4801` (Auxiliary), `#4805` (Onboard Logging), `#4799` (Configuration)

---

**Note**: This is a living document. Update progress as tabs are migrated and add any new patterns or gotchas discovered during migration."

Length of output: 46

---

🏁 Script executed:

#!/bin/bash

# Create the GitHub issue without the documentation label
gh issue create \
  --title "Track Vue/Pinia Tab Migration Progress" \
  --label "enhancement" \
  --assignee "haslinghuis" \
  --body "## Overview

This issue tracks the ongoing migration of legacy JavaScript tabs to Vue 3 with Pinia state management. The goal is to modernize the codebase by converting all tabs to use Vue components with proper state management while maintaining feature parity.

**Related:** `#4800`

---

## Migration Status

### ✅ Migrated Tabs (13)

- [x] Auxiliary (PR `#4801`)
- [x] Backups
- [x] Configuration (Pinia refactor in PR `#4799`)
- [x] GPS
- [x] Help
- [x] Landing
- [x] Logging
- [x] Onboard Logging (PR `#4805`)
- [x] Options
- [x] Ports
- [x] Servos
- [x] User Profile

### 🔄 Remaining Legacy Tabs (13)

- [ ] CLI
- [ ] Failsafe
- [ ] Firmware Flasher
- [ ] LED Strip
- [ ] Motors
- [ ] OSD
- [ ] PID Tuning
- [ ] Power
- [ ] Receiver
- [ ] Sensors
- [ ] Setup
- [ ] Transponder
- [ ] VTX

---

## Migration Guidelines

### File Structure

1. **Create Vue component**: \`src/components/tabs/[TabName]Tab.vue\`
2. **Extend BaseTab**: Import and use \`<BaseTab tab-name=\"...\">\` wrapper
3. **Organize legacy assets**: Keep corresponding CSS/HTML in \`src/js/tabs/\` until fully migrated

### Component Structure

\`\`\`vue
<template>
    <BaseTab tab-name=\"example\">
        <div class=\"content_wrapper\">
            <div class=\"tab_title\" v-html=\"\$t('tabExample')\"></div>
            <WikiButton docUrl=\"example\" />
            <!-- Tab content here -->
        </div>
    </BaseTab>
</template>

<script setup>
import { ref, computed, onMounted } from 'vue';
import { useFlightControllerStore } from '@/stores/fc';
import BaseTab from './BaseTab.vue';
import WikiButton from '@/components/elements/WikiButton.vue';

const fcStore = useFlightControllerStore();
// Component logic here
</script>

<style scoped>
/* Tab-specific styles */
</style>
\`\`\`

### Pinia Store Integration

1. **Use existing stores** where applicable:
   - \`src/stores/fc.js\` - Flight controller data (FC.CONFIG, FC.GPS_CONFIG, etc.)
   - \`src/stores/connection.js\` - Connection state
   - \`src/stores/navigation.js\` - Tab navigation
   - \`src/stores/dialog.js\` - Dialog management
   - \`src/stores/debug.js\` - Debug utilities

2. **Access FC data via store**:
   \`\`\`javascript
   import { useFlightControllerStore } from '@/stores/fc';
   
   const fcStore = useFlightControllerStore();
   const config = computed(() => fcStore.config);
   \`\`\`

3. **Create new stores** if needed for tab-specific state that should be shared

### CSS Integration

1. **Use scoped styles**: Add \`<style scoped>\` section in Vue component
2. **Import legacy CSS** during transition: Can reference existing CSS from \`src/js/tabs/\`
3. **Gradually inline styles**: Move CSS rules into component \`<style scoped>\` block
4. **Remove legacy CSS**: Clean up old CSS files after migration is complete

### State Management Best Practices

1. **Reactive data**: Use \`ref()\` for primitive values, \`reactive()\` for objects
2. **Computed properties**: Use \`computed()\` for derived state
3. **Legacy FC object**: Access via Pinia store computed properties (FC is already reactive)
4. **MSP calls**: Use existing MSP infrastructure, ensure proper error handling

### Translation (i18n)

1. **Use \$t() helper**: \`v-html=\"\$t('translationKey')\"\` or \`{{ \$t('key') }}\`
2. **Update locales**: Add new keys to \`locales/en/messages.json\` (English only)
3. **Existing keys**: Reuse translation keys from legacy tabs where possible

### Important Migration Rules

1. **Feature parity first**: Migrate existing functionality without adding new features
2. **No new error handling**: Unless required for Vue migration to function properly
3. **Test thoroughly**: Ensure migrated tab works alongside legacy tabs
4. **One tab per PR**: Keep PRs focused on single tab migration
5. **Static IDs**: Safe to use in shared components since only one tab is active at a time

### Common Patterns to Migrate

1. **jQuery event handlers** → Vue event handlers (\`@click\`, \`@change\`, etc.)
2. **jQuery DOM manipulation** → Vue template bindings (\`v-model\`, \`v-for\`, \`v-if\`)
3. **Global state in tab** → Pinia store or component state
4. **Inline scripts** → \`<script setup>\` composition API
5. **String templates** → Vue template syntax

### Testing Checklist

- [ ] Tab loads without errors
- [ ] All UI elements render correctly
- [ ] MSP communication works (read/write)
- [ ] Save/apply functionality works
- [ ] Tab switching doesn't break state
- [ ] Translation keys display correctly
- [ ] Styles match legacy tab appearance
- [ ] Legacy tabs still work (no regression)

---

## Post-Migration Cleanup Tasks

Once all tabs are migrated:

1. Remove remaining jQuery event handlers (e.g., in main.js)
2. Clean up legacy tab files in \`src/js/tabs/\`
3. Remove unused legacy code and dependencies
4. Further improvements and optimizations

---

## Resources

- **Base Tab Component**: \`src/components/tabs/BaseTab.vue\`
- **Example Migrated Tabs**: PortsTab.vue, ConfigurationTab.vue, GpsTab.vue
- **Pinia Stores**: \`src/stores/\`
- **Legacy Tabs**: \`src/js/tabs/\`
- **Recent Migration PRs**: `#4801` (Auxiliary), `#4805` (Onboard Logging), `#4799` (Configuration)

---

**Note**: This is a living document. Update progress as tabs are migrated and add any new patterns or gotchas discovered during migration."

Length of output: 65

---

@haslinghuis I've created issue #4812 to track the Vue/Pinia tab migration progress. The issue includes:

Migration Status Tracking:

• ✅ 13 Migrated tabs (Auxiliary, Backups, Configuration, GPS, Help, Landing, Logging, Onboard Logging, Options, Ports, Servos, User Profile)
• 🔄 13 Remaining legacy tabs (CLI, Failsafe, Firmware Flasher, LED Strip, Motors, OSD, PID Tuning, Power, Receiver, Sensors, Setup, Transponder, VTX)

Comprehensive Migration Guidelines:

• File structure and component template
• Pinia store integration (fc, connection, navigation, dialog, debug stores)
• CSS integration patterns (scoped styles, legacy CSS transition)
• State management best practices
• Translation/i18n usage
• Important migration rules (feature parity, no new features unless required)
• Common jQuery → Vue patterns
• Testing checklist

Post-Migration Cleanup Tasks:

• jQuery event handler removal
• Legacy code cleanup
• Further optimizations

The issue references #4800 and recent migration PRs (#4801, #4805, #4799) as examples. It's marked as a living document to be updated as tabs are migrated.

---

🧠 Learnings used

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4781
File: src/components/tabs/GpsTab.vue:759-766
Timestamp: 2026-01-10T21:39:28.222Z
Learning: In betaflight-configurator, when reviewing refactoring/migration PRs (e.g., migrating tabs from legacy JavaScript to Vue), focus on the migration correctness and structure. Do not suggest adding new error handling, improvements, or features that weren't present in the original code unless they are directly required for the migration to function properly. Maintainer haslinghuis confirmed this approach on PR `#4781`.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 0
File: :0-0
Timestamp: 2025-12-23T22:01:54.915Z
Learning: In betaflight-configurator PR `#4727`, ConfigurationTab.vue was successfully migrated from `semver-min` to `semver`. As of the PR update, only src/js/tabs/motors.js still uses `import semver from "semver-min"`, and this is the last file requiring migration before issue `#4741` can be fully resolved and semver-min removed from package.json.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4794
File: src/components/elements/WikiButton.vue:3-11
Timestamp: 2026-01-12T22:04:39.803Z
Learning: In betaflight-configurator, only one tab component is active and rendered at a time, so components used across multiple tabs (like WikiButton) won't have multiple instances in the DOM simultaneously. This means static IDs in shared components used by tabs won't cause duplicate ID issues.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4727
File: src/components/tabs/ConfigurationTab.vue:708-708
Timestamp: 2025-12-15T21:10:06.905Z
Learning: In betaflight-configurator, two semver import patterns currently coexist in the codebase: `import semver from "semver-min"` (used in motors.js and ConfigurationTab.vue, with semver-min listed as an explicit dependency in package.json) and `import semver from "semver"` (used in 20+ legacy tabs and PortsTab.vue as a transitive dependency). Both patterns work in production. The standardization of these patterns is tracked in issue `#4741` and should be addressed separately from individual tab migration PRs.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4510
File: src/js/msp.js:384-391
Timestamp: 2025-09-19T20:42:20.332Z
Learning: Complex MSP duplicate handling fixes in Betaflight Configurator can cause infinite loading messages when changing tabs due to disruption of the callback resolution mechanism. Simple code-only duplicate detection (using this.callbacks.some((instance) => instance.code === code)) is the safer approach that preserves tab switching functionality.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4510
File: src/js/msp.js:384-391
Timestamp: 2025-09-19T20:41:44.286Z
Learning: When fixing MSP duplicate handling in Betaflight Configurator, avoid complex changes to callback resolution mechanisms as they can break tab switching functionality. Simple duplicate detection based on code and payload size is safer than complex requestKey-based approaches.

---

Learnt from: blckmn
Repo: betaflight/betaflight-configurator PR: 4583
File: src/js/tabs/firmware_flasher.js:949-961
Timestamp: 2025-09-02T07:45:48.606Z
Learning: In src/js/tabs/firmware_flasher.js, the config file loading code path after firmware loading (in the load_file click handler) cannot be reached when UF2 firmware is loaded, according to the maintainer blckmn. This code is maintained for backward compatibility with unified target settings and will be refactored in a future PR.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4708
File: locales/en/messages.json:7721-7729
Timestamp: 2025-11-20T20:26:40.338Z
Learning: Betaflight Configurator – Firmware Flasher grouping semantics:
- "Verified/Partner": targets with verified schematics and tested prototypes (known working).
- "Unsupported": vendor/community-supplied targets that did not go through the verification program.
- "Legacy": legacy targets kept for existing users.
These labels surface in src/js/tabs/firmware_flasher.js via i18n keys:
firmwareFlasherOptionLabelVerifiedPartner, firmwareFlasherOptionLabelVendorCommunity, firmwareFlasherOptionLabelLegacy. Only English text should be updated directly in locales/en/messages.json; other locales are managed externally.

---

Learnt from: blckmn
Repo: betaflight/betaflight-configurator PR: 4771
File: locales/en/messages.json:4443-4444
Timestamp: 2026-01-01T18:12:28.065Z
Learning: betaflight/betaflight-configurator: For feature-focused PRs (e.g., login/backups), maintainers prefer not to include unrelated typo/text cleanups (e.g., locales/en/messages.json key "pidTuningPidSlidersHelp"). Such edits should be deferred to a separate PR. Source: PR `#4771`, comment by blckmn: "Not for this PR".

---

Learnt from: mituritsyn
Repo: betaflight/betaflight-configurator PR: 4526
File: src/js/gui.js:43-43
Timestamp: 2025-06-20T12:35:49.283Z
Learning: In the Betaflight Configurator codebase, tabs in `defaultCloudBuildTabOptions` are conditionally displayed based on firmware build options. The logic in `serial_backend.js` checks `FC.CONFIG.buildOptions` and only adds tabs to `GUI.allowedTabs` if the firmware was built with support for that feature.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4597
File: src/js/utils/common.js:95-127
Timestamp: 2025-09-09T20:02:33.475Z
Learning: In the Betaflight Configurator codebase, the Chromium v140 compatibility issue with sortSelect was resolved by rewriting the implementation to use native DOM APIs (Array.from, select.options, select.remove, select.add) instead of jQuery DOM manipulation methods (this.children, this.empty().append). The fix still performs DOM operations but avoids the specific jQuery methods that were causing issues in Chromium v140.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4532
File: src/js/VirtualFC.js:234-234
Timestamp: 2025-06-27T22:06:49.210Z
Learning: In the betaflight-configurator codebase, the VirtualFC.js AUX_CONFIG array must stay synchronized with the betaflight firmware's msp_box.c definitions to ensure proper auxiliary mode functionality. Changes to mode names should follow the firmware source code even if it potentially breaks backward compatibility with saved presets.

---

Learnt from: haslinghuis
Repo: betaflight/betaflight-configurator PR: 4532
File: src/js/VirtualFC.js:234-234
Timestamp: 2025-06-27T22:06:49.210Z
Learning: In the betaflight-configurator codebase, the VirtualFC.js AUX_CONFIG array must stay synchronized with the betaflight firmware's msp_box.c definitions to ensure proper auxiliary mode functionality. Changes to mode names should follow the firmware source code even if it potentially breaks backward compatibility with saved presets.

[haslinghuis]

@Erics1337 added a sub task for tracking in #4812

[haslinghuis]

@Erics1337 could we improve agents using https://github.com/github/awesome-copilot/blob/main/instructions/vuejs3.instructions.md

See also https://github.com/github/awesome-copilot/blob/main/docs/README.instructions.md

[Erics1337]

@haslinghuis I took a look at the awesome-copilot Vue 3 instructions. My take is we are already doing a lot of what is in there, so I do not think there is huge value in dropping the whole file in verbatim.

Where it would help is capturing the specific deltas for this repo so agents stop guessing. Some of it is trivial bikeshedding (PascalCase vs snake_case, etc.), but some of it is meaningful, especially around typing.

The biggest gap vs the “ideal” is that Configurator is still a JS codebase, not TS. I am curious what your appetite is for changing that. A full TypeScript migration feels like a big lift and risky to do all at once, but I think we can move in that direction incrementally if we pick the right approach.

One path is JSDoc-first (types in comments + stricter checking) to get most of the TS benefits without breaking builds, then migrate file-by-file to .ts when it makes sense. That would also improve agent output immediately.

If you are aligned, I can put together a small repo-specific Copilot instructions doc that references the Vue 3 baseline and then spells out our conventions, including a JSDoc-first typing approach for stores and composables. What do you think about aiming for TS long-term vs keeping it JSDoc-based for now?

[haslinghuis]

@Erics1337 Agree. Going JsDoc-first and then migrating JS to TS could be next phase(s) after having completed Vue migration. Also perhaps we need to sweep over to remove some leftovers. It is amazing what have achieved so far.

[haslinghuis]

We are ready to implement this - following implementations using Nuxt UI / TailWind