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. - a class to represent the action, that takes the components of the payload as the parameters of its constructor
- a type, in the format
- 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.
- e.g. submitting the login form dispatches a
- 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
...
Overview
Content Tools