Metastory ~ Validating ES6 classes
ES6 comes packed with classes, loads more Symbols and loads of extra goodies to help us along our way but I wanted to share a small thing I did recently while writing some new FOSS.
For a while now, I’ve been working on Multicolour and for the most part I’m incredibly happy and proud of it and the work gone into it.
Recently, I’ve decided to build out a new DAL for it. As cool as Waterline is, it’s old, has plenty of bugs (look through the Multicolour source code to see comments and fixes for known bugs) and their roadmap still has items from 2013 in it which might seem obvious and basic to some.
The new DAL (Data Abstraction Layer) is not an ORM (Object-Relational Mapping). Something I really wanted to be clear about, I just want to be able to choose my DB tech and know what I’m doing without any extra tech or if the client chooses a different DB tech no “shit the bed” moment and debt recovery.
And while it’s literally only in the gestation period (so to say..) I wanted to guarantee to the consumers of the DAL that the adapters are written properly, written well and all share the exact same documentation.
For this, I have to go back to my roots as a C++ developer (Lonnnnng time ago) and take up some of the ideas I had then about ensuring a sub-class followed the interface set out by the parent.
Interfaces are a way to describe how a subclass’ API should look, what methods it must have. The implementation is irrelevant, see this example:
The above is just the scaffolding for what a subclass should look like, so if we tried to use that interface (in any other language with interface support)
I would expect some kind of Syntactical error along the lines of
HEY, LOOKS LIKE YOU’RE TRYING TO CREATE A LIGHTBULB CLASS. HOW DO I TURN IT ON OR OFF?!
But alas, we don’t have that we have classes and that’s fine we just need to validate the subclass somehow. I asked on Twitter if anyone knew how to get the public members of an ES6 class.
I wanted to get an object that represents a class and validate that, in essence creating an interface from my class:
Here’s what I came up with, as minimal as I could.
An example “interface” would be (taken directly from Datus):
I create an object from the public members on the class (which will be whatever extends `Interface`) and then validate that against my interface.
It’s hidden behind a Symbol because I don’t want to pollute the consuming class in any way. It all populates up to the Adapter class which validates the bottom of the pile with the symbolised “INTERFACE” and voila, you get an Interface and errors for bad consumption/extension!
Why not use TypeScript?