[7839] Data Farm > Applications 4 - remaining vue + loaders

[n-lark]

Description

See test plan: #7839 (comment)

Related Issue(s)

Resolves #7839

• Single-application views now read the app from the data-farm store instead of local fetch.
• Removes mixins/Application.js, replaced by a useActiveApplication composable.
• Detail-page Page Loader is now a shell skeleton ApplicationDetailSkeleton.

The loading work for the ux store will be done in a follow up - Applications 5 - UXStore Loader Registry #8053

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
  • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production
• Link to Changelog Entry PR, or note why one is not needed.

Labels

• Includes a DB migration? -> add the area:migration label

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.14%. Comparing base (21dd63f) to head (0d105ef).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8052   +/-   ##
=======================================
  Coverage   76.14%   76.14%           
=======================================
  Files         439      439           
  Lines       23571    23571           
  Branches     6281     6281           
=======================================
  Hits        17948    17948           
  Misses       5623     5623           

Flag	Coverage Δ
backend	76.14% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[andypalmi]

Nice migration, the context.application getter deriving from the store is much cleaner than the old mixin watch.

One thing on createInstance.vue: the breadcrumb at lines 7-8 reads application.id and application.name directly, but application now comes from the store's activeApplication, which is null until loadActiveApplication resolves in created (the old mixin defaulted it to {}). That breadcrumb sits in the always-rendered header and is only guarded by v-if="team", and team is usually already present from session storage, so could it throw during the first render before the app loads? Line 28 in the same file already uses application?.id, so mirroring that (application?.id / application?.name, or v-if="team && application") would probably cover it. index.vue and CreateInstanceMultiStep.vue already look guarded.

Would it be worth a small render test for that page with an unloaded store, just so this path is covered? The store additions themselves have good coverage.

[andypalmi]

Two small non-blocking things for possible follow-up:

Stale app data in the list cache. context.setApplication now delegates to setActiveApplication, which merges its argument into applicationsById. That argument now includes the app object nested in an instance or device (setInstance/setDevice pass instance.application / device.application). If that nested object is partial or stale relative to the list, opening an instance would overwrite the list card's name/description with the instance payload's values until the next full refetch. Is instance.application guaranteed to carry the current, complete name and description, or could this surface stale values on the Applications list?

Delete-while-viewing, as a seam with #8030. If a deleted event arrives for the app you're currently on, removeApplication drops it from applicationsById, so activeApplication becomes null and index.vue's !application?.id guard flips the page back to the loading skeleton permanently. Is that the intended outcome, or should a delete-while-viewing redirect to the Applications list (or show a "removed" state) instead of an indefinite skeleton?