Skip to content
/ d3fc Public

A collection of components that make it easy to build interactive charts with D3

License

Notifications You must be signed in to change notification settings

d3fc/d3fc

Repository files navigation

D3FC Logo

Build status npm version

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:

  1. Run the command line script npx changeset
  2. Select the packages you want to include in the changeset using ↑ and ↓ to navigate to packages, and space to select a package.
  3. Hit enter when all desired packages are selected.
  4. You will be prompted to select a bump type for each selected package.
  5. 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 -

  1. MAJOR version when you make incompatible API changes (1.x.x)
  2. MINOR version when you add functionality in a backward compatible manner (x.1.x)
  3. 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 -

  1. MAJOR version when you make incompatible API changes
  2. MINOR version when you add functionality in a backward compatible manner
  3. PATCH version when you make backward compatible bug fixes

License

These components are licensed under the MIT License.

Sponsors

Project supported by Scott Logic.