Note: This tutorial is targeted at Angular 9, using the Ivy renderer, as this version fixes a number of CSS bugs, particularly relating to binding CSS custom properties.

When faced with a need to visualise data, many developers' first instinct is to reach for a 3rd-party charting library. There's nothing wrong with this: there are several robust and full-featured libraries out there, and it's usually smart to leverage existing, good quality code. But we shouldn't forget that Angular, coupled with modern CSS features, also provides a great base on which to create our own, bespoke visualisation components. Doing so gives us the ability to tailor them to our exact use-cases, and avoid the inevitable trade-offs and bloat that comes with trying to solve for the general case of visualisation and charting. Also, creating visualisation components is just plain fun.

In this article, we'll explore the process of creating a bar chart component for Angular. Even if you've created similar components before, the approach here might surprise you. We won't be rendering to a canvas element, or to dynamic SVG. We won't be using D3, or any dependencies besides those that come with a standard Angular CLI app. We won't be using any listeners or polling to detect resizes and run complex and flaky layout code. Instead, we'll strive to use modern CSS features, in particular grid and custom properties, to build the component's layout in a declarative and automatically responsive way.

The finished chart can be viewed in this 

The complete code for the chart and both examples can be 

The first thing to do is create our component. We can use Angular CLI's schematics to generate one for us:

ng generate @schematics/angular:component bar-chart --style=scss

CREATE src/app/bar-chart/bar-chart.component.scss (0 bytes)
CREATE src/app/bar-chart/bar-chart.component.html (24 bytes)
CREATE src/app/bar-chart/bar-chart.component.spec.ts (643 bytes)
CREATE src/app/bar-chart/bar-chart.component.ts (281 bytes)
UPDATE src/app/app.module.ts (717 bytes)

In a theoretical sense, we can consider our component as a function that maps from its inputs to a rendered output (i.e., the chart). So, let's start by identifying what the input data should look like by defining some TypeScript interfaces inside 

interface BarChartSeries {
  label: string;
  color: string;
}

export interface BarChartCategory {
  label: string;
  values: number[];
}

Our chart's raw data will be stored in this structure, and supplied to our component using 

@Input()
series: BarChartSeries[];

@Input()
columns: BarChartColumn[];

We'll need to define some additional inputs later, for things like the chart title, but these will suffice for now.

Next we'll the basic layout structure of our component. We start with a simple mockup of our bar chart component, placed within the context of a skeleton app page:

When building components, it is important to think of layout in terms of "inner" — those aspects controlled by the component code itself — and "outer" — those controlled by the surrounding content.

In its most basic form, our component is just a box placed within another larger box (the page):

Everything that goes on inside the inner, purple box is the responsibility of the component, but it should make few or no assumptions about the size and position of the box within the larger layout. Instead, it should adapt to the size of its container. This will make it more generic, and more easily re-usable in different situations and contexts.

By leaving the positioning and sizing of our component up to its consumer, the dimensions of our component's layout box become an input, as important (and unknown) as the data we'll be showing as columns, series and categories. We could read these dimensions explicitly from the DOM and calculate our entire layout in JavaScript, but this is difficult to do in a truly performant and bulletproof way (although 

's Layout API may change this, when it arrives).

To achieve a responsive inner layout without having to calculate everything ourselves, we will use CSS Grid layout. The design our grid, we begin by breaking up the mocked-up content into sections:

We can see that, in essence, our component consists of five areas:

The next step is to break the layout up further, into the rows and columns of our layout grid, which we then define in 

. Since we want our component to be responsive. We also need to consider how these will be sized relative to the total available space. CSS grid provides a great deal of scope of how a row or columns can be sized. But at a high–level, there are four strategies:

It is this ability to control the sizing strategy of different sections of our component that makes using grid such a compelling alternative over rendering to canvas or SVG. Even though SVG is responsive in the sense of being scalable to any size without losing detail, its positioning system is extremely primitive, making it impossible to create truly responsive visualisations in a declarative way.

Now let's break our design down further, into rows and columns:

Note that we will be using grid's named-lines capability to identify important offsets in our grid. This is important to make the CSS we write for each section structurally independent of the rest of the grid. In contrast, hardcoding exact row and column offsets makes it much harder to modify the grid structure later, if we want to introduce a new element, such as a row of controls.

We have a fixed set of five rows, and they can be defined as follows:

:host {
  display: grid;
  grid-template-rows:
    [title] auto [legend] auto [data] minmax(10em, 1fr)
    [x-axis] auto [x-axis-label];
}

Note that only one of our rows, the data row, will be fully flexible. The others will size to fit their content instead.

 function to give the flexible row a minimum and maximum size. In this, case we give a small minimum of 

, to ensure that the data at least remains visible, while letting the data row grow as large as it can with a 

Defining the columns of our grid is more complicated, as there will be a dynamic number of them. Fortunately CSS grid provides for this situation.

:host {
  // ...
  grid-template-columns: [y-axis-label] auto [y-axis] auto
    [cols-start] repeat(var(--column-count)), [col-start] minmax(5em, 1fr))
    [cols-end] 1em;
}

 function expression to specify the dynamic data columns. Let's look at it isolation:

repeat(var(--column-count), [col-start] minmax(5em, 1fr))

 expression indicates that we would like to repeat the following column definition some number of times. This can be a static number, but in our case the repeat count is a CSS custom property/variable, called 

