Refactor project-view to use future proof ideas

[breadchris]

Might be better to throw here and let it crash.

In the future, I'm going to restructure my calls into the Actions to be idempotent. And by that I mean, grabbing the project and projectConfig will happen in the Component or Container and then this Action won't have to deal with reading from another store.

This is a pattern that I'm guilty of starting and, unfortunately, it's pervasive in the codebase. That's just an early mistake that I made while learning Vuex that we'll have to take time sorting out as we code.

Collection of thoughts:

• Bugs are more likely to happen when refactoring because function calls rely on side-effects from other calls (open project must happen before you can push to the repo).
• The contract with a function requires inspecting it's code to understand if it will have a bug, versus when handed parameters Typescript handles that for us (by yelling about bad arguments).
• Because we can't have multiple params to a function in the store, we have to create a type/interface to hold that contract (at least in the "old" store style). That friction made me avoid passing complex arguments because it was painful.
• The store becomes more tightly coupled to the state of other stores, which makes refactoring the app more painful. Case in point, go refactor Project View (and you will experience suffering).
• Stores should be idempotent and independent of your View code. Their state should be self-contained and treated more as "microservice APIs".
• I didn't want any logic in components early on (because in React land that was the mantra, but we also had Containers for holding complex logic). That pushed a lot of complexity into the stores and created friction for development. While meeting tight deadlines, I started skipping Containers and calling the store directly from Components. And I still didn't want logic in the Components... So the stores are really fat because of this.

Case in point, I've made some mistakes in the architecture and it pervades all new code written. It'd be nice to start avoiding those mistakes (by changing the principles we write new code with) and fixing this up over time.

Originally posted by @freeqaz in https://github.com/_render_node/MDI0OlB1bGxSZXF1ZXN0UmV2aWV3Q29tbWVudDQxMTU2NjY2Nw==/comments/review_comment