Forem: Kartik Sharma

The of "Aha" moment of this month! 🫨

Kartik Sharma — Sun, 26 Oct 2025 09:24:27 +0000

Kartik Sharma

Oct 26 '25

⚛️ Why Conditional Initial Values Don’t Always Work with useState

#webdev #react #typescript #ai

Comments

2 min read

⚛️ Why Conditional Initial Values Don’t Always Work with useState

Kartik Sharma — Sun, 26 Oct 2025 09:23:43 +0000

React components re-render whenever their props change — but how that affects internal state can be tricky.

Take this snippet I came across yesterday while reviewing one of my older projects:

const [options, setOptions] = useState(selectedOptions ? selectedOptions : []);

At first glance, the logic seems fine:

“If the selectedOptions prop exists, use it; otherwise, start with an empty array.”

It works — but only if the parent component sends the correct selectedOptions on the very first render.

Now imagine the parent fetches that data asynchronously (say, from an API). On the initial render, it passes an empty array — and later, once the API resolves, it sends the real selectedOptions.

Here’s where things break.

Even though React re-renders the child component when the prop updates, the state won’t reinitialize.

Why?

Because useState only uses its initializer on the first render.

The mindset behind this line —

“Whenever the component receives a new selectedOptions prop, re-instantiate this state.”

— isn’t how React actually works.

React recalculates your JSX on every render, but it does not re-run the initializers for hooks like useState. That initial value is locked in after the first mount.

This is precisely why useEffect exists — to respond to changing props and synchronize internal state accordingly.

The correct approach looks like this 👇🏼

useEffect(() => {
  if (selectedOptions) {
    setOptions(selectedOptions);
  }
}, [selectedOptions]);

This version reflects the right mindset:

“Whenever selectedOptions changes, update the options state to match it.”

That’s the real difference — not in the code, but in how you think about React’s lifecycle.

So that’s my take on this topic — something I rediscovered while reviewing my past work and reflecting on how I used to approach logic building.

Remember, learning a language or framework goes far beyond just syntax. Syntax can be mastered in days or weeks, but developing the mindset — the psychology behind how a framework actually thinks and behaves — takes time. It only comes from running into those tricky edge cases and “aha” moments that challenge how you reason about code.

Thanks for reading! 👋🏼

Stop the Chaos: My Go-To React Folder Structure Pattern

Kartik Sharma — Sat, 26 Jul 2025 06:55:30 +0000

React.js is an incredible library for building web applications — from small prototypes to large-scale, production-grade apps. But unlike full-fledged frameworks, React doesn’t enforce a structure. This flexibility is powerful, yet it comes with a trade-off: you’re responsible for designing a maintainable architecture.

Technically, React won’t stop you from putting your entire app in a single .tsx file (please don’t do this), but such freedom often leads to messy codebases that are hard to scale and hand over. Poor structure can quickly become a blocker in scenarios like:

1. Handover to Other Developers

When another developer joins the project, they might have no idea where things live — where’s the business logic? where’s the UI code? Without a clear separation (like containers vs display), reusing or refactoring components becomes risky; one wrong move could break the entire app.

2. Confusion About Existing Code

Without organization, it’s tough to know what already exists. Are there utility functions for this? Do we already have a custom hook for that? Developers end up reinventing the wheel or combing through files line by line to find what they need.

3. Painful File Navigation

If naming conventions or folder patterns aren’t standardized, simply navigating the codebase becomes frustrating. You waste time searching for related files instead of building features.

Solving These Issues with the Display + Container Pattern

To overcome the challenges mentioned above, I prefer using the Display + Container Pattern in our React projects. Over time, this approach has massively improved our team’s productivity — we spend less time untangling code and more time shipping features.

The beauty of this pattern is that it’s not something you need to memorize like syntax rules; it’s more like a simple formula (2 + 2 = 4). Once you apply it a few times, it quickly becomes second nature to organize your components this way.

Let me walk you through a practical example so you can see exactly how it works. Let’s have a look at this Feature/Section I have in one of my project where I am simply Rendering the User’s Profile & there Details

Folder Structure

src/
├── features/
│   └── UserProfile/
│       ├── index.tsx                # Export container (entry point)
│       ├── UserProfileContainer.tsx # Logic + state mgmt
│       ├── UserProfileDisplay.tsx   # Pure UI
│       ├── hooks/                   # Hooks specific to UserProfile
│       │   └── useUserProfile.ts
│       └── components/              # Sub components specific to display
│           └── UserAvatar.tsx

