Page History
...
Have a look at the project board
Take an issue that’s in the ready section and has nobody assigned to it
Assign yourself
When you start working on it, move the issue to the “in progress” section
Work on a separate branch for the issue on your fork
- When you’re ready, fire a pull request
in the comments of the pull request, write something akin to “this PR connect’s to #{the ID of the issue}”. That way the issue will be moved automatically to the review column.
When at least two people have reviewed and approved your PR, it can be merged in master.
- You can also help out by reviewing the pull requests of other people
Please keep an eye on your pull request afterwards, the reviewers may have questions or comments about it, or ask you to tackle things in a different way, before they can approve it
Most discussions about the task or the pull request can happen through the github & project board comments.
If it’s more complex you can bring it up in one of these meetings.
After your Pull Request has been merged, drag the issue to the done column on the project board. (this can also be automated by adding “this merge closes #{the id of the issue}” in the merge comment.
- If you've claimed an issue, but can't work on it for some reason, please remember to unassign yourself and put it back in the "ready" column so someone else can take over.
Guidelines
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.
Code Style
- Follow the official angular 2 style guide. It contains guidelines for naming files, directory structure, etc.
- TSLint can help you with that. It will run automatically whenever the code is rebuilt (even during a watch task) or you can run it manually with
npm run lint
...
- 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
, added to an ActionTypes object. - a static function class to create represent the action, that takes the components of the payload as the parameters of its parametersconstructor
- a action type, a static string 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
General
DataServices and RemoteData objects
- There is a DataService for each type of DSpaceObject.
- These data services ensure resources get fetched from the rest api (the _mock_ rest api at this point), and stored in the ngrx store
- The find methods in the DataServices return RemoteData objects
- RemoteData objects contain the status of the request (loading/failed/succeeded) and the data (or error message), as observables.
This gist shows how you would use it in practice:
In the component I specify that
collectionData
has the typeRemoteData<Collection[]>
In the OnInit:
this.collectionData = this.cds.findAll();
And then in the template, handle the different cases: dedicated messages for
isLoading
andhasFailed
and the actual data forhasSucceeded
of course in a more realistic scenario you might send the error to a notification service instead of handling it yourself
The
async
pipe allows you to use observables in the template as if they were plain objects.Because of the observables, the template will update automatically if the data in the store gets updated
- 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.