Pattern Library

July 31, 2023 ยท View on GitHub

CI/CD Status

>> Pattern Library Demo

Check out our Contribution File

Check out our Architecture File

Check out our Code of Conduct

Design Guidelines

Link to Styleguide

Communication

Use the following channels for different kinds of requests/reports:

  • Bug reports, small change requests, "wishes": Issues
  • Questions, requests for help, requests for product presentations, etc: Slack #patterns-lib-devs
  • Feature requests (Components, etc): Contact Webhub Team

What we deliver

We release self-contained plug-and-play web components based on the custom elements specification, derived from the lit-element base class (maintained by Google).

Pattern Library components are exported to npm with 2 types of build artifacts: /dist/index.js and /lib/index.* in ES2019.

Component versioning

Different versions of our web components can coexist on the same web page! Here you can read more about component versioning.

Released Components

lerna

ComponentGithub Packages
AXA Accordionnpm version
AXA Buttonnpm version
AXA Carouselnpm version
AXA Checkboxnpm version
AXA Commercial Hero Bannernpm version
AXA Containernpm version
AXA Cookie Disclaimernpm version
AXA Datepickernpm version
AXA Dropdownnpm version
AXA Fieldsetnpm version
AXA File Uploadnpm version
AXA Footernpm version
AXA Headingnpm version
AXA Footer Smallnpm version
AXA Iconnpm version
AXA Input Filenpm version
AXA Input Textnpm version
AXA Linknpm version
AXA Materialsnpm version
AXA Policy Featuresnpm version
AXA Popupnpm version
AXA Radionpm version
AXA Tablenpm version
AXA Table Sortablenpm version
AXA Textnpm version
AXA Textareanpm version
AXA Top Content Barnpm version
AXA Modalnpm version
AXA Steppernpm version
AXA Testimonialsnpm version

Code of Conduct

We are dedicated to building a welcoming, diverse, and safe community. We expect everyone participating in the AXA community to read and accept our Code of Conduct

Version Control

This repository is a monorepo managed by Lerna. This means that all components are centrally managed here, even though we publish them to NPM as separate packages.

Commits

We are using Conventional Commits to automatically version the components and update their changelogs. Feel free to use a tool of your choice to generate these commits.

Example for a commit message

feat(button): add new color blue

Closes #ticket-1234

Example for a Changelog entry

# [16.3.0](https://github.com/axa-ch-webhub-cloud/pattern-library/compare/@axa-ch-webhub-cloud/materials@16.2.2...@axa-ch-webhub-cloud/materials@16.3.0) (2023-07-31)

### Features

- **materials:** update color ([b832830](https://github.com/axa-ch-webhub-cloud/pattern-library/commit/b83283048acb5594812d019e2523bb014d3fc509)), closes [#123456](https://github.com/axa-ch-webhub-cloud/pattern-library/issues/123456)

For more examples, especially with BREAKING CHANGES, have a look at the Conventional Commits Examples.

Pattern Library via community CDN

You can add any Pattern Library component via the community CDN jsdelivr. This is useful for Prototyping or experimenting or if you don't want to bother with a frontend stack. This works only native (no react support). Here an example on how to add the JS for <axa-button></axa-button>: <script src="https://cdn.jsdelivr.net/npm/@axa-ch/button@latest/dist/index.js"></script>

How do I get my (unit) tests to work when using Pattern Library components?

The problem

Unit-test frameworks like Jest run under the node environment, which is quite different from a browser. The most commonly used abstraction to mimic a minimal browser within node is jsdom. However, jsdom lacks crucial features such as Mutation Observer, Custom Elements and other browser APIs commonly needed by web components.

Solutions

So what are your options?

  • Insisting on jest, one option would be to use a better DOM emulation. Exchanging jsdom with happydom, we now have enough emulated browser features to test web components. The details are described here.
  • Instead of using jest, employ end-to-end (e2e) testing tools that control a real browser, e.g. Playwright, Cypress or Testcafe. Arguably this is a better match for UI-heavy apps anyway, because e2e tests are closer to a real user experience.
  • Use a lightweight mocking strategy. The idea is to mock pattern library components by a simple, traditional-HTML replacement such as a <div> or a <button>. Here is a code sketch using Jest that employs this strategy: 
    All Pattern-Library React components are imported from this index.js.

import createAXAButton from '@axa-ch-webhub-cloud/button/lib/index.react';
import createAXADropdown from '@axa-ch-webhub-cloud/dropdown/lib/index.react';

export const AXAButton = createAXAButton(createElement);
export const AXADropdown = createAXADropdown(createElement);

AXAButton.displayName = 'AXAButton';
AXADropdown.displayName = 'AXADropdown';

    __mocks__/index.js

export const AXAButton = (props) => {
return <button {...props}>{props.children}</button>;
};
...

Testing with Selenium, Testcafe and other UI testing tools

By default, pattern-library web components make use of ShadowDOM. To trigger interactions inside such web component you need to access the DOM via the ShadowRoot. Schematically, this works like this: UI Testtool -> Driver -> native DOM selector -> ShadowRoot -> querySelector

Here is a concrete example in Java using Selenium:

public WebElement expandRootElement(WebElement element, WebDriver driver) {
    WebElement ele = (WebElement) ((JavascriptExecutor) driver)
            .executeScript("return arguments[0].shadowRoot",element);
    return ele;
}

Calling this method gives you the ShadowRoot in your Selenium environment. Beware: when calling findElement on the return value of expandRootElement only the following selectors will work:

  • By.id
  • By.className
  • By.cssSelector