As a Mobile developers, we often need to inspect and debug network calls made by our Android apps — especially when working with APIs.
That’s where Charles Proxy comes in handy. It acts as a man-in-the-middle proxy that helps you capture, analyze, and even modify requests and responses in real-time.

In this post, I’ll guide you through setting up Charles Proxy on both Android real devices and emulators, along with SSL setup for HTTPS debugging.

🔧 What You’ll Need

• Charles Proxy (Download)
• A computer (macOS/Windows/Linux) running Charles
• Android device (physical phone) or emulator
• Your app or browser that makes API calls

🧠 Understanding How Charles Works

Charles acts as a proxy between your Android device and the internet.
When your device routes traffic through Charles, it captures all outgoing requests and incoming responses.
For HTTPS traffic, Charles uses an SSL certificate to decrypt the content — which you must install on your Android device or emulator.

📱 Setting Up on an Android Real Device

Step 1: Connect Both Devices to the Same Network

Make sure your Android phone and laptop are on the same Wi-Fi.

Now let’s find your computer’s local IP address directly from Charles.

• Open Charles Proxy
• Go to the menu Help → Local IP Address
• Copy the IP address shown (e.g., 192.168.1.5) — this will be your Proxy Hostname when configuring the Android Wi-Fi proxy.

Step 2: Configure Charles Proxy Port

Let’s configure proxy port, you can change accordingly your port availability.

1. Open Charles → go to Proxy → Proxy Settings
2. Note the HTTP Proxy Port (default: 8888)

Step 3: Set Proxy on Android Device

1. On your phone, open
   Settings → Wi-Fi → [Your Network] → Modify Network → Advanced Options
2. Set Proxy = Manual
3. Enter: Proxy Hostname: your computer’s IP & Proxy Port: 8888

Step 4: Allow Connection in Charles

When your phone connects, you’ll see a pop-up in Charles:

“Allow this device to connect?”

✅ Click Allow

Step 5: Install SSL Certificate on Android

1. On your phone, open Chrome and visit:
   👉 http://charlesproxy.com/getssl
2. A certificate file charles-ssl-proxying-certificate.crt will download.
3. Go to Settings → Security → Install Certificate → CA Certificate
4. Select and install the file.

After this you are good to go, you will able to see traffic in charles proxy.

🧩 Setting Up Charles Proxy on Android Emulator

Emulators are easier since they share a virtual network with your computer.

Step 1: Start Charles and Emulator

Make sure Charles is running before you open the emulator.

Step 2: Configure Proxy Using ADB

Run this in your terminal:

adb shell settings put global http_proxy <computer-ip>:8888

Example:

adb shell settings put global http_proxy 192.168.1.5:8888

To clear the proxy later:

adb shell settings put global http_proxy :0

Step 3: Install SSL Certificate in Emulator

Drag and drop the certificate file (charles-ssl-proxying-certificate.pem) into your emulator, or use:

adb push charles-ssl-proxying-certificate.pem /sdcard/

Then install it via: Settings → Security → Install Certificate → CA Certificate

That’s it, Now you could see proxy start working

🧪 Verify the Setup

Open any app or browser — you should now see network requests in Charles!

If HTTPS traffic isn’t decrypted:

• Go to Proxy → SSL Proxying Settings → Enable SSL Proxying
• Add your target domain(s), e.g. *.api.yourdomain.com *.googleapis.com

In the above attach screenshot, i have hide some urls which are too sensitive to display but you can add you’r own.

Also, you can quickly enable SSL proxying when you see a request in Charles (under the Structure tab), you can right-click on the URL → select “Enable SSL Proxying”.

This automatically adds the domain to your SSL proxying list — no need to open the settings manually.

💡 Pro Tips

Sometime Android emulators don’t recognize your machine’s local IP (like 192.168.x.x).
In that case, use the special Android emulator loopback address instead:

adb shell settings put global http_proxy 10.0.2.2:8888

🏁 Conclusion

Charles Proxy is an excellent debugging tool - once set up, you can inspect and manipulate all your app’s network calls in real-time.
Whether you’re testing APIs, debugging performance, or simulating backend issues, this setup will make your life easier.

For a detailed guide on setting up Charles Proxy with iOS devices and emulators, check out this article:
Setting Up Charles Proxy with iOS Devices and Emulators by Mayur Kadam

Setting Up Charles Proxy with Android Devices and Emulators was originally published in Mighty ghost hack on Medium, where people are continuing the conversation by highlighting and responding to this story.

🌍 Introduction: More Than Just Features

When I first started building apps with React Native, I focused on animations, performance, and pixel-perfect UI.
One day, while testing a application I build, a colleague turned on VoiceOver (on iOS) — and the screen reader didn’t read anything :) Buttons were just “unlabeled elements,” and inputs were “text field…”

That moment I think about development. I realized that accessibility (a11y) isn’t just about compliance — it’s about respect.
Respect for users who experience apps differently, yet deserve the same ease of use.

We need accessibility some form of disability person. Making your app accessible opens it up to more users.

Accessible features like high contrast, larger fonts, or voice navigation help all users.

So in this post, I’ll walk you through practical accessibility strategies for React Native apps — with working code examples and a developer’s perspective.

⚙️ Accessibility in React Native

React Native provides a strong foundation for accessibility on both iOS and Android, offering tools that bridge native accessibility systems like VoiceOver (iOS) and TalkBack (Android). These tools allow screen readers and assistive technologies to understand and interact with your app’s UI elements.

React Native have built-in support for properties such as

• accessible,
• accessibilityLabel,
• accessibilityRole,
• accessibilityHint,
• importantForAccessibility and so on.

with these props developers can create inclusive experiences without reinventing the wheel.

📉 Let’s take some example to briefly understand

⚙️ 1. Labels, Roles, and Hints — Giving Your UI a Voice

Help screen readers understand your UI. React Native provides accessible, accessibilityLabel, accessibilityRole, and accessibilityHint , below is the code snippet how to use

<TouchableOpacity
  accessible={true}
  accessibilityLabel="Submit order"
  accessibilityHint="Double tap to confirm your purchase"
  accessibilityRole="button"
  onPress={handleSubmit}
>
  <Text>Submit</Text>
</TouchableOpacity>

