DEV Community: Muhammad Fahmi Rasyid

Test Frontend Changes with Browser (Using Chromium Overrides)

Muhammad Fahmi Rasyid — Tue, 09 Sep 2025 07:30:02 +0000

I used to spend way too much time waiting for the backend team.
If I needed to test what happens when an API returns something different - or worse, an error - I had two options:

Ask the backend team to change their response.
Spin up a mock server and wire everything myself.

Both were slow.

Then I discovered something hidden in DevTools: Network Overrides.
It felt like flipping a secret switch. Suddenly I could control API responses without touching the backend. Here's how it went down.

Step 1: Opening the Toolbox

I right clicked on the page → Inspect.
Instead of going to the Console, I switched over to the Sources panel.

On the left, there was a tab called Overrides just sitting there quietly.

Step 2: Creating My Sandbox

Clicking Overrides, DevTools asked me to choose a folder.
This folder is where my fake responses would live.

I picked an empty folder, allowed Chrome to use it, and suddenly had my little override sandbox ready.

Step 3: Grabbing a Response

Next, I went to the Network tab, refreshed the page, and spotted the request I wanted: /api/config.

Right-click → Save for overrides.
DevTools copied the real response into my local folder.

Step 4: Editing the Rules

I opened the file under Sources > Overrides and changed a few values.
Something like turning "featureEnabled": false into "featureEnabled": true.

Step 5: Refresh & Smile

I refreshed the page.
The app now behaved as if the backend really returned my modified response.

In the Network tab, a small icon appeared beside the request, showing it was overridden.

Step 6: Turning It Off

When I was finished, I just unchecked Enable Local Overrides in the Overrides panel.
Everything went back to normal server responses.

Pro Tips: Mocking Errors & Timeouts

Once I got comfortable, I started pushing things further:

Mock an error response: Edit the override file and replace its body with an error JSON, e.g.

  { "error": "Internal Server Error" }

Then in the headers, change 200 OK to 500 Internal Server Error.

Simulate a timeout: In the Network tab, right-click the request and select Block request URL. Now your app behaves as if the server never responded. Great for testing loaders and retries.

Closing Thoughts

Network Overrides turned my browser into a mini-mock server.
No more waiting for backend changes, no more begging teammates for test data.
Just fast, local experiments right inside DevTools.

Next time you're stuck waiting on an API change, give Overrides a try - it might save you hours.

Building a 3D Formula Visualizer: Lessons Learned

Muhammad Fahmi Rasyid — Mon, 10 Feb 2025 21:17:00 +0000

Hey folks! 👋 A while ago, I embarked on a journey to build a 3D formula visualization tool using React, Three.js, and TypeScript. It sounded simple at first—just render some mathematical formulas in 3D and let users tweak parameters in real-time. But as with any project, the reality was far from straightforward. Along the way, I hit roadblocks, made mistakes, and learned a ton. If you're thinking of doing something similar, let me share what worked (and what didn’t) so you can hopefully avoid some of the pitfalls I encountered.

Lesson 1: Future-Proof Your Code

When I first started, I knew I needed a way to manage different formulas cleanly. At first, I had a bunch of functions scattered everywhere, each handling its own calculations and geometry generation. This quickly became a nightmare. Every time I wanted to add a new formula, I had to copy-paste logic and tweak it manually—definitely not sustainable.

Initially, I stored formulas in a simple object-based structure, something like this:

export const formulas: Record<string, Formula> = {
  gielis: {
    metadata: {
      name: "Gielis",
      description: "A variation of the superformula",
      parameters: {
        a: { name: "a", min: 0.1, max: 10, step: 0.1 },
        b: { name: "b", min: 0.1, max: 10, step: 0.1 },
        m: { name: "m", min: 0, max: 20, step: 1 },
        n1: { name: "n1", min: 0.1, max: 10, step: 0.1 },
      },
    },
    calculate: ({ phi, a, b, m, n1, n2, n3 }) => {
      return Math.pow(
        Math.pow(Math.abs(Math.cos((m * phi) / 4) / a), n2) +
        Math.pow(Math.abs(Math.sin((m * phi) / 4) / b), n3),
        -1 / n1
      );
    }
  }
};

This worked at first, but as I added more formulas, maintaining this structure became unwieldy. So, I decided to go with an abstract base class to enforce structure. The idea was to have a consistent API that every formula would follow, making expansion easier and reducing redundancy. Here’s what I came up with:

// filepath: /formulas/BaseFormula.ts
abstract class BaseFormula implements Formula {
  abstract metadata: FormulaMetadata;
  abstract calculate(params: FormulaParams): number;
  abstract createGeometry(params: FormulaParams): THREE.BufferGeometry;
}

To further improve maintainability, I transitioned to a class-based registry system:

import { Formula } from "../types/Formula";
import { GielisFormula } from "./GielisFormula";
import { TerrainFormula } from "./TerrainFormula";
import { SineInterferenceFormula } from "./SineInterferenceFormula";
import { GyroidFormula } from "./GyroidFormula";
import { CellularNoiseFormula } from "./CellularNoiseFormula";
import { MobiusFormula } from "./MobiusFormula";

