add components for new board patterns that work with baduk

[merowin]

Changes

• take out the baduk adapter class
• some more refactoring so the variants can work with graph boards
• add components for graph boards in the vue-client that work with baduk and the board factory

Not done yet:

• make it so Freeze, Quantum have boards that render the graph boards (they have their own components)
• add game config input forms for variants that now support the new patterns.
• Figure out what to do with Annotations on the board (I copied the Multicolored Grid board and made it work for the graphs).

But

It's already working for the most part. Here is variant Tetris on a rhombitrihexagonal board:

I had some problems with backwards compatibility at first, but I think that I sorted those out.

[benjaminpjones]

Nit: we've got a lot of Array-style methods on Graph!

Suggested change

	const graph = new Graph<TColor>(adjacencyMatrix);
	intersections.forEach((intersection) =>
	graph.set(intersection.id, startColor),
	);
	const graph = new Graph<TColor>(adjacencyMatrix).fill(startColor);

[merowin]

changed accordingly, thanks!

[benjaminpjones]

Nice fix! Could be worth a simple unit test - something like:

test("createGraph", () => {
  const intersections = createGridBoard({
    type: BoardPattern.Grid;
    width: 3;
    height: 3;
  });
  const graph = createGraph(intersections, 0);

  expect(graph.serialize()).toEqual(...);
});

[merowin]

I Added a simple unit test.
It's rather difficult to write a meaningful unit test about the graph boards, because its rather abstract, and the one I added is not independent of the implementation (i.e. another implementation may work just fine, but fail the test).

[benjaminpjones]

Ah yeah, that's a good point, I agree implementation-independence is a good quality to strive for. I think your comment in the code is a sufficient mitigation, but some thoughts on how to create implementation-independent graph tests in general -

When testing createGraph, we could build intersections from scratch instead of a factory:

const intersections = [Intersection(...), Intersection(...);
intersections[0].connectTo(intersections[1], true);

const graph = createGraph(intersections);

// This should hold true regardless of impl (unless we decide to re-map IDs)
expect(graph.neighbors(0)).toEqual([1]);

When testing factories, just assert on properties that should remain invariant. E.g. counts and sizes:

expect(intersections.length).toBe(18)
// hard to assert on each intersection because order dependent, but
// maxes, mins and other aggregators should be mostly invariant
for (intersection of intersections) {
    expect(intersection.Neighbors.length).toBeGreaterThanOrEqualTo(2);
    expect(intersection.Neighbors.length).toBeLessThanOrEqualTo(4);
    // Same with positions
    expect(intersection.Position.x).toBeGreaterThan(0.0);
}

[JonKo314]

We could expect() some other things here, that do not depend on the intersection IDs. Like the number of intersections and neighbors overall, or the number of neighbors per intersection.

[merowin]

Added an assertion about the total number of neighbours (double counted edges).

There is already another test case that checks the total number of nodes of the rhombitrihexagonal board.

[JonKo314]

Could be changed into one line. Some IDEs will complain about using two lines.

[benjaminpjones]

Is there an eslint rule that does this? If it's something we care about, I wouldn't mind adding it to the configs

Edit: I found this: eslint-plugin-sonarjs/prefer-immediate-return but I don't know what SonarJS or whether it's worth pulling in another plugin.

[JonKo314]

I don't think eslint checks that. It's included in a big closed issue, but it was never implemented according to that. eslint/eslint#667

https://www.jetbrains.com/help/phpstorm/javascript-and-typescript-redundant-local-variable.html

---

I wouldn't bother adding another plugin just to do that, but I'd be okay with using it.

[merowin]

Simplified to one line.