Forem: Vijay

Struggling with 'command not found' on Mac?

Vijay — Thu, 07 Aug 2025 08:21:23 +0000

You open a new terminal window. You type a command.

But your Mac says, "command not found." It's super annoying.

What’s going on here?

The Problem: Your Terminal Forgot Everything

You're trying to use a command like nvm. It's a handy tool, right? But your computer has no idea what you're talking about.

This happens with tools you install with Homebrew. The nvm command only works after you run a specific command.

You have to tell your terminal about it again.

The Explanation: Shell Configuration

Think of your terminal like your buddy. When you first say hi, he's got a fresh memory. He doesn't remember anything from your last chat.

The special source command is how you remind him. It's a command that tells the shell to run a file's commands. It's like you're loading a script.

That script tells your shell where to find nvm. Now your terminal remembers what to do.

The Solution: Make It Automatic

We need to make sure your terminal remembers this automatically. We do that by editing a special file. This file runs every time you open a new terminal.

You just need to put that source command inside.

Step 1: Find your shell's config file.

Most modern Macs use zsh. If you're using zsh, you'll want to edit the .zshrc file. If you have an older Mac, it might be bash.

Then you'll need to edit the .bash_profile file. Not sure? Just type echo $SHELL.

Step 2: Add the fix to the file.

Open your file with a simple command. Use nano ~/.zshrc or nano ~/.bash_profile. Scroll to the bottom of the file.

Paste this little snippet of code there.

export NVM_DIR="$HOME/.nvm"
[ -s "$(brew --prefix)/opt/nvm/nvm.sh" ] && \. "$(brew --prefix)/opt/nvm/nvm.sh" # This loads nvm

Step 3: Save and restart your terminal.

Hit Ctrl + X to exit and save. Then open a new terminal window. You can also run source ~/.zshrc or source ~/.bash_profile to try it right away.

Now, your terminal should remember your nvm command every time. No more "command not found" errors.

It’s a simple fix for a common headache.

You've just automated your terminal's memory. It’s a small change. But it makes a big difference.

Now you can get back to coding without the hassle. Pretty cool, right?

Prompting Techniques in Gen AI: The Founder's Guide to Getting Better Results

Vijay — Mon, 28 Jul 2025 13:21:28 +0000

Most founders are terrible at prompting.

They treat AI like Google search. They type random questions. Then wonder why outputs suck. Your prompting strategy determines everything.

Better prompts = better results = better ROI.

Here's how to actually do it right.

What Good Prompting Actually Is

Think of prompting like giving instructions to an intern.

You wouldn't just say "write something." You'd provide context. Set expectations. Give examples. Explain the goal.

AI works the same way.

Good prompts have four parts:
• Clear context about the situation
• Specific task you want done
• Expected format for the output
• Success criteria or constraints

Bad prompts are vague. Good prompts are precise.

The difference? Hours of time saved. And results you can actually use.

The Anatomy of Effective Prompts

Every great prompt follows a pattern.

It's not magic. It's just structure. Here's the framework I teach every founder:

Context: Set the stage first.
"You're a marketing expert helping a B2B SaaS startup."

Task: Be specific about what you want.
"Write three subject lines for our product launch email."

Format: Tell it how to respond.
"Format as a numbered list with brief explanations."

Constraints: Add guardrails.
"Keep each subject line under 50 characters."

This takes 30 seconds to write. But saves hours of back-and-forth.

The 5 Biggest Prompting Mistakes I See

Most founders mess up the basics.

They skip context. Use vague language. Don't iterate. These mistakes cost time and money.

Mistake #1: Being too generic
Bad: "Write marketing copy"
Good: "Write a 100-word product description for our project management tool targeting small business owners"

Mistake #2: No examples provided
Always show what good looks like. AI learns from examples better than explanations.

Mistake #3: Forgetting to specify format
Do you want bullets? Paragraphs? A table? Say it upfront.

Mistake #4: Not iterating on results
First output is rarely perfect. Ask for revisions. Be specific about changes.

Mistake #5: Treating each prompt like a one-shot
Build conversations. Reference previous outputs. Create context chains.

