Use OOP instead of one shared config + prop drilling

[yamiteru]

Currently we cannot run multiple benchmarks in the same JS Realm at the same time since all of them share one single config which we reset on every suite run.

Even though I don't know why someone would want to run multiple suites at the same time (since it'd create noise) the prop drilling is enough of a reason for this rewrite into OOP.

Since this library is mainly gonna be used in NodeJS where size of "downloaded" code doesn't matter then there is no benefit to keeping the current structure. Even if the library is gonna be used in a browser I don't think the size actually matters since it's not gonna be a part of a normal web/app. Most likely the only web/app it's gonna be used in is gonna be a benchmark web/app.

[yamiteru]

#12 I've pushed the first OOP version.

Although I don't like how big the main file is so I'm gonna have to figure out how to extract the code outside of the file but maintain the class since I like how much easier the code is now.

[yamiteru]

So I've tried extracting the functions and then passing the class private variables into it via props but I don't really like that since there is quite a lot of duplication.

I'd like to do something like this:

import { run } from "./utils";

class Suite {
  public run = run;
}

To mimic this behavior I've tried creating classes the good ol' way like this:

import { run } from "./utils";

function Suite() {}

Suite.prototype.add = add;

Which works until I want to define and call private methods. So I cannot use this either.

I've tried to come up with a helper function which would take all private and public variables/methods and a constructor but my brain has melted while attempting to implement it.

This is how the API looked like:

import { run } from "./utils";

const Suite = createClass({
  constructor: () => { /* ... */ },
  private: {
    name: "",
    benchmarks: {}
  },
  public: {
    run
  }
});

So right now the best solution seems to be something like this:

// utils/run.ts
import { Benchmark, Events } from "..types";
import { Suite } from "../suite";

export function run(
  this: Suite, 
  name: string, 
  benchmark: Benchmark, 
  events?: Events
) {
  /* ... */
}

// suite.ts
import { run } from "./utils";

class Suite {
  public run(
    name: string, 
    benchmark: Benchmark, 
    events?: Events
  ) { 
    run.bind(this)(name, benchmark, events); 
  }
}

There's still quite a lot of duplication but at least I'm always passing the whole class instance and not just individual variables/methods. I leave that part to the function that it calls.

This way the class could be under 100 LoC and the actual logic would be extracted away.

Although I'm not sure if it's possible to call private methods like this. If not then I'll have to go back to the drawing board.

[H4ad]

Keeping it as a class is a good way of matching the APIs of benchmark.js, which makes it easier for someone to migrate from benchmark.js to your library by just changing the imports.

Also, I prefer this new way of declaring, using .add function, for a lot of benchmarks (in which I tend to use loops), it became way cleaner to declare it using for + .add function than trying to create just one big object will all tests together.