Vertex UI Shared Library

This library maintains common components, assets, config defaults, models, and more which can be used in Vertex MicroApps.

Getting Started

Installing the package locally

1. Create or modify .npmrc file in your user profile directory - Windows C:\Users\<YourUsername>\.npmrc or Mac /Users/<your-username>/.npmrc

   @se-sustainability-business:registry=https://npm.pkg.github.com/
   //npm.pkg.github.com/:_authToken=${GITHUB_TOKEN}
   @fortawesome:registry=https://npm.fontawesome.com/
   //npm.fontawesome.com/:_authToken=${FONTAWESOME_TOKEN}

2. Create a PAT on Github with 'Read Packages' permissions. If you don't already have one, see GitHub documentation. When setting up your PAT, make sure you configure SSO with SE-Sustainability-Business.

3. Once you have your PAT, assign it to an environment variable called GITHUB_TOKEN. There are a few ways to do this:

   Mac: Navigate to your .zshrc or .bashrc file and add the PAT

   vim ~/.zshrc # or .bashrc
   # add the following line
   export GITHUB_TOKEN=your_personal_access_token_here
   # save and exit
   source ~/.zshrc
   # restart existing terminals

   Windows: Press Windows + S key, search for "Environment Variables". Click "Edit" for env variables and add a new variable called GITHUB_TOKEN and assign it to your PAT

4. Repeat the process above to create another env var for FONTAWESOME_TOKEN. Please reach out to someone on the Vertex team to have the token sent to you.

5. Once your env vars are set up and terminals restarted, run npm install @se-sustainability-business/vertex-ui-shared for the latest version - see vertex-ui-shared for other versions. Note: you may need to also restart your IDE if you are still seeing issues authenticating. Be sure that your environment variable is mapping correctly as well.

Start from Template

If you plan to set up a new MicroApp, fork from this template repo. This library is included, configs are defaulted, and workflows are set up. Follow the same steps as above to install the library locally.

Import Components

In .ts file, import {CheckboxComponent} from '@se-sustainability-business/vertex-ui-shared/checkbox'; In .html file, <vx-checkbox></vx-checkbox>

Components Storybook

A demo of many of our components can be found here: https://vertex-components-non.sb.se.com

Running linting and tests

To run the automated linting and unit tests:

1. Install NodeJS and the dependencies
2. Run linting: npm run lint
3. Run prettier: npm run prettier, to fix files automatically use npx prettier --write .
4. Build and run the tests: npm test

Pull Requests

Pull request titles must follow the conventional commit syntax, as enforced by the pr-title action.

The typical pull request should be named using the syntax: <Type>(<Optional Scope>): <Issue> <Description>. As an example, feat(shared): EM-100 Add drodpdown component. Let's break this down.

• Type - Usually feat for features or fix for fixes.
  • Features should use type feat, and will generate a minor release.
  • Fixes should use the type fix, and will generate a patch release.
  • Other types are allowed but will not generate a release, which means they cannot be deployed to any environment These include ci, build, docs, refactor, or test. See the Angular type options for a more complete list.
  • Breaking changes should include the message BREAKING CHANGE somewhere in the commit message (not the title), and will generate a major release, but these should be rare.
• (Optional) Scope - If present, should indicate which project is modified by the pull request, e.g. feat(shared). If multiple projects are affected by the pull request, the scope should not be specified.
• Issue - The ID of the Jira ticket, so that Jira can associate the pull request with the issue and reviewers can easily find it.
• Description - Largely self-explanatory, the description should give a brief description of the changes being made. This could match the Jira ticket summary, but may also describe the actual code changes being made. For example, instead of describing a bug, the description in the PR should describe the code fix.

Accessibility

Per the European accessibility act, user interfaces built by Schneider Electric must conform to certain accessibility standards.

As a baseline, developers working in this repository should use the axe DevTools extension for Chrome or Firefox to ensure that no accessibility issues are reported on pages that are updated as part of the pull request. Developers should run a full scan with the page in different states if relevant, e.g. with any dialogs or overlays opened.

If major issues are reported on a page due to existing problems unrelated to changes made in the current pull request, it is acceptable to instead open a Jira ticket to address those issues at a later date (or identify an existing Jira ticket). In that case, the ticket should be linked in the pull request description for visibility and awareness.

Reviews

Before merging, ensure that all pipelines pass and a review is required.

• Code changes in your own team's project can be reviewed and approved by your team.
• Code changes in other projects should require approval from one of those projects' team members.