-
-
Notifications
You must be signed in to change notification settings - Fork 489
GeoNetwork client app building blocks codesprint 1st and 2nd June 2020
François Prunayre edited this page Jun 2, 2020
·
18 revisions
Address:
- Monday/Tuesday: Olivier, Florent, Francois at the farm, 321, Route de la Mollière, Saint-Pierre-de-Genebroz, Chambéry, Savoie, Auvergne-Rhône-Alpes, France
- Florent
- Olivier
- Francois
- Arnaud
- ?
- titellus
- Spacebel
- Monday morning / Brainstorming based on concerns & recommendations from everyone. First draft guideline document (Florent, Olivier, Francois)
- Tuesday / 9h30 CET / Online meeting to present the options (All who are available - Michel, Paul, Olivier, Florent, Francois, ?)
- Tuesday / Write a first guideline & project basis setup
Define possible base rules for a new client application for GeoNetwork. Choose libraries and start setting up the project to be able to make prototype and show new possibilities required in some projects.
- AngularJS EOL is 2021
- Improve performances - we know why and how the client app can be faster eg. watchers, incremental DOM
- Make GeoNetwork easier to embed in a third party app eg. with shadow DOM
- …
- Technical debt
- Quite some years on overlaying features over features - all can be simplified
- Code style
- Nobody is using JSLint … probably because not mandatory or lazy devs ;)
- WRO4J works but is effectively a completely custom, hand-made bundler which is hard to maintain (written in Java for frontend devs…), based on old assumptions, and has such a large role in the build that it is almost impossible to get rid of
- No type checking
- No centralized state management
- No strict encapsulation of components (either scopes or styles), scopes are shared between many components eg. the search directive => this also means components are not really reusable outside of the standard UI
- CSS
- the large size of all the CSS continued
- overruling of styles
- HTML I want to change is outside of the view directory and therefore unreachable
- sometimes the guidelines of the UI framework (Bootstrap) are interpreted loosely
- ‘difficult' HTML for the Editor
- UI
- Disable client app module when services are down or unavailable? Eg if one day we have an harvesting machine, we have to have a client app for this app and be able to load it when needed, check service availability and enable it if running.
- Define UI design templates, so pages look as unified as possible across the application.
- Accessibility can be better
- UI configuration - how much config options? Good defaults? Merge a custom one with the defaults
- 2 notification systems
- Sometimes you can init app with the location URL (eg. search - most of the time, not in batch edit), sometimes not (point to a category page in the admin or an harvester).
- Limitations
- Using Jquery and Bootstrap means putting the app in a shadow dom is not feasible
- Improve the current asynchronous code to retrieve the information from the catalog that is needed in the UI. Cancel pending search when clicking multiple times on search button.
- Design
- Bootstrap app / Sometimes debug mode and prod does not behave the same. Load UI config & user info first, then bootstrap app components ...
- Testing
- No component testing
- catalog can not be indexed by search engine as SingelPageApplication. Google has a tool to optimise SPA crawling
- Performances
- Embeddable
- Build
- Codestyle & linting > prettier + CI for UI (PR blocked if not valid (lint + format))
- Wro4j > abandoned, modern frontend architecture (nodejs, webpack or other, bundlers, tasks ..)
- Dependency Google closure > abandoned, ES6 modules
- Type checking > typescript
- Debug and prod different: managed by bundler and source map
- Test: test are mandatory on ui changes, check test coverage
- JS
- State management > Very likely to use something like Redux, for core data (not UI for instance)
- Component encapsulation > should disappear with modern component framework (ex Angular OnPush Change Detection Strategy)
- Shadow DOM & jquery > remove jquery
- Disable client app module when services > lazy loading, good code splitting, state, service healthcheck
- Improve the current asynchronous: use observable (rxjs) eg. to cancel pending requests
- Styling
- Css language: scss ? css variable works well, likely use css native
- Style encapsulation > CSS is embedded in component in some framework lik Angular. If other frameworks, be more careful
- Large CSS: small css file embedded in components. In Bootstrap 4 for instance, many helpers class to use in markup (so less css).
- Overruling of styles: css are encapsulated in component
- Template
- Custom HTML: no custom > derive from master
- Define UI design templates: give a try to storybook
- Config
- UI configuration: keep UI settings (themes, some config, remove features)..
- Permalink: router state
- Follow guidelines > better experience to avoid same mistakes, be more critical on review and be more strict on guidelines. Write a guideline for GN developers
- Accessibility can be better: storybook plugin, tool that checks accessibility for you, use framework css that help ? Add specific task on CI
- Typescript
- Style with CSS
- Angular https://angular.io/
- Bootstrap https://getbootstrap.com/ (no JQuery)
- Storybook to demo components https://storybook.js.org/
- Prettier for linting https://prettier.io/
- Jest for testing
- Search input
- Sort by component
- Result panel
- Then a webcomponent
- Comment on the proposal?
- Name for the project?
- Repo on github https://github.com/fgravin/gn-ui
- Base project for building prototypes
- Discussion https://sourceforge.net/p/geonetwork/mailman/message/37021872/
- Results will be presented during GeoNetwork online user meeting 23 June 2020
If you have some comments, start a discussion, raise an issue or use one of our other communication channels to talk to us.