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 type, in the format dspace/feature-name/ACTION-NAME, added to an ActionTypes object.
    • e.g. dspace/host-window/RESIZE 
  • a class to represent the action, that takes the components of the payload as the parameters of its constructor
    • e.g. HostWindowResizeAction
• 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

...