Let’s Break down Each File & There purpose One by one!

Barrel Export

index.tsx

export { default } from './UserProfileContainer';

Whenever I need to use the UserProfile section across my app, I won’t import it directly from UserProfileContainer.tsx.

Instead, I’ll import it via the index.tsx file using Barrel Exports!

This approach standardizes a single entry point for the component/feature, making imports cleaner, easier to manage, and more scalable as the project grows.

Usage Example:

import UserProfile from '@/features/UserProfile'; // imports container by default

Container Component

UserProfileContainer.tsx

import React from 'react';
import UserProfileDisplay from './UserProfileDisplay';
import { useUserProfile } from './hooks/useUserProfile';

interface Props {
  userId: string;
}

const UserProfileContainer: React.FC<Props> = ({ userId }) => {
  const { user, loading, handleFollow } = useUserProfile(userId);

  if (loading) return <p>Loading...</p>;
  if (!user) return <p>User not found</p>;

  return <UserProfileDisplay user={user} onFollow={handleFollow} />;
};

export default UserProfileContainer;

The Container Component is responsible for rendering the Display Component and handling all business logic.

This includes tasks such as data fetching, form submission, and processing or preparing relevant data before passing it to the Display Component as props.

In short, the Container manages logic and state, while the Display focuses solely on UI rendering.

Display Component

UserProfileDisplay.tsx

import React from 'react';
import { User } from '@/types/user.types';
import UserAvatar from './components/UserAvatar';

interface Props {
  user: User;
  onFollow: () => void;
}

const UserProfileDisplay: React.FC<Props> = ({ user, onFollow }) => {
  return (
    <div className="p-4 border rounded shadow-sm">
      <UserAvatar name={user.name} />
      <h2 className="text-xl font-bold">{user.name}</h2>
      <p className="text-gray-600">{user.email}</p>
      <button
        className="mt-2 px-3 py-1 bg-blue-500 text-white rounded"
        onClick={onFollow}
      >
        Follow
      </button>
    </div>
  );
};

export default UserProfileDisplay;

All the relevant data and event handlers are passed down as props to the Display Component.

This means its only responsibility is to render the data—nothing more, nothing less.

By keeping it purely presentational, the Display Component stays simple, reusable, and easy to test.

Feature-Specific Hooks

hooks/useUserProfile.ts

import { useEffect, useState } from 'react';
import { getUserProfile } from '@/services/userService';
import { User } from '@/types/user.types';

export const useUserProfile = (userId: string) => {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    getUserProfile(userId).then((data) => {
      setUser(data);
      setLoading(false);
    });
  }, [userId]);

  const handleFollow = () => {
    alert(`Followed ${user?.name}!`);
  };

  return { user, loading, handleFollow };
};

All the relevant custom hooks will be stored inside the dedicated hooks**/ directory** to keep the project structure organized and maintainable.

Nested Components

components/UserAvatar.tsx

import React from 'react';

interface Props {
  name: string;
}

const UserAvatar: React.FC<Props> = ({ name }) => {
  return (
    <div className="w-12 h-12 rounded-full bg-gray-300 flex items-center justify-center text-white font-bold">
      {name.charAt(0)}
    </div>
  );
};

export default UserAvatar;

Naturally, if you’re building an entire page, it will likely contain nested components and smaller UI pieces.

These smaller components should be stored inside the `/components` directory for better organization.

Additionally, if a small component (like UserAvatar.tsx) doesn’t include any business logic or interactive behavior, you can store it directly in the directory—keeping it simple and purely presentational.

Real-World Scenario

Let’s imagine you’re working on the UserProfile page and need to make some changes.

With the Display + Container pattern in place, you instantly know where to look based on the type of change you’re making — no guesswork, no memorizing file names, just logical calculation.

Need to change API/state logic? → Go to UserProfileContainer.tsx → Else need UI/styling change? → Go to UserProfileDisplay.tsx → Nested UI? → Check components/ folder.

Step-by-Step Thought Process

Identify your task → Is it logic-related or UI-related?
Logic-related? → Go to Container file.
UI-related? → Go to Display file.
For nested UI pieces → Check components folder under the feature.
For hooks used only in this feature → Check hooks folder under the feature.