What this does:

• Screen readers announce: “Submit order, button. Double tap to confirm your purchase.”

Note — We have much more support from React native for more properties refer this Accessibility — React Native Documentation

⚙️ 2. Accessibility in Forms

Forms are where accessibility is often neglected — but easy to fix.

<View>
  <Text accessibilityRole="header">Login</Text>

  <TextInput
    placeholder="Email"
    accessibilityLabel="Email address"
    keyboardType="email-address"
  />

  <TextInput
    placeholder="Password"
    accessibilityLabel="Password field"
    secureTextEntry
  />

  <TouchableOpacity
    accessibilityLabel="Login button"
    accessibilityHint="Logs you into the app"
    onPress={handleLogin}
  >
    <Text>Login</Text>
  </TouchableOpacity>
</View>

What this does:

• Screen readers announce: “Email address, text field… Password field… Login button — logs you into the app.”

⚙️ 3. Support Dynamic Font Scaling

Some users increase font sizes for better visibility. If your app ignores this, it breaks readability. React Native makes it easy to support system-wide font scaling.

<Text allowFontScaling={true}>
  Welcome back, John!
</Text>

Note — If you’re using custom scaling libraries (like react-native-size-matters), ensure they respect system preferences.

Tip — Test by changing system font size under Settings → Accessibility → Display → Font Size.

⚙️ 4. Ensure High Contrast & Dark Mode Compatibility

Color contrast is crucial — poor contrast can make text unreadable for users with low vision. React Native’s useColorScheme() hook helps you handle this gracefully.

import { useColorScheme, Text } from 'react-native';

const colorScheme = useColorScheme();
const textColor = colorScheme === 'dark' ? '#fff' : '#000';

What this does:

• The useColorScheme() hook in React Native subscribes to the system’s color scheme (light or dark mode) and updates in real time whenever the user changes the device appearance setting.

⚙️ 5. Control Focus Order and Navigation

Screen readers navigate through focusable elements. If your screen has modals or custom components, you must guide focus manually.

import { AccessibilityInfo, findNodeHandle, useRef } from 'react-native';

const SuccessModal = () => {
  const titleRef = useRef(null);

  useEffect(() => {
    const node = findNodeHandle(titleRef.current);
    if (node) AccessibilityInfo.setAccessibilityFocus(node);
  }, []);

  return (
    <View accessible={true}>
      <Text ref={titleRef} accessibilityRole="header">
        Payment Successful
      </Text>
      <Text>Your order will be delivered soon.</Text>
    </View>
  );
};

What this does:

• When the modal opens, the screen reader immediately focuses on “Payment Successful”, helping users orient themselves.

⚙️ 6. Large touch targets

Users with motor disabilities, or even those using your app while walking, need tappable elements that are big enough and spaced apart properly.
According to WCAG (Web Content Accessibility Guidelines) and Apple’s Human Interface Guidelines, 👉 the minimum recommended touch target size is 44×44 dp.

<TouchableOpacity
  onPress={handleLike}
  accessibilityLabel="Like this post"
  accessibilityRole="button"
  hitSlop={{ top: 10, bottom: 10, left: 10, right: 10 }}
>
  <Image source={require('./heart.png')} style={{ width: 24, height: 24 }} />
</TouchableOpacity>

What this does:

• Increase tappable area of application without Changing Visual Size.

⚙️ 7. Haptic Feedback (Vibration)

Some users can’t rely on visual or audio feedback alone — they may not see a toast message or hear a click sound. Adding haptic feedback gives them an immediate tactile signal that an action was successful (or failed).

const handleDelete = async () => {
  await Haptics.notificationAsync(Haptics.NotificationFeedbackType.Error);
  alert('Item deleted!');
};

What this does:

• This triggers a sharper vibration, letting users instantly sense that something important happened.

🧪 How to Test & Validate Accessibility in React Native

Let’s look at the best ways to test accessibility in React Native apps 👇

1. Manual Testing with Screen Readers

The first and most important step is hands-on testing using native accessibility tools.

• iOS: Use VoiceOver (enable from Settings → Accessibility → VoiceOver).
• Android: Use TalkBack (enable from Settings → Accessibility → TalkBack).

2. Automated Testing Tools

A few third-party and native tools can help automate accessibility checks:

• @react-native-community/eslint-plugin-a11y — integrates with ESLint to catch common accessibility issues.
• Detox + Jest — can be combined for automated accessibility validation in UI tests.
• Google Accessibility Scanner (Android) — scans your app for a11y issues like low contrast or missing labels.
• Xcode Accessibility Inspector (iOS) — visualizes accessibility hierarchy and properties.

Accessibility testing is not a one-time process — it’s an ongoing part of your development workflow. Every new feature, update, or redesign should include accessibility validation.
By regularly testing, you ensure your app stays inclusive, usable, and delightful for everyone.

📝 Short Note

These are some of the most common accessibility (a11y) features every React Native developer should consider while building applications. You may not need to use all of them at once, but applying the right combination of these properties and techniques ensures that your app is truly inclusive and user-friendly for everyone.

Making accessibility a part of your development process isn’t just a checklist — it’s a commitment to creating apps that welcome every user, regardless of ability or environment.

🧩 Make Your App Inclusive: Accessibility Strategies That Every React Native Developer Should Know was originally published in Mighty ghost hack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever felt frustrated that LinkedIn doesn’t support bold, italic, or underlined text? 🤯

I did too! So, I built something cool — LinkedIn Text Formatter 🎉

🔥 What’s the problem?

LinkedIn keeps things plain — no HTML tags, no markdown, no built-in formatting options. That means:
❌ No way to highlight key points
❌ No easy way to structure your thoughts
❌ No way to add a bit of personality to your posts

Meanwhile, platforms like LeetCode, Discord, and Twitter allow formatted text using Unicode. So I thought — why not bring that same magic to LinkedIn?

💡 The Solution: A Simple, Free Chrome Extension

With LinkedIn Text Formatter, you can now effortlessly format your posts with:
✅ 𝐁𝐨𝐥𝐝, 𝑰𝒕𝒂𝒍𝒊𝒄, U̲n̲d̲e̲r̲l̲i̲n̲e̲, and • Bullet etc
✅ Live Preview of typed text🔥
✅ Instant Copy-Paste for LinkedIn
✅ Emoji Support 😃🎉
✅ 100% Free & Open Source

