@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)
- [x] Demo page
- [x] 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 -
placeholder
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 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:
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:
- 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:
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)