DEV Community: Fredi Manuel Barraza Hernández

Building a ChemDraw clone with DDD (Part III): Interacting with Atoms and Bonds

Fredi Manuel Barraza Hernández — Sun, 29 Mar 2026 20:46:41 +0000

For a chemical draw to be truly functional, drawing isn't enough; the user must be able to interact with every element on the screen. Selecting an atom is intuitive, but how do you select a chemical bond (a line segment) with pixel-perfect precision? In this post, I'll break down the mathematical process and the challenges of implementing this collision engine.

Selecting Atoms: The Easy Path

Detecting if the cursor is over an atom is the ideal scenario. Since our domain already stores the (x, y) coordinates of each node, the solution is applying Euclidean distance.

We calculate the separation between the mouse (P) and each atom (A) with the formula:

\sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2}

If the distance is shorter than a defined search radius, the atom is considered a candidate. To ensure precision, if multiple atoms are within range, we always select the one with the minimum distance.

class Molecule {
  // ...
  private findClosestAtom(
    x: number,
    y: number,
    radius: number,
  ): { atom: Atom; distance: number } | null {
    const candidates = [...this._atoms.values()]
      .map((atom) => ({
        atom,
        distance: Math.sqrt(Math.pow(atom.x - x, 2) + Math.pow(atom.y - y, 2)),
      }))
      .filter(({ distance }) => distance <= radius)
      .sort((a, b) => a.distance - b.distance);

    return candidates[0] || null;
  }
  // ...

Selecting Bonds: The "Infinite Line" Problem

With bonds, things get complicated. A bond is a line segment, not a single point. My first instinct was to use the classic equation for the distance from a point to a line:

\frac{|Ax + By + C|}{\sqrt{A^2 + B^2}}

The problem: This formula assumes the line is infinite. If you click miles away but happen to be perfectly aligned with the bond's trajectory, the formula will trigger a "hit". In a molecule with hundreds of bonds, this creates "ghost collisions" across the entire canvas.

The Solution: Projection and Clamping

To solve this, we need to find the closest point specifically within the segment bounded by atoms A and B. Here's where the vector math comes in.

The algorithm projects the mouse coordinates onto the line and calculates the "projection factor" t.

If t = 0, the closest point is atom A.
If t = 1, the closest point is atom B.
If t is between 0 and 1, the closest point lies somewhere along the bond.

Key here is clamping: forcing t to stay between 0 and 1 using Math.max(0, Math.min(1, t)). This effectively "encloses" the collision logic within the physical boundaries of the bond.

private pointToSegmentDistance(
  px: number, py: number, // Mouse point
  ax: number, ay: number, // Atom A (Start)
  bx: number, by: number  // Atom B (End)
): number {
  const abx = bx - ax;
  const aby = by - ay;
  const apx = px - ax;
  const apy = py - ay;

  const abLengthSq = abx * abx + aby * aby;

  // If atoms overlap, return distance to point A
  if (abLengthSq === 0) return Math.sqrt(apx * apx + apy * apy);

  // Scalar projection restricted to the [0, 1] range (Clamping)
  const t = Math.max(0, Math.min(1, (apx * abx + apy * aby) / abLengthSq));

  // Find the coordinates of the closest point on the segment
  const closestX = ax + t * abx;
  const closestY = ay + t * aby;

  // Final distance between mouse and the closest point on the segment
  return Math.sqrt(Math.pow(px - closestX, 2) + Math.pow(py - closestY, 2));
}

Atoms vs Bonds

A common UX challenge in chemical editors is overlap. What happens if the mouse is near a bond but also directly over an atom?

In chemistry, the atom is the primary unit of interaction. Therefore, I implemented a simple but effective business rule: Atoms always have priority. If the engine detects a collision with both an atom and a bond, the atom "hijacks" the selection event. This prevents users from accidentally deleting a bond when they intended to edit an element.

Conclusion: The "God Object" Warning

While this collision engine works perfectly, it has exposed a growing architectural debt. My Molecule class—which should only care about chemical valences and atoms—is now bloated with 2D geometry formulas and pixel coordinates.

I’ve created a God Object.

In the next post, I’ll perform "major surgery" on this architecture. We will split the system into two Bounded Contexts: a Chemistry context for the logic and a Spatial context for the geometry.

Building a ChemDraw clone with DDD (Part II): Strict Value Objects & Error Boundaries

Fredi Manuel Barraza Hernández — Mon, 23 Mar 2026 02:33:10 +0000

In my previous post, I laid down the basic entities and value objects to model the chemical domain. But there was a glaring flaw in the initial MVP: The Atom entity was too permissive.

The problem: Playing God

Previously, the domain allowed you to instantiate an Atom with any string as its chemical element. You could play god and create a new 'Hydroxygen' atom without the system complaining.

Obviously, in chemistry, the periodic table is a strictly closed set. The code needs to reflect that physical reality.

The solution: A Closed Registry

My solution was straightforward but rigorous. I created a strict ChemicalElement value object backed by a closed registry of valid elements. The factory method of this VO only accepts a valid chemical symbol, otherwise, it rejects the creation.

To make this completely type-safe, I used a TypeScript generic trick to infer the literal types and guarantee that the object key always matches the element's symbol.

Here's the code:

export interface ElementData {
  symbol: string;
  name: string;
  atomicNumber: number;
  atomicMass: number;
  commonValencies: number[];
}

// This helper function enforces that the key of the element exactly matches its symbol property
const createElementsMap = <T extends Record<string, ElementData>>(elements: {
  [K in keyof T]: T[K] & { symbol: K };
}) => elements;

export const ELEMENTS = createElementsMap({
  H: {
    symbol: "H",
    name: "Hydrogen",
    atomicNumber: 1,
    atomicMass: 1.008,
    commonValencies: [1],
  },
  C: {
    symbol: "C",
    name: "Carbon",
    atomicNumber: 6,
    atomicMass: 12.011,
    commonValencies: [4],
  }
  // ...
});

export type ElementSymbol = keyof typeof ELEMENTS;

export type ChemicalElementProps = Readonly<{
  symbol: string;
  name: string;
  atomicNumber: number;
  atomicMass: number;
  commonValencies: number[];
}>;

export class ChemicalElement extends ValueObject<ChemicalElementProps> {
  private constructor(props: ChemicalElementProps) {
    super(props);
  }

