Noticed that the MPSControlSection arming logic was very tightly coupled with the snackbar code, not sure why but it would've been not the best since we don't want the snackbar to have any side effects on the arming (snackbar should only be responsible for displaying error messages).
I decoupled arming code from snackbar code, and in the process also refactored snackbar code so that there is one global app snackbar state that lives inside the redux store instead of multiple instances of a snackbar component (doesn't make sense for there to be multiple anyways).
Type of change
What types of changes does your code introduce to this project?
Put an x in the boxes that apply
[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)
How Has This Been Tested?
Please describe the tests that you ran to verify your changes.
[x] Testing network error snackbar successfully pops up when backend is not running.
Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. This is simply a reminder of what we are going to look for before merging your code.
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
Description
Noticed that the
MPSControlSection
arming logic was very tightly coupled with the snackbar code, not sure why but it would've been not the best since we don't want the snackbar to have any side effects on the arming (snackbar should only be responsible for displaying error messages).I decoupled arming code from snackbar code, and in the process also refactored snackbar code so that there is one global app snackbar state that lives inside the redux store instead of multiple instances of a snackbar component (doesn't make sense for there to be multiple anyways).
Type of change
What types of changes does your code introduce to this project? Put an
x
in the boxes that applyHow Has This Been Tested?
Please describe the tests that you ran to verify your changes.
Checklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. This is simply a reminder of what we are going to look for before merging your code.