Tari Ibaba is a software developer with years of experience building websites and apps. He has written extensively on a wide range of programming topics and has created dozens of apps and open-source libraries.
With the immutable swap worked out, our game plan is pretty straightforward:
For each item i in 0..n, immutably select an index in 0..i to swap with i for each i in 0..n
Loop through the array again and immutably swap each element with its assigned swapping pair.
For #1 we can easily use map() to create an array with the new random positions for every index:
JavaScriptCopied!
const getShuffledPosition = (arr) => {
return [...Array(arr.length)].map((_, i) =>
Math.floor(Math.random() * (i + 1))
);
};
/* [0, 2, 0, 1]
swap item at:
1. index 0 with index 0
2. index 1 with index 2
3. index 2 with index 0
4. index 3 with index 1
*/
getShuffledPosition(['🔵', '🔴', '🟡', '🟢']);
getShuffledPosition(['🔵', '🔴', '🟡', '🟢']); // [0, 1, 1, 3]
getShuffledPosition(['🔵', '🔴', '🟡', '🟢']); // [0, 0, 2, 1]
What about #2?
We’re outputting an array, but we can’t use map again because the transformation at each step depends on the full array and not just the current element.
Just like you can always write a recursive algorithm as a loop, you can write every imperative iteration as a brilliant single-statement chain of array methods.
JavaScript has come a long way in the past 10 years with brand new feature upgrades in each one.
Still remember when we created classes like this?
JavaScriptCopied!
function Car(make, model) {
this.make = make;
this.model = model;
}
// And had to join strings like this
Car.prototype.drive = function() {
console.log("Vroom! This " + this.make +
" " + this.model + " is driving!");
};
Yeah, a lot has changed!
Let’s take a look at the 7 most significant features that arrived in ES10 (2019); and see the ones you missed.
1. Modularization on the fly: Dynamic imports
The ES10 year was the awesome year when import could now act as function, like require(). An async function.
Keeping imports at the top-level was no longer a must; We could now easily resolve the module’s name at compile time.
Loading modules optionally and only when absolutely needed for high-flying performance…
JavaScriptCopied!
async function asyncFunc() {
if (condition) {
const giganticModule = await import('./gigantic-module');
}
}
Loading modules based on user or variable input…
JavaScriptCopied!
import minimist from 'minimist';
const argv = minimist(process.argv.slice(2));
viewModule(argv.name);
async function viewModule(name) {
const module = await import(name);
console.log(Object.keys(module));
}
It’s also great for using ES modules that no longer support require():
JavaScriptCopied!
// ❌ require() of ES modules is not supported
const chalk = require('chalk');
console.log(chalk.blue('Coding Beauty'));
(async () => {
// ✅ Runs successfully
const chalk = (await import('chalk')).default;
console.log(chalk.blue('Coding Beauty'));
})();
2. Flattening the curve
flat() and flatMap() gave much cleaner ways to easily flatten multidimensional arrays.
Eradicating the need for painful array-looping flattening code:
Yeah, and we didn’t even add any checks for wrong types and edge cases. And it goes without saying that I spent more than a few minutes debugging this…
And just imagine how it would be if we add multi-dimensional array support like in numpy:
Where did we come from on the call stack? Let’s trace() our steps back!
Fantastic for debugging:
JavaScriptCopied!
function coder() {
goodCoder();
}
function goodCoder() {
greatCoder();
}
function greatCoder() {
greatSuperMegaGeniusCoder();
}
function greatSuperMegaGeniusCoder() {
console.log(
"You only see the greatness now, but it wasn't always like this!"
);
console.log(
'We\'ve been coding for generations -- let me show you...'
);
console.trace();
}
coder();
3. count()
console.count() logs the number of times that the current call to count() has been executed.
Too indirect and recursive a definition for me! You may need to see an example to really get it…
They work together to precisely measure how long a task takes.
57 microseconds, 11 seconds, 50 years? No problem.
time() – start the timer.
timeLog() – how far has it gone?
timeEnd() – stop the timer.
Let’s use them to compare the speed of all the famous JavaScript loop types.
JavaScriptCopied!
console.time('for');
for (let i; i < 1000; i++) {
for (let i = 0; i < arr.length; i++);
}
console.timeLog('for');
for (let i; i < 1000000; i++) {
for (let i = 0; i < arr.length; i++);
}
console.timeEnd('for');
const arr1000 = [...Array(1000)];
const arr1000000 = [...Array(1000000)];
console.time('for of');
for (const item of arr1000);
console.timeLog('for of');
for (const item of arr1000000);
console.timeEnd('for of');
console.time('forEach');
arr1000.forEach(() => {});
console.timeLog('forEach');
arr1000000.forEach(() => {});
console.timeEnd('forEach');
for starts out slow but it destroys the other as the list grows…
6. group() + groupCollapsed() + groupEnd()
Another great combo for grouping a bunch of console messages together; visually with indentation and functionally with a UI expander.
group() – adds 1 further grouping level.
groupCollapsed() – like group() but group starts out collapsed.
groupEnd() – go back to previous grouping level.
JavaScriptCopied!
console.log('What can we do?');
console.group('Abilities');
console.log('Run👟 - solid HIIT stuff');
console.groupCollapsed('Code💻');
console.log('JavaScript');
console.log('Python');
console.log('etc of course');
console.groupEnd();
console.log('Eat🍉 - not junk tho...');
Just indentation on Node – so groupCollapsed() has no use here.
7. dir()
dir() is a genius way to inspect an object in the console and see ALL it’s properties and methods.
Actually just like console.log()? 🤔 But console.dir() is specially designed for this particular purpose.
But watch what happens when you log() vs dir() HTML element objects:
log() shows it as a HTML tag hierarchy, but dir() shows it as an object with every single property it has and could ever dream of having.
Final thoughts
So they’re plenty of console methods apart from console.log(). Some of them spice things up in the console UI with better visualization; others are formidable tools for debugging and performance testing.
As expected VS Code has the basic zoom in & out in every text editor.
But they’re some hidden gems to quickly level up your zoom game once found.
Dig into the command palette and you’ll find Font zooming – zooming just the code without the rest of the editor UI.
Pretty cool – did you know about this?
Zoom with scroll
Easily adjust zoom with Ctrl + mouse scroll:
After turning on the Editor: Mouse Wheel Zoom setting:
Powerful zoom extensions
The VS marketplace is packed full with powerful, capable extensions that boost various aspects of your workflow.
For zooming, there’s none better to start with than Zoom Bar:
The first thing you notice right away after install: the exact zoom level now shows up in the status bar:
+ and - buttons are obviously to zoom in and out.
Select the zoom percentage and this dialog appears:
Tons of pre-defined zoom options to choose from.
Just as you can see your exact zoom, you can also set it precisely with Input zoom:
Why not? 😏
And what about zooming just the terminal font?
There’s an extension for that too:
At the bottom-right you can clearly see the displayed terminal font.
My status bar has gotten semi-painfully humongous now, but it’s clear how useful these upgrades are… They were always great for taking screenshots when I used a 768p PC.
An of course: laser-precise focus on specific lines, syntax, and details without straining your eyes. Or whatever other reason you need to zoom for.
function c(a) {
return a / 13490190;
}
const b = c(40075);
console.log(p); // 0.002970677210624906
All we see is a calculation. We have no idea what those numbers and variables mean in the bigger picture of the codebase.
It’s a mystery. It’s magic to everyone apart from the developer who wrote the code.
We can’t possibly make any contributions to this code; we’re stuck.
But what if our dev had looked beyond code that merely works and also focused on communicating the full story of the code?
At the very least they would have given those variables far more descriptive names to explain the context:
JavaScriptCopied!
function calculateSpeedstersTime(distance) {
return distance / 13490190;
}
const time = calculateSpeedstersTime(40075);
console.log(time); // 0.002970677210624906
This small change vastly improves the code’s readability. Now you have a general idea of what’s going on.
But there are still mysteries we must solve.
It’ll still take us a little bit to realize 13490190 is speed — but how much speed?. And we know 40075 is a distance, but why 40075 of all the numbers?
For maximum readability we replace these magic numbers with variables with explanatory names
Now you understand every single thing this code does at a glance.
Understanding at a glance is always the goal.
Even with readable code…
Anyone can understand this TS code here; but there’s a serious issue that could easily lead us to hours-long bug hunting.
Can you spot it?
JavaScriptCopied!
class Person {
state: string;
name: string;
greet() {
console.log(`Hey I'm ${this.name}`);
}
eatFood() {
if (this.state === 'tired') {
this.state = 'fresh';
}
}
exercise() {
if (this.state === 'fresh') {
this.state = 'tired';
}
}
}
Problem: We’re lousily checking the state for equality and assigning with magic strings again and again.
Repeating ourselves, and allow a mere typo to break this code in the future. And the bug won’t always be easy to spot like it would be in this tiny code.
That’s why we have union types; similar to enums in TypeScript and other languages.
JavaScriptCopied!
class Person {
name: string;
// ✅ Only 3 values, not infinite
state: 'tired' | 'fresh' | 'sleepy';
greet() {
console.log(`Hey I'm ${this.name}`);
}
eatFood() {
if (this.state === 'tired') {
this.state = 'fresh';
}
}
exercise() {
// ✅ Typo: Error thrown
if (this.state === 'fres') {
this.state = 'tired';
}
}
}
Now 'tired' and 'fresh' are no longer random string literals. They’re now registered values of a pre-defined type.
And this is one of the powerful advantages TypeScript has over regular JS.
We even have this exact type of issue in a Dart codebase I’m part of. We’ve used the same magic strings like 10 times each.
But Dart only has enums and it’s not so easy to convert from magic strings to enums like we did here with union types. So we better refactor before it comes back to bite us!
The only thing that remains constant…
Keep using magic values and they keep spreading throughout the codebase across more and more files.
Replacing them is a chore.
JavaScriptCopied!
// email.js
export function sendEmail({ username }) {
emailApi.send({
title: `Hi ${username ?? 'User'}`,
role: 'user' // Union type value
});
}
// user-info.jsx
export function UserInfo({ user }) {
return (
<div>
<div>Name: {user.name ?? 'User'}</div>
<div>Email: {user.email}</div>
</div>
);
}
What happens when you want to change the default user name to something else but you’ve got the 'User' magic string in over 15 files?
Even Find and Replace will be tricky because they could be other strings with the same value but no relation.
We can fix this issue by creating a separate global config file containing app-wide values like this:
JavaScriptCopied!
// app-values.js
export const DEFAULT_USERNAME = 'User'; // ✅ Only one place to change
// email.js
import { DEFAULT_USERNAME } from './app-values';
export function sendEmail({ username, role }) {
emailApi.send({
message: `Hi ${username ?? DEFAULT_USERNAME}`, // ✅
role: role ?? 'user',
});
}
// user-info.jsx
import { DEFAULT_USERNAME } from './app-values';
export default function UserInfo({ user }) {
return (
<div>
<div>Name: {user.name ?? DEFAULT_USERNAME}</div> // ✅
<div>Email: {user.email}</div>
</div>
);
}
Final thoughts
Banish magic numbers and strings from your JavaScript code for clarity, maintainability, and efficiency.
By adopting these practices you pave the way for code that is not only functional but also self-documenting, collaborative, and resilient in the face of change.
Like the previous two possible white-space values, pre-line works in the same way when you set the innerHTML or innerText property of the element to a string using JavaScript.