⚡ How It Works

It’s super simple:
1️⃣ Type your text into the formatter
2️⃣ Watch the Live Preview update in real time
3️⃣ Click Copy and paste it directly into LinkedIn

That’s it! 🎯

💻 Open Source — Get Involved!

This is an open-source project, and I’d love for you to explore the code, contribute, or suggest improvements. Let’s build and learn together! 🚀

🚀 Try It Out!

🔹 Chrome Extension: Install Here
🔹 Live Web Version: Try Here
🔹 GitHub Repository: Check the Code

🤝 Your Feedback Matters!

Would love to hear your thoughts! Try it out and drop your feedback — it’ll help shape future updates. Who knows? AI-powered suggestions or hashtag generators could be next! 🚀

Hey LinkedIn Users, Let’s Make Your Posts Stand Out! was originally published in Mighty ghost hack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the last few months, I’ve been preparing for React Native developer positions and recently had the opportunity to interview with FanCode. The process was intense, insightful, and filled with learning moments. I want to share my experience to help others prepare for similar roles.

Interview Rounds

1. Online Assessment (1 hr & 15 mins)
2. Problem Solving (60 mins)
3. Platform Round (60 mins)
4. Design Round (60 mins)

Once you clear all rounds, there will be 2 more rounds of interviews with engineering leadership, mainly to test for cultural fitment.

Round 1: Online Assessment

This round included three different programming questions, and I was given 1 hour and 15 minutes to complete them. The questions I encountered were:

1. Limit Promise Concurrency: Implement a function that dynamically manages the concurrency limit while processing multiple promises.
2. Remove Circular Dependency: Write a function to remove circular dependencies from a given object.
3. Polyfill for setAllTimeout and clearAllTimeout: Implement a polyfill for both these functions.

I was able to complete all three questions. However, for the second problem (removing circular dependencies), some test cases failed as I could not handle certain edge cases. Despite this, I scored enough to advance to the next round.

Round 2: Problem Solving

This round focused on testing JavaScript proficiency by requiring the implementation of three polyfills. Candidates had 60 minutes to write working, executable solutions for the provided tasks.

The questions I encountered were:

1. Flatten Array by Level: Write a polyfill to flatten an array to a specified depth. For example:

flatten([1, [2, [3, [4]]]], 2);
// Output: [1, 2, 3, [4]]

1. SetInterval and ClearInterval: Implement polyfills for the setInterval and clearInterval methods, mimicking their behaviour using setTimeout.
2. Promise.allSettled Method: Write a polyfill for Promise.allSettled, which takes an array of promises and returns a promise that resolves after all of the given promises have either been fulfilled or rejected.

I completed all three questions within the allotted time and ensured the solutions were robust and executable. Clearing this round allowed me to progress to the Platform Round.

Round 3: Platform Round

This round primarily tested my in-depth knowledge of React Native architecture and its modern advancements. The 60-minute session was divided into three sections, each focusing on different aspects of React Native expertise.

Section 1: React Native Architecture Discussion
In this segment, the interviewer asked detailed questions about React Native’s architectural evolution. The topics included:

• Old vs. New Architecture: Differences between the old architecture (based on the bridge) and the new one (TurboModules, JSI, and Fabric).
• Optimization Improvements: Discussed enhancements like reduced bridge bottlenecks, faster rendering via Fabric and the role of Hermes in improving performance.
• Why Updates Were Necessary: They probed into the reasons for adopting TurboModules and JSI, highlighting their impact on app performance and inter-module communication.
• How It Works Internally: Questions centred around how JSI facilitates direct communication with the JavaScript engine and eliminates the need for serialization/deserialization via the bridge.

The pattern of questioning was consistent: “What is it? Why was it introduced? How does it work?” This required both theoretical knowledge and a practical understanding of React Native internals.

Section 2: Native Component & Module Implementation
In this part, the interviewer provided documentation with the design for a native component and module that I had to implement. This required:

• Creating a Native Component using Android’s SimpleViewManager.
• Developing a Native Module to handle custom business logic.

I managed to complete about 80% of the implementation due to time constraints. The focus was on:

• Writing clean, reusable native code.
• Ensuring seamless integration with React Native.

Section 3: React Fundamentals and Patterns
The final section comprised verbal questions on core React and React Native concepts. Topics included:

• React Component Lifecycle: How to React Native leverages lifecycle methods.
• State Management: Best practices for managing state in large applications.
• React Hooks: Practical usage of useEffect, useContext, and custom hooks.
• Design Patterns: Discussion on reusable component patterns and optimizing performance in React Native apps.

Completing most of the coding tasks and demonstrating a solid understanding of React fundamentals helped me move forward to the next round.

Round 4: Design Round

This round tested my ability to design systems and applications effectively, with a focus on both backend and frontend aspects. The task provided by the interviewer was to design a Slack messaging system with the following requirements:

1. Peer-to-Peer Messaging: Enable real-time, direct communication between two users.
2. Group Messaging: Support for creating and managing group conversations.
3. API Design: Design RESTful APIs that handle messaging functionality efficiently.
4. History: Store chat history of conversation.

Functional and Non-Functional Requirements

The interviewer expected a detailed breakdown of both functional (e.g., sending, and receiving messages) and non-functional requirements (e.g., performance, scalability, data consistency). They emphasized maintaining real-time communication and ensuring scalable backend architecture.

My Approach

Backend Design — Proposed a distributed system architecture using WebSockets for real-time communication.

API Design — Created a plan for APIs, including endpoints for sending, receiving, fetching old messages, and managing groups & focused on ensuring low latency for real-time events while keeping APIs stateless for ease of maintenance.

Frontend Design Discussion
After completing the system design, the discussion shifted toward the frontend. The interviewer asked how I would efficiently display and paginate messages given the API responses. Key points included:

• Data Fetching and Caching: Use infinite scrolling for message lists with APIs returning batched data.
• State Management: Manage the state effectively using a combination of Redux and React Query for real-time updates.
• Unread Message Count: Display the user's unread message optimally count over UI.

