DEV Community: Jack Shen

JavaScript techniques you wish you knew involving objects

Jack Shen — Fri, 07 Aug 2020 14:23:39 +0000

If you've spent any amount of time in web dev, chances are you've heard the saying, "everything in JavaScript is an object!". That isn't entirely true, but we're not here today to discuss technicalities, or even this "truism" at all. Instead, we're going to be discussing regular old, boring objects. The type you might use to store and cart around data in your code, and some techniques about how you might wrangle them more effectively.

A brief recap on objects

Objects are fairly straightforward. Their basic structure consists of zero or more key-value pairs (a.k.a. object properties) inside a set of braces. The value can be anything supported by JavaScript, including functions and other objects as well. More complex object structures may include several layers of nested objects, or even circularly have itself as a value (not great if you want to display the data).

One way of thinking about objects is to liken them to a computer's directory structure. The key might represent a file or folder, the value its contents. A nested object would be a directory within a directory, a function an executable, and a circular reference a shortcut!

const Documents = {
  "My Contacts.csv": [["Mum", 61412345678], ["Domino's", 82752120]],
  "password.txt": "hunter2",
  "New Folder": {},
  Work: {
    "cleanup_script.ahk": () => {},
    "Invoices": {
      "2018": {
        /* ...etc */
      },
      "2019": {
        /* ...etc */
      },
      "2020": {
        "Invoice0331.docx": ""
        /* ...etc */
      }
    }
  }
};

N.B. outside of the above example, it's usually preferred for variables to be named in camelCase rather than PascalCase

Similar to how the directory path to Invoice0331.docx would be /Documents/Work/Invoices/2020/Invoice0331.docx, you would describe it in JavaScript like so:

Documents.Work.Invoices[2020]["Invoice0331.docx"]

We can use the period for property names that are valid JavaScript identifiers; for all other ones (including ones with whitespace, periods, other funky stuff) we have to use the brackets.

Optional chains, more like compulsory ropes

Continuing with our directory analogy, what happens if you try to access a file or folder that doesn't exist? Say you made a typo and tried to open Documents/Work/Invoices/2021/OBVIOUSLYDOESNTEXIST—your CLI would throw a complaint, or if using a GUI file explorer, you might get an alert. Likewise, JavaScript would give you the following error if you tried to access Documents.Work.Invoices[2021].OBVIOUSLYDOESNTEXIST:

Uncaught TypeError: Cannot read property 'OBVIOUSLYDOESNTEXIST' of undefined

When coding, trying to access a property value whose intermediary node does not exist is a fairly common occurrence. Perhaps you may have tried to access a ref that hasn't been set yet, or a particular dataset's shape may not be fully complete. If you are aware that a certain property may not exist, you might decide to test it first before trying to go through with the full access, essentially the coding equivalent of dipping your toes in the water:

// given b may or may not be defined
if (!a.b) return;
return a.b.c;

// or
return a.b && a.b.c;

That works ok, but you can quickly see how this might become a nuisance:

return (
  someObj.someNestedObj &&
  someObj.someNestedObj.someOtherObj &&
  someObj.someNestedObj.someOtherObj.someFinalPropertyValue
  // etc
);

For this, optional chains work better. Optional chaining is fairly new, only having been moved to stage 4 of its ECMAScript proposal in early December 2019. It is very simple to use—just use ?. in place of . after the property you wish to test. This also works for method calls you are not certain are defined and even for array indices:

// check if myObj.prop1 is defined before trying to access prop2
myObj.prop1?.prop2; // will give undefined if either prop1 or prop2 doesn't exist

// check if myObj.prop1 is defined before trying to access "prop 2"
myObj.prop1?.["prop 2"];

// check if myObj.method is defined before trying to call it
myObj.method?.();

// check if myArr[5] is defined before trying to access its 8th index
myArr[5]?.[8];

If the property you tested with the optional chaining operator is nullish—either undefined or a null value—the chain short-circuits and evaluates as undefined. This has the same effect as using a logical AND operator &&, but in fewer lines. With deeply nested objects or extraordinarily long key names, this small change is great for readability.

