A Sum of Parts and Creative Inertia
By: Kal Megati
Tags: JavaScript, Coding, Ruby on Rails, API, Sql

A Constructed Warrior, Frozen in Time

I recall building my final Lego creation some half a decade ago: an OC Toa of Magnetism using Technic pieces. It is still posed up on my desk, and as I marvel at my craftsmanship I notice that all of the axel pieces I used are grey, rather than the much more common black. I would have needed to specifically search to find all of my grey axels, and for what? The grey contrasts the white and silver armor pieces just as black axels would, so why not use the more common color?

We’ll get back to that at the end; for now let’s talk code. We’re looking at Tabula Rasa, in particular the Element and ElementScreen components. Element creates a table displaying information in multiple cells; the user has the control to disable certain cells in order to make Element more minimalist or succinct. This is accomplished by having Element’s render function encounter a conditional for each cell displayed. Among its props, Element receives an array which denotes which cells are active and inactive, and these conditionals read the specific parts of the array to determine whether they should or should not appear.

In retrospect, this seems like the sort of thing I could have handled using a plain old Javascript object (a “pojo”) rather than an array. I am already using a pojo to fill in the text of these boxes, so why not use the same format? Instead of { label1: foo, label2: bar, [1, 0] } I could more intuitively organize them as { text: { label1: foo, label2: bar }, active: { label1: true, label2: false } } . Or even as { label1: { text: foo, active: yes }, label2: { text: bar, active: no } } . Under the hood, one can more easily look at these objects and understand what their purpose is, rather than having to parse out the array and keep track of which index matches which label. This is especially so because my array doesn’t even follow the convention of 1=true and 0=false; instead, 0=false and “non-0”=true (which is only visible from my methods, not the pojo itself). So why are the active boxes for Element determined by this strange secondary array?

Here is where we need to look into Tabula Rasa’s history: namely, the fact that it started with an integrated Ruby on Rails API on a SQLite database. SQLite cannot store objects with attributes that are objects, so handing over pojos with nested pojos inside cannot be stored as singular objects in my backend. In fact, cannot even store them with attributes that are arrays! My answer here was to have this nested array replaced with a string using .join() right before the client sends the request to the server. The reason for not simply using 1=true was so that one could look at the array and see immediately which cells were inactive: 120000709 is an Element with only its 1st, 2nd, 7th, and 9th cells active. And so the question flips: why an array instead of a string from the start?

Javascript has two types of variables: objects (including arrays) and primitives(including booleans, integers, and strings). The crucial operative difference: objects are mutable while primitives are not. In order to have an Element be dynamically rerendered in its new format, I would need to give users the ability to change which cells are active by connecting checkboxes to them. These checkboxes would not be able to change specific indices of a string (as strings are immutable), but they can change specific indices of an array. And then for the client to read the string that it is given by the server, the first thing that must happen is that string be adapted back into an array using .split("") .

Consider all the pieces here: SQLite can only store information in types that JS considers to be primitive, and so JS would not be able to modify this data without some manipulation in the middle. And so we bridge the gap between SQLite storage and JS mutability using the String type and the Array type, which can easily be transmuted back and forth between each other.

Once my methods are all built on the premise that Element box activity is determined from an array, it becomes a chore to later decide that activity is not an array but some other sort of variable, because it requires changing the arguments or contexts of many methods down the line. So although the removal of the integrated API means that activity could now be integrated into the pojo instead of seperate as an array, the fact that the original setup still works convinced me not to do so. The array was added for SQLite’s sake, but it had become such a core part of my process that it did not feel fitting to remove it.

As for my Toa of Magnetism, its a similar story. Originally its armor was not supposed to be white, but rather black. I chose grey axels then because the black axels would not properly contrast with black armor. And when I switched from black armor to white? I could have gathered black axel pieces and switched them as well, but the grey axels worked just as well and they were already assembled. I’ve no objective reason, but grey just “felt” better at this point, because they had been with me for much of my process. And so they persisted, despite having originally been chosen for a reason that was no longer necessary.

Creation is determined by the choices we make at the beginning, and those initial preconceptions can become great pillars of stability down the line. And coding is an expression of creation.