Although I was able to answer most of the questions, a couple of edge cases stumped me, particularly around questions related to WebSockets & its response.

Outcome

After a week of anxious waiting, I received an email from FanCode stating that they would not be moving forward with my application. The message read:

“After much discussion and analysis with the team, we, unfortunately, have decided not to proceed with signing you on at this time. However, we will keep your profile on file, and as soon as a position aligns with your talent, we will reach out!”

While I didn’t make it to the finish line, I gained practical knowledge and feel motivated to keep growing as a developer. Looking forward to the next adventure!

Interview Experience with FanCode for a React Native Developer Role was originally published in Mighty ghost hack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Are you curious about how Depth-First Search (DFS) works? This Word Search Game is an interactive tool designed specifically for learners interested in understanding data structures, particularly through visualizing DFS in action.

Note: This isn’t a traditional game where users manually select a matching grid, search for words and receive feedback on correctness. Instead, it’s a visual tool designed to demonstrate how the DFS algorithm operates to find words automatically within a grid.

Project Overview

In this project, we’ll build a user interface that includes:

• Two input fields: One for selecting a target word and another for user input.
• Customization options: Controls to adjust the grid size and the speed of the DFS search.
• Visual controls: Buttons to start the search, shuffle the grid, and reset the game.
• Responsive UI: Designed for both mobile and desktop views.

Core Algorithms

1. Depth-First Search (DFS): Used for pattern matching and locating word sequences in the grid.
2. Linear Search: Extracts valid words from the grid for visualization purposes.

The main focus of this article will be on the algorithmic backbone of the project: implementing DFS and linear search. For UI components, feel free to use any front-end framework of your choice, such as React, Vue, or Angular.

Why DFS for Word Search?

DFS is known for exploring all possible paths from a given node before moving on to the next. This makes it ideal for problems.

DFS provides the functionality to thoroughly explore every possible letter combination in a word search grid, making it possible to find valid words without missing any options.

In this project, we’ll explore DFS in a 2D grid (the word search board) where each cell is a node connected to its adjacent cells. We aim to demonstrate how DFS can systematically search for words by exploring all possible paths within the grid.

Understanding the DFS for Word Search

DFS works by exploring each path fully before backtracking. Here’s a basic pseudocode for DFS in a grid context:

1. Start at a cell and mark it as visited.
2. Recursively explore each unvisited neighbouring cell.
3. If a cell matches the next character in the target word, continue the search.
4. If all characters are found, the word is located.
5. Backtrack if a path doesn’t match the word.

In this project, DFS will dynamically navigate through grid cells to check if the word exists in different directions.

For simplicity, I have only included horizontal and vertical directions. However, real word search puzzles also look for diagonal paths, which can be easily implemented. I will add this feature if there is positive feedback on this project. Since this open-source project is available on GitHub, I encourage learners to fork the repository and add more features as they wish.

Implementing the DFS Algorithm in JavaScript

var dfsSearch = function (board, word) {
    let result = false;

    var validate = (row, col, k) => {

        // Out of boundary case for recursive call
        if (row < 0 || col < 0 || row >= board.length || col >= board[0].length) return;

        // Wrong Character
        if (board[row][col] != word[k]) return false;

        // Base case to return from recursive call
        if (k === word.length - 1) {
            result = true;
            return true;
        }

        // Change value as null so we dont go back and forth
        board[row][col] = null;

        // try all directions
        validate(row + 1, col, k + 1);
        validate(row - 1, col, k + 1);
        validate(row, col + 1, k + 1);
        validate(row, col - 1, k + 1);

        // Change into real value, reset the board.
        board[row][col] = word[k];
    }

    // Iterative loop
    for (let i = 0; i < board.length; i++) {
        for (let j = 0; j < board[0].length; j++) {
            if (board[i][j] === word[0]) {
                if (validate(i, j, 0)) return true;
            }
        }
    }

    return result;
};

