@brightspace-ui-labs/edit-in-place v2.1.1
@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 inputplaceholder
String, default:'Enter a value'
): placeholder text of the input. Ifvalue
is blank, this appears in italics as the label.placeholder
must not be blank.size
(Number): length of the inputmaxlength
(Number): imposes an upper character limitreadonly
(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:
andfeat:
will trigger patch and minor releases when merged tomain
. 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: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. 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:
orperf:
will trigger apatch
release. Example:fix: validate input before using
- Commits which are prefixed with
feat:
will trigger aminor
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:
andtest:
. 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 the1.15
release (after version1.16
exists)2.x
for feature releases on top of the2
release (after version3
exists)
1 year ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
2 years ago
3 years ago
3 years ago
3 years ago
3 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
5 years ago
5 years ago
5 years ago
5 years ago