DEV Community: Glenn Faison

JavaScript/TypeScript Development and Phantom Bugs: When Code Magically Works (or Fails)

Glenn Faison — Wed, 11 Jun 2025 19:31:34 +0000

Every developer has a story. You’re deep into debugging, tearing your hair out over a bug that defies logic. You step through the code, variables show impossible values, and execution paths twist unexpectedly. Then, you restart your development server, or maybe even your entire machine, and poof! The bug is gone. Even more perplexing, sometimes simply adding a console.log statement makes the issue vanish.

This isn’t just frustrating; it chips away at your confidence and leaves you wondering: was it ever really a bug, or just a ghost in the machine?

A Recent Encounter with the Unexplainable

I recently hit one such wall while working on a Next.js application, developing a higher-order component for text editing. The component withTextEditing wraps other React components, adding content editing functionality and integrating with a state management system via useReducer and TanStack Query.

Here’s a simplified version of the TypeScript code:

// Example: withTextEditing HOC
export function withTextEditing<Tag extends Extract<ComponentTag, "header1" | "header2" | "header3" | "paragraph" | "inline-text" | "button">>(
  WrappedComponent: React.ComponentType<ComponentProps<Tag> & WrappedComponentProps>
) {
  return function ContentEditableComponent(props: ComponentProps<Tag>) {
    // Line 1: State initialization
    const [contentEditable, setContentEditable] = React.useState<boolean>(false)

    // Line 2: Destructuring props
    const { component, ...otherProps } = props

    // Line 3: Accessing a nested property
    const isConnected = !!component.attributes?.__data_source__
    return (
      <WrappedComponent
        component={component}
        contentEditable={contentEditable}
        suppressContentEditableWarning
        {...otherProps}
      >
      </WrappedComponent>
    )
  }
}

While stepping through ContentEditableComponent in the browser's debugger, I observed truly baffling behavior:

After Line 2 (the destructuring): The component variable was undefined, even though props.component clearly held a valid object. This directly contradicts how JavaScript destructuring works, where a variable should be assigned the value present at the time of destructuring.
After Line 3 (accessing isConnected): Even more astonishingly, the component variable (which was const!) seemed to change its value. It was no longer undefined; it now held the value of props.component.attributes. A const variable being re-assigned is fundamentally impossible in JavaScript under normal execution.
This is the kind of situation that sends you into a debugging spiral. How can a const change? How can destructuring fail so spectacularly?

The “Magic Fixes” We Rely On

Often, faced with such spectral bugs, developers resort to a few common “fixes” that don’t involve changing the code itself:

The “Sleep On It” Fix: You go to bed, utterly frustrated. You wake up, run the exact same code, and it magically works. Did the computer clear some cache? Did the moon align differently?
The “Log it and Shame it”: You add console.log statements throughout your code to trace variable values and execution flow. Suddenly, the bug disappears.
The Restart Ritual: Restarting your development server, your browser, your IDE, or even your entire operating system.

Why Does This Happen? The Suspects (According to Me)

While these “magic fixes” feel supernatural, I want to believe they hint at underlying technical complexities and inconsistencies in my code OR development environments. A quick web search (probably not deep enough) doesn’t really point me towards anything useful concerning Javascript or TypeScript, but I have a few suspects (other than that I routinely write code with magical bugs):

Debugger and Sourcemap Misalignment: Modern JavaScript/TypeScript projects are heavily transpiled and bundled. Debuggers rely on sourcemaps to map the running, minified code back to their original source. If these sourcemaps are incorrect, out of date, or if the debugger itself has quirks, the execution pointer or variable values displayed in the debugger can be misleading or simply wrong.
Caching Issues: Build tools (Webpack, Next.js internal caching), browser caches, IDEs handling file versions… Maybe they sometimes hold onto stale versions of code or assets, leading to unexpected behavior until a hard refresh or cache clear.
Subtle Race Conditions and Timing?: In highly asynchronous applications, tiny variations in execution timing can determine whether a race condition manifests or not. A restart, a console.log, or even system reload can subtly alter these timings, making a bug appear or disappear.
Environmental Factors: I often wonder if my environment increases my chances of facing such flakey issues; high temperatures, moisture, etc
Long System Uptime/Memory Leaks: A system running for days or weeks might accumulate memory leaks or other OS-level instabilities that affect application performance or debugging tools.
Overheating: An overheated CPU or GPU can lead to unstable system behavior, potentially affecting compiler or runtime stability.