// instead of
if (
  (object.that.is && object.that.is.deeply.nested) ||
  (object.withExtraordinarily &&
    object.withExtraordinarily.longPropertyKeyNames)
) {
  /* code */
}

// you can write
if (
  object.that.is?.deeply.nested ||
  object.withExtraordinarily?.longPropertyKeyNames
) {
  /* code */
}

// of course you could write this as an alternative
const is = object.that.is;
const withE = object.withExtraordinarily;
if ((is && is.deeply.nested) || (withE && withE.longPropertyKeyNames)) {
  /* code */
}
// but you've unnecessarily introduced variables

Destructuring is fun

Destructuring isn't anything new or revolutionary; it's been around for a while and it's great fun.

Destructure a property!

// instead of
const apples = fruit.apples;

// consider
const { apples } = fruit;

Destructure a nested property!

// instead of
const apples = food.fruit.apples;

// consider
const { apples } = food.fruit;

// or
const {
  fruit: { apples }
} = food;

Destructure multiple properties!

// instead of
const apples = food.fruit.apples;
const vegetables = food.vegetables;

// consider
const {
  fruit: { apples },
  vegetables
} = food;

Destructure and rename your properties!

// instead of
const apples = food.fruit.apples;
const veggies = food.vegetables;

// consider
const {
  fruit: { apples },
  vegetables: veggies
} = food;

Destructure your React props!

//instead of
const Pantry = props => {
  const apples = props.food.fruit.apples;
  const vegetables = props.food.vegetables;
  const handleClick = props.onClick;

  /* react code */
};

// consider
const Pantry = (
  {
    food: {
      fruit: { apples },
      vegetables: veggies
    },
    onClick: handleClick
  },
) => {
  /* react code */
};

Truly, the possibilities are endless.

Optional... destructuring?

Destructuring really shines when you need to use a substantial number of properties from one or more objects, e.g. if you have many React component props. It saves you the trouble of having to define each variable, one chain expression at a time. But with nested objects, you may once again run into the issue of undefined intermediaries.

At first glance, there is no immediately obvious way of using optional chaining operators with destructuring. However, because optional chains evaluate to undefined when they short-circuit, it is entirely possible to take advantage of their use in destructuring by combining them with default and substitute values:

// this is equivalent
const prop2 = obj?.prop1.prop2;

// to this
const { prop2 } = obj?.prop1 || {}

By short-circuit evaluating obj?.prop1 to undefined, you can substitute the left-hand-side with an empty object {} using the logical OR operator ||. If so desired, the substitute could be an object with any shape custom to your needs.

This principle can be applied to a wide variety of scenarios, both with or without optional chaining altogether:

// this is equivalent
const prop2 = obj?.prop1.prop2?.prop3;

// to this
const { prop2: { prop3 } = {} } = obj?.prop1 || {};

In summary

Not every situation will call for optional chaining, destructuring, or "optional destructuring". It is important to be cognizant of when and where you choose to employ ?. instead of ., only in front of properties you genuinely need to test and not as a wholesale replacement. In some cases, it may be easier and more readable to write out a few chain expressions than to deal with destructuring and short-circuiting to default/substitute values.

In the end though, these expressions are great fun and feel natural to use, all that's left is to employ them where you see fit.

How to graduate from junior positions into mid/senior roles

Jack Shen — Mon, 09 Mar 2020 04:43:40 +0000

Having worked with and mentored many junior developers, there has been one doubt I've heard more often than any other.

I've learned a lot, but I don't know if I'm ready to become a mid-level developer.

In two words: impostor syndrome. This is a prevalent psychological poison preventing progression in the programming profession. Now I'm no psychologist, but if you're struggling with similar thoughts, here are three tips that've worked well for me.

1. Learn smarter, not harder.

A common archetype of imposterism involves feeling like you don't know enough, or don't meet the technical requirements to take the next step of your development career.

There will always be something new to learn, this will be most apparent in the middle of trying to figure out the latest framework you think all senior devs should know. This realisation may reduce your learning into a Sisyphean task, leading to frustration and resentment.

