Fix useStore composable losing reactivity when used in uxStore

[cstns]

Description

Main train of thought after reproducing the issue locally and noticing that the mainNavContexts was undefined which prevented the mainNav's nearestContextualMenu watcher to set the mainNavContext due to it's safeguard is that the useStore composable is losing store reactivity and causing the uxStore mainNavContexts getter to fail.

Related Issue(s)

closes #4797

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

Labels

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

[joepavitt]

just for readability and consistency, can we make this variable state please?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.59%. Comparing base (33ac8f7) to head (b9b17f0).
Report is 56 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4937      +/-   ##
==========================================
- Coverage   78.64%   78.59%   -0.05%     
==========================================
  Files         324      325       +1     
  Lines       15265    15296      +31     
  Branches     3507     3512       +5     
==========================================
+ Hits        12005    12022      +17     
- Misses       3260     3274      +14     

Flag	Coverage Δ
backend	78.59% <ø> (-0.05%)	⬇️

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

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

[joepavitt]

should these be store and rootStore?

Given that the input to usePermissions is store, but you're passing a variable called rootState?

[cstns]

It would depend on the context where they are used, I used the naming vuex describes them in their api. It would be better if i'd change the argument name in the composable to rootState to match it

[joepavitt]

Can confirm this hasn't fixed the issue for me. To reproduce consistently:

• Sign out
• Sign in as a Platform Admin
• Go straight to Admin Settings

[joepavitt]

Debugging this myself, and found that in MainNav.vue, the watch for nearestContextualMenu is firing correctly, but this.mainNavContexts is undefined.

Investigating further...

[cstns]

Very nice catch! Back to the drawing board but at least now i have something to work with

[joepavitt]

If I hardcode:

mainNavContexts: function (state, getters, rootState, rootGetters) {
        return {}
}

Then the mainNavContexts is no longer undefined, so I'm guesisng Vue is catching an error in the getter and returning undefined, even though I've put breakpoints and console logs in that egtter, and none of them are firing 🤷

[cstns]

That's what i though i was fixing, i assumed that the permissions mixin was failing but I was working blindfolded until now. Now that I can reproduce it consistently i can get to the bottom of it easier

[joepavitt]

Found the issue:

Navigating Direct for First Time:

On the Refresh (Working)

The back button isn't getting loaded correctly into the context.

I've also verified this is occurring when you go to the "User Settings" for the exact same reason.

[joepavitt]

Boils down to a few circular dependencies going on, as well as race conditions between multiple watchers. This vuex architecture to manage this is incredibly messy

[joepavitt]

Calling this.setMainNavBackButton(menu) in the nearestContextMenu handler does at least make the side menu render, but it does so without a "Back" button.

I need to call that a night, but you have enough to go on in order to get this fixed in the morning hopefully.

[joepavitt]

Fix pushed in #4949 this can be closed