When changing on object's structure look for both object and key in question

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the dumb-mistakes-and-gotchas category.

Last Updated: 2024-04-25

I wanted to refactor the following taxation rates data:

rates = {
  utility:  {
    // This is the important part for our purposes today:
    0: 1125,
    2000: 1202,
    3000: 1278
  }
}

This is how it was changed.

rates = {
  utility: {
    // i.e. now the data has been nested under a newly introduced key: `ratesPer200Kg`
    ratesPer200Kg: {
      0: 1125,
      2000: 1202,
      3000: 1278
    }
  }
}

This change (obviously) requires that references to the object need to also be updated. Which seems easy, when looking at things here. But in the actual codebase, the references to this data were spread out and accessed in a piecemeal fashion, gradually unwrapping layers of the object at distant points in the file. Here's an example:

import rates from "data"

// ...
// Lots of other code

// then eventually I access a sub-key -- assigning it to another variable name.
const utilityRates = rates["utility"]
// ...
// Much later
const taxPer200Kg = utilityRates["0"]
// etc.

I simply didn't think to update this part. The different variable name seduced me into thinking further searching for places to update wasn't necessary.

What I should have done was search the code for references to the previous container key (i.e. utility) and then updated any immediate child references.

// correct code
const utilityRates = rates["utility"]
// modified code
const tax = utilityRates['ratesPer200Kg']['0']

Lesson

When changing the structure of an object, search the codebase not just references to the object, but also references to the sub-key in question.