2016-11-15 DSpace 7 UI Working Group Meeting notes

Date

15 Nov 2016

Goals

• Make a number of decisions about the structure, build tools, ways of working, etc.

Seed Project & build tools

 Description

• There is no seed project ideally suited for our purpose at the moment.
• Angular-cli is the recommendation from the angular team, and is assumed to be used in most guides and posts
• But the current stable angular-cli branch isn't compatible with angular universal

• there is a fork that adds compatibility released as a separate npm package called universal-cli

• That has also been merged in to angular-cli a few days ago: PR

• But isn’t part of a release yet

• We could

  • start from the universal seed project
  • start from universal-cli
  • start from the angular-cli master branch

• Something else to keep in mind is the ability to keep it modular and extensible. If this becomes the DSpace UI, how do customisations to it work?

  • Do people fork the UI github and work on the code?

  • Does the UI become an NPM package that people include in their own projects?

  • Should there be some sort of overlay system, like in the the current XMLUI?

Conclusions

• None of us have enough experience with these projects. They need to be tried out and compared. Art Lowel (Atmire) will do this by next meeting
• We want to use tslint and codelyzer in our build, for code analysis 
• We also want to include an editorconfig file to help with code consistency across different developers

Testing

Description

• Do we want to unit tests for every part of the UI?
• Do we want end to end testing
• Jasmine for unit tests, protractor for end-to-end, karma as a runner?
• Do we want to encourage BDD?

Conclusions

• We want to work as test driven as possible.
• However we don't want to make unit tests a hard requirement to be able to commit anything. But there have to be tests before it can be merged in to master
• We can always relax that policy if it proves to be too restrictive
• End to end test shouldn't be required but should be encouraged
• Jasmine, protractor and karma are fine

i18n

Description

• Angular 2.0.1 added a first version an i18n system, however it’s still tagged as experimental and that shows.
• It’s not easy to work with
• your translations files have to be generated from the templates using a tool. If you add fields afterwards, you have to generate it again, and merge the already translated messages in
• It doesn’t seem to support variables
• and doesn’t support language switching at runtime.
• It creates a version of the entire app in every language and you need to go to the one in the language you’d like.

Conclusions

• we'll stick to ng2-translate for now, which is the third party module we used in the prototype, as it doesn’t have all these downsides.

CSS

Description

• Framework
  • Angular material still has multiple downsides
    • lacks a number of components
    • lacks customisability
    • lacks basics we need, like a grid system
  • Bootstrap 4 while in alpha seems like a better choice

• Do we want to use component styles or not?

  • while that has the advantages
  • that your style is highly modular
  • that component styles can’t influence or break each other
  • How will that work in respect to theming?
  • will that require someone writing a theme to modify the component CSS for every component?

Conclusions

• We'll use bootstrap 4, with ng-bootstrap instead of ng2-bootstrap
• Component styles shouldn't be a problem for themablity as global, overriding styles can be added using the view encapsulation property of the app component
• So we'll use component styles

Storing state & Data Abstraction Layer

Description

• In order to end up with a robust system, with good performance, that's easily testable and minimizes the risk of unexpected side effects, we want to avoid leaving the implementation of calls to the backend, and the storage of state up to the individual developer of a component or service. 
• To manage state in the application we could look towards Redux, and ngrx
• For a structured data abstraction layer JS Data is worth investigating
• Both of these could be used separately or together.
• While they have many advantages, they'll also make it more difficult for new developers to get involved. Is the extra structure worth it?

Conclusions

• There is also universal storage, part of angular universal that has some overlap
• Not enough people have experience with redux, js data or universal storage.
• We will research this by the next meeting, in order to come to an informed decision.