export const formulaRegistry: Record<string, Formula> = {
  gielis: new GielisFormula(),
  terrainGen: new TerrainFormula(),
  sineInterference: new SineInterferenceFormula(),
  gyroid: new GyroidFormula(),
  cellularNoise: new CellularNoiseFormula(),
  mobius: new MobiusFormula(),
};

export const getFormula = (type: string): Formula => {
  const formula = formulaRegistry[type];
  if (!formula) {
    throw new Error(`Formula type '${type}' not found`);
  }
  return formula;
};

This simple refactor had a huge impact. Every formula now extended from this base class, keeping things modular and predictable. The calculations were separate from the Three.js geometry logic, making everything easier to debug and maintain. Plus, with TypeScript enforcing structure, I avoided a ton of runtime errors. It was a game-changer for scalability.

Lesson 2: Real-Time 3D Rendering is Tricky

With the formula structure in place, I thought the hard part was over. But then came the real challenge—real-time rendering. I wanted users to tweak parameters and see their changes reflected instantly in the 3D visualization. Simple in theory, but in practice? Not so much.

The first version of my app was sluggish. Every update caused unnecessary re-renders, and the scene management was all over the place. The solution? I had to rethink how updates were handled. I found two key improvements that made a world of difference.

First, I centralized my scene management. Instead of each formula handling its own objects independently, I created a single place where objects were added, updated, and removed dynamically. This ensured that changes in parameters translated directly into visual updates without causing conflicts or memory leaks.

Second, I made React state the driver of updates. Instead of manually modifying the Three.js scene, I let React’s state management handle the reactivity. Whenever a user adjusted a parameter, the state changed, triggering a recalculation and an efficient update to the scene. This cut down on unnecessary re-renders and made the visualization feel much smoother.

What’s Next? 🚀

Building this 3D formula visualizer was an eye-opening experience. While I solved many challenges, there’s still so much more to explore. In future iterations, I want to add support for custom formulas, letting users define their own equations and see them rendered in real-time. I also want to build a more intuitive parameter control system to make tweaking values feel seamless.

You can check out the project on GitHub: UltraFormula Repo and try the live demo here: UltraFormula on Vercel.

Right now, the app supports six different formula visualizations:

Gielis Formula
Perlin Noise Terrain Generator
Sine Interference Pattern
Gyroid Surface
Cellular Noise
Möbius Strip

Have you worked on something similar? What challenges did you face? I’d love to hear about your experiences—drop a comment below! 👇

Building a Board Game with React: Lessons Learned

Muhammad Fahmi Rasyid — Mon, 20 Jan 2025 22:07:07 +0000

Creating something from scratch is one of the best ways to learn—and that's precisely what I did when I decided to build Dakon Clash, a digital board game. Inspired by an Indonesian traditional game using beads and fused with elements of Reversi, this project wasn’t just a fun way to engage with friends but also an ambitious playground for learning React Router v7 (aka Remix).

Here’s a peek into my journey—the triumphs, mistakes, and lessons I learned along the way.

Why React and Remix?

React has been my go-to framework at work, so sticking with it felt natural. When Remix (React Router v7) came out, I saw this as the perfect opportunity to kill two birds with one stone: learn Remix and build something I genuinely cared about. There’s no better way to learn than by diving into a project, especially when it’s challenging and fun. Spoiler alert: it was both.

What’s New in Remix (React Router v7)?

Remix merged into React Router, becoming React Router v7—a full-fledged framework. One standout feature that benefited my project was the routing. This allowed me to separate the board and controls into independent files, rendering them independently. The modular design improved maintainability and made the project easier to work with as it grew. It’s these little changes that made Remix such a joy to use.

Wrestling with State Management

State management is the heart of any interactive application, but I underestimated just how tricky it could get. Here’s how my state management journey evolved:

Monolithic Chaos

I started by throwing everything into zustand. I thought, "Hey, why not use a centralized store for everything?" At first, this approach worked, but as the game grew, so did the complexity. Debugging became a nightmare—it was harder to debug than to add features, which says a lot.

The All-in-One Engine

Next, I refactored everything into an EngineClass. This represented the entire game: board state, game logic, player interactions, everything. While it worked better than the previous version, the class became enormous and unwieldy. When I tried to set the state for other objects, recursion issues crept in, creating a tangled web of dependencies.

Breaking It Down

Finally, I took a step back and broke the engine into smaller, more manageable pieces. I separated the logic into distinct classes: Board, Player, GameMaster, and Engine. The zustand store was now only responsible for holding the board state. This modular approach brought clarity and opened the door for future features like multiplayer, playback, and a bot engine.

The Lesson:

Don’t overcomplicate things. I made the mistake of focusing too much on details without seeing the bigger picture. Simplicity isn’t just elegant—it’s practical. Refactoring may feel like starting over, but it’s an essential part of the process.

Designing the Game

UI/UX design wasn’t something I’d done much of before, so I kept it simple. My brainstorming tool of choice? MS Paint. Yes, really.