A similar leetcode problem is available (Problem #79). I recommend first solving the Word Search problem on LeetCode. This problem will help you grasp the core concepts.

Implementation of Extract text in JavaScript

We can extract potential words from the grid using linear search to find sequences in different directions. Here’s a basic JavaScript function for extracting words:

const extractWordsFromGrid = (grid, minLength = 3) => {
  const words = new Set();

  const numRows = grid.length;
  const numCols = grid[0].length;

  const addWord = (word) => {
    
    if (word.length >= minLength) {
      words.add(word);
    }
  };

  // Extract horizontal words
  for (let row = 0; row < numRows; row++) {
    let rowStr = grid[row].slice(0, randomIntFromInterval(1, grid[row].length - 1)).join("");
    addWord(rowStr); // Left-to-right
    addWord([...rowStr].reverse().join("")); // Right-to-left
  }

  // Extract vertical words
  for (let col = 0; col < numCols; col++) {
    let colStr = [];
    for (let row = 0; row < numRows; row++) {
      colStr.push(grid[row][col]);
      
    }
    
    addWord(colStr.slice(0, randomIntFromInterval(1, colStr.length - 1)).join("")); // Top-to-bottom
    addWord([...colStr].reverse().join("")); // Bottom-to-top
  }
  
  return shuffleElements(Array.from(words)); // Convert Set to Array for output
};

const randomIntFromInterval = (min, max) => {
  return Math.floor(Math.random() * (max - min + 1) + min);
};

const shuffleElements = (arr) => {
  return arr.sort((a, b) => Math.random() - 0.5);
};

DFS Traversal Visualization

To enhance the user experience, we use a colour scheme to visualize the DFS traversal:

• Green: Indicates cells that match the word.
• Yellow: Shows DFS traversal as it moves through each cell.
• Sky Blue: Highlights the next potential match.

Each cell changes colour to reflect the DFS progression, and a delay is applied between steps (adjustable via a speed control slider) to allow users to follow the search process in real-time.

Project Resources

The complete code for this project is available on GitHub, allowing you to explore the full implementation or contribute by adding more features.

Play with the Game: Experience the Word Search DFS Visualization through the interactive link — https://mayurkadampro.github.io/Word-Search-DFS-Visualization/

GitHub Repository: Check out the entire codebase and feel free to fork the repo to add additional features — https://github.com/mayurkadampro/Word-Search-DFS-Visualization

If you enjoyed this article and found the visualization tool helpful for understanding how DFS works with grid-based structures, please consider following me for more practical projects and hands-on tutorials. Stay tuned for exciting new content on data structures, algorithms, and interactive learning tools!

Build a Word Search Game to visualize a Depth-First Search Algorithm was originally published in Mighty ghost hack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Developing applications that rely on external APIs or services, a common challenge is handling repeated failures gracefully. Imagine a scenario where an API becomes temporarily unavailable — calling it over and over will only increase the load and waste resources. To address this, we can implement a circuit breaker pattern.

This pattern stops calls to the failing service temporarily and resumes them after a set time, allowing the service to recover. In this post, we’ll build a simple JavaScript circuitBreaker function to illustrate this concept.

Why Use a Circuit Breaker?

A circuit breaker prevents your system from getting overwhelmed by failing calls. Here are the main reasons to use it:

1. Reduces unnecessary load: Stops repeated, futile calls to a failing service.
2. Allows recovery time: Gives the failing service time to get back up.
3. Improves user experience: Avoids showing repeated error messages to the user.

We’ll create a circuitBreaker function that:

• Attempts to call a function (like an API request).
• Counts consecutive failures.
• Temporarily halts further calls after a fixed number of failures (threshold).
• Resume calls after a specified period (halt time).

const HALT_TIME = 5000; // 5 seconds
const FAILED_THRESHOLD = 3; // Number of failed attempts before halting

const circuitBreaker = (cb, haltTime = HALT_TIME, failThreshold = FAILED_THRESHOLD) => {
    let failCount = 0;
    let isHalted = false;
    let timeout;

    return () => {
        if (isHalted) {
            console.log("Service is currently unavailable. Please wait a moment and try again.");
            return;
        }

        try {
            const result = cb();
            failCount = 0; // Reset fail count if call succeeds
            console.log("Call succeeded");
            return result;
        } catch (error) {
            failCount++;
            console.log(`Call failed (${failCount}/${failThreshold})`);

            if (failCount >= failThreshold) {
                isHalted = true;
                console.log(`Threshold reached. Halting calls for ${haltTime / 1000} seconds.`);

                timeout = setTimeout(() => {
                    failCount = 0; // Reset fail count after halt period
                    isHalted = false;
                    console.log("Service resumed.");
                }, haltTime);
            }
        }
    };
};

// Example usage:
const mockApiCall = () => {
    if (Math.random() > 0.5) {
        throw new Error("API call failed.");
    }
    return "API call succeeded.";
};

const testFunction = circuitBreaker(mockApiCall);

// Simulate multiple calls
for (let i = 0; i < 10; i++) {
    testFunction();
}


// let request after some interval
setTimeout(() => {
    testFunction();
}, HALT_TIME);

Output

Explanation of Key Parts

Configuration Variables:

• HALT_TIME sets how long to halt calls after too many failures.
• FAILED_THRESHOLD sets the number of consecutive failures allowed before halting.

Circuit Breaker Logic:

• failCount keeps track of consecutive failures.
• isHalted is a flag that prevents further calls when set to true.

Function Return and Timeout:

• If the function succeeds, failCount resets.
• When failCount reaches the threshold, a timeout is set to halt further calls temporarily.
• After haltTime, the timeout resets failCount and clears isHalted, allowing calls to resume.

Conclusion

With this circuitBreaker function, you can control how your JavaScript code handles repeated failures, making your application more robust and reliable. This pattern is especially useful in microservices and cloud environments where services may temporarily experience load issues or maintenance downtime. You can also extend this circuit breaker to log failures, alert users, or dynamically adjust the halt time based on usage patterns.

Building a Simple Circuit Breaker in JavaScript to Handle Repeated Failures was originally published in Mighty ghost hack on Medium, where people are continuing the conversation by highlighting and responding to this story.

Interviewing for the SDE-2 position at Dream11 was both challenging and insightful. Although I wasn’t selected, I walked away with new insights and a better understanding of the interview process at a top tech company. Here’s a breakdown of the experience, my challenges, and the valuable lessons I learned.

Initial Contact

The process started with a phone call from a Dream11 recruiter. The initial phone screening was straightforward, focusing on my background and experience to assess whether my profile was a good match. Once cleared, I was invited to the next stage—a virtual DSA (Data Structures and Algorithms) coding round.

Round 1: Virtual DSA Coding Challenge

Date: October 18, 2024
Format: Virtual
Duration: 1hr
Interview Panel: SDE3 at Dream11

Search in Rotated Sorted Array

Missing Number

Longest Substring

I had to solve three DSA problems. This round evaluated problem-solving speed and accuracy. I was able to clear this round, which felt like a small victory and a boost of confidence to tackle what lay ahead.

Round 2: The In-Office Platform Round

The next step was an on-site interview at Dream11’s Mumbai office. This “Platform Round” was more intense, involving a 40-minute coding session split between two problems. Here’s how it went:

Problem 1: CSV to JSON with the optimal solution

I attempted a complex approach, but time constraints made it challenging to implement fully.

however for your refrence you can find below optimize solution.

Solution — https://github.com/mayurkadampro/JavaScript-Coding-Interview-Problems/blob/main/Interview%20Question/CSVToJSON.js

Problem 2: implementation of a rate limiter that evenly distributes requests over a one-minute period using JavaScript closures

I solved it partially within the 20-minute limit.

Solution — https://github.com/mayurkadampro/JavaScript-Coding-Interview-Problems/blob/main/Interview%20Question/rateLimiter.js

While I couldn’t complete the round to my satisfaction, I learned the importance of quick decision-making under pressure and the value of opting for simpler approaches where possible.

This round was heavily focused on coding knowledge and algorithmic skills, highlighting the standards Dream11 sets for its engineering team.

What I Learned

Although I didn’t advance further, I took away valuable lessons to apply to future interviews:

• Time Management: Breaking down the problem and choosing the most efficient solution in a limited time is key.
• Complexity Awareness: Sometimes, the simplest approach is the best approach, especially when the clock is ticking.
• Resilience: Every round brings new insights that make you stronger for the next opportunity.

Takeaway

Each interview is a stepping stone toward growth. While I wasn’t selected this time, the experience helped me refine my problem-solving approach and reinforced my dedication to continuous learning.

In-Person Interview Experience at Dream11 [SDE-2] | Mumbai was originally published in Mighty ghost hack on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is the DOM?

DOM stands for Document Object Model.

The Document part refers to the webpage you see in the browser—specifically, the HTML Document.

Object means the elements like images, headers, and paragraphs are treated like objects. Each object has its properties (like id, class, style) and methods. Using these properties and methods, you can manipulate the elements.

The Model in DOM is a representation of the HTML document as a hierarchical tree. This tree includes all the elements. And it captures the parent-child relationships between them.

DOM Manipulation

1. Selecting Elements
2. Creating Elements
3. Adding or Inserting Elements
4. Removing Elements
5. Modifying Element Content
6. Modifying Attributes
7. Modifying Styles
8. Traversing the DOM
9. Event Handling
10. Other Useful DOM Utility Methods

1. Selecting Elements

These methods allow you to select elements from the DOM:

document.getElementById(id): Select an element by its id.

const element = document.getElementById('myId');

document.getElementsByClassName(className): Select all elements with the specified class.

const elements = document.getElementsByClassName('myClass');

document.getElementsByTagName(tagName): Selects all elements with the specified tag name.

const elements = document.getElementsByTagName('div');

document.querySelector(selector): Select the first element that matches a CSS selector.

const element = document.querySelector('.myClass');

document.querySelectorAll(selector): Select all elements that match a CSS selector.

const elements = document.querySelectorAll('.myClass');

2. Creating Elements

These methods create new elements or text nodes:

document.createElement(tagName): Creates a new element with the specified tag name.

const newDiv = document.createElement('div');

document.createTextNode(text): Creates a new text node with the specified text.

const textNode = document.createTextNode('Hello World');

3. Adding or Inserting Elements

These methods add new elements to the DOM or insert elements at specific positions:

parentNode.appendChild(childNode): Adds childNode as the last child of parentNode.

document.body.appendChild(newDiv);

parentNode.insertBefore(newNode, referenceNode): Inserts newNode before referenceNode within parentNode.

const referenceNode = document.getElementById('myId');
document.body.insertBefore(newDiv, referenceNode);

parentNode.prepend(newNode): Inserts newNode as the first child of parentNode.

document.body.prepend(newDiv);

element.insertAdjacentElement(position, newElement): Inserts an element relative to another element. Positions include beforebegin, afterbegin, beforeend, and afterend.

element.insertAdjacentElement('beforeend', newDiv);

4. Removing Elements

These methods remove elements or child nodes:

parentNode.removeChild(childNode): Removes childNode from parentNode.

document.body.removeChild(newDiv);

element.remove(): Removes element from the DOM directly.

newDiv.remove();

5. Modifying Element Content

These properties and methods modify the content inside elements:

element.textContent: Gets or sets the text content of an element.

element.textContent = 'Hello, World!';

element.innerHTML: Gets or sets the HTML content of an element.

element.innerHTML = '<strong>Hello, World!</strong>';

element.outerHTML: Gets or replaces the element itself with new HTML content.

element.outerHTML = '<div>New Content</div>';

6. Modifying Attributes

These methods manage element attributes:

element.getAttribute(attributeName): Gets the value of an attribute.

const id = element.getAttribute('id');

element.setAttribute(attributeName, value): Sets the value of an attribute.

element.setAttribute('class', 'newClass');

element.removeAttribute(attributeName): Removes an attribute.

element.removeAttribute('class');

element.hasAttribute(attributeName): Checks if an attribute exists.

const hasId = element.hasAttribute('id');

7. Modifying Styles

These methods modify inline styles:

element.style.property: Sets an inline style property.

element.style.color = 'red';

element.classList.add(className): Adds a class to the element.

element.classList.add('myClass');

element.classList.remove(className): Removes a class from the element.

element.classList.remove('myClass');

element.classList.toggle(className): Toggles a class on or off.

element.classList.toggle('active');

element.classList.contains(className): Checks if an element contains a specified class.

const hasClass = element.classList.contains('active');

8. Traversing the DOM

These properties and methods navigate through the DOM tree:

element.parentNode: Gets the parent of an element.

const parent = element.parentNode;

element.childNodes: Gets a list of an element's child nodes.

const children = element.childNodes;

element.firstChild: Gets the first child of an element.

const firstChild = element.firstChild;

element.lastChild: Gets the last child of an element.

const lastChild = element.lastChild;

element.previousSibling: Gets the previous sibling of an element.

const prevSibling = element.previousSibling;

element.nextSibling: Gets the next sibling of an element.

const nextSibling = element.nextSibling;

element.children: Returns an HTMLCollection of child elements.

const childElements = element.children;

element.firstElementChild and element.lastElementChild: Access the first and last child elements.

const firstElement = element.firstElementChild;

9. Event Handling

These methods attach and remove event listeners:

element.addEventListener(event, handler): Attaches an event listener to an element.

element.addEventListener('click', () => console.log('Clicked!'));

element.removeEventListener(event, handler): Removes an event listener from an element.

element.removeEventListener('click', handler);
// OR
const listener = element.addEventListener('click', handler);
element.removeEventListener(listener);

10. Other Useful DOM Utility Methods

element.cloneNode(deep): Creates a clone of an element. Pass true to also clone child elements.

const clone = element.cloneNode(true);

element.contains(childNode): Checks if an element contains a specific child node.

const isContained = element.contains(childNode);

element.replaceChild(newChild, oldChild): Replace an existing child with a new one.

element.replaceChild(newNode, oldNode);

These methods give you comprehensive control over the DOM, allowing you to select, create, manipulate, traverse, and delete elements dynamically, as well as handle events. This is essential for building interactive, dynamic web applications.

Javascript DOM Manipulation methods was originally published in Mighty ghost hack on Medium, where people are continuing the conversation by highlighting and responding to this story.

SOLID principles to React projects significantly enhance code quality, making it more maintainable, scalable, robust and flexible applications.

SOLID Principles in React

1. Single Responsibility Principle (SRP) — Focus on one task per component.
2. Open/Closed Principle (OCP) — Extend components without modifying them.
3. Liskov Substitution Principle (LSP) — Components should be interchangeable without breaking the application.
4. Interface Segregation Principle (ISP) — Components should only take the necessary props, avoiding bloated interfaces.
5. Dependency Inversion Principle (DIP) — Rely on abstractions (e.g., contexts, hooks) rather than concrete implementations for flexibility and decoupling.

1. Single Responsibility Principle (SRP)

• Definition: A component should have only one reason to change, meaning it should do one thing and do it well.
• In React: Break down large components into smaller, reusable pieces, each handling a single responsibility.

Not following SRP: In this example, the UserProfile component handles fetching data, managing state, and rendering the UI—all in one component.

// ❌ BAD EXAMPLE - Violating SRP
import React, { useState, useEffect } from 'react';

const UserProfile = () => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchUserData = async () => {
      try {
        const response = await fetch('https://api.example.com/user');
        const data = await response.json();
        setUser(data);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    };
    fetchUserData();
  }, []);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
};