Instead, maintain a strong repertoire of core skills you specialise in, and learn on an as-needed basis. Learning occurs continuously, how and what you learn will change over time to suit your needs. Since your skills and knowledge inevitably decay when not used, there's no point in learning everything if your responsibilities change or it turns out you won't need to use it much.

Pretty much nobody starts off as a perfect fit for their role, the majority grow into their positions. Likewise, you will have the opportunity to grow into your next position as a mid-level or senior dev -- you do not (and should not!) need to know everything.

2. Own your code.

Many devs take "ownership" of what they do and take pride in every line of code they write. While this is a great mindset to be in, criticism can be perceived as a blow to one's esteem and may cast doubt on whether they are ready to move to the next career stage.

Setbacks and failures are normal, and I'd argue are something to be welcomed, as they provide stepping stones to improving oneself. Learning to own your code in spite of your mistakes is an important part of self-reflection and professional development. Open one of your very first projects. Chances are you'll find it no longer meets your standards for "good code". Chances are in a few years you'll feel similarly about today's code. This is normal, natural, and occurs at every level of development.

The point I am trying to make here is that there will never be "perfect" code, as standards (both your own and others') change over time. As in the first tip, learning and self-improvement is a continuous process, so there is no point in taking criticism of your code as a personal attack. Take ownership of your code, criticism included, and don't use it as an excuse to prevent your career progression.

3. Learn from and teach others.

Every senior dev has been in the same mental position as you. Anxiety over self-worth is one of those universal experiences that everyone--regardless of age, gender, race, or skill-level--will encounter several times over their lifetimes.

Understanding and accepting the ubiquity of this phenomenon is a key step to understanding and accepting your own value as a developer. Sharing experiences with both your mentors and mentees will increase the breadth of your perspective -- simply knowing you are not alone is often enough to allay many fears you may have.

And even if it isn't, talking with a trusted senior colleague will allow you to consolidate and reflect upon your concerns, while receiving constructive feedback to help you on your development journey. Similarly, mentoring your juniors will affirm your skill and knowledge while possibly providing parallels between their own fears and your own.

Taking the next step.

Your value is only limited by how much of it your prescribe yourself. By recognising, embracing, and overcoming your self-doubts, you elevate yourself both professionally and personally. Ultimately, it's up to you to accept that you're ready and take the next step of your career.

Got any other tips? Share them below.

Stop using for loops. Here's why.

Jack Shen — Mon, 02 Mar 2020 04:48:55 +0000

It is ~~current year~~ new Date().getFullYear(), and still I still see many JavaScript devs using and even recommending the use of for loops. You yourself may even be using for loops on a regularly basis. Here's why you shouldn't and what you should use instead.

Why shouldn't you use `for` loops?

for loops and their usage are largely a holdover from imperative languages, in particular C-likes and their derivatives. While they are quite versatile, they suffer many flaws.

Let's start with clarity. Let's face it, for loops just don't make the prettiest blocks of code, and only increase in ugliness the larger they get. In complex algorithms, they can quickly become enigmatic, nigh unreadable save for commenting. And while comments are an expected courtesy, there's a reason why bad documentation is such a frequent joke amongst devs.

Secondly, for loops increase the chance of unwanted side effects. for loops--and while loops-- are what's known as control statements, meaning they must be placed inside of a function and can not be used as standalones. This inherently increases the chance you'll end up manipulating variables outside of the loop's scope. Unfortunately, this clashes with more modern programming paradigms in functional programming, specifically precluding anything involving for loops from being a pure function.

Thirdly, for the exact same reason as above, for loops are prone to requiring mutation in some form. A lot of the time, this is also unavoidable because all for loops can really do is facilitate iteration. By themselves, for loops are kinda useless, which means you have to declare a variable to mutate, or mutate the original array. Again, this is at odds with functional programming principles.

What should you use instead?

As of ES6, Array.prototype methods have been introduced that make for loops obsolete in most ways.

Let's recap the reasons against for loops and how these methods solve them.

1. Lack of clarity.

In ideal circumstances, good code should be self-evident and self-explanatory. Array methods bring us closer to that ideal, they are almost descriptive enough to read as some sort of "shorthand natural language".

myArray.every(value => value > 40);
// Check every element of myArray is greater than 40.

myArray.filter(word => word.length > 6);
// Filter out every element in myArray longer than 6 characters.

myArray.sort();
// Sort myArray (lol)

Contrast these with their for loop equivalents:

const checkEveryValueGreaterThanForty = myArray => {
  for (let i = 0; i < myArray.length; i++) {
    if (myArray[i] <= 40) return false;
  }
  return true;
};

const checkEveryWordLongerThanSix = myArray => {
  for (let i = 0; i < myArray.length; i++) {
    if (myArray[i].length <= 6) return false;
  }
  return true;
};

// Most devs already know to use Array.prototype.sort(), consider this
// a more extreme example of what enigmatic for loop code can look like
function bubbleSort(myArray) {
  let isSorted = false;
  while (!isSorted) {
    isSorted = true;
    for (let i = 1; i < myArray.length; i++) {
      if (myArray[i - 1] > myArray[i]) {
        isSorted = false;
        [myArray[i - 1], myArray[i]] = [myArray[i], myArray[i - 1]];
      }
    }
  }
  return myArray;
}

Yikes. As you can see, these are ugly, long, and you actually have to spend time reading through the entire thing to figure out what's going on. Using array methods cut them down into a single beautiful line with an immediately recognisable purpose.

2. Side effects.

Many array methods are higher-order-functions -- they take in a callback function as one of their parameters. By explicitly calling array instance methods, iteration can be performed in something like a self-enclosed scope. You may have already noticed this in the previous examples, where loops inside functions were replaced by one-line methods.

3. Possible mutation.

Accessor methods are handy for modifying an array, and iteration methods replace most if not all functionality provided by for loops without touching the original array.

const doubleArrayValues = myArray => {
  const newArray = [];
  for (let i = 0; i < myArray.length; i++) {
    newArray[i] = myArray[i] * 2;
  }
  return newArray;
};

Notice in this example we've had to create a new variable newArray. This is necessary if we do not wish to change myArray, but even still, we must mutate newArray in order for the algorithm to work. What if we tried an array method?

myArray.map(value => value * 2);

We have eliminated the need for a new variable without compromising our desire to keep the original array unchanged.

In addition, there are mutator methods such as Array.prototype.pop(), Array.prototype.sort(), and Array.prototype.splice(). What this provides, especially when chaining methods, is greater flexibility in how you approach an algorithm.

That's not to say you can't mutate using non-mutator methods. However, you'd have to go out of your way to mutate the original array:

myArray.forEach((element, index) => {
  myArray[index] = element * 2;
});

Kinda defeats the purpose, but once again, you have the flexibility to do so if you really want to for some reason (you shouldn't).

The bottom line.

Array methods, when applied properly, are incredibly powerful and render for loops all but obsolete. It is possible to write very pure functions, without mutating any arrays or objects and without creating any variables or constants. For example, the popular Combination Sum interview question can be purely solved using only recursion and array methods.

// Array.prototype.reduce() is incredibly powerful when applied correctly

const combinationSum = (sum, numbers) =>
  numbers
    .filter(filterNumber => filterNumber <= sum)
    .reduce((path, currNumber) => {
      if (currNumber === sum) return [...path, [currNumber]];
      else
        return combinationSum(sum - currNumber, numbers).reduce(
          (allCombos, currCombo) => [...allCombos, [currNumber, ...currCombo]],
          path
        );
    }, []);

Of course, for loops are still around for a reason. Perhaps you have a specific application where it's not appropriate to, or just can't use array methods. In those cases, take care to give your counter a proper name if you intend to use it -- something like let index = 0 instead of just let i = 0. In any other case, try your hand with array methods.

A simple, practical tip to improve performance in the front-end.

Jack Shen — Mon, 24 Feb 2020 04:45:56 +0000

W3C maintains a list of JavaScript best practices, one of which is an imperative to "keep DOM access to a minimum". That's all well and good, but what does it really mean in more practical terms? Let's explore this with a simple example.

Let's say for stylistic purposes, I would like my website to have an element I can drag around inside the window. The script might look something like this:

const draggable = document.getElementById("draggable");

let isDragging = false;
let offsets = {};

// Start drag
draggable.addEventListener("mousedown", () => {
  isDragging = true;
  /* Get offset between mouse and element position here */
});

// Drag
document.addEventListener("mousemove", () => {
  if (!isDragging) return;
  /* Update top and left styles here */
});

// Stop drag
document.addEventListener("mouseup", () => {
  if (isDragging) isDragging = false;
});

In order for the element to be draggable around and over other elements in the same window, it would need these CSS style properties:

<div
  id="draggable"
  style="display: absolute; left: 300px; top: 500px"
></div>

The script would work by updating the left and top properties whenever the mousemove event is fired.

How might you get the current left and top property values, in order to perform the necessary calculations? You might be tempted to directly access them through the element's styling, with draggable.style.left or getComputedStyles(draggable).top.

This is a trick question. You should avoid accessing the DOM at all.

Here's a better approach:

const draggableCoords = { left: 300, top: 500 };
const draggable = document.getElementById("draggable");

draggable.style.left = `${draggableCoords.left}px`;
draggable.style.top = `${draggableCoords.top}px`;

// The rest of the code

What I did here was set the source of truth for draggable's left and top styles inside the script. By making JavaScript the foundation of my application, the HTML is now dependent on the script, and not the other way around. This nicely avoids having to access the DOM altogether.

The benefit of this approach is immediately obvious. While the performance benefits for my example aren't significant, it is clear how the computational advantage would be magnified in a complex, production-scale project.

One thing you must keep in mind when refactoring code.

Jack Shen — Mon, 17 Feb 2020 04:24:30 +0000

Recently, I found myself building a JavaScript-based animation within a front-end project I was working on. Here's a simplified version of the code:

const animate = () => {
  // some sort of DOM update here
  requestAnimationFrame(animate);
}

animate();

After a short while, I decided I wanted an FPS counter -- just something presentational that shows inside the browser. My first thought was to write a similar function, but for updating an FPS value shown on the page:

const ONE_SECOND = 1000;
let fps = 0;

const getFPS = startTime => {
  window.requestAnimationFrame(() => {
    const currentTime = performance.now();
    if (currentTime - startTime < ONE_SECOND) {
      fps++;
      getFPS(startTime);
    } else {
      fpsDisplay.innerText = `${fps} FPS`;
      fps = 0;
      getFPS(currentTime);
    }
  });
};

getFPS(performance.now());

There is nothing seriously wrong with this approach. It updates properly and produces the correct value.

However, I quickly realised this solution was far from ideal: a second use of requestAnimationFrame would make no sense if my project had animation-heavy code.

In fact, it was superfluous given that animate() already included a requestAnimationFrame call. I could achieve the same functionality by refactoring my getFPS() function so that it shared the same call:

const ONE_SECOND = 1000;
let fps = 0;

const animate = () => {
  // some sort of DOM update here
  fps++;
  requestAnimationFrame(animate);
}

const  getFPS = () => {
  setInterval(() => {
    fpsDisplay.innerText = `${fps} FPS`;
    fps = 0;
  }, ONE_SECOND);
};

animate();
getFPS();

This is what's called colocating. The principle of colocation is simple: group like code with one another.

A good analogy for the above example is measuring the speed of a car. It would be an absurd waste of time and money to purchase a second car, match its speed with the first, and use a radar gun on the second. In comparison, the colocated code would be like installing a speedometer in the first car.

Colocating, in addition to decreasing code length and increasing readability, boasts significant computational savings. By refactoring the bulk of getFPS() inside of animate(), only a single instance of requestAnimationFrame() was needed.

There are a myriad of benefits to colocation, including but not limited to easier readability and maintainability, better predictability, improved performance, and closer adherence to DRY principles.