Forem: Surjoyday Talukdar

I ran npm run dev but it is saying next command not found

Surjoyday Talukdar — Thu, 13 Mar 2025 21:10:43 +0000

Fix 'sh: next: command not found' in Next.js – Quick & Easy Solution!

Surjoyday Talukdar ・ Mar 13

#webdev #programming #javascript #nextjs

Fix 'sh: next: command not found' in Next.js – Quick & Easy Solution!

Surjoyday Talukdar — Thu, 13 Mar 2025 21:09:55 +0000

I recommend following the steps below, as suggested by timneutkens in the Next.js GitHub issue #8945. Installing Next.js globally can cause multiple issues when deploying to production.

Steps to Fix:

In your terminal type:
nano ~/.zshrc
Scroll to the very end of the .zshrc file and add the following lines to include the locally installed node_modules/.bin directory in your PATH:

export PATH="./node_modules/.bin:$PATH"

Save and exit the file:

Press CTRL + X to exit.
Press Y to confirm saving.
Press Enter to save the changes.

Apply the changes by running: source ~/.zshrc

This ensures that your locally installed dependencies are prioritized without requiring a global installation of Next.js.

How to Handle Errors When Accessing Context Outside the Provider in React

Surjoyday Talukdar — Sat, 21 Sep 2024 21:40:40 +0000

When working with React’s Context API, it’s important to handle cases where components try to access context outside the Provider. If you don't, it could lead to unintended results or hard-to-track bugs.

The Issue
When you create a context using createContext(), you have the option to pass in a default value. This default value is what gets returned if a component tries to access the context outside of the Provider.

If you don’t pass a default value to createContext(), accessing the context outside a Provider will return undefined.
If you do pass a default value (like null or any other value), that value will be returned instead when the context is accessed outside of a Provider.

For example:

const PostContext = React.createContext(null); // Default value is null

In this case, if a component tries to access PostContext without being wrapped in a Provider, it will return null.

The Fix: A Custom Hook with Error Handling
To avoid situations where the context is accessed outside its Provider, we can create a custom hook that throws an error if the context is accessed incorrectly. This is useful for catching mistakes early in development.

function usePosts() {
  const context = useContext(PostContext);

  if (context === null) {
    // checking for "null" because that's the default value passed in createContext 
    throw new Error("usePosts must be used within a PostProvider");
  }

  return context;
}

Why This Matters
If no error handling is in place, accessing context outside of its Provider could return null, undefined, or whatever default value you used. This can lead to hard-to-debug issues in your app. By throwing an error, it’s much easier to catch and fix the problem early.

Managing State in Multiple Instances of the Same Component in React

Surjoyday Talukdar — Thu, 22 Aug 2024 19:56:12 +0000

When you're working with React and have multiple instances of the same component, managing state can get tricky. Depending on how your components need to interact, you'll want to handle state differently. Here’s what I’ve found works well.

Independent Instances: Keep State Inside the Component

If your components don’t need to talk to each other, it’s best to keep their state inside the component. This way, each instance has its own state, and changes in one don’t affect the others.

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

// Usage
<Counter /> // Instance 1
<Counter /> // Instance 2

Here, each Counter component keeps track of its own count. So, if you click the button in one counter, it doesn’t change the count in the other.

Dependent Instances: Manage State in the Parent Component

But if the components need to share some state or work in a coordinated manner, it’s better to move the state up to the parent component. The parent can manage the shared state and pass it down as props. This ensures that all instances stay in sync and work together smoothly.

function Parent() {
  const [sharedCount, setSharedCount] = useState(0);

  return (
    <div>
      <p>Total Count: {sharedCount}</p>
      <Counter count={sharedCount} setCount={setSharedCount} />
      <Counter count={sharedCount} setCount={setSharedCount} />
    </div>
  );
}

function Counter({ count, setCount }) {
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

This approach works because when the state is in the parent component, any update to that state triggers a re-render of all instances, ensuring they all display the latest UI. If the state were kept in each instance separately, only the instance with the state change would re-render, leading to inconsistent UI across instances.

Examples from My Projects

I figured this out while building an accordion component. Here are two examples from my own work:

Independent Accordion Instances: example. In this setup, each accordion instance works independently.
Dependent Accordion Instances: example. In this version, all accordion instances depend on each other and stay in sync.

Quick Recap

If components work separately, keep state inside each component.
If they need to share state or work together in a coordinated manner, manage the state in the parent.

This approach made a big difference for me when building these accordion examples. Hope it helps you too!

The Story behind typeof null returning "object" in Javascript

Surjoyday Talukdar — Sat, 10 Aug 2024 22:46:55 +0000

Like in many languages, JavaScript represents objects as references (pointers) to memory locations where the object data is stored. When JavaScript was created, null was represented as a special pointer value that didn't point to any memory location (a "null pointer"). When the typeof operator was later introduced, it used the same internal mechanism of the JavaScript engine to check the type of values. Since null was represented as a special type of object (a null pointer), the typeof operator returns "object" for null. This behavior, though technically a bug, has not been fixed to maintain JavaScript's backward compatibility.

What happens each time that we require a module by calling the require function with the “module” name as the argument.

Surjoyday Talukdar — Sun, 09 Jun 2024 13:32:41 +0000

First the path to the require module is resolved and the file is loaded.
After the module is loaded, the modules code is wrapped into a special function which will give us access to a couple of special objects.

The NodeJS runtime takes the code of our module and puts it inside an IIFE (the wrapper function is an IIFE), so it means Node does not directly execute the code that we write in the module and that we required using the require function, but instead its the “ wrapper (IIFE) function” that will contain our code in it’s body and will then execute our code . The “wrapper IIFE” is also the one that passes the “exports”, “require”, “module”, “__dirname” “__filename” into the module (file) and that is why in every module we automatically have access to stuff like the require function.

→ By doing this Node achieve 2 important things :

i. Firstly doing this gives developer access to all the variables like “require”, “__filename”, etc.
ii. Secondly it keeps the “top-level variables ( variables declared outside of any function )” that we define in our modules private, so scoped only to the current module, instead of leaking everything to the global object.

Example : If we have 2 modules and we export module 1 to module 2 then all the top-level variables of module 1 are now scoped inside the wrapper function of the module 2 instead of leaking the everything from the module 1 into the global object. It promotes modularity, prevents naming conflicts, and offers controlled access to functionalities within modules

math.js (Module 1):

// Top-level variable (private)
const PI = 3.14159;

function add(a, b) {
  return a + b;
}

exports.add = add; // Expose the add function

app.js (Module 2):

const math = require('./math');

console.log(math.add(5, 3)); // Output: 8 (using the exported function)

// Cannot access PI directly from math module
// console.log(PI); // This would result in an error

3.After that the code in the module’s “wrapper function” is EXECUTED by the Node.JS runtime.

4.Now after the code execution it time for the “require” function to return something and whats returns is the exports of the required module. This exports are stored in the “module.exports” object

→ When to use “module.exports” or simply “exports”

i. We use module.exports to export single variable, e.g. one class or one function and set it equal to the variable (module.exports = Calculator )
ii. We use exports when we want to export multiple named exports like multiple function, for example , exports.add = (a+b) => a+b

5.And finally the entire module gets “Cached” after the first time they are loaded, meaning if we require the same module multiple times we always get the same result and the code and modules is only executed in the first call , in subsequent calls the result is then retrieved from the cache.