We shipped a Logic Gates diagram builder app for React, Angular, Vue and Svelte a few weeks ago. It's a cool app, allowing users to construct diagrams with some nifty features like auto edge connect while dragging, and auto connect when dropping on an existing edge:

what it didn't do, though, was offer the ability for someone to see the flow of logic through the diagrams they had created. And so that's the topic of today's article - we're going to run through how we went about adding a simulator function to this app.

Input/output shapes​

The current set of shapes does not contain anything I can use to inject or read values. So I had a quick chat with an agent about it:

In a previous post I mentioned a book that introduced to me the concept of the "data-ink" ratio - the amount of ink used to represent data vs the total amount of ink used to draw the entire image. At that time I was working for a travel company, and I was so enamoured with this book that I instantly went off and started designing prototypes for alternative ways we could present our users with the results of their searches.

None of my ideas were adopted: I couldn't find a champion amongst the middle managers. But that didn't make me think they were no good. One of my favourites was what I'm going to talk about today - flight search results using a scatter chart.

Searching for flights​

When I search for a flight I most often have:

• a general idea of when I want to depart
• a budget
• a personal list of airline preferences
• a preference for getting there quickly, but
• an aversion to flights longer than 15 hours

Many years ago a manager of mine introduced me to a fantastic book about data visualization, entitled The Visual Display of Quantitative Information, by Edward Tufte:

You should go to a bookstore and buy this book, it's great.

One of the core concepts in this book is that of the "data-ink" ratio - the amount of ink used to represent data vs the total amount of ink used to draw the entire image. There are many examples of this throughout the book, and it's a concept that has stuck with me.

FIFA World Cup​

We recently dusted off our FIFA World Cup Visualizer and released it as an app that people can use in their sites. In this app we're particularly pleased with the group stage visualization, because we think it has a satisfying data-ink ratio:

For a given team in the group stage, this visualization lets the user track 10 discrete pieces of information:

The VisuallyJs API, as with most Javascript APIs, makes extensive use of Javascript objects for configuration. A good practice to follow with inputs from the user is to make an internal copy, so as to be sure that your library is not introducing any unexpected side effects. Keep in mind that Javascript objects are passed by reference, ie:

function doSomething(obj) {
    obj.title = "A new value."
}

const myObject = {
    title:"Initial title"
}

doSomething(myObject)

console.log(myObject.title)

=> "A new value."

...this is why we want to make a copy of any object we are given, because we don't know where else the user is using this JS object it passed in.

function doSomething(obj) {
    obj = Object.assign({}, obj)
    obj.title = "A new value."
}

const myObject = {
    title:"Initial title"
}

doSomething(myObject)

console.log(myObject.title)

=> "Initial title"

Obviously this example is a little contrived, but hopefully you get the point. By using Object.assign({}, obj) to create a copy of the object we were given, we've now insulated ourselves from userland...or have we? What about if I pass in a more complex object:

Way back in the day, HTML offered a very limited set of components for capturing input from a user. Over the years this has changed, with new controls being introduced and finding widespread support across the various browsers. One of these new-ish input types (new-ish if you've been writing webapps for 20 years or so, anyway) is the color input:

You can click that color bar and you'll get a popup from which you can select a new color. When you change the color, the span next to it will update to tell you what the current color is.

Available events​

According to MDN there are a couple of events you can hook into:

• input input is fired on the input element every time the color changes
• change The change event is fired when the user dismisses the color picker

In React, you'd use onInput or onChange to bind to these events.

We recently completed a migration of infrastructure from AWS to Hetzner, saving quite a bit of cash in the process. It was quite straightforward for the most part - we created Cloud instances in Hetzner to replace our EC2 boxes, and span up a Postgres instance on a box of its own to replace RDS. We store packages for our private NPM repository on S3; Hetzner has Object Storage for that, so we migrated those, and we were pretty much done. But then a quick look at Hetzner's docs for Object Storage did not show any official Java libraries for interfacing with Object Storage, and in any case we had a whole persistence layer sitting on S3 that we were not particularly keen to rewrite!

From reading Hetzner's website we reached the conclusion that "S3 Compatible" probably meant we could access our buckets via the Amazon S3 client in Java, but how? Our original code looked like this:

import software.amazon.awssdk.regions.Region
import software.amazon.awssdk.services.s3.S3Client

S3Client s3Client = S3Client.builder().region(Region.MY_REGION).build()

To access an AWS API, you need to tell it an access key and a secret access key (which you've created in your AWS console). This code doesn't tell AWS anything about credentials, so how does it know what to use? The AWS client code tests various places looking for an access key and a secret access key. In our case we were using a credentials file in the ~/aws for development, and environment variables in production.

JsPlumb uses the excellent Typedoc documentation generator to create our API documentation, but since we adopted it last year we haven't really made the most of it. We would run Typedoc over our codebase with the default settings, and the result is a page in which everything is listed alphabetically, grouped by Enumerations Classes, Interfaces, etc.

It can be a useful page - if you know what you're looking for. But it doesn't lend itself very well to browsing, and browseable docs are great, because they lead to discovery.

The last 6.x release API docs page looks like this:

While working on an Angular version of our popular Gantt chart demonstration this morning I stumbled across a Typescript linting issue whose purpose is not at all clear to me.

THE PROBLEM​

Say I have this interface for a person:

export interface Person {    
    firstName:string
    lastName:string
}

and this for a serialized person:

export interface Person {    
    firstName:string
    lastName:string
    fullName:string
}

Now I want to write a serializer to export a bunch of these people:

export function serializePeople(persons:Array<Person>):string {
    return persons.map(p => {
        return {
            fullName:`${p.firstName} ${p.lastName}`,
            firstName:p.firstName,
            lastName:p.lastName
        }
    })
}

This looks ok, right? Well in fact the default settings for Angular's tsconfig.json cause an error:

Property 'firstName' comes from an index signature, so it 
must be accessed with ['firstName']

Classes are a controversial topic in the Javascript/Typescript world. Are they a terrible idea? Are they really useful, when used sensibly? This post will make no attempt at answering either of these questions. This post is about a niche method that I first encountered many years ago in the world of Java - isAssignableFrom - and how you can go about writing it for use in Typescript/Javascript.

What does it do?​

This is what the Javadocs have to say about it:

public boolean isAssignableFrom(Class<?> cls)
Determines if the class or interface represented by this Class object is either
the same as, or is a superclass or superinterface of, the class or interface
represented by the specified Class parameter. It returns true if so; otherwise
it returns false.

So, given some class, you can use isAssignableFrom to figure out whether that class is a subclass of some other class.

Why would I need this?​

If you're thinking it's a bit niche, yes, I agree. isAssignableFrom is one of those methods you don't use much. But when you need it, you need it.

JsPlumb uses Docusaurus, a super handy static site generator, for various parts of our ecosystem, including our Documentation and also our recently released stand alone components product.

While developing the site for JsPlumb Components, we wanted to include a couple of pieces of information that would vary depending on whether we were running in development mode locally (ie docusaurus start) or building for production. We looked into the various options available, all based on the dotenv plugin for Webpack, but couldn't find what we were looking for: a solution that worked, with minimal manual intervention, in both development mode and when building for production.

So we ended up building our own plugin. This plugin reads values from a JSON file and makes them available to your site via the customFields map in the Docusaurus siteConfig.