  public static create(symbol: string): Result<ChemicalElement, Error> {
    if (!Object.hasOwn(ELEMENTS, symbol)) {
      return err(new Error(`Invalid element symbol: ${symbol}`));
    }

    const elementData = ELEMENTS[symbol as ElementSymbol];
    return ok(
      new ChemicalElement({
        symbol: elementData.symbol,
        name: elementData.name,
        atomicNumber: elementData.atomicNumber,
        atomicMass: elementData.atomicMass,
        commonValencies: [...elementData.commonValencies],
      }),
    );
  }
}

The Error Flow: Result vs. Exceptions

If you noticed the Result return type above, that's because I'm using a library called neverthrow. It brings the Result monad pattern to TypeScript, wrapping a function's outcome in an object that contains either the expected value or an explicit error. This forces the consumer to handle the error, completely eliminating the hell of unhandled exceptions crashing the app.

However, I still use raw throw statements but strictly for Invariant Violations, situations that imply a catastrophic failure in the system's memory or logic, not just a business rule rejection.

To see this philosophy in action, look at how the Molecule aggregate root handles the deletion of an atom:

public removeAtom(atomId: EntityId): Result<void, Error> {
  const atom = this._atoms.get(atomId);

  // Expected Domain Error: The user tried to delete an atom that isn't there.
  if (!atom) {
    return err(new Error("Atom not found in molecule"));
  }

  const bondsToRemove = atom.bonds;
  for (const bond of bondsToRemove) {
    const otherAtomId = bond.atomIds.find((id) => id !== atomId);

    if (!otherAtomId) {
    // INVARIANT VIOLATION: A bond exists but doesn't connect to another atom.
    // The graph is corrupted. We panic and throw.
      throw new Error("Invalid bond: does not connect to another atom");
    }

    const otherAtom = this._atoms.get(otherAtomId);
    if (!otherAtom) {
      // INVARIANT VIOLATION: The bond points to a ghost atom.
      throw new Error("Invalid bond: other atom not found in molecule");
    }

    const removeResult = otherAtom.removeBond(bond);
    if (removeResult.isErr()) {
      return err(removeResult.error);
    }
  }

  this._atoms.delete(atomId);
  return ok();
}

By distinguishing between return err() (business logic failures) and throw new Error() (corrupted state), the domain remains predictable, safe, and incredibly easy to debug.

In upcoming posts, I'll dive into how I connected this pure chemical domain to a visual Canvas, and the vector math required to select chemical bonds on the screen.

Building a ChemDraw clone with DDD (Part I): Modeling Organic Chemistry with DDD

Fredi Manuel Barraza Hernández — Thu, 12 Mar 2026 02:37:06 +0000

In this blog series, I'll be documenting my process of building a minimal chemical molecule drawer (similar to ChemDraw). My motivation is straightforward: I want to combine my background in competitive chemistry with my goal to stress-test Domain-Driven Design in a complex domain.

To provide some context, a chemical drawer is, in essence, a tool that allows users to draw atoms and the bonds between them to generate structures like this one:

This first part focuses strictly on a constrained MVP: generating a canvas with Carbon atoms and single bonds.

The Domain

My domain consists of three core concepts: Atoms, Bonds and Molecules.

Modeling atoms was straightforward: they are entities with an atomic element and a position on the canvas. Bonds, however, involved a more challenging model.

Note: Currently, atoms hold a 2D position. While true DDD would isolate spatial geometry from UI canvas coordinates, I'm keeping simple x, y coordinates in the entity for now to ease the initial rendering setup, treating it as spatial domain data rather than pure UI data.

A philosophical question I faced was: Should bonds be entities or value objects? If atoms are entities, why couldn't bonds be?
After all, bonds, just like atoms, can be created, deleted, and modified.

Ultimately, I modeled them as value objects. Here is why: A bond is entirely described by its attributes (atoms it connects, the bond type, etc.). Textbook value object, I know, but it wasn't immediately obvious to me at first.

The realization hit me when I considered identity. Two atoms can be at the same position (on the canvas) and be the same chemical element, yet they are two different atoms. Bonds are different. There can't be two bonds connecting the same pair of atoms (well, technically they can in real chemistry, but in this model, we treat multiple connections as a single bond with a 'double' or 'triple' type). Additionally, there are no major issues if, instead of modifying a bond, the old one is destroyed and a new one is created.

To wrap up the bond model, I added the following invariant: An atom can't be connected to itself.

Finally, the aggregate root: the Molecule. This entity stores both atoms and bonds. It has methods to create atoms (that will be part of the molecule) and to add bonds.

The Molecule model will ensure for each bond that the two atoms it links exist, they are distinct, and there isn't already a bond between those same atoms.

export class Molecule extends AggregateRoot {
  private _atoms: Map<EntityId, Atom> = new Map();
  private _bonds: Bond[] = [];

