@brightspace-ui-labs/edit-in-place

@brightspace-ui-labs/edit-in-place

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

• Design organization buy-in
• 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 web component for displaying text and editing it in-place.

Installation

To install from NPM:

npm install @brightspace-ui-labs/edit-in-place

Usage

<script type="module">
    import '@brightspace-ui-labs/d2l-labs-edit-in-place.js';
</script>
<d2l-labs-edit-in-place placeholder="Edit Me"></d2l-labs-edit-in-place>

Properties:

• value (String): value of the input
• placeholderString, default: 'Enter a value'): placeholder text of the input. If value is blank, this appears in italics as the label. placeholder must not be blank.
• size(Number): length of the input
• maxlength(Number): imposes an upper character limit
• readonly(Boolean): The label will behave like a simple text element if true.

Events:

The d2l-labs-edit-in-place dispatches the change event when text is saved via pressing the Enter key while focusing the input, or by pressing the save button:

editInPlace.addEventListener('change', (e) => {
  console.log(editInPlace.value);
});

Headers

d2l-labs-edit-in-place can be used in headers and other section-related elements by wrapping it within the desired element:

<script type="module">
    import '@brightspace-ui-labs/edit-in-place/edit-in-place.js';
</script>
<h2>
    <d2l-labs-edit-in-place placeholder="Edit Me"></d2l-labs-edit-in-place>
</h2>

Developing, Testing and Contributing

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

Running the demos

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

npm start

The demo page can be found at http://localhost:8000/demo/d2l-labs-edit-in-place.html. Note the port number your shell outputs; If it differs from the above URL, change the URL accordingly.

Testing

To lint (eslint):

npm run lint

To run unit tests locally using Web Test Runner:

npm run test:headless

To run both lint AND local unit tests:

npm test

Versioning & Releasing

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

The semantic-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)