DEV Community: Percy Hanna

Building a dynamic Canvas rendering engine using JSX

Percy Hanna — Tue, 02 Apr 2024 15:59:38 +0000

Our product team is busy adding many great new features to Aha! Whiteboards and Aha! Knowledge — including wireframes, voting, and improvements to viewing Aha! Roadmaps data within a whiteboard. We added all of this functionality in just the last few months, and we are busy building even more features that will deliver product value to our users.

As the engineering lead for these products, I saw all of the above features (and others) on our product roadmap and had a few thoughts:

How can we easily build features that rely on dynamic content and real-time user collaboration?
How can we do that on Canvas? Rendering dynamic content on Canvas is complicated — or at least, it's much more difficult than using HTML and React, which is how we have built most interactive features at Aha!

The challenge

Anyone who has used Canvas in the past understands the challenge. You cannot simply render content to the screen — you must manually draw content using functions such as lineTo, fillRect, fillText, and so on. Consider the really simple example of rendering "Hello, world!" with basic styling and a quick layout. Let's try and reproduce this HTML in Canvas:

<span style="border: solid 1px black; padding: 5px; font: 16px Times;">
  Hello, world!
</span>

The code above will produce this:

But let's see what we would need to generate this in Canvas:

// Rendering context
const ctx: CanvasRenderingContext2D = canvas.getContext('2d');
const padding = 5;

// Measure the text
ctx.font = '16px Times';
ctx.textBaseline = 'top';
const textMetrics = ctx.measureText('Hello, world!');

// Calculate the box size
const contentWidth = textMetrics.width + padding * 2;
const contentHeight = textMetrics.fontBoundingBoxDescent + textMetrics.fontBoundingBoxAscent + padding * 2;

// Draw the border
ctx.fillStyle = 'black';
ctx.strokeRect(0, 0, contentWidth, contentHeight);

// Render the text
ctx.fillText('Hello, world!', padding, padding + textMetrics.fontBoundingBoxAscent);

Almost 20 lines of code just to render the most basic of content.

Dynamic content

This becomes even more complex when you start adding dynamic content. For example, one of the first features in our Aha! Whiteboards roadmap was to add emoji reactions to our sticky note shape. This is a simple way to gather feedback from everyone viewing the whiteboard. The feature seems simple enough. In React/HTML, you might have something that looks like this:

<button className="emoji-button" onClick={clickHandler}>
  👍 1
</button>

And here is what the user would see:

In Canvas, this becomes much more difficult. We have to render the button, add the padding and border radius, and then render the emoji and reaction number.

But it doesn't stop there: What if 10 people react with a thumbs-up? Or 100? Now, that button must be wider to adapt to the content inside of it. In HTML, you don't even have to think about this. It just happens. You would just write your code like this:

<button className="emoji-button" onClick={clickHandler}>
  👍 {counter}
</button>

Chances are that's how your component was written in the first place. You didn't even think about how to resize the button element — the browser's rendering engine just did that for you. Emoji reactions was just the first feature I saw in our roadmap. And there were many others. But the big, daunting one was wireframes.

Not only did we need a way to render a button that was entirely in our control, but we also needed to allow users to create their own buttons and add their own content to it. And a button was one of the simpler components we needed.

The naive solution

The very naive solution would be to write each button and wireframe shape separately. You could perhaps create a renderButton function as a helper to render a button to the Canvas. Generalize the above code into a function, and you come up with something like this:

// Rendering context
const ctx: CanvasRenderingContext2D = canvas.getContext('2d');

function renderButton(text: string, padding = 5) {
  ctx.save();

  // Calculate the box size
  const textMetrics = ctx.measureText(text);
  const contentWidth = textMetrics.width + padding * 2;
  const contentHeight = textMetrics.fontBoundingBoxDescent + textMetrics.fontBoundingBoxAscent + padding * 2;

  // Draw the button background
  ctx.beginPath();
  ctx.roundRect(0, 0, contentWidth, contentHeight, 4);
  ctx.fill();

  // Render the text
  ctx.fillText(text, padding, padding);

  ctx.restore();
}

But this solution is limited. It only solves a specific problem and doesn't help fill in the functionality gap that HTML addresses out of the box. Imagine how this would scale as you add more complex shapes like these:

Navigation menu:

Dropdown picker:

So the complexity of rendering all of these wireframes grows quickly, even with relatively simple shapes. How do you calculate the width and height of each navigation item? How do you render the borders, backgrounds, and dividers between each item?