. This variable is the bridge between our component and its stylesheet, and we'll see later how it can be supplied by the JavaScript code.

 gives each repeated column a name. These names don't have to be unique, as we can specify one by supplying an index with the name, e.g., 

, etc. This lets us place content in a particular column without worrying about the rest of the grid's details.

 makes each column size between a minimum of 

 and an unbounded maximum, similarly to how we constrained the data row. Because there may be more than one column, any available space will be shared equally between them.

With the grid structure of our component defined, we can begin adding the content. We'll progress through each piece of content:

We'll start simple, with the chart title. We can add a new input to configure this:

And, if it's set, we'll bind it to an element in the component template:

<div *ngIf="title" class="title">{{ title }}</div>

And finally we can add some styles for this element:

.title {
  grid-row: title;
  grid-column: 1 / -1;
  justify-self: center;
}

Note: We'll make an exception to our named-lines policy here, as the title needs to span the whole grid, meaning its easiest just to define as spanning from column 

The legend displays a key of the chart series. We already have an input for this, so we now need to render it into our template:

<ol class="legend">
  <li class="legend-item" *ngFor="let s of series" [style.--color]="s.color">
    {{ s.label }}
  </li>
</ol>

Here we see our first use of a CSS custom property, 

, which we're binding to the value of the 

 field of the series. This lets us pass a value from the JS realm into CSS, where we can use it in place of a static value:

.legend-item::before {
  display: inline-block;
  content: '';
  background-color: var(--color);
  // Etc.
}

Here we've used it as the background color of a pseudo element. This wouldn't be possible with a regular style attribute binding, and we'd have to introduce an additional element into our HTML. This approach keeps our markup simple.

Note: If you're using Angular 8, there is a bug with binding 

. It is possible to work around this issue by manipulating the underlying DOM element directly. I recommend writing a custom directive to do so, the API of which could look something like this:

Custom properties help us develop a clean abstraction between the component's JS, template, and stylesheet. The template is only responsible for binding a single, domain-specific value, which the stylesheet bind to whichever elements and properties it wants, without the knowledge of the JS or template.

Now we come to the heart of our grid, the categories.

The final piece of our CSS grid configuration is to supply the 

 definition. As this is declared on the host element, we can't bind it in the template. Instead, we can use a host-binding in the component class:

@HostBinding('style.--category-count')
public get categoryCount() {
  return this.categories.length;
}

We also want to calculate and bind another property: 

Recall that our category data structure looks like this:

export interface BarChartCategory {
  label: string;
  values: number[];
}

For each category, we need to render both 

 array, as coloured bars in the data area, and its 

 property, in the axis area. We'll begin with a single loop over the 

<ng-container *ngFor="let category of categories; index as ci">
  
  
</ng-container>

, rather than an element. When using CSS grid, we need to keep our markup as flat as possible, because items can only be placed within a grid belonging to their parent element. In future, we will be able to achieving more hierarchical nesting using CSS sub-grids or 

, but at the moment neither of these features have sufficient cross-browser support.

<ng-container *ngFor="let column of columns; index as ci">
  <div class="category" [style.grid-column]="'col-start ' + (ci + 1)">
    <div
      class="bar"
      *ngFor="let value of category.values; index as di"
      [style.--value]="value"
      [style.--color]="series[di].color"
    ></div>
  </div>
  
</ng-container>

 div into the correct position by binding its 

. This ensures it will be placed into the correct repeated column.

 we won't bind any styles directly. Instead, we'll supply two CSS variables: 

, which contains the raw frequency value from the 

, which contains the series color from the 

 field. We'll use both in the component stylesheet:

.category {
  grid-row: data;
  display: flex;
  align-items: flex-end;
}

.bar {
  flex: 1;
  background-color: var(--color);
  height: calc(var(--value) / var(--max-value) * 100%);
  margin: 0 1px;
}

 div is a flex container that aligns its items to the end, which is equivalent to aligning their bottom end to the 

 property as the background color. However, by abstracting it using a property, we could have media queries to change how it is used, such as applying it as an outline when printing, without requiring a change to the template.

 function to determine the height of the bar. By dividing it by a second, 

 property, then multiplying it by 100%, we can scale the height of the 

public categories: BarChartCategory[] = [];

@HostBinding('style.--max-value')
public maxValue = 1;

@Input('categories')
public set categoriesInput(value: BarChartCategory[]) {
  if (!value) {
    return;
  }

  this.categories = value;
  this.maxValue = Math.max(...value.flatMap(c => c.values));
}

Note: Using the simple maximum may not produce the most elegant 

 axis scale. We'll improve on this later.

When dealing with unknown data, text labels are a real source of pain. Long labels can easily overflow the container. On a bar chart, the best approach for 

 axis labels is usually to rotate them at a 45-degree angle. This prevents them overflowing into each other, while being more readable and space efficient than 90-degree labels.

<ng-container *ngFor="let category of categories; index as ci">
  
  <div
    class="category-label-container"
    [style.grid-column]="'col-start ' + (ci + 1)"
  >
    <div class="category-label">
      <div class="label-text">
        {{ category.label }}
      </div>
    </div>
  </div>
</ng-container>

To rotate the labels, we can use CSS transforms:

.category-label {
  transform-origin: top right;
  transform: translateX(-50%) rotate(-45deg);
  text-align: right;
}

However, CSS transforms are not taken into account for layout purposes. The 

 axis area will be sized as if all the labels were unrotated, giving it a single-line height, and meaning these labels will overflow the bottom of the container.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Free Tools

Dynamic Visualisation with Angular

Tags

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript