Make PacketViewer table loading state more robust#2560
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2560 +/- ##
==========================================
+ Coverage 79.21% 79.22% +0.01%
==========================================
Files 662 662
Lines 51218 51259 +41
Branches 736 736
==========================================
+ Hits 40570 40609 +39
- Misses 10568 10570 +2
Partials 80 80
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
...c3-cosmos-init/plugins/packages/openc3-vue-common/src/components/TargetPacketItemChooser.vue
Outdated
Show resolved
Hide resolved
b6ba592 to
39190a8
Compare
jmthomas
left a comment
There was a problem hiding this comment.
When I directly navigate via http://localhost:2900/tools/packetviewer/INST/HEALTH_STATUS/ it appears to hang and I just get the loading screen
Seems to load ok for me 🤔 |
completing the first iteration
clayandgen
left a comment
There was a problem hiding this comment.
Loading well for me, the simplified loader approach is definitely going to make this easier!
I was running into some situations where the table was never showing items because the numeric loading state was not going back to 0. This was due to
changeUpdaterbeing called twice whilethis.rows.lengthwas 0, each of which increasing the loading state, then the first resolution decreasing the loading state value and the second no longer triggering the decrease becausethis.rows.lengthwas no longer 0. By adding a scoped boolean to control whether to decrease the component state, and a decrease in the immediate return case, we can ensure that the value is always decreased after it has been increased