This logical separation makes onboarding new developers and scaling features significantly easier.

Wrapping Up

That’s pretty much it for the file patterns and practices I prefer in my React projects.

I hope this guide serves as a helpful reference or even a hand‑off document for your team when structuring future projects.

And remember — this approach isn’t about memorizing rules; it’s about following a simple, predictable pattern that makes your codebase easier to navigate and maintain.

When ChatGPT interacts with your Code 🧑🏼‍💻

Kartik Sharma — Sun, 19 Jan 2025 05:27:25 +0000

In this post, I'll guide you through the process of implementing function calling in your app. With this functionality, your app can feature a sophisticated chatbot that dynamically responds to users based on their context. By integrating function calling, the chatbot can execute actions—such as querying a database or triggering specific operations—directly from the conversation, making interactions more intelligent and seamless.

What the heck is Function calling anyway?

Function calling is a powerful feature within the OpenAI Assistant's API that enables applications to perform complex operations dynamically. It allows the Assistant to execute predefined actions, such as triggering database queries, making API calls, or invoking custom functions in your codebase, in response to user queries. This feature integrates seamlessly with your application's logic, making it a versatile tool for creating intelligent and interactive experiences.

Use Case of Function calling

Ditching Traditional Filtering in Your App

Filtering and sorting components are a staple in most applications, whether it's e-commerce or otherwise. However, instead of having users interact with traditional widgets to select product attributes like color, size, type, or budget, you can simplify the experience with plain English queries. For example, users can simply type something like, "White shirt in size medium for men under 2K," and let your app handle the rest.

Implementing Function Calling in the ChatGPT SDK

Implementing the function calling feature in the ChatGPT SDK is straightforward, especially if you're already familiar with the SDK. Here’s a simple step-by-step guide:

Define the Function and Its Argument Types

Start by specifying the function's behavior and clearly define its argument types. This ensures the Assistant understands how to call your function and what parameters it requires.
Integrate the Function into the Assistant API

Pass the defined function to the Assistant API using the tools parameter. This connects the function to the Assistant, enabling it to be called dynamically during interactions.
Test Your Implementation

Put your setup to the test! Run scenarios to ensure the function behaves as expected when invoked by the Assistant.

Define the Function and Its Argument Types

Defining a function tool is straightforward. It involves creating an object that specifies the actual function name to be triggered and its argument types. When defining arguments, you can also:

Specify the Data Type: Define the expected data type for each argument (e.g., string, number, boolean).
Set Argument Requirements: Indicate whether an argument is required or optional.
Enforce Specific Formats: Define any particular format the argument should follow, such as uppercase, lowercase, or specific patterns like date formats.

This level of customization ensures the function behaves predictably and meets the application's requirements.

Code Example of function definition:

{
  type: "function",
  function: {
    name: "search_product",
    description:
      "Search for a product in the e-commerce app based on user preferences.",
    parameters: {
      type: "object",
      properties: {
        color: {
          type: "string",
          description: "The color of the product (e.g., red, blue, white).",
        },
        item: {
          type: "string",
          description:
            "The type of item to search for (e.g., shirt, shoes, bag).",
        },
        name: {
          type: "string",
          description:
            "The name or brand of the product, if specified by the user.",
        },
        size: {
          type: "string",
          description:
            "The size of the product (e.g., small, medium, large, or numeric sizes).",
        },
        price: {
          type: "number",
          description:
            "The maximum price the user is willing to pay for the product.",
        },
      },
      required: ["item"],
    },
  },
}

Integrate the Function into the Assistant API

Once the function is defined, the next step is to connect it to the Assistant API instance. This integration ensures that the ChatGPT instance is aware of the function's existence and can trigger it whenever appropriate.

By passing the function definition through the tools parameter during the Assistant setup, you enable the model to leverage your custom function dynamically, making it a valuable part of the application's interaction flow.

Code Example:

import OpenAI from "openai";

// Initialize the OpenAI client with your API key
const apiKey = "Your-api-key";
const openAiClient = new OpenAI({ apiKey });

// Define the tools array and pass the function definition created earlier
const tools = [shoppingTool];

