Page History

...

• The state in this application is managed by ngrx. 
• Using it properly requires some discipline from developers and reviewers.
• If you're new to redux or ngrx, take a look at the resources on the technology page
• Anything that's dynamic about the application is called a state change, and should be saved in the store. 
• That means a boolean that saves if the navigation is open or closed, or a list of DSpace Objects from the backend, anything that can change as the application runs.
• Every state change should be defined as an action. in a file called ${feature-name}-actions.ts. e.g. host-window.actions.ts
  An action definition consists of 
  • a action type, a static string in the format dspace/feature-name/ACTION-NAME. 
    • e.g. dspace/host-window/RESIZE 
  • a static function to create the action, that takes the components of the payload as its parameters
    • e.g. resize(newWidth: number, newHeight: number): Action
• The effect of each action on the state should be defined in the reducer, in a file called ${feature-name}-reducer.ts. e.g. host-window.reducer.ts
  • keep in mind that a reducer shouldn't modify the previous state in any way. You can test for this using deep-freeze.
• If an action is be the source of another action, that relation is described in an effect.
  • e.g. submitting the login form dispatches a LOGIN_REQUEST action, with the user's credentials as its payload.
  • an AuthorizationEffect class listens for that action, and when it occurs it calls the rest api with those login credentials 
  • if the REST API answers positively, the AuthorizationEffect dispatches a new LOGIN_SUCESS action, with the token that was returned.
  • if the REST API returns an error, the AuthorizationEffect dispatches a new LOGIN_ERROR action, with the error message that was returned.
• All reducers need to be added to a single reducer aggregator file per module before they can be used
• The same needs to happen for effect files
  
  

General

• Before firing a PR, always ensure your code works on the server (disable javascript in your browser and see if it still works) as well as the client, and that it works with the AoT build (npm start) as well as the webpack build (npm run watch:dev)
• Keep adaptability in mind. An institution installing DSpace will often want to modify a few things about the UI. The easier we can make that, the better. Therefore keep your components small (divide them in to sub-components), make sub-modules for coherent functionality, use SASS variables, etc.
• We agreed to remove the concept of Communities from the UI. They should be called Collections as well.
  
  

...