Stage refactoring is complete

A bit later than more recent Devember posts, but work was still done. Weekends are bad for development with so many errands to run and chores to complete, but better late than never. This is just a preview of what’s going to happen (probably) in the last two weeks of December when I’m on vacation and in holiday mode full time.

Today’s changes all revolve around refactoring in the Stage class.

The design of things has changed somewhat; instead of the Stage class having rendering methods directly, there is now an Interface (unimaginatively named Render) which has all of the possible public rendering methods. There is also a new class CanvasRenderer which implements the interface by using the canvas context of the stage, which is basically a complete rip of the code that used to exist in the Stage class.

There is now a new property, Stage.renderer of type Render (anything that implements the interface will work), which means that anything that wants to draw needs to use stage.renderer.method() which is a bit more verbose, but it makes the code more readable in the implementation. I really wish partial classes were a thing in TypeScript.

While I was at it I also took advantage of the simple enum capabilities (simple as in they exist, unlike in JavaScript) of TypeScript for the drawArrow() rendering method. Now instead of passing in a number to determine the style of arrow head drawn and another number for which end(s) of the lines the arrowheads should be rendered, the code is much more readable.

Sadness for the day: Unsurprisingly (when you think about it) the method declarations in an interface are not allowed to specify default values for their parameters; that can only be done in implementations, not declarations. I totally get why that’s the case, and I left the defaults in the concrete implementation, but it does rather complicate the idea of swapping render classes if the defaults are not written in stone.

On the one hand this could mean that things look wildly different when the renderer is switched. On the other hand it could also be used to allow each implementation to choose sensible defaults for often defaulted parameters so that things actually work better. Time will tell on that one, I guess.