  // ...

  public addBond(
    atomAId: EntityId,
    atomBId: EntityId,
    type: BondType = BondType.Single,
  ): Result<Bond, Error> {
    const atomA = this._atoms.get(atomAId);
    const atomB = this._atoms.get(atomBId);

    if (!atomA || !atomB) {
      return err(
        new Error("Both atoms must exist in the molecule to create a bond"),
      );
    }

    if (atomAId === atomBId) {
      return err(new Error("A bond cannot connect an atom to itself"));
    }

    const exists = this._bonds.some(
      (b) =>
        (b.atomIds[0] === atomAId && b.atomIds[1] === atomBId) ||
        (b.atomIds[0] === atomBId && b.atomIds[1] === atomAId),
    );

    if (exists) {
      return err(new Error("A bond already exists between these atoms"));
    }

    const bondResult = Bond.create([atomAId, atomBId], type);

    if (bondResult.isErr()) {
      return err(bondResult.error);
    }

    const bond = bondResult.value;
    this._bonds.push(bond);

    return ok(bond);
  }
}

With this Molecule aggregate root, the app successfully isolated the basic rules of chemistry from the UI. The domain now dictates that atoms must exist to be bonded, and self-bonding is structurally impossible. Bonds, treated as Value Objects, keep our mental model clean and our memory footprint light.

But right now, the domain is too permissive. A carbon atom could technically accept a hundred single bonds if the UI allowed it (a chemist would cry if they saw this).

In the next parts, I'll be introducing valence warnings, new elements, and more bond types (double, triple).

Stay tuned.

The problems I faced when coding a Pomodoro Timer with React.js

Fredi Manuel Barraza Hernández — Mon, 17 Mar 2025 03:04:40 +0000

Introduction

Recently, I was looking for web development ideas to kick off my new YouTube channel, Typing Zen, so I decided to code a simple Pomodoro timer app. After all, it shouldn't be too hard, right? Well, as it turns out, even a basic project can throw unexpected challenges your way. From handling circular progress bars without third-party libraries to dealing with JavaScript closures, I ran into some tricky problems that forced me to think outside the box. In this post, I'll share how I tackled these issues and what I learned along the way.

The Circular Progress Bar

My first challenge was the circular progress bar. Since I didn’t want to use any third-party libraries in my project—except for React and Tabler Icons (because nobody wants to handle SVG icons manually)—I quickly realized that implementing a circular progress bar wasn't as straightforward as I had thought.

The solution I came up with was using an SVG path to manage the progress of the bar. Here’s the code I used:

function CircularProgressBar({ progress, children }: CircularProgressBarProps) {
  const angle = progress * 2 * Math.PI;

  let path = "";
  if (angle <= Math.PI / 2) {
    path = `M 50,50 V 0 H ${50 + 50 * Math.sin(angle)} V ${50 - 50 * Math.cos(angle)} Z`;
  } else if (angle <= Math.PI) {
    path = `M 50,50 V 0 H 100 V ${50 - 50 * Math.cos(angle)} H ${50 + 50 * Math.sin(angle)} Z`;
  } else if (angle <= (3 * Math.PI) / 2) {
    path = `M 50,50 V 0 H 100 V 100 H ${50 + 50 * Math.sin(angle)} V ${50 - 50 * Math.cos(angle)} Z`;
  } else {
    path = `M 50,50 V 0 H 100 V 100 H 0 V ${50 - 50 * Math.cos(angle)} H ${50 + 50 * Math.sin(angle)} Z`;
  }

  return (
    <div className={styles.container}>
      <svg className={styles.bar} viewBox="0 0 100 100">
        <path d={path} />
      </svg>
      <div className={styles.content}>{children}</div>
    </div>
  )
}

This solution creates a filled SVG path that dynamically colors the portion of the progress bar corresponding to a given progress level. Here are some examples:

After adding some styles:

.container {
  display: flex;
  justify-content: center;
  align-items: center;
  position: relative;
  border-radius: 50%;
  width: 15rem;
  aspect-ratio: 1 / 1;
}

.bar {
  fill: black;
  position: absolute;
  width: 100%;
  height: 100%;
  border-radius: 50%;
}

.content {
  position: relative;
  display: flex;
  align-items: center;
  justify-content: center;
  width: calc(100% - 2rem);
  aspect-ratio: 1 / 1;
  border-radius: 50%;
  background: #fff;
}

This was the final result:

In my video, I added more colors and an animation for progress changes, but I consider this part to have been the hardest challenge.

JavaScript Closures and the Timer Issue

My second problem was dealing with JavaScript closures.

When I tried to program the timer using the setInterval function, I noticed that the global variables used inside the callback function remained unchanged, even when their values were updated outside the callback. This was especially problematic when working with useState.

After doing some research, I found that this issue is caused by how closures behave in JavaScript. To prevent issues with variables from outer scopes, closures only capture the initial value of a variable at the time of the first render.

To fix this, my solution was to use setTimeout instead of setInterval and generate a new callback function whenever the state was updated. Here’s how it works in code:

export function usePomodoroTimer() {
  const [leftTime, setLeftTime] = useState(ACTIVITY_TIMES.working);
  const [status, setStatus] = useState<PomodoroStatus>("stopped");
  const [activity, setActivity] = useState<PomodoroActivity>("working");
  const [sessionCount, setSessionCount] = useState(1);

  const timeoutRef = useRef<number | undefined>(undefined);

  // Instead of using global variables, we pass their values as parameters
  function setNewTimeout(
    activity: PomodoroActivity,
    leftTime: number,
    sessionCount: number,
  ) {
    timeoutRef.current = setTimeout(
      getTimeoutCallback(activity, leftTime, sessionCount),
      1000,
    );
  }

  function getTimeoutCallback(
    activity: PomodoroActivity,
    leftTime: number,
    sessionCount: number,
  ) {
    const initialTimestamp = Date.now();

    return () => {
      // Some logic where we update the state
      // ...

      setActivity(newActivity);
      setLeftTime(newLeftTime);
      setSessionCount(newSessionCount);

      // Set a new timeout with the updated values
      setNewTimeout(newActivity, newLeftTime, newSessionCount);
    };
  }

  useEffect(() => {
    return () => {
      clearTimeout(timeoutRef.current);
    };
  }, []);

  function run() {
    setStatus("running");
    setNewTimeout(activity, leftTime, sessionCount);
  }

  // ...
}

Conclusion

Thank you for reading this far!

If you're interested in the code, you can check out the GitHub repository:
https://github.com/quibylix/pomodoro-timer.

Additionally, if you enjoy mechanical keyboard sounds, relaxing videos, or just want to watch someone coding, feel free to check out my YouTube video where I build this app!

Let me know in the comments if you've faced similar challenges or if you have suggestions for my future posts and projects. See you next time! 🚀