export default UserProfile;

Following SRP: Now, let’s refactor the code to adhere to the Single Responsibility Principle by breaking it into three separate components.

1. Custom Hook for Data Fetching (useUserData)

// ✅ GOOD EXAMPLE - Following SRP
import { useState, useEffect } from 'react';

const useUserData = () => {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchUserData = async () => {
      try {
        const response = await fetch('https://api.example.com/user');
        const data = await response.json();
        setUser(data);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    };
    fetchUserData();
  }, []);

  return { user, loading, error };
};

export default useUserData;

2. Loading and Error Handling Component (UserInfo)

// ✅ GOOD EXAMPLE - Following SRP
import React from 'react';

const UserInfo = ({ user, loading, error }) => {
  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
};

export default UserInfo;

3. Main Component (UserProfile)

// ✅ GOOD EXAMPLE - Following SRP
import React from 'react';
import useUserData from './useUserData';
import UserInfo from './UserInfo';

const UserProfile = () => {
  const { user, loading, error } = useUserData();

  return <UserInfo user={user} loading={loading} error={error} />;
};

export default UserProfile;

2. Open/Closed Principle (OCP)

• Definition: Software entities should be open for extension but closed for modification.
• In React: Use higher-order components (HOCs), render props, or composition to extend component behaviour without modifying the existing code.

