The following is a transcript of the latest episode on the Professional JavaScript podcast.
Tagline
Hey everyone and welcome to the first episode of Professional JavaScript, the podcast for learning how to grow as a JavaScript developer in a professional environment where the problems are greater than just another todo list tutorial.
Each week, I, Michael Mangialardi, will be sharing what I’m learning as I write JavaScript code on a professional team. I’ll cover tips, tricks, technologies, and other goodies that you don’t always get when consuming other online resources.
Today’s Episode
In today’s episode, I’ll be telling you why you should “use the source” like Luke Skywalker used the force.
This is a timely episode. My wife and I just recently got a Disney+ subscription and watched the entire Skywalker Saga from start to finish.
It was my wife’s first time watching the series…I know 😱
Since watching the series, the talk of the house has been full of Star Wars references such as “use the force.”
While my wife and I have been saying “use the force,” I was reminded of the value of telling myself to “use the source.”
You see, the dependencies of a JavaScript codebase can sometimes seem like the
dark side. It’s cold and mysterious, and if you expand your
node_modules directory, you might get blasted by Emperor
Palpatine.
There is some good reason for that. After all, there can be a lot of packages
within your node_modules folder.
At the end of the day, we almost always use someone else’s code to build things. There is enough to be overwhelmed with given all the frameworks, utilities, and tools in the JavaScript ecosystem.
However, the way to grow as a professional JavaScript developer is to think about the “why” behind your code, not just the “how.”
Using the source is a great way to find out “why” a shareable package was created in the first place.
A package is shared when it solves a common problem.
Reading the README often provides a good sense as to what the
problem is and how the package solves it.
Digging into the source code reveals “how” the problem was solved.
You may not need to write all the code out yourself to solve the problem (since you can use the shared package), but you may need to peak into the source code to understand how it solves the problem.
As you explore how packages solve problems, you will gather ideas of how you can take bits and pieces of the solutions and apply them to unique problems that you come across as a professional developer.
Think of a shared package as a completed Lego set and the source code as the Lego.
For example, as part of my series on design tokens, I wrote an article on using a package called Style Dictionary to generate HSL color shades.
Style Dictionary is a shared package that can take a JSON file representing design specifications (also called design tokens) and transform them into a platform deliverable.
My article was on leveraging Style Dictionary to transform a JSON file with design specifications of “primary,” “secondary,” and “error” colors and exporting those colors, along with a range of shades, as CSS variables.
Before, Style Dictionary seemed like magic. I ran the CLI tool and it transformed a JSON file into CSS variables after I sprinkled some settings in a config file.
After getting stuck on how to generate shades from a single color, I dove into the source code.
It turns out that the transformations Style Dictionary did on colors were nothing more than a thin wrapper around a small JavaScript package for manipulating colors called tinycolor.
When I was not able to find a pre-defined way to use Style Dictionary to
transform a single color into shades, I was able to go straight to the
tinycolor library to solve the problem.
If I only knew about the Lego set, I would never have known about the value of the Lego. If I never looked into the source code, I would have never learned about how I could extract a portion of the code to solve a different problem.
Use the source.
I’ll conclude this episode with a final tip as well as a challenge.
My tip is to start at the entry file of the source code and work your way through it. It can be confusing if you pick a random file to examine. However, starting from the beginning of the problem and working your way through the solution will help demystify the source. Treat it like a code review, read comments, and parse out what is relevant versus irrelevant.
My challenge is to use the source this week on any codebase that you touch.
Outro
Thanks for tuning in for this week’s episode of Professional JavaScript. Be sure to like, subscribe, and head over to my blog www.michaelmang.dev/blog to learn with me.
Cheers! 🎉