Fix these five things. Your results improve immediately.

Advanced Techniques That Actually Work

Once you master the basics, try these.

These techniques separate good prompters from great ones. They're not complicated. Just specific.

Chain of Thought Prompting
Ask AI to think step-by-step. Add "Let's think through this step by step" to complex requests.

Role-Based Prompting
Start with "You are a [specific expert]." This primes better responses.

Few-Shot Learning
Give 2-3 examples of input/output pairs. AI picks up patterns quickly.

Constraint Laddering
Start broad. Add constraints gradually. This prevents over-specification early.

Output Formatting
Use templates. "Respond using this format: Problem: [X], Solution: [Y], Impact: [Z]"

These techniques work. But only if you use them consistently.

How to Train Your Team on Prompting

Your team needs prompting skills too.

Don't assume they'll figure it out. Good prompting isn't intuitive. It's a learnable skill.

Here's my training approach:
• Start with the basic framework
• Practice on real company tasks
• Share successful prompts across teams
• Create a prompt library
• Review and iterate together

Common training mistakes:
• Teaching too many techniques at once
• Not practicing on real work
• Skipping the feedback loop
• Treating it as one-time training

Make prompting part of your process. Not an afterthought.

Measuring Prompt Effectiveness

You can't improve what you don't measure.

Track these metrics for your AI initiatives:

Time to useful output: How long until you get something usable?

Revision cycles needed: How many back-and-forth rounds?

Output quality scores: Rate results on accuracy and relevance.

Team adoption rates: Who's actually using AI tools?

Cost per useful output: Factor in API costs and time spent.

Most founders skip measurement. Then wonder why AI isn't working.

Building Prompting Systems That Scale

Individual great prompts are nice. Systems are better.

Here's how to scale prompting across your startup:

Create prompt templates
Build reusable prompts for common tasks. Marketing copy. Code reviews. Customer support.

Build prompt libraries
Document what works. Share across teams. Version control your best prompts.

Establish quality standards
Define what good output looks like. Train your team to recognize it.

Automate repetitive prompts
Use APIs for recurring tasks. Don't manually copy-paste the same prompts.

Monitor and optimize
Track performance. Update prompts based on results. Iterate constantly.

The goal isn't perfect prompts. It's consistent, scalable results.

What This Means for Your Startup

Good prompting is a competitive advantage.

While competitors struggle with poor AI outputs, you'll get better results faster. Your team will be more productive. Your AI investments will actually pay off.

Start with the basics:
• Use the four-part prompt structure
• Avoid the five common mistakes

• Train your team properly
• Measure what matters
• Build systems that scale

The companies winning with AI aren't the ones with the biggest budgets. They're the ones with the best prompting.

Your AI is only as good as your prompts. Make them count.

Why Gen AI Isn't Optional for Your Startup Anymore

Vijay — Mon, 28 Jul 2025 10:36:27 +0000

Your competitors are already building with AI.

Here's what every software product owner needs to know about staying competitive in 2025. Generative AI isn't some distant future tech anymore. It's here, it's accessible, and it's changing everything about how we ship products.

The question isn't whether you should adopt it. The question is how fast you can move.

The Window for AI Advantage Is Closing Fast

Remember when having a mobile app was revolutionary?

That advantage lasted maybe 18 months before everyone caught up. AI adoption is happening even faster. Your customers are already using ChatGPT, Claude, and other AI tools daily. They expect that same intelligence in your product.

Here's the brutal truth: if you're not integrating AI features now, you're falling behind. Your users will find alternatives that do. And they won't look back.

But Integration Doesn't Have to Be Overwhelming

You don't need a PhD in machine learning to get started.

The barrier to entry has dropped dramatically. Here's what's actually required:

API integrations (you're already doing this with payments, auth, etc.)
Basic prompt engineering (think of it like writing good search queries)
User experience design (your bread and butter)
Data handling best practices (table stakes for any app)

Start small. Pick one workflow your users repeat constantly. Add AI to make it faster, smarter, or more personalized.

Your Customers Are Already Thinking AI-First

I talked to a founder last week who was shocked.

His users were copying data from his app into ChatGPT to get insights he could have provided. They were literally leaving his product to get the AI experience they wanted.

Think about your user journey. Where do people get stuck? Where do they need to think hard or do repetitive work? Those are your AI opportunities.

Your customers aren't asking for AI features because they assume you'll figure it out. But they're quietly evaluating alternatives that do.

The Economics Actually Make Sense Now

Here's what surprised me most about AI integration costs.

The API calls are cheaper than you think. GPT-4 costs about $0.03 per 1,000 tokens. That's roughly 750 words. For most use cases, you're talking pennies per user interaction.

Compare that to:

Customer support tickets you won't need to handle
Features you won't need to build from scratch
User churn you won't experience
Development time you'll save on repetitive functionality

The ROI calculation is getting easier every month.

Start With These Three Areas

Don't try to AI-ify everything at once.

Focus on these high-impact, low-risk areas first:

Content generation: Help users create, edit, or optimize text
Data analysis: Turn spreadsheets into insights automatically
Smart automation: Reduce clicks and repetitive tasks

Pick the one that directly impacts your core metrics. Revenue, retention, or user activation. Build it, ship it, measure it.

Then move to the next one.

Your competition isn't waiting for perfect.

They're shipping AI features that are good enough to delight users. You should be too.

The startups winning in 2025 won't be the ones with the most sophisticated AI. They'll be the ones who integrated it thoughtfully, quickly, and kept iterating.

Your users are ready. The technology is ready. The question is: are you?

Your Features Are Boring Users to Death

Vijay — Sat, 19 Jul 2025 13:03:05 +0000

Are you writing product copy like engineering documentation, not sales material?

Probably, you are making the three mistakes below:

Mistake #1: You're Listing Features, Not Benefits

You describe what your product does. Users care about what it does for them.

Instead of "Advanced AI-powered analytics dashboard," try "See which customers will churn before they leave." Don't list technical specs. Show the outcome users get.

Your features should make users think "I need this."

Mistake #2: You're Speaking Geek, Not Human

You use words like "optimize," "leverage," and "streamline." Normal people don't talk like that.

Say "makes your work faster" instead of "optimizes workflow efficiency." Write like you're explaining to your mom. She's smart, but she's not a developer.

Drop the buzzwords. Use simple language.

Mistake #3: You're Not Solving Their Pain

You focus on how cool your product is. Users want their problems solved.

Start with their frustration: "Tired of losing customers without knowing why?" Then show your solution. Make it about them, not you.

Address their 3 AM worries directly.

Stop writing like a manual. Start writing like a human who understands other humans' problems.

Turn Boring Features Into Customer Magnets

Vijay — Fri, 18 Jul 2025 13:17:53 +0000

Most founders can build amazing products.

But they can't write compelling copy. Your features sound boring and technical. Customers scroll past without reading anything.

Formula #1: Feature → Benefit → Outcome

Start with what it does first.

Then explain what that means exactly. Finally, show the end result. This creates a clear path.

Example: "Auto-backup saves work every minute. You'll never lose progress again. Sleep better knowing data's safe."

Features become benefits when connected properly. Use this formula everywhere possible.

Formula #2: Problem → Solution → Result

Lead with customer pain first.

Show how you fix it completely. End with their total transformation.

Example: "Tired of manual invoicing? Auto-invoice creates bills instantly. Get paid faster, work less."

Pain-first writing hooks readers immediately. They feel understood and valued.

Formula #3: Before → After → Impact

Paint their current frustrating state clearly.

Show the improved reality after. Explain why it matters most.

Example: "Before: Hunting through folders daily. After: Find anything in clicks. Save three hours weekly."

Contrast makes benefits crystal clear. People love dramatic transformations.

These formulas work for any feature. Practice them on your worst copy. Your conversion rates will thank you.

Stop listing features like grocery items. Use these formulas to sell instead. Your customers will actually read everything. Sales will follow naturally.

Solving Dynamic Layout With CSS Grid

Vijay — Fri, 16 May 2025 10:35:56 +0000

Today, I had a requirement to render a list of items in two columns.

Interestingly, 2 of the items need to use both columns.

First, I tried to use Flexbox, and then I thought, let's use Grid.

To test it out, I created a simple HTML structure for grid layout.

Here it is:

<div class="grid-container">
    <div class="grid-item">1</div>
    <div class="grid-item">2</div>
    <div class="grid-item">3</div>
    <div class="grid-item">4</div>
    <div class="grid-item">5</div>
    <div class="grid-item">6</div>
    <div class="grid-item span-both">7</div>
    <div class="grid-item span-both">8</div>
</div>

In this structure, I created a grid container with 8 items. I needed to span the 7th and 8th items to use both columns. So I have added one more class on it span-both.

And then I added below CSS code to make it work.

.grid-container {
    display: grid;
    grid-template-columns: repeat(2, 1fr); /* Two columns */
    gap: 10px; /* Space between items */
}

.grid-item {
    background-color: lightblue;
    padding: 20px;
    text-align: center;
}

.span-both {
    grid-column: 1 / -1; /* Span both columns */
}

You might be thinking, 'How does that work?'

So here is my explanation:

Grid Container: The display: grid; property activates the grid layout. I used grid-template-columns: repeat(2, 1fr); to create two equal columns.
Styling Grid Items: I gave each grid item a light blue background and some padding for better visibility.
Spanning Columns: The .span-both class uses grid-column: 1 / -1;, allowing the 7th and 8th items to stretch across both columns, making them stand out.

That's it for today.

Feel free to experiment with different layouts, colors, and spacing to create a grid that suits your needs.

Or let me know if you are having any issues.

Happy coding!

5 Surprising and Lesser-Known HTTP Methods Facts Every Developer Should Know to Avoid API Pitfalls

Vijay — Tue, 22 Oct 2024 12:58:18 +0000

Not just backend developers—frontend developers should also have a solid understanding of HTTP methods.

And I’m sure you understand it will. But if not, here is a refresher for the most common HTTP methods.

GET: is the method used to retrieve data from the server.
POST: is how you send data to create resources.
PUT: is used to update or create a resource.
DELETE: removes a resource from the server.
PATCH: makes partial updates to an existing resource.

While they are doing great for their purpose, they have some more power, which is not very common.

Let’s see what are those:

Fact #1: GET Can Include a Body (But It’s Rarely Used)

GET requests usually don’t have a body, but they technically can.

You must be wondering why someone will send a body in GET; for that purpose, we already have POST. Yeah, you're right, but there are some cases where it can be useful. For example, in the case of Long URLs. You might need some parameters that can’t be sent in the URL due to its length restriction. In that case, sending in the body in JSON format can be useful. But it’s always better to use other methods like POST when you need to send data.

GET is flexible, but using a body is uncommon for good reason.

Fact #2: POST is Not Always About Creating Resources

While POST is known for creating new resources, it is also used for complex queries.

There are several use cases where the APIs need to filter the data based on several conditions. That condition can result in complex queries that can’t be sent in URLs due to their length restriction. In that case, POST might be a better choice than GET, as it can carry more data in the request body.

So, POST is versatile beyond just creating resources.

Fact #3: PUT vs PATCH: More Than Just Syntax

PUT replaces the entire resource, while PATCH makes partial updates.

If you use PUT to update a user profile, you must send the whole resource, even if only one field changes. Otherwise, all other details will be lost. In this case, PATCH is more efficient when only a small part of the data needs updating.

Remember, PATCH is your go-to for small, efficient updates.

Fact #4: DELETE Can Return a Body

It’s not common, but DELETE requests can return a response body.

After the DELETE requests are successful, it returns the confirmation that the resource was removed. But you can design your APIs in such a way that they can return the deleted resource’s details in the response. You may ask what the use of it is. They can be useful if you want to log in or display confirmation of the deleted data.

Well, DELETE isn’t just for removing—it can provide useful feedback, too.

Fact #5: Safe and Idempotent Aren’t the Same

Methods like GET are both safe and idempotent, but these terms mean different things.

A safe method doesn’t change the server’s state, while an idempotent method guarantees that repeating the request has the same effect every time. For example, DELETE is idempotent but not safe since it changes the server state by removing a resource.

Now, you may ask me, what is the point of knowing these lesser-known facts?

If you know these, the chances of unexpected behaviour in your APIs will be less.

I hope these lesser-known details will help you design and work with APIs more effectively. Let me know what other facts you know. Happy coding.

If you have enjoyed reading this, follow me on Twitter/X to read more.

5 Key Techniques to Create Responsive Layouts So That You Don’t Have to Relying On Heavy CSS Frameworks

Vijay — Mon, 21 Oct 2024 15:44:18 +0000

You don’t need heavy CSS frameworks to build responsive layouts.

CSS frameworks like Tailwind and Bootstrap are really powerful, but sometimes, they are too much for smaller websites. You can achieve all those features offered by them in pure CSS code. Under the hood, they all use the same basic technique for responsive websites.

In fact, if you really want to know how those frameworks and responsive websites work, then you need to understand the 5 fundamental techniques.

Here are the 5 techniques to make your website responsive:

Technique #1: Configure the Viewport

Did you know a single meta tag can control how your website scales on any screen size?

Yeah, that meta tag is Viewport.

If you don't know what the Viewport is, then Viewport is the visible area on a webpage on a device, whether it is a phone, tablet or desktop. You may ask what it does. It determines how content is scaled and displayed based on the device's screen size.

Since the screens come in various sizes, the Viewport plays a crucial role in making the website responsive.

Now, how to use it?

Simply use the Viewport meta tag in your HTML file.

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Technique #2: Adopt a Mobile-First Approach

If you’re not designing mobile-first, you’re doing it wrong.

Because over half of web traffic today comes from mobile devices. And that’s what approach Tailwind adopted. And they are asking you to do the same. Here, we are talking about using pure CSS instead of a framework, but the approach is still the same.

The mobile-First approach helps in the longer term, as you will have to write multiple versions of the same code for different types of devices.

Technique #3: Utilize CSS Grid and Flexbox

Are you still using Float-based layout for your website?

I hope you are not. And if you are still using it, then it is time to switch to Flexbox and CSS Grid since they are powerful tools for creating flexible layouts.

When you need to create a one-dimensional layout, go for Flexbox

And When you need to create a two-dimensional layout, then go for Grid

Technique #4: Create Fluid Layouts

Are you using fixed pixel values everywhere on your website?

Most developers choose to go with pixel(px) value while developing the different layouts on the screen. Pixel values are great for fixed layouts but not so great for responsive layouts. If you use a fluid layout like a percentage-based value, then your layout will smoothly resize on any viewport size.

.container {
    width: 90%;
    margin: 0 auto;
}

Technique #5: Use Media Queries Wisely

Media Queries are another helpful technique for making responsive layouts

But it needs to be used wisely. It is using different breakpoints for different layouts. Most developers go wrong with it. They start creating for all possible screen sizes, which leads to unmanageable code.

In my suggestion, media queries should be made on key transitions between device categories. For e.g. Mobile to Tablet, Tablet to Desktop.

All right, as you can see, there are multiple techniques available to make your website responsive. On paper, it looks like 5 different techniques are ready to be used, but practically, when you start working on any production website, you will start seeing the use case of all those techniques.

Now go and build a responsive site, and let me know what you used at its best.

If you have enjoyed reading this, follow me on Twitter/X to read more.

3 Reasons Why Mastering JavaScript Fundamentals Is Crucial for Frontend Developers for Long-Term Career Success

Vijay — Fri, 18 Oct 2024 07:59:41 +0000

9 years ago, I tried to learn Angular 1.

And I failed it badly. I was frustrated and scared. I didn't touch it for the next 7-8 months.

One day, I got my chance to throw my frustration in front of my friend. My friend asked a straightforward question. Do you know any of the below concepts?

Scope and the Scope chain
this keyword
Closures
Dependency injection
Call by Value vs Call by Reference

I was looking into his eyes deeply lost in nowhere.

He only said - You need to master JavaScript Fundamentals.

And so do you.

Here are 3 more reasons why:

Reason #1: Framework Independence

Do you get excited about every shiny new JavaScript framework there or get scared?

Let me tell you, if your JavaScript fundamentals are strong, then you will love it; otherwise, you will be in a constant state of fear.

Why is that so?

The reason is simple - under the hood, all the framework is dependent on JavaScript itself and uses its capabilities. If you understand the fundamentals, then no framework is challenging to learn.

Reason #2: Problem-Solving Capabilities

Are you failing your interview due to a lack of problem-solving capabilities?

Instead of grinding 100 of the LeetCode problems, I would instead take a different approach - develop your own polyfill version of all JavaScript inbuilt methods like map, filter, and reduce.

There are two benefits to doing so

You will deeply understand how all those methods work under the hood
Your problem-solving capability will skyrocket.

Reason #3: Code Quality and Maintenance

Need help fixing bugs quickly?

Every day, we deal with code that's messy, hard to read, and a pain to debug. This happens because developers ignore the basics. When you get the fundamentals right, it's hard to write messy code. By focusing on clean, readable, and maintainable code, you set yourself and your team up for success.

Technical debt is something you should always take seriously.

I hope you understand why mastering the fundamentals are important than switching to every new framework.

Now, go and nailed it. All the best.

If you have enjoyed reading this, follow me on Twitter/X to read more.

The CLEAN Framework: A 5-Step Blueprint for Writing Bug-Free, Maintainable JavaScript Code

Vijay — Thu, 17 Oct 2024 09:31:53 +0000

Friday evening with the bug. What a scary dream.

No, it's not a dream. It can happen. In fact, it happens so often that you start wondering about yourself and your team's skills.

How can you minimise the bug, by the way?

I have devised a framework to rescue you—the CLEAN Framework for Clean Code.

C → Consistency is the king.

Make your code consistent. What that means, if you asked?

When you start solving the bug, you see the variable names x, y, and z. You are wondering what the hell those are. You trace back all the places it is used and come to know that it is for updating the name, address and email variable. Now, you are cursing yourself as to why you have used x, y, and z instead of a racial variable name to waste your precious Friday evening on a unavoidable bug.

So, what to do?

In my way, follow a style guide. Like Airbnb or Google does. I prefer Airbnb.

Airbnb Style Guide - https://github.com/airbnb/javascript

Google Style Guide - https://google.github.io/styleguide/jsguide.html

L → Lean Functions and Modules

Break it down now, y'all!

Wondering what and why I'm suggesting to breaking things up?

Well, Cool down. I'm not saying to break the keyboard in front of you. I suggest breaking down the more extended functions you wrote, which are now difficult to read and understand what's going on. Break it down so that each function does and does one thing well—like a helper function, helping your original function code.

Small, focused functions are the secret sauce of maintainable code.

E → Efficient Optimisation

Speed is necessary, but not at the expense of readability and bug-free code.

I know, I know. You will say, I have to complete that feature faster as the deadline is near. Now I will ask you how you gonna solve that bug with the same lightning speed you wrote the original code.

Not easy. Right?

But here is this. Start with writing your feature. Once you are done and before you push your code for review, ask yourself how you can optimise the code. Should I have used map instead of forEach? Should I have used for...of loop instead of for loop?

Optimised code is happy code, and happy code makes for happy developers.

A → Antique Code Care

Legacy codes are boring, but actually, they are viable antiques.

Someone spends a lot of time understanding the requirement and making it work. You are right; sometimes, it is not the best optimised and readable code. But now it's in your hands to make it right. If time allows, refactor it slowly and steadily. Take one step at a time to keep the original features intact.

Respect the legacy, but don't be afraid to nudge it into the future gently.

N → New Feature Adoption

There is the reason why ES6+ feature keep adding.

They are not just shiny new toys; they are the new superpower of writing cleaner and more efficient code. Arrow functions, destructuring, and template literals are the Swiss Army knife of JavaScript. And let's not forget about asynchronous programming. Promises and async/await are like traffic controllers for your code, keeping everything flowing smoothly without any pile-ups.

Modern features make your code more expressive and your life easier.

Bonus: Test, Debug, Repeat

A well-tested codebase is a happy codebase.

How do you feel when you go for a blood test and find nothing major? Yeah, the codebase can feel the same way if you imagine it. In fact, if the code is well tested, there is less chance of getting a bug on Friday evening.

Writing tests are bonus, but it is a must to have.

Remember, you've got this! You're well-equipped to tackle any JavaScript challenge with the CLEAN framework (Consistency, Lean modules, Efficient optimisation, Antique code care, and New feature adoption). Now go forth and code like the JavaScript ninja you are!

If you have enjoyed reading this, follow me on Twitter/X to read more.

Difference Between Jest, Enzyme and React Testing Library

Vijay — Thu, 02 May 2024 14:49:58 +0000

Jest, Enzyme, and React Testing Library (RTL) are popular tools for testing React applications, but they serve different purposes and have different philosophies.

Jest:

Jest is a testing framework developed by Facebook.

It's widely used for testing JavaScript code, including React applications. Jest is known for its simplicity and ease of use. It's an all-in-one solution for testing, providing utilities for test runners, assertions, mocking, and code coverage.

Jest's key features include:

Test Runners: Jest provides a test runner that executes test cases and provides results.
Assertions: It includes built-in assertion utilities to verify the correctness of the code.
Mocking: Jest allows easy mocking of modules and functions.
Snapshots: It supports snapshot testing, which captures the output of a component and compares it to a previously saved version.
Code Coverage: Jest can generate code coverage reports to help identify untested code.

// sum.js
function sum(a, b) {
  return a + b;
}
module.exports = sum;

// sum.test.js
const sum = require('./sum');

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

// Snapshot testing a React component
test('renders a button correctly', () => {
    const { getByText } = render(<Button>Click Me</Button>);
    expect(getByText('Click Me')).toMatchSnapshot();
});

Enzyme:

Enzyme is a testing utility for React developed by Airbnb.

It provides tools to make testing React components easier and more intuitive. Enzyme focuses on component-level testing, allowing you to shallow or deep render components and interact with them in tests.

Enzyme's key features include:

Shallow Rendering: Rendering only the component and not its children, useful for isolating unit tests.
Full DOM Rendering: Rendering the full DOM, including child components, for more comprehensive integration testing.
Component Interactions: Enzyme allows you to simulate user interactions such as clicks and input changes.
Assertions: While Enzyme itself doesn't include assertion utilities, it's often used in conjunction with Jest or other assertion libraries.

// MyComponent.js
import React from 'react';

function MyComponent({ onClick }) {
  return <button onClick={onClick}>Click me</button>;
}
export default MyComponent;

// MyComponent.test.js
import React from 'react';
import { shallow } from 'enzyme';
import MyComponent from './MyComponent';

test('click event', () => {
  const mockFn = jest.fn();
  const wrapper = shallow(<MyComponent onClick={mockFn} />);
  wrapper.find('button').simulate('click');
  expect(mockFn).toHaveBeenCalled();
});

React Testing Library (RTL):

React Testing Library is a lightweight testing library for React developed by Kent C. Dodds.

It promotes writing tests that resemble how users interact with your application. RTL encourages testing components in the way they are used by end-users, focusing on behavior rather than implementation details.

RTL's key features include:

Queries: RTL provides a set of query methods to select elements in the DOM, similar to how users would find elements.
Accessibility: It emphasizes testing accessibility features, ensuring your components are usable by all users.
No Component API: RTL doesn't provide utilities for manipulating or inspecting components directly, encouraging testing from the user's perspective.
Integration with Jest: While RTL can be used with any test runner, it integrates seamlessly with Jest.

Example RTL Test:

// MyComponent.js
import React from 'react';

function MyComponent({ onClick }) {
  return <button onClick={onClick}>Click me</button>;
}
export default MyComponent;

// MyComponent.test.js
import React from 'react';
import { render, fireEvent } from '@testing-library/react';
import MyComponent from './MyComponent';

test('click event', () => {
  const mockFn = jest.fn();
  const { getByText } = render(<MyComponent onClick={mockFn} />);
  fireEvent.click(getByText('Click me'));
  expect(mockFn).toHaveBeenCalled();
});

Choosing the right tool depends on your project's needs:

Jest: If you need a general-purpose testing framework for JavaScript, including React components, Jest is a solid choice.
Enzyme: If you need to test complex React components with intricate internal state or logic, Enzyme can be helpful.
React Testing Library: If you prioritize testing from a user's perspective and want to ensure that components behave as expected in response to user interactions, React Testing Library is often preferred.

In many cases, a combination of these tools can be effective, using Jest as the test runner, React Testing Library for user-facing behavior, and Enzyme for specific situations where testing internal state is necessary.

3 Key Steps of Diffing Algorithm in React for Efficiently Updating the Real DOM

Vijay — Wed, 01 May 2024 14:10:57 +0000

Ever wondered how React's diffing algorithm manages to efficiently update the real DOM ?

React's diffing algorithm is a crucial mechanism that efficiently updates the real DOM based on changes in the virtual DOM. It plays a significant role in React's performance optimization by minimizing the number of DOM manipulations required.

Here are the 3 key steps.

1. Virtual Dom Generation

After a state or prop change, React creates a new virtual DOM tree that reflects the updated UI state.
Virtual DOM is a lightweight in-memory representation of the UI.

2. Recursive Comparison

React's diffing algorithm recursively compares the root nodes of the previous and new virtual DOM trees.
It employs a heuristic approach with the following key principles:
- Element Type: If elements have different types (e.g., div vs. span), they are considered entirely different and replaced.
- Key Prop: If elements have the same type and a key prop, React assumes their order and identity are significant. It rearranges or replaces elements based on key changes.
- Text Content: If elements have the same type and no key prop, React compares their text content. If different, the element's text is updated.
- Attributes: If elements have the same type and content, React compares their attributes. If any attributes differ, the corresponding DOM element's attributes are updated.

3. DOM Reconciliation

Based on the diffing results, React determines the minimal set of DOM operations needed to bring the actual DOM in sync with the virtual DOM.
This might involve:
- Inserting new DOM nodes.
- Updating existing DOM nodes (e.g., text content, attributes).
- Removing DOM nodes that are no longer present in the virtual DOM.

Time and Space Complexity

Naive Approach

In worst case, comparing two trees has a time complexity of O(n^3), where n is the number of nodes.
This can be computationally expensive for large trees.

React's Heuristic Approach:

To achieve efficient diffing, React employs a heuristic approach that leverages the following optimizations:
- Key Prop: React uses the key prop to uniquely identify nodes across different renders. This allows the algorithm to track node movements and updates more efficiently.
- Structural Assumptions: React assumes that elements of different types will produce different trees, reducing the need for extensive comparisons.
- Depth-First Traversal: React traverses the trees in a depth-first manner, focusing on the first child node before moving to siblings. This helps in early detection of changes and potential optimizations.
Through these optimizations, React's diffing algorithm achieves a time complexity of O(n) in most practical scenarios, making it significantly faster than the naive approach.
The space complexity of React's diffing algorithm is generally O(n), as it requires memory to store the virtual DOM trees and the diffing results.

Example

Consider the following simple React component:

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

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

When the count state changes, React creates a new virtual DOM with the updated value. The diffing algorithm then compares the virtual DOM with the real DOM:

Root Comparison: Both roots are div elements, so the comparison moves to the child elements.
Recursive Comparison:
- The p elements are compared. The text content has changed, so the real DOM element is updated.
- The button elements are compared. They are the same type, so their props are compared. The onClick handler is the same, so no change is needed.

As a result, only the text content of the p element is updated in the real DOM, minimizing unnecessary DOM manipulations.

Key Points:

The diffing algorithm is essential for React's efficient DOM updates.
It minimizes the number of DOM manipulations, leading to better performance and responsiveness.
React uses heuristics and optimizations to achieve near-linear time complexity.
The time complexity is typically O(n).
Understanding the diffing algorithm can help you write React components that are more performant and efficient.