Journal
Writing my own utility methods
After the back and forth in the previous post, I ended up writing a few of my own utility methods instead of adding another dependency, like lodash. The main methods I needed right now for Cushion’s onboarding (and all future forms that interact with the API) are clone
, defaults
, and pick
. These will let me set up the form data as a new reference-free payload, default any missing values, and send only specific data to the API.
As I wrote these methods, I realized the real value in writing them—I can design the methods specifically for my needs. This means that for the clone
method, my version is a deep clone because that’s all I’ll ever need. If I need a shallow clone, I’d simply use a spread or Object.assign
.
A better example is my pick
method. In addition to providing an array of keys to return, I allow passing an object with an additional array of keys to support deep picking. For example:
const A = {
a: "a",
b: "b",
c: { one: 1, two: 2, three: 3 }
};
console.log(pick(A, ["a", {c: ["one", "three"]}]));
// outputs { a: "a", c: { one: 1, three: 3 }};
In Cushion’s onboarding, deep picking lets me extract specific preferences to update when sending the user to the API rather than sending the entire nested preferences data object. I believe lodash support deep picking as well, but using a path string, like foo.bar.baz
. That’s fine, but in my case, it’s much more useful to specify a single nested object with an array of its keys rather than each full path individually.
One other benefit of writing these methods myself is that it’s actually a good coding exercise. While it’s an absolute dream to build fancy animated pages for Stripe all day, the part of me that grew up loving logic puzzles also loves writing these methods and the tests for them. Sure, the challenge of coding an animation that might not even be possible on the web is a thrill, but that makes the straightforwardness of TDD so relaxing—write a failing test, make it pass, optimize if you want. I can’t do this full-time, though. At some point, my creative side starts itching and I need to return to design. It’s a cycle.