Refactor (project): component state cleanup

[ciyer]

We have too many redux stores; we should have just one redux store for the entire application. If a component needs local state, it should use react hooks.

While doing this, we should also reduce to a minimum the information passed to sub-components of the project page. Currently, they get the full project state, but they should only receive what they need.

Here are the locations where stores are created:

createStore

• index.js: user --> Move UserState under the Schema/Model representation #632
• Landing.js: Home --> Remove Landing.state.js #1180

StateKind.REDUX

• Notebooks.state.js: NotebooksModel --> create a single global model and adapt the old StateModel logic #627
• DatasetList.state.js: DatasetListModel --> Move DatasetListModel to global store #1182
• ProjectFork.container.js: Fork --> Adapt the fork UI/UX to be similar to new project creation #1118
• ProjectList.state.js: ProjectListModel --> Move ProjectListModel to projectsCoordinator #1181
• Project.js: View --> Refactor project state management #1183
• ProjectNew.container.js: New --> closed by feat: use core service to fetch templates and create projects #963

mix

• Issue.js / CollaborationList --> Lift issues and merge requests state to root #624

StateKind.REACT

• QuickNav.container.js: QuickNavContainerWithRouter --> this doesn't necessarily need to be moved since data are stored in a local react state. We may still want to move it to the global redux store, but I can't see many synergies now (that may change with a search bar using a KG query)

[lorenzo-cavazzi]

A couple of ideas to keep in mind while moving to a single redux store:

• gradually move nested data to the first level if it's feasible. E.G. from this:

   projects: {
     project: {
   	commits: {},
   	branches: {}
     }
   }
  

  to this:

   {
   	projects: {},
   	project: { id:123, ... }
   	branches: { projectId:123, ... }
   	commits: { projectId:123, branch:"master", ... }
   }
  

  The main benefit is that it's easier for components to mapStateToProps to a specific topic. It's also easier to handle stale updates after involking an API

• stop using setUpdating/ "is_updating" as defined in Models.js because it overwrites the object values and it's generally not desirable.
  Instead, try to use an extra property status: { fetched: <timestemp>, fetching: <bool>} as suggested in Server Notifications Middleware #225

• As a general rule, we can try to keep in the redux store all the data coming from the backend and map them to props directly where needed instead of passing props down (this avoids undesired refreshes). All the other data (usually temporary data or UI-related data) should be stored in react state/props

[lorenzo-cavazzi]

ProjectList and QuickNav may be the next step since the content seems to be about projects and it may share functions with the already existing ProjectsCoordinator

[lorenzo-cavazzi]

The cleanup here was mostly done. We need additional refractory but we will open dedicated issues for that