const performProductLookup = async (userQuery) => {
        // Send the user's query to the Assistant API
        const response = await openAiClient.chat.completions.create({
            model: "gpt-3.5-turbo",
            messages: [
                {
                    role: "user",
                    content: userQuery,
                },
            ],
            tools,
        });

        // Check if the Assistant invoked a tool (function)
        const toolCalls = response.choices[0]?.message?.tool_calls;
        if (toolCalls?.length > 0) {
            const functionCall = toolCalls[0].function;

            // If the invoked function matches "shoppingTool", parse its arguments
            if (functionCall.name === "search_product") {
                const parsedArguments = JSON.parse(functionCall.arguments);
                return {
                    name: functionCall.name,
                    arguments: parsedArguments,
                };
            }
        }

        // Return the general content string if no tool was invoked
        return response.choices[0]?.message?.content || "No content returned.";
};

(async () => {
    const productResponse = await performProductLookup(
        "White Shirt in size medium under 2K"
    );
    console.log(productResponse);
})();

Response from Assistant’s API:

{
  name: 'search_product',
  arguments: { color: 'white', item: 'shirt', size: 'medium', price: 2000 }
}

Once the user query is parsed and the relevant arguments (such as color, item, size, etc.) are extracted, you can pass them to the actual function responsible for performing a real-time database lookup. This function will query your database, search for matching products, and return the results, which can then be presented to the user in a structured format.

By using these arguments, you ensure that the lookup is dynamic and tailored to the user’s specific request.

That’s it! Now you have the flexibility to define the logic based on your specific needs and implement custom functionality for your application. Whether you're handling product lookups, automating workflows, or performing any other operation, the possibilities are endless.

Let me know in the comments how you’ve implemented this and if you have any questions or feedback.

Thanks for reading!

Automate Refresh Tokens with Axios Intercepters!

Kartik Sharma — Tue, 22 Oct 2024 16:18:43 +0000

The Problem

A while back, I was working on a small project that interacted with the Salesforce API and performed CRUD operations on my objects. I was using React.js (with no backend setup, just a static frontend). However, I encountered a problem while working with the API. The access token I generate using the OAuth method is valid for only 24 hours! This means I have to manually generate a new token by making an OAuth API call every time I refresh the application.

I don’t like how my application is making unnecessary API calls to Salesforce OAuth to refresh the token, even when it hasn’t expired. To overcome this, I want to implement the following logic in my code:

axios.get('https://www.someapi.com/fetch-data').then((data)=> {
// doing something with the Data
},{}).catch((error)=> {
    if(error.response.statusCode === 401){
        // If Token Expired
        RefreshToken()
        window.alert("Session Expired Please Reload the Window!")
    }
})

My logic is essentially this: if there’s a 401 response from the API endpoint, I make a refresh token API call, store the new token in local storage, and then prompt the user to reload the page to use the newly generated token for subsequent API calls. However, this approach relies on the user to perform an additional action, which could be automated to improve the user experience and avoid unnecessary interruptions.

Using Axios Intercepters

Let’s see it in action

axios.interceptors.response.use(
  (response) => response,
  async function (error) {
    const originalRequest = error.config;
    if (error.response.status === 401 && !originalRequest._retry) {
      if (isRefreshing) {
        return new Promise((resolve, reject) => {
          failedQueue.push({ resolve, reject });
        })
          .then((token) => {
            originalRequest.headers["Authorization"] = "Bearer " + token;
            return axios(originalRequest);
          })
          .catch((err) => {
            return Promise.reject(err);
          });
      }

      originalRequest._retry = true;
      isRefreshing = true;

      return new Promise((resolve, reject) => {
        initiateNewAccessTokenApi()
          .then((token) => {
            axios.defaults.headers.common["Authorization"] = "Bearer " + token;
            originalRequest.headers["Authorization"] = "Bearer " + token;
            processQueue(null, token);
            resolve(axios(originalRequest));
          })
          .catch((err) => {
            processQueue(err, null);
            reject(err);
          })
          .finally(() => {
            isRefreshing = false;
          });
      });
    }

    return Promise.reject(error);
  }
);

Code Explanation

What I did was attach a middleware to every request that Axios makes, checking if any response comes back with a 401 HTTP status code. If it does, I re-initiate the access token by calling the refresh token API, store the new token in local storage, and automatically re-trigger all the previous API calls that were denied. That’s it! No more asking the user to ‘reload the window!’ 😸

I hope this helps and integrates well with your work!