Relocate redux selectors for background state

[brad-decker]

Background Information

We currently have a number of redux selectors for getting values from the ‘metamask’ background state object. These selectors are scattered through the various selector files. Typically what happens is that an engineer needs a selector for something in the background, and create an intermediary selector in the same file they are working in. Conversely it could have been a carryover from before we had much separation in our selectors. The eventual goal of our redux refactoring will be to have no selectors/* folder because selectors will be consolidated into the slice files.

That won’t be the case for background state, though. We do not want to have a slice in redux for the background state, as it gives the illusion that redux controls the background state instead of being a copy of it for purposes of allowing component access and rerendering on changes.

To help us get an idea of where background state is access in the UI, we need to move all of the selectors that are only for background state to be in the new background folder. There are some selectors that use background state and redux UI state together for some purpose, for these we need to extract the background part into a selector that is stored in the background folder and then compose that in the original selector to get the data necessary. This will help us to get an understanding of which parts of our redux stores are dependent on background state.

Details

Similar to breaking the API folder down by controller, it would be good to breakdown selectors by controller as well. The reason for this is that we may want to shift from the flattened state tree to a state tree that is subdivided by controllers (which is how the background interacts with state. The flattening happens before sending to the UI). By not flattening if we chose to use a different way of interacting with the background (like GraphQL) we’d have a clearer separation and we could push the mechanism for that solution (Schemas, resolvers, mutations, etc in GraphQL) to the controller level…this would allow us to keep the definition of how the clients interact with controller state at the controller level instead of implemented in the clients.

By separating the background selectors away from redux we aren’t losing anything, we can still use Redux until such a time as we think it’s necessary to shift, but we have clearer boundaries between what is and isn’t UI (Ephemeral) state versus background (persisted). If we further separate boundaries by controller it will allow us to figure out a dependency graph of which UI components rely upon state from the various controllers.

If we want a task per controller, I can do that, or we can list them out as todos on this task and divide up by item. As we do this we should create the new files in TypeScript.