Crossref Front End Framework
Component | |
Area | tools-libraries |
Language | Vue |
Description | Crossref Front End Framework |
Production URLs | |
Quality | No Sentry, no SONAR |
Source Code |
Our framework for building new browser-based user interfaces. Built with Vue.js framework, on Vuetify component framework. New components can be built within this framework and then included into places where needed.
Project Boilerplate
For the latest boilerplate for frontend code, head to the MyCrossref repo on Gitlab, and checkout either crossref-template
for a project with Vue, Vuetify, Jest, Cypress and ESLint setup, or crossref-template-json-forms
for the same but with JSON Forms intergated too.
Targetted Browsers
We follow Vuetify’s browser support policy, which is currently:
Browser | Support Status |
---|---|
Chromium (Chrome, Edge Insider) | Supported |
Edge | Supported |
Firefox | Supported |
Safari 10+ | Supported |
IE11/Safari 9 | Supported with polyfill |
IE 10 and below | Not Supported |
Safari 8 and below | Not Supported |
We include the polyfill for IE11/Safari 9, and note the caveat relating to IE 11 <template>
tag support.
Coding Style
New code should be written in typescript and should adhere to the Typescript Standard Style. When extending existing Javascript with new features, those new features should be written in Typescript, and the entire module considered for migration to Typescript at the same time.
JavaScript should be written to ES6 (ECMAScript 2015) specification where possible, and transpiled during a build step to code runable on all targetted browsers. JavaScript should adhere to the Javascript Standard Style (style guide, linter and formatter). Vue components should be built as Single File Components. Code should be transpiled using Babel and bundled (built) with webpack.
Linting
Code can be linted with ESLint, using an .eslintrc configuration file that extends the “standard” ruleset. An example of this can be found in the Frontend project repo.
Run eslint with eslint --ext .js,.vue src
to check all .js or .vue files within the src/ directory.
Run eslint with eslint --fix --ext .js,.vue src
to check and fix the same
In the Frontend VueJS project repo, the vue CLI service lint command is configured to run ESLint with --fix
enabled against the Standard Style ruleset, and an extra ruleset that checks for deviations from the recommended VueJS component style guide.
Run Vue CLI lint with npm run lint
to check and fix all .js and .vue files within the Vue project.
When running the project with npm run serve
, lint on save is enabled by default. This can be controlled by the lintOnSave
paramter within vue.config.js
.
Testing
Unit tests should be written to target the Jest test runner.
Unit tests targetting Vue components should use the Vue Test Utils.
Intergration tests should be written to for Cypress.
Mocking endpoints
Endpoint responses can be mocked using Jest’s manual mocks, a lightweight service like json-server or MirageJS.
When creating manual mocks, use mockResolvedValue
for returning simple values, or mockImplementation
for more complex cases.
Json-server and MirageJS let you fake an entire API, and use it during development as well as while running tests (including Cypress tests). MirageJS has the advantage of running entirely within the app (it hijacks XHRs) and json-server has the advantage that it simulate the real network conditions of requesting an API exposed on a different domain/port (which allows you to test things like CORS).
Scoped CSS
Vuetify applies an aggressive CSS reset stylesheet gloablly, and this can cause trouble when non-vuetify content must co-exist on the same page. For example, inputs are rendered borderless, and all padding and margins are reset. This is only a live problem on the webDeposit form, where the authentication UI must co-exist with the legacy form content.
Rather than un-do all the resets and attempt to override them only for the legacy content, a version of the framework CSS is built with the Vuetify CSS (including the reset) scoped with a prefix - the data-vuetify
html attribute. Any page that needs to allow legacy content to co-exist with Vuetify components can reference crossref-ui.prefixed.css
.
A known side-effect of this prefixed CSS is that it causes extra an vertical scroll bar (as well as the native browser scrollbar) to appear within the Vuetify root component, if the content is greater than the viewport height. Therefore, only use this CSS prefix workaround when necessary.
Environment-specific configuration
Some configuration properties or values requried by the framework will differ, based on which environment it is deployed into.
As the same code is deployed into sandbox and production, the framework performs automated detection of the deployed environment, based on the URL it is hosted at.
The urls are tested by comapring the current hostname to a list provided in the .env
file, with their corresponding environment.
NB previously this test was only against the subdomain of the current url, hence the variables are called VUE_APP_..._SUBDOMAINs
rather than ..._DOMAINS
. This will be fixed in a later release.
# comma,separated list of domains that match and environment
VUE_APP_PRODUCTION_SUBDOMAINS="doi.crossref.org,authenticator.production.crossref.org,authenticator.crossref.org"
VUE_APP_SANDBOX_SUBDOMAINS="test.crossref.org,sandbox.crossref.org,authenticator.sandbox.crossref.org"
VUE_APP_STAGING_SUBDOMAINS="staging.crossref.org,authenticator.staging.crossref.org"
VUE_APP_LOCAL_SUBDOMAINS="localhost,127.0.0.1"
If a non-production environment is matched, the concomitant configuration overrides file is loaded from src/environments/nameofenvironment.js
and these properties merged in on top of the base configuration. Properties passed into the first argument of the run({...})
method are merged in last, over the top of any environment-specific overrides.
If no environment is matched, production
is returned as the default, and an error logged.
The domain to environment matching functionality (in getEnv()
) is wrapped in a try/catch as it occurs before Sentry is loaded (so it can be passed into Sentry.init({...})
as the environment
property). Any errors are added to an array, which is processed and any exceptions shipped to Sentry after the Sentry.init()
call.
Integration into CS
The integration into the Admin Console is handled by (this .jsp)[http://gitlab.com/crossref/content_system/-/blob/develop/web/jsp/admin/login.jsp] and serves as a useful reference for the required configuration and HTML boilerplate.