A Call to the JavaScript/TypeScript Community

I’m curious to hear from other developers:

How often do you encounter these “phantom bugs” or “magic fixes” in your JavaScript/TypeScript development? Is it a rare occurrence, or a frustratingly regular part of your workflow?
Do you consider them a major hindrance to productivity and confidence, or just a minor annoyance that you quickly circumvent?
What’s your go-to immediate solution when you suspect such an issue? (e.g., restart dev server, clear browser cache, restart browser, restart OS, add console.log?)
Have you noticed any specific conditions under which these issues are more likely to occur? (e.g., specific library versions, long running processes, low disk space, specific hardware configurations, heavy network activity affecting local tools?)

Let’s discuss these elusive bugs, why they happen, and share our strategies for navigating the often-magical world of JavaScript/TypeScript development.

Your First/Last Name Fields Are Broken for Half the World

Glenn Faison — Thu, 18 Jul 2024 15:10:08 +0000

Most identity-verification and onboarding forms still assume Western "first name + last name" conventions, systematically rejecting or mangling the names of hundreds of millions of people worldwide.

I want to talk about my frustrations with identification in tech, the kinds of issues that I've encountered, and some suggestions to fix it.

The Self-imposed Limitations of Current Systems

Our current systems tend to ask people for a "first name" and "last name", and our systems (computerized or not) tend to do some funny form of composition in order to generate a full name. In my opinion, they could just ask the foremost authority: the person who answers to those names.

While this arbitrary composition works well for many cases, there is a significant enough population for whom it doesn't. The system ends up referring to its users in ways that are less than satisfactory.

Something that should be obvious is that everybody has a full name. This is the basic common ground our systems should start from. If the system actually requires it, just ask the user for their names as they are on the birth certificate, and they will give you that. However, a full name in no way tells you what the user would like you to call them, and how they would like to be called also depends on who is doing the calling.

Cultural Differences in Naming Conventions

Naming conventions and formats vary conspicuously across different cultures. For example, some cultures have the notion of a "family name", a name that every member of the family shares. That family name may come in the first or last position or in the middle, whatever it is. Some people may have 4 names, 3, or just 2.

An interesting case study would be Cameroon, where there is a French-speaking population and an English-speaking one, divided in roughly a 70:30 ratio, respectively. For most of the anglophone citizens, the family name, which Europeans or Americans would refer to as "last name", tends to come last when they write out their full names. Conversely, for the Francophones, this "last name" will generally come first.

