Skip to content

Latest commit

 

History

History
84 lines (60 loc) · 4.23 KB

CONTRIBUTION.md

File metadata and controls

84 lines (60 loc) · 4.23 KB
Raw

Contribution

What you need to contribute

  • Node (v. 16.15.1), which is the same version that runs on the pipeline.
  • Prettier - A code styling tool. You don't explicitly need it, but without fitting the ruleset, you will not be able to merge.

Install and run the AXA Pattern Library

npm install // automatically runs `npm run bootstrap as postinstall hook`
npm start

Your site is now running at http://localhost:6006.

Rules

Styles

  • We follow DRY, KISS, YAGNI principles when we write SCSS. This includes variables, mixins, etc.

Git Commit Message Rules

  • must be English only,
  • must be written in present tense or imperative,
  • must start with a verb and initial capital letter.
  • are prefixed by JIRA/github issue number,
  • reasonably self-contained,

How-to release components

  • Ensure you have an npm account under the @axa-ch organisation and write rights for this repository.
  • (Optional) Run npm whoami and in case of you not being logged in: npm login
  • Create and switch to branch release and push the branch remotely
  • Run npm run release. Follow the guidelines in the CLI
  • Create a PR against develop, after merge delete release branch

Testing

UI Testing

  • A Component should have at least a smoke test
  • Test file name: e2e.js
test.describe('button', () => {
  test('should render', async ({ page }) => {
    await page.goto(fixtureURL('your-component-page'));
    
    expect(page.locator('text="Login"').isVisible());
  })
})

Unit Testing

  • Test file name: unit.test.js

Branch Deployment

Whenever a push to a branch happens, which is represented by a pull request, the branch will automatically be deployed to github pages and is publicly accessible. Found here: https://axa-ch-webhub-cloud.github.io/plib-feature/BRANCH_NAME

Create a new component

How-to create a new component

npm run new and follow the instructions in the CLI.

How-to write a story

Please see Storybook documentation for details.

Best Practices

  • Never calculate derived properties (in the UML sense, cf. /property) inside the firstUpdated lifecycle method of a component. This method is only executed once, after first render. If properties are expected to change dynamically over time, those derived properties would not be recalculated and therefore could lead to bugs. Instead, either calculate such derived properties in the updated (preferred) or attributeChanged method or implement them directly inside the render method of a component.
  • Never use child.scss without scoped selectors. DO: axa-footer-small { span { ... } } DON'T: span { ... }.
  • Never use axa- component tags in selectors to refer to dependent components, since these tags are versioned. Use classes instead. DO: axa-top-content-bar .m-top-content-bar__button { ... } DON'T: axa-top-content-bar axa-button { ... }
  • Do not use console logs in the DEMOs because we cannot expect our user to have DEV Tools open
  • Never and in any circumstances use bitwise operators
  • The DRY is a very important principle. But even more important is to know exactly when to break it. Sometimes a super DRY climate can lead to over-engineered solutions that end up being unmaintainable 😀. There is no rule here, just be careful to not implement a system that is too complex. Lots of options in interfaces or configuration possibilities could be one indicator that the system gets too complex.
  • If you have side effects outside of your component (e.g. global event listeners, added DOM nodes) you have to undo those side effects in disconnectedCallback
  • Do not write overly complex code. Sometimes the rule: "If everything fits on one line of code, my code is smarter" does not apply. Is never about being cool, rather being clear.