Buttons

Let's take a deeper look at a very simple shape we have in our Wireframes: the button. As I demonstrated above, implementing a basic button renderer would not be difficult in and of itself. But there is already a bit of added complexity here. Our button needed to support multiple styles:

Style	Example
Basic
Rounded
Outline
Rounded outline
Link

Each of these variations adds a bit more code and complexity to our renderButton function. It would definitely be possible to support all of these designs with a single function, but would it be elegant? Reusable? Dynamic?

Did you notice the icons? Well, users can choose to place the icon on the right side instead. And they can change the color of the button and the text, too. By themselves, each of these are minor things to add. But eventually, that function would become overloaded with all the variations, customizations, and edge cases that need to be handled.

JSX

In order for our team to be able to easily implement all of these features, we needed a readable, elegant, and powerful way to render dynamic content to Canvas in a familiar way. I thought to myself, wouldn't it be great if we could just render content to Canvas the same way we do with React?

And then I had my Aha! moment. WE COULD! To do this, we would use one of the really powerful and innovative features that React introduced to the world — something called JSX. It's really just syntactic sugar to write HTML syntax into declarative and well-structured element objects. For those of you who are unfamiliar with JSX, what it does for you under the hood is convert code like this:

<button className="emoji-button" onClick={clickHandler}>
  👍 {counter}
</button>

Into something like this:

_jsx('button', { className: 'emoji-button', onClick: clickHandler }, '👍 ', counter);

JSX, in my opinion, was the biggest innovation that came out of React given that you could write HTML directly in your JavaScript. I had used other frameworks such as MooTools in the past. You could use them to dynamically construct HTML in JavaScript, but with a very verbose and tedious syntax. It looked very similar to the converted code above. And it worked, but it was not satisfying or pleasant.

The beauty of JSX is that you can override how elements are converted to JavaScript code using something called a pragma. A pragma, or directive, is something that tells the JSX compiler how to process the code. In your JSX/TSX code, you can add a pragma to the top of your file like this:

/** @jsx CanvaSX */
import { CanvaSX } from 'canvasx';

Now, instead of converting your JSX to React code, the above code would be converted to something called CanvaSX code (more on this later):

CanvaSX('button', { className: 'emoji-button', onClick: clickHandler }, '👍 ', counter);

The solution

My goal was simple and clear: I wanted to be able to write JSX code that could render a simple navigation/tab menu. The system should generate the layout and render that content for me dynamically, and I shouldn't have to think about the complexities of measuring text and padding and layouts. It would need to handle very common layout patterns such as margin, padding, (rounded) borders, and so on.

The really powerful feature would be to have all the layout complexity completely hidden from the developer. When rendering the navigation items, the width of each item would need to be based on the text and/or icon inside it, and then the borders and background should be rendered based on the width of that content. We would then need to render dividers between each item.

Introducing CanvaSX

I spent some time prototyping a rough implementation of a rendering engine that I've come to call CanvaSX (Canvas+JSX). The early versions were quite rough, but the benefits were obvious. I could write simple shapes like a button or navigation menu using very familiar syntax, and I didn't even have to think about calculating coordinates or layouts.

Eventually, I added support for basic interaction properties (such as onClick and tooltip handlers) and some very rudimentary flexbox-like components, too. Now, we could have something like a real button completely rendered in Canvas. The end result made the emoji button as simple as this code:

<Rect
  fill={backgroundColor}
  borderRadius={2}
  padding={2}
  onClick={emojiClickHandler}
  tooltip={emojiTooltipContent}
>
  <FlexRow gap={2} verticalAlignment='center'>
    <Emoji shortCode={shortCode} />
    <Text color={textColor}>{votes}</Text>
  </FlexRow>
</Rect>

Which made sure we could offer reactions like these:

The wireframe button is very similar, but it simply passes along user input to the properties. For example, to support rounded vs. square buttons, we just need to write something like this:

<Rect
  fill={backgroundColor}
  borderRadius={round ? 32 : 4}
>
  <Text color={textColor}>{text}</Text>
</Rect>

This code is very easy to read for anyone familiar with React, and CanvaSX addresses all of the layout complexities.

How does it work?

The magic behind CanvaSX is that every component can measure itself. With this information, CanvaSX can generate the layouts automatically. This is what the Text component's measuring function might look like:

Text.calculateDimensions = (props, ctx: CanvasRenderingContext2D) => {
  ctx.save();

  if (props.font) {
    ctx.font = props.font;
  }

  const textMetrics = ctx.measureText(props.children);

  ctx.restore();

  return {
    width: textMetrics.width,
    height: textMetrics.fontBoundingBoxAscent,
  };
};

A parting note

Building CanvaSX is one of the highlights of my career. I have had the opportunity to work on many features in my more than five years of working at Aha! These include capacity planning for teams, redesigned drawers, Aha! Develop, and our custom card layout editor. I've recently worked on many improvements to Aha! Whiteboards, which is where CanvaSX came in. It has proven itself to be extremely powerful and flexible — and it is now used as the foundation for emoji reactions, wireframes, updated record cards, and our brand-new voting tool!

I work with a team of extremely talented engineers at Aha! We collaborate to solve hard problems and deliver value to our users. If this sounds like something you would enjoy doing, you should check out our open positions.

Embrace the monolith: Adding a new product to Aha!

Percy Hanna — Fri, 29 Apr 2022 20:52:29 +0000

When our engineering team first began conceptualizing Aha! Develop, we were faced with a monumental question. How should we implement the architecture of adding a brand new product? We could start fresh with a brand new codebase, utilizing the latest technologies and frameworks. Or we could build on top of our existing monolithic codebase that powers Aha! Roadmaps and Aha! Ideas. We examined the pros and cons of greenfield, microservices, or continuing to use our existing monolith — all in pursuit of the most lovable solution for our users.

Option 1: Greenfield

Starting with a brand new codebase is really appealing. We could keep it simple without any extra baggage like complex dependencies, legacy code, technical debt, or old build pipelines. Using the latest versions of all of our favorite frameworks like Rails 7 and React 18 would mean not having to worry about testing for regressions. And we could start fresh with a new design system or CSS framework.

Developing something new out of nothing is one of the things that excites me the most about product development work. But eventually you will start building the same features you’ve built before. Maybe some are already in a Ruby gem or JavaScript npm package, so you could easily incorporate them into a new product. But in most situations, it’s specific to your business and not neatly packaged inside a gem. You could extract some from other codebases, but you'll end up reinventing the wheel or duplicating a lot of old code.

Even if the new greenfield product does not have a lot of overlap with previous products, you might find yourself rewriting common systems like authentication, permissions, notifications, or other things you’ve implemented before. Most applications share a lot of this core functionality regardless of the product itself.

Option 2: Microservices

Microservices have been popular in the past several years. Building Aha! Develop on top of microservices would make our application more modular and scalable. We could transition core functionality of authentication, permissions, notifications, and sharing/publishing to their own microservices. These would lead to smaller pieces of isolated code that are only responsible for a concise set of tasks. They can be scaled independently in order to maintain service level objectives (SLOs) or other key metrics. Then Aha! Develop could reuse these core services with a UI built separately from the other products in our suite. All of our core business logic would be nicely encapsulated, tested, and deployed separately. Any number of interfaces or APIs could be built on top of that foundation.

That would all come with some fairly significant tradeoffs. As the dependency hierarchy between each microservice or application grows, changes require complex coordination between various teams to prevent regressions. When new features are needed, meetings and thorough documentation ensure the necessary APIs behave as expected to support the desired functionality. Teams must coordinate back and forth over weeks or months to manage the testing, development, and deployment of the new features. As the product requirements evolve, additional meetings and work are needed to support the new behaviors.

The benefits of having simpler code in microservices get eroded by increased process and operational complexities. Sometimes those tradeoffs are worth the effort, though.

Option 3: Monolith

Our third option was to continue building on top of our existing monolithic application. We had already added Aha! Ideas to our suite of products in late 2020. This gave us the confidence that we could build another new product using a similar approach, even though it was targeting an entirely new demographic — developers. This approach also allows for better integration and consistency for customers using multiple Aha! products together.

Monolithic applications are sometimes frowned upon due to their other costs of operation. For example, some frontend JavaScript developers might prefer more isolation from our Rails backend. If a developer is using a platform or framework they're less familiar with, this could affect productivity or developer happiness — something that cannot be ignored. We've found that providing documentation and onboarding processes helps alleviate these issues.

A monolithic application can also quickly run into performance limits, often from an underlying service. For example, due to the large volume of job queuing, we have run into CPU and memory bottlenecks with our Redis-backed Resque service. We were able to make improvements to our job queuing by implementing a Kafka-based queuing system. This improved the performance and reduced the latency of our jobs. The jobs are still executed as part of our monolithic application — meaning the operational costs are fairly isolated.