I drafted version 0 of the UI in Paint and used it as a rough blueprint. To refine this further, I used Vercel's v0.dev to improve the design and structure. But, Writing the actual code from these drafts was where the learning really happened. It wasn’t perfect, but it was mine, and the process was rewarding.

Here's the first version

Game Logic: Turning Ideas into Code

Creating the game logic was my favorite part. I started by drafting pseudo-code for the game’s rules. The core idea revolves around placing beads into cells, triggering chain reactions when cells reach a certain threshold, and flipping opponent cells to your color. The challenge lay in converting these mechanics into code while keeping it efficient.

One highlight was implementing the logic for analyzing the board and making weighted decisions. While it’s not perfect yet (and the AI is still a work in progress), I’m proud of how far it’s come. Converting a mental picture into working code was a satisfying challenge.

Lessons Learned

Dive into a project to learn new tech. Remix became much more approachable because I had a real project to build with it. Learning through doing always wins.
Think bigger but keep it simple. I overcomplicated things early on, which led to headaches. Sometimes, the simplest solution is the best.
Refactor without fear. It’s easy to get attached to your first attempt, but don’t hesitate to rewrite if it’ll make your code better.
Enjoy the process. Even with blockers and setbacks, I had fun creating Dakon Clash. That’s what matters most.

What’s Next?

Dakon Clash is far from finished. My modular engine opens up possibilities for multiplayer, playback, and a smarter bot engine. There’s always room for improvement, but I’m happy with what I’ve learned and built so far.

Conclusion

Building Dakon Clash wasn’t just about creating a game—it was about growing as a developer. If you’re thinking of tackling a side project, do it. You’ll learn, struggle, and grow. And who knows? You might end up with something you’re proud to share with the world.

Feel free to share your thoughts, feedback, or similar experiences in the comments. And if you want to check out the code, I’ll leave a link below. Thanks for reading!

The Game:
DakonClash Game

The Code:
DakonClash on Github

From Pods to Projects: Mastering Task Management the Whale-some Way

Muhammad Fahmi Rasyid — Wed, 26 Jun 2024 20:08:24 +0000

As I delved further into the project management process, I discovered an intriguing parallel: we can learn a lot from how whales manage their pods. Here's my journey into this oceanic analogy.

In the vast ocean of project management, tracking progress can feel as daunting as navigating the deep blue sea. However, adopting the principles of a whale pod simplified the process for me, ensuring smooth and efficient project tracking. Allow me to take you through this journey, where the wisdom of whales provided a relaxed yet effective approach to project management.

Estimation Philosophy: Swimming in Sync

When I started out, traditional project tracking seemed to demand pinpoint accuracy, like a lone whale searching for the perfect current. But watching whale pods taught me the power of consistency and collaboration. By maintaining steady estimates and adjusting predictions with a load factor—much like the gentle sway of a whale’s tail—teams can focus on completing tasks rather than obsessing over exact hours spent.

Breaking Down Tasks: From Giant Whales to Agile Dolphins

I noticed how a pod of whales collaborates to tackle large tasks, inspiring me to break down our project tasks into manageable pieces. We aimed for tasks that could be completed in 0.25 to 2 ideal days. It felt like teaching a whale calf to swim—small, achievable strokes leading to success. This approach made tracking easier and boosted team morale as we saw our progress ripple through the water.

Simplified Progress Tracking: The Whale Song of Success

Visual aids became our version of the hauntingly beautiful whale songs. A simple bar graph showing completed and estimated remaining tasks provided a clear overview. Rather than relying on complex predictions, we displayed our current progress and let stakeholders infer trends, much like interpreting the rhythms and patterns of a whale’s song.

Handling Scope Changes: Navigating New Currents

Scope changes felt inevitable, much like the shifting ocean currents. We ensured our tracking tools could account for these changes to provide an accurate picture of progress. Visual representations of scope changes helped communicate their impact to stakeholders, just as a whale pod adapts to new waters and communicates through body language and song.

Encouraging User Engagement: The Pod Mentality

Simplified tracking methods encouraged our team to engage actively, mirroring the close-knit cooperation of a whale pod. Visible progress, like a color-coded iteration board, provided immediate feedback and motivated team members. This approach allowed us to quickly identify the status of each task without delving into detailed reports, much like how whales recognize each other's roles and statuses within the pod.

Sailing Smoothly with Simple Tools

Effective project tracking doesn’t require complex tools or meticulous data recording. By focusing on consistent estimates, breaking down tasks, and using simple visual aids, project managers can maintain control and ensure steady progress. Inspired by the wisdom of whale pods, this approach offers a practical way to navigate the ocean of project management with grace and efficiency.

Conclusion

In the end, project management is about finding harmony and balance within the team, much like a whale pod navigating the vast ocean together. By adopting these whale-inspired strategies, you can lead your team to smoother sailing and greater achievements. So, take a deep breath, dive in, and let the wisdom of the whales guide your project management journey.

TL;DR:

I discovered how project management can be inspired by the behavior of whale pods. By adopting principles of consistency, collaboration, task breakdown, and simple visual tracking, teams can navigate projects more smoothly. Learn how to handle scope changes and boost team engagement, drawing wisdom from the gentle giants of the ocean.