A test of asynchronously creating objects

It doesn't seem unreasonable to expect that Objects/Classes could be constructed/initialised from data downloaded to the client via a request, EG using fetch().

There are many potential use-cases but the most obvious is for computation on the client.

A fool's errand?

There is no standardized way to write async constructors in javascript. Eloquent article explaining the probem

The concept of OOP and Classes in the context of JS is perhaps best described as "colloquial". The core ideas are taken from familiar Languages (Java/C#) but the actual v8 engine interpretation is a little different. The JS syntax and implementation also has a few gotchya moments to be wary of, notably that returning anything (other than this) from a constructor() function will overwrite the instance of its object scoped `this`.

Meaning that...

... consequently, the logical expectation, that our discountCactii is an instance of Cactii has been broken.

The description above may seem innocuous, in that why would a constructor ever return something that wasn't itself? However, if we want to return data asynchronously, perhaps from a server/endpoint then there is a moment when the client will have to wait for the result. Using the PromiseAPI is a really effective way of implementing this functionality, but we cannot return a promise from a constructor as we run in to the problem we had earlier.

Let's explore furthing using a Pokemon API.

Using the pokemon API to request the data of a pokemon by its name...

Or a collection from their pokedex number, starting from 1. Where the argument is the total number to return. (EG 150 - all original pokemon)