And I'm actually using these terms loosely because they will mean different things in different cultures, they may or may not even exist in certain cultures. Each name has a different significance and label to it, depending on the culture where it is from. There are cultures where the last name of a person is their father's name or mother's name with a certain suffix. For some others, the last name is a tribute to the namee's godparent (or just a significant person to the namee's parents). The possible quirks in naming are very many.

The Discretion of the User

Another thing I've noticed is that for most of the systems that request first and last names from users, these names actually don't matter to the system. They are not unique in the system. They are not usually tied to identification. Usually, what the system needs, is a way to refer to the user in communications between the system and user. This issue can be solved by requesting a username.

There exist a few cases where the system will need to publicly refer to a user. The system should also ask the user to give that information to them, rather than arbitrarily spinning something up. If I get a certification from some system and they make a public post about it or print out a certificate, I would like to either choose the name on the certificate or have my actual full name on it, in the right order.

A Case Study: Cameroon

In my country, the majority is French-speaking, and in general, their last names or family names come first in the order of names. Across the country, the tendency is that in public services, the system will ask for your names in a disjointed first-name-and-last-name fashion, and the majority of the processes are run according to the French-speaking system. The result is many cases of anglophone citizens having name mismatches between their birth certificates and public documents.

Right now, what happens, roughly speaking, is that for some anglophone people, public systems will have their last names in the first position, and their first names in the last position. It could range from mildly displeasing to inconvenient if the order of your names is botched on a public document. It's a failure, but it is what it is.

I observed that some anglophone citizens in these situations will choose to enter all their names in either the slot for "first name" or the slot for "last name" on any form. They just enter their full names in one of these slots and leave the other empty. However, another name composition issue comes in where these systems now have your full name, with "not applicable" or "N/A" as a prefix or suffix. This is a little better but still not ideal, the only benefit being that your names are in the right order.

Personal Experience with LinkedIn Verification

With the previous context, let's move on to my passport and how putting my full name in the "last name" slot and leaving the "first name" slot empty became a problem.

So on LinkedIn, I've been trying to get my profile verified, to increase my success in the job market. LinkedIn uses a third party called Persona for verification, and Persona requires that I scan my international passport in order to verify my information. That makes sense.

However, they absolutely require a first name and they absolutely require a last name. So what happens is that when I scan my passport, the "first name" is empty. The "last name" has my full name. Persona tells me the passport is invalid because they cannot see a first name and unfortunately, there's no way I can edit it to add that first name in. So what happens? I cannot complete my verification. The only thing I'm going to have to do is reach out to their customer support.

The Quirks of Social Media Names

I created a social media account and I wanted my display name to be "Evil Genius", I decided to enter "Evil" as "first name" and "Genius" as "last name", hoping that they're going to compose it as "Evil Genius" as opposed to "Genius Evil", "Evil", or "Genius". I wasn't warned that it was up to their discretion to pick what name to call me or show other users in notifications or posts.

Imagine my disappointment when I opened the page, just to be greeted by "Hello, Evil". Doesn't sound as funny as "Evil Genius", does it?

Suggestions for Improvement

All these issues with naming conventions being decided by the systems rather than by the user hurt people's sensitivities, cause issues with integrating identification between different systems, and just make the systems inconvenient for users. I would suggest:

just sticking with asking for usernames
asking the user how they would like to be referred to in public communications and in bilateral dealings with the system
If the user's real full name is required, ask for that, rather than composing something up.

This would save the operators of the system the trouble of having to compose these names, along with the inconveniences discussed above. The feelings and the happiness of the users are protected, and everybody is happy.

A Good Reason to NOT Copy and Paste Code

Glenn Faison — Thu, 11 Nov 2021 20:04:54 +0000

Many beginners are advised to “type code yourself instead of copy-pasting” because it enables one to internalize the process and the code more quickly. But as programmers gain more experience and attain the level where they need to get things done rather than ensure they learn, they get comfortable with CTRL+C, CTRL+V from Stack Overflow and other sources. As an experienced developer, I recently saw first-hand why I should never copy and paste any code I found online (or anywhere, for that matter)

Consider the code below (see https://certitude.consulting/blog/en/invisible-backdoor/):

const [ ENV_PROD, ENV_DEV ] = [ 'PRODUCTION', 'DEVELOPMENT'];
const environment = 'PRODUCTION';
function isUserAdmin(user) {
    if(environmentǃ=ENV_PROD){
        return true;
    }
    return false;
}
isUserAdmin();

Looks benign, right? And we would expect this code to always return false, yes? Unfortunately, no. Now open a browser console, copy this code, and paste in the console. You may be shocked that it returns true.

To cut the long story short, what looks like a loose inequality check on line #4, is deceptively an assignment operation, which reads like (environmentǃ = ENV_PROD)! In JavaScript, assignment operations return the assigned value, which in this case is truthy (will be treated as true wherever a boolean value is expected)

But isn’t environmentǃ an invalid variable name in JavaScript, you ask? It’s complicated. You’d be right to say an exclamation sign cannot be part of a variable name. However, the ǃ you see there is in fact not the everyday exclamation sign you know. It’s an obscure character that happens to be accepted as regular text by the JavaScript interpreter, and thus can be a valid part of a variable name

So while a programmer looks at line #4 and sees environment != ENV_PROD, the JavaScript interpreter sees environmentǃ = ENV_PROD

There! I hope this is a compelling enough reason to not take copy-pasted code lightly. And I hope you see how typing code snippets yourself can save you from bugs that hide in plain sight!