Not following OCP: In this example, the Button component has different styles based on the type prop. Every time a new button style is needed, we have to modify the existing Button component.

// ❌ BAD EXAMPLE - Violating OCP
import React from 'react';

const Button = ({ type, label }) => {
  let style = {};

  if (type === 'primary') {
    style = { backgroundColor: 'blue', color: 'white' };
  } else if (type === 'secondary') {
    style = { backgroundColor: 'gray', color: 'white' };
  } else if (type === 'danger') {
    style = { backgroundColor: 'red', color: 'white' };
  }

  return <button style={style}>{label}</button>;
};

export default Button;

Every time we want to add a new button type, we need to modify the existing component by adding a new if or else if conditions, which violates OCP.

Following OCP: Instead of modifying the Button component for every new style, we can create a Higher-Order Component (HOC) that adds different styles based on the button type. This way, the Button component remains unchanged, and we can extend its behaviour by wrapping it with different HOCs.

// ✅ GOOD EXAMPLE - Following OCP
import React from 'react';

// Base Button Component
const Button = ({ style, label }) => {
  return <button style={style}>{label}</button>;
};

// HOC for Primary Button
const withPrimaryStyle = (WrappedComponent) => {
  return (props) => {
    const style = { backgroundColor: 'blue', color: 'white' };
    return <WrappedComponent {...props} style={style} />;
  };
};

// HOC for Secondary Button
const withSecondaryStyle = (WrappedComponent) => {
  return (props) => {
    const style = { backgroundColor: 'gray', color: 'white' };
    return <WrappedComponent {...props} style={style} />;
  };
};

// HOC for Danger Button
const withDangerStyle = (WrappedComponent) => {
  return (props) => {
    const style = { backgroundColor: 'red', color: 'white' };
    return <WrappedComponent {...props} style={style} />;
  };
};

// Use the HOCs
const PrimaryButton = withPrimaryStyle(Button);
const SecondaryButton = withSecondaryStyle(Button);
const DangerButton = withDangerStyle(Button);

const App = () => (
  <div>
    <PrimaryButton label="Primary Button" />
    <SecondaryButton label="Secondary Button" />
    <DangerButton label="Danger Button" />
  </div>
);

export default App;

3. Liskov Substitution Principle (LSP)

• Definition: Objects or components should be replaceable with instances of their subtypes without altering the correctness of the program.
• In React: When creating components or extending them, ensure they can be used interchangeably without breaking the application.

Not following LSP: In this example, incorrect use of interface methods and not following the base interface for the same type of component violates the LSP principle.

// ❌ BAD EXAMPLE - Violating LSP
interface BadBaseButton {
  onClick: () => void;
  text: string;  // Restricts to string only
}

const BadBaseButton: React.FC<BadBaseButton> = ({ onClick, text }) => (
  <button onClick={onClick}>{text}</button>
);

// Violates LSP by changing prop structure and behavior
interface BadPrimaryButton {
  label: string;  // Different prop name
  onAction: (e: React.MouseEvent) => Promise<void>;  // Different type
}

const BadPrimaryButton: React.FC<BadPrimaryButton> = ({ label, onAction }) => {
  const handleClick = async (e: React.MouseEvent) => {
    await onAction(e);
  };

  return <button onClick={handleClick}>{label.toUpperCase()}</button>;
};

// Usage shows incompatibility
const BadExample: React.FC = () => {
  const handleClick = () => console.log('clicked');
  
  return (
    <div>
      <BadBaseButton 
        onClick={handleClick} 
        text="Click me" 
      />
      
      {/* Won't work! Different props and behavior */}
      <BadPrimaryButton 
        label="Click me"
        onAction={async (e) => console.log('clicked')} 
      />
    </div>
  );
};

Following LSP: It helps to ensure base props are extended consistently, the same onClick type throughout, components are interchangeable & add features without breaking the base contract.

// ✅ GOOD EXAMPLE - Following LSP
interface GoodBaseButtonProps {
  onClick: () => void;
  children: React.ReactNode;
}

