Components to rapidly build fast, highly customisable, interactive charts with D3
Installation
The latest release of D3FC is available via npm or the unpkg CDN. The D3FC project is composed of a number of separate packages each of which can be installed via npm and used independently, or if you prefer you can install the entire D3FC bundle, which includes all of the separate packages -
npm install d3fc
<script src="https://unpkg.com/d3"></script>
<script src="https://unpkg.com/d3fc"></script>
Test your installation using the simple chart example.
Documentation
The following getting-started guides are available -
- Building a Chart - a walk through building a chart with D3FC and what makes it different from other libraries.
- The Decorate Pattern - the pattern D3FC employs, resulting in charting components that are both simple and flexible.
- Transitions - how to use D3 transitions with D3FC.
For API documentation see the corresponding package documentation -
Examples can be found on the project website. These same examples are also available offline.
Framework integration examples:
There are also a number of other documents and articles that provide a bit more background regarding the design principles of D3FC -
Developing
This project is a mono-repo that uses Lerna to manage dependencies between packages. To get started, run -
npm ci
npm test
When making changes to a package, you can execute the following either from within the package folder to build just that package or from the project root to build all packages -
npm run bundle
To open a development sandbox which is automatically updated when you save changes to source files, navigate to the project root and run -
npm start
CI
This project is equipped with a Continuous Integration (CI) pipeline using GitHub Actions. It runs a series of checks whenever a pull request to master is opened. The pipeline includes the following steps:
- Build: Verify that the code can be successfully built.
- Test: Tests the application to ensure that new changes do not introduce regressions.
- Linting: The code is analyzed for adherence to coding standards and best practices, using eslint, markdownlint, and commitlint.
See Conventional Commits for a more detailed explaination.
When opening a PR, be mindful of (and make necessary changes in accordance with) these checks.
Releases
Releases are managed via CI and Changesets.
When contributing to the project, developers should add a changeset.
A changeset is a Markdown file with YAML front matter. The contents of the Markdown is the change summary which will be written to the changelog and the YAML front matter describes what packages have changed and what SemVer bump types they should be
---
"@d3fc": major
"@d3fc/d3fc-annotation": minor
---
Change all the things
Changesets should include:
- WHAT the change is
- WHY the change was made
- HOW a consumer should update their code
Adding a changeset
To add a changeset, before putting up a PR, contributors should:
- Run the command line script
npx changeset
- Select the packages you want to include in the changeset using ↑ and ↓ to navigate to packages, and space to select a package.
- Hit enter when all desired packages are selected.
- You will be prompted to select a bump type for each selected package.
- Select an appropriate bump type for the changes made. See SemVer Versioning
Your final prompt will be to provide a message to go alongside the changeset. This will be written into the changelog when the next release occurs.
Source
Dependabot updates should not affect the consumer, and so do not need a Changeset. These will have PATCH (x.x.1
) version bumps.
SemVer Versioning
From SemVer -
- MAJOR version when you make incompatible API changes (
1.x.x
)
- MINOR version when you add functionality in a backward compatible manner (
x.1.x
)
- PATCH version when you make backward compatible bug fixes (
x.x.1
)
Github tags and releases are done using the Tag Release on Push action. By default, a minor
version bump will be added. To override this, use release:major
, release:minor
, or release:patch
on PRs. Only one of these tags should be added to a PR.
From SemVer -
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backward compatible manner
- PATCH version when you make backward compatible bug fixes
License
These components are licensed under the MIT License.
Sponsors
Project supported by Scott Logic.