Extending the monolith

Extending the monolith ended up being the clear winner for Aha! Develop. We already had a solid foundation of core functionality. Adding new features or APIs would not be any more difficult than if we had chosen greenfield or microservices.

By embracing our monolithic codebase, we were able to launch Aha! Develop on top of the foundation we had already built. For example, instead of reimplementing authentication and permissions from scratch, we focused on building compelling new features like extensions, the workflow board, and our new GraphQL API.

Security and permissions

Aha! takes security and permissions very seriously. Building the same level of security and compliance into a brand new codebase would take a significant amount of effort. It would also increase the surface area for attacks by having more infrastructure that needs monitoring and safeguarding, as well as additional codebases that must have their dependencies reviewed, approved, and updated to protect us against security threats.

GraphQL API

To support Aha! Develop, we built a new GraphQL API on top of our existing, rich Aha! data schema. This API supports many features in Aha! Develop, such as the workflow board, backlog management, and sprint planning views. Extension authors can also interact with the data or create custom extension fields to customize the tool to suit their needs.

Since we built this into our monolith, the API takes full advantage of our existing data model and Aha! Ideas and Roadmaps take advantage of the new GraphQL API. We are also able to implement performance improvements that benefit all of our customers, such as our solution to automatically avoid N+1 queries in GraphQL.

Common features

One of the major benefits of using a monolithic codebase is the ability to reuse code. Our Rails monolith uses many common patterns for writing reusable and modular code. We've used patterns like concerns, service objects, and decorators to help us avoid repetitive code, simplify testing, and provide consistent behavior across the application.

We reused code to add components like comments, to-dos, record links, and audit history to Aha! Develop with very little effort. For example, we added a new model for Aha! Develop — the iteration (or "sprint") model. We use Rails concerns so our models are composable. Here are a few of the concerns we included in the iteration model:

include HasDescription
include HasWatchlist
include Terminology
include ActsAsTabbedRecord
include ActsAsCommentable

With these few lines of code, our iteration models included many advanced behaviors we had already implemented elsewhere in Aha!

Not only is reusing the models helpful, but we could also reuse our existing views. This gives us access to our drawer and details design that lets Aha! Develop manage custom fields and layouts with a simple and intuitive interface. We have now added a completely new model to our application that looks and behaves just like the others.

Collaborative text editor

Our rich collaborative text editor is one of the many compelling features in the Aha! product suite. Including it as part of Aha! Develop was a critical feature. We even added syntax highlighting to the editor — an improvement built for Aha! Develop — but now all Aha! customers can take advantage of this great feature.

Adding a new product to Aha!

Since all of this core functionality was already available to us, adding a new product to the Aha! suite was relatively simple. The only difficult part was focusing on Aha! Develop’s differentiating features.

Develop teams

Develop "teams" were constructed as a natural extension to our existing workspace hierarchy. This allows team configuration and settings to behave similarly to workspaces in Aha! Roadmaps. Each team can configure their own statuses, terminology, and workflows. This was yet another way to build on top of existing patterns used in Aha! Roadmaps without writing a lot of new code.

Billing and permissions

Adding a new product to our billing system was not without its challenges. The system was originally built to support only a single product with a few different pricing tiers. Our new billing system would need to support several different products, with a number of pricing tiers each. We introduced additional subscription plans and can now support accounts that use multiple products. Customers can have quite a few different billing configurations but there are some we need to prevent.

To implement this, we introduced a new "flavor" model that is used to determine the billing plan, pricing tier, and number of seats for the various products in our suite. Previously this information was stored at the account level. This flavor model also dictates available functionality from within the application. We can now use a single model to manage the billing and available functionality for accounts.

Launching Aha! Develop

In the end, we didn't need to reinvent any wheels. We didn't reimplement permissions, authentication, comments, custom fields, or layouts. All of these features have evolved and matured over many years, representing countless iterations and improvements to the Aha! product suite. It would be wasteful to throw out all of that effort. Embracing the monolith allowed us to build and launch Aha! Develop with a rich and mature interface — while saving our developers months of effort and providing a Complete Product Experience for our users.

Sign up for a free trial of Aha! Develop

Aha! Develop is a fully extendable agile development tool. Prioritize the backlog, estimate work, and plan sprints. If you are interested in an integrated product development approach, use Aha! Roadmaps and Aha! Develop together. Sign up for a free 30-day trial or join a live demo to see why more than 5,000 companies trust our software to build lovable products and be happy doing it.