@brightspace-ui-labs/view-toggle

A lit-element component for toggling between views

Usage no npm install needed!

<script type="module">
  import brightspaceUiLabsViewToggle from 'https://cdn.skypack.dev/@brightspace-ui-labs/view-toggle';
</script>

README

d2l-labs-view-toggle

Note: this is a "labs" component. While functional, these tasks are prerequisites to promotion to BrightspaceUI "official" status:

Design organization buy-in

design.d2l entry

Architectural sign-off

Continuous integration

Cross-browser testing

Unit tests (if applicable)

Accessibility tests

Visual diff tests

Localization with Serge (if applicable)

Demo page

README documentation

A lit-element component for toggling between views

Installation

To install from NPM:

npm install @brightspace-ui-labs/view-toggle

Usage

<script type="module">
    import '@brightspace-ui-labs/view-toggle/view-toggle.js';
</script>
<d2l-view-toggle
        toggleOptions='[{"text":"Bananas","val":"overall"},{"text":"Minions","val":"minios"},{"text":"Pyjamas","val":"subject"}]'
        text="Toggle: "
></d2l-view-toggle>

Developing, Testing and Contributing

After cloning the repo, run npm install to install dependencies.

If you don't have it already, install the Polymer CLI globally:

npm install -g polymer-cli

Running the demos

To start a local web server that hosts the demo page and tests:

polymer serve

Testing

To lint:

npm run lint

To run local unit tests:

npm run test:local

To run a subset of local unit tests, modify your local index.html, or start the dev server and navigate to the desired test page.

To run both linting and unit tests:

npm test

Versioning & Releasing

TL;DR: Commits prefixed with fix: and feat: will trigger patch and minor releases when merged to master. Read on for more details...

The sematic-release GitHub Action is called from the release.yml GitHub Action workflow to handle version changes and releasing.

Version Changes

All version changes should obey semantic versioning rules:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

The next version number will be determined from the commit messages since the previous release. Our semantic-release configuration uses the Angular convention when analyzing commits:

Commits which are prefixed with fix: or perf: will trigger a patch release. Example: fix: validate input before using
Commits which are prefixed with feat: will trigger a minor release. Example: feat: add toggle() method
To trigger a MAJOR release, include BREAKING CHANGE: with a space or two newlines in the footer of the commit message
Other suggested prefixes which will NOT trigger a release: build:, ci:, docs:, style:, refactor: and test:. Example: docs: adding README for new component

To revert a change, add the revert: prefix to the original commit message. This will cause the reverted change to be omitted from the release notes. Example: revert: fix: validate input before using.

Releases

When a release is triggered, it will:

Update the version in package.json
Tag the commit
Create a GitHub release (including release notes)
Deploy a new package to NPM

Releasing from Maintenance Branches

Occasionally you'll want to backport a feature or bug fix to an older release. semantic-release refers to these as maintenance branches.

Maintenance branch names should be of the form: +([0-9])?(.{+([0-9]),x}).x.

Regular expressions are complicated, but this essentially means branch names should look like:

1.15.x for patch releases on top of the 1.15 release (after version 1.16 exists)
2.x for feature releases on top of the 2 release (after version 3 exists)