const GoodBaseButton: React.FC<GoodBaseButtonProps> = ({ onClick, children }) => (
  <button onClick={onClick}>{children}</button>
);

// Properly extends base props
interface GoodPrimaryButtonProps extends GoodBaseButtonProps {
  variant?: 'solid' | 'outline';  // Optional additional prop
}

const GoodPrimaryButton: React.FC<GoodPrimaryButtonProps> = ({ 
  onClick, 
  children, 
  variant = 'solid' 
}) => {
  const className = variant === 'solid' ? 'bg-blue-500' : 'border-blue-500';
  
  return (
    <button onClick={onClick} className={className}>
      {children}
    </button>
  );
};

// Usage shows compatibility
const GoodExample: React.FC = () => {
  const handleClick = () => console.log('clicked');
  
  return (
    <div>
      {/* Both components can use the same handler */}
      <GoodBaseButton onClick={handleClick}>
        Click me
      </GoodBaseButton>
      
      <GoodPrimaryButton onClick={handleClick} variant="solid">
        Click me
      </GoodPrimaryButton>
    </div>
  );
};

4. Interface Segregation Principle (ISP)

• Definition: Clients should not be forced to depend on interfaces they do not use.
• In React: Ensure that components accept only the props they need, and use custom hooks to separate different concerns.

Not following ISP: In this example, the extended interface is forced to implement all props even if it doesn’t need them.

// ❌ BAD EXAMPLE - Violating ISP
interface ButtonProps {
  label: string;
  onClick: () => void;
  icon: string;        // Not all buttons need icons
  loading: boolean;    // Not all buttons need loading state
  disabled: boolean;   // Not all buttons need disabled state
}

const Button: React.FC<ButtonProps> = ({ label, onClick, icon, loading, disabled }) => {
  return (
    <button onClick={onClick} disabled={disabled}>
      {loading ? "Loading..." : label}
      {icon && <span>{icon}</span>}
    </button>
  );
};

Following ISP: Now, let’s refactor this code by Segregating interfaces for different aspects of the button.

// ✅ GOOD EXAMPLE - Following ISP
interface BasicButtonProps {
  label: string;
  onClick: () => void;
}

interface LoadingButtonProps extends BasicButtonProps {
  loading: boolean;
}

// Simple button without unnecessary props
const SimpleButton: React.FC<BasicButtonProps> = ({ label, onClick }) => {
  return <button onClick={onClick}>{label}</button>;
};

// Button with loading state
const LoadingButton: React.FC<LoadingButtonProps> = ({ label, onClick, loading }) => {
  return (
    <button onClick={onClick}>
      {loading ? "Loading..." : label}
    </button>
  );
};

5. Dependency Inversion Principle (DIP)

• Definition: High-level modules should not depend on low-level modules; both should depend on abstractions.
• In React: Use context, hooks, or dependency injection to invert dependencies.

Not following DIP: In this example, the BadNotificationButton component directly depends on concrete ToastNotification.

// ❌ BAD EXAMPLE - Violating DIP
class ToastNotification {
  show(message: string) {
    // Direct implementation of toast
    console.log(`Toast: ${message}`);
    // Imagine this actually shows a toast
  }
}

// Component directly depends on concrete implementation
const BadNotificationButton: React.FC = () => {
  // Direct instantiation - tightly coupled
  const toaster = new ToastNotification();

  const handleClick = () => {
    toaster.show('Button clicked!');  // Directly coupled to toast
  };

  return (
    <button onClick={handleClick}>
      Show Notification
    </button>
  );
};

Following DIP: We refactored the code by wrapping it with the createContext API, ensuring adherence to the Dependency Inversion Principle (DIP). This approach minimizes tight coupling by promoting loose dependencies and enhances the overall modularity and flexibility of the code.

// ✅ GOOD EXAMPLE - Following DIP
// Define the abstraction
interface NotificationService {
  notify(message: string): void;
}

// Concrete implementations
class ToastService implements NotificationService {
  notify(message: string) {
    console.log(`Toast: ${message}`);
    // Actual toast implementation
  }
}

class AlertService implements NotificationService {
  notify(message: string) {
    console.log(`Alert: ${message}`);
    // Actual alert implementation
  }
}

// Context for dependency injection
const NotificationContext = React.createContext<NotificationService | null>(null);

// Provider component
interface NotificationProviderProps {
  service: NotificationService;
  children: React.ReactNode;
}

const NotificationProvider: React.FC<NotificationProviderProps> = ({
  service,
  children
}) => (
  <NotificationContext.Provider value={service}>
    {children}
  </NotificationContext.Provider>
);

// Custom hook for using notifications
const useNotification = () => {
  const service = React.useContext(NotificationContext);
  if (!service) {
    throw new Error('useNotification must be used within NotificationProvider');
  }
  return service;
};

// Button component depends on abstraction
const GoodNotificationButton: React.FC<{
  message: string;
}> = ({ message }) => {
  const notificationService = useNotification();

  const handleClick = () => {
    notificationService.notify(message);
  };

  return (
    <button 
      onClick={handleClick}
      className="px-4 py-2 bg-blue-500 text-white rounded hover:bg-blue-600"
    >
      Show Notification
    </button>
  );
};

// Example Usage
const App: React.FC = () => {
  // Can easily switch between services
  const toastService = new ToastService();
  const alertService = new AlertService();

  return (
    <div className="p-4">
      {/* Using Toast Service */}
      <NotificationProvider service={toastService}>
        <div className="mb-4">
          <h2 className="text-lg font-bold mb-2">Toast Notifications</h2>
          <GoodNotificationButton message="Toast notification!" />
        </div>
      </NotificationProvider>

      {/* Using Alert Service */}
      <NotificationProvider service={alertService}>
        <div>
          <h2 className="text-lg font-bold mb-2">Alert Notifications</h2>
          <GoodNotificationButton message="Alert notification!" />
        </div>
      </NotificationProvider>
    </div>
  );
};

By following these principles, you can ensure that your React components remain consistent, substitutable, and reliable, leading to more maintainable and scalable applications.

SOLID Principles in React for Cleaner and Scalable Code was originally published in Mighty ghost hack on Medium, where people are continuing the conversation by highlighting and responding to this story.