Forem: Sheraz Manzoor

Coding is dead; Engineering is not.

Sheraz Manzoor — Sat, 28 Feb 2026 17:19:29 +0000

Tech industries have been marking something as dead, since the internet came. They marked PHP dead, they marked the desktop apps dead, now they're saying coding is dead. So, let's disscuss, is coding really dead?

With vibe coding platforms, the startups are bragging about, shipping without developers. Some even say;

If AI can write code, what's left for developers?

Answer to the question.

To answer that bitter question, I would love to share my personal experiences.

First experience is very recent, I guess it was in December. A client approached me on Linkedin, and said this exactly;

"I have created a website with loveable, everything is fine but there's an issue. On google page insights the performance score is only 28%. Can you fix this and bring the score to 90+?"

So, AI generated the website for him, but he still needed my services. And when I looked his code, there were 2000+ lines of code in various single files, images loading on the homepage were above 5 mb, most of'em.

And I did my "engineering" and the performance boosted to 98.

The second experience is that client approached me with a very similar situation, I'll edit his message a bit to avoid confidential information leaks, he said;

"I have a THAT specific issue, I'm trying to resolve it with AI from weeks, but nothing worked out, can you help me in this please? Give me a quotation and a timeline"

So, AI failed at that certain problem, which was basically "Engineering" related; not about "Coding"

To cut the story short, the coding is really dead, but engineering didn't and it'll never.

The death of Coding

Let's be honest; Writing the boilerplate code was never the highest form of intelligence. We even found free templates which really helped a lot several times.

CRUD oprations, API endpoints, forms validations, UI design, these tasks are increasingly automated, and don't be sad, it's not a tragedy, it's progress. Just like calculators didn't kill Mathematics, AI wouldn't kill Engineering. After AI, just an idea died;

A developer is someone who writes the code line by line

What coding was? And why it wasn't enough?

In very descriptive way, "Coding was just syntax execution". And on the other hand, "Engineering is problem solving".

An engineer understands ambiguous requirements, designs scalable systems, anticipates failure modes, balances performance, security, costs and UX, makes trade-off under real world pressure. So, coding is a language, engineering is the mindset.

Why Engineering will always survive?

Real world problems are very messy, they aren't like simple vanila problems. Client contradicts themselves, requirements change in the mid-build, business goals conflicts with technical realities.

Engineering is the ability to shape chaos into meaningful systems. AI can generate functionality, it cannot take responsibility.

AI works always with context and patterns. Now, from the experiences I shared, many files had 2000+ lines of code, not a single AI can make edits in that single file, and reality we have tens and thousands of files, what will AI do there? It'll crash. On the other hand, Engineers write systems based on domain knowledge, business context, user behavior and organized constraints. Context is not a prompt, context is experience.

Here's my new blog post, I had been working and testing Nextjs 15 for two months and here's a summary of it.

Sheraz Manzoor — Tue, 09 Dec 2025 10:37:30 +0000

Sheraz Manzoor

Dec 9 '25

What's new Nextjs 15?

#nextjs #react #javascript #typescript

Comments

2 min read

What's new Nextjs 15?

Sheraz Manzoor — Tue, 09 Dec 2025 10:36:23 +0000

Vercel Recently launched Nextjs 15, and decaled it as stable and ready for production. Today we'll disscuss what's new in Nextjs 15.

Basically there are new features in Nextjs 15;

React 19 RC Support

Next.js 15 RC now supports React 19 RC. This includes the new features for both client and server side rendering. One of the new features in React 19 is Actions which is a very common use case in React Apps to perform Data Mutation and then update in response.

For example; when a user submits a form to change their name, you'll make an api request and then handle a response.

`@next/codemode` CLI

Now you can easily upgrade to latest Nextjs and React versions

npx @next/codemod@canary upgrade latest

Turbopack Dev (Stable)

Performance and stability has been improved to the next level.

React Compiler (Experimental)

The React Compiler is a new compiler created by the React team at Meta. Complier understands your code at a deep level through it's understanding of plain JavaScript semantics and the rules of React, which allows it to add automatic optimizations to your code.

The code reduce the amount of manual memorization developers has to do with apis such as useMemo and useCallback, making code simpler, easier to maintain, and less error prove.

Hydration Error Improvements.

Nextjs continues to build on those by an improved hydration error view. Hydration errors now display the source code of the error with suggestion on how to address the error.

Such improvements help the developers to better understand the error fix it in low time.

Caching Updates

In Nextjs 15, caching default for fetch requests, GET Route handlers and Client Route Handlers and client router cache has changed from cached by default to uncached by default.

If you want to retain the previous behavior, you can continue to opt-into caching.

Partial Prerendering (Experimental)

Partial Prerendering is a new rendering strategy that combines the benefits of static and dynamic rendering on the same route. Quite similar to parallel routing, right? With PPR, you can wrap any dynamic components in a Suspense Boundary.

When a new request comes in, Nextjs will immediately serve a static HTML shell from the cache, then render and stream the dynamic parts in the same HTTP request.

`unstable_after` API (Experimental)

This executers a stream after a response finishes streaming.

So, these were the backbone new features of Nextjs 15, I find them quite fascinating and interesting, and after using them from almost two months (October 2025 to December 2025), I can now witness that is really lot much better already, and in the next releases it will improve further more.

I would love to hear your thoughts, questions and critics on it.

How to deal with a slow API, a story in two parts.

Sheraz Manzoor — Sat, 02 Aug 2025 12:24:30 +0000

Why optimize when you can simply... shift the problem to someone else?

Understanding React's `use` API

Sheraz Manzoor — Fri, 21 Feb 2025 17:23:09 +0000

A Sneak Peek into React’s `use` API: Simplifying Async Data Fetching

React's use API is an experimental yet powerful feature designed to simplify asynchronous data fetching within components. Instead of juggling useEffect and state variables, use lets you directly await promises inside the render phase.

Why is `use` a Game-Changer?

✅ Eliminates unnecessary useEffect hooks

✅ Works seamlessly with Server Components

✅ Simplifies async operations for cleaner, more readable code

How Does it Work?

Here's a quick look at how use fetches data directly inside a component:

import { use } from "react";

async function fetchData() {
  const response = await fetch("https://jsonplaceholder.typicode.com/posts/1");
  return response.json();
}

export default function Post() {
  const data = use(fetchData());
  return (
    <div>
      <h2>{data.title}</h2>
      <p>{data.body}</p>
    </div>
  );
}

Is use Ready for Production?

⚠️ Not yet! The API is still experimental and currently works best with React Server Components. However, it shows great promise in simplifying data fetching workflows.

Read Full Blog →

🚀 Introducing My Personal Tech Blog: CodePanda.online 📝

Sheraz Manzoor — Sun, 16 Feb 2025 11:47:20 +0000

Hey everyone! 👋

I’m super excited to share that I’ve launched my personal blog website — CodePanda.online! It’s a space where I’ll be sharing my knowledge, experiences, and helpful tips for web developers and tech enthusiasts.

💻 What to Expect on CodePanda:

✅ Hands-on tutorials for JavaScript, TypeScript, React, Next.js, and more.
✅ Practical Tips & Tricks – Quick solutions to common coding challenges.
✅ Insights from real-world projects I’ve worked on.
✅ In-Depth Tutorials – Step-by-step guides on JavaScript, TypeScript, React, Next.js, and more.
✅ Snippets and solutions you can use in your own apps.

I created CodePanda to document my journey as a developer and help others by sharing what I learn along the way. Whether you're just starting out or already deep into your coding career, I hope my posts make your development life a little easier.

🔗 Check it out here: codepanda.online

I’d love for you to stop by, explore, and let me know what topics you’d like me to cover next! 🚀🔥

Different Ways to fetch data in Reactjs

Sheraz Manzoor — Tue, 04 Feb 2025 06:58:20 +0000

Fetching data is a fundamental task in modern web or any kind of applications, as almost every web app interacts with an API or a backend service. There are several ways to fetch data in React, and choosing the right approach depends on factors like performance, reactivity, and ease of use. In this blog, we'll explore different major techniques and methods of fetching data in React.js.

Simple Fetch Method

The fetch() API in JS is used to request to the server and load the information in the webpages. You can call any API which returns data in JSON or XML. This method returns a promise.

export default function TextAPI(){
    useEffect(()=>{
        fetch("https://example.com").
        then(response => response.json()).
        then(json => console.log(json))
    },[])
    return <div>HELLO WORLD!</div>
}

Axios

For many developers, it is the preferred way of fetching data.
Axios is a popular 3rd-party that simplifies HTTP requests with features like request cancellation, automatic JSON parsing, and better error handling.

import { useEffect, useState } from 'react';

export default function FetchComponent() {
    const [data, setData] = useState(null);
    const [loading, setLoading] = useState(true);

    useEffect(() => {
        fetch('https://jsonplaceholder.typicode.com/posts')
            .then(response => response.json())
            .then(json => {
                setData(json);
                setLoading(false);
            })
            .catch(error => console.error('Error fetching data:', error));
    }, []);

    if (loading) return <p>Loading...</p>;
    return <pre>{JSON.stringify(data, null, 2)}</pre>;
}

Many developers like this, but I don't. It is just a personal opinion. If we want to store data for caching, we'll need a new third party library, and this way, we will have to install several third party packages just for getting data from API? Doesn't make sense to me.

React Query

This one is my personal favorite. With this, we can achieve a lot more than just fetching data. It provide support for caching, prefetching, refetching, error handling, which improves overall user experience by preventing irregularities and ensuring our app feels really faster.

import { useQuery } from 'react-query';
import axios from 'axios';

const fetchPosts = async () => {
    const { data } = await axios.get('https://jsonplaceholder.typicode.com/posts');
    return data;
};

export default function ReactQueryComponent() {
    const { data, error, isLoading } = useQuery('posts', fetchPosts);

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

    return <pre>{JSON.stringify(data, null, 2)}</pre>;
}

Here, we can do a lot much things with a single library, we don't have to rely on multiple libraries for data handling. That's why a ❤ to React Query.

Server-Side Fetching with Next.js

In Nextjs, we can fetch data on server side, in server components. And that is much easier than the traditional useEffect way in React.

"use server"
export async function getServerSideProps() {
    const res = await fetch('https://jsonplaceholder.typicode.com/posts');
    const data = await res.json();

    return { props: { data } };
}

Now you can import and call this function anywhere in your Nextjs Application. In Server components you can call it directly without any issue, but in Client Components, You'll have to call it useEffect.

The best approach will be to fetch data in a parent server component, and pass that data to our client components.

Conclusion

There are various ways to fetch data in React, each with its own advantages and use cases.
Choosing the right method depends on your project requirements, API structure, and performance needs. Happy coding!
But my suggestion will be React Query, as it has a ton of features.

If you need guidance or a separate blog on any of the above methods, please let me know in comments.
Checkout my blog: https://www.codepanda.online/

[Boost]

Sheraz Manzoor — Tue, 10 Dec 2024 18:06:33 +0000

Good Commit ✔ VS. Bad Commit ❌: Best Practices for Git

Sheraz Manzoor ・ Jul 19 '24

#git #github #webdev #beginners

Introduction to Next.js Middleware: How It Works with Examples

Sheraz Manzoor — Tue, 01 Oct 2024 10:13:13 +0000

Let's talk about routing in Nextjs. Today, we will talk about the one of most powerful thing middleware. Middleware in Nextjs offers a powerful and flexible way both to intercept requests from server and control requests flow (redirects, URL rewriting) and globally enhance features like authentication, headers, cookie persistence.

Creating Middleware

Let's create Middleware Next.js application. First of all, we'll create a new file for middleware like middleware.js or middleware.ts, in the src folder. Middleware in Next.js then needs to allow you the fine control over where it will be active (ie custom matcher configuration, or using isXXX functions)

Redirecting

Using redirection as an example, let's imagine a scenario where navigating to /profile should redirect the user to the homepage. With the custom matcher configuration approach, we can achieve this by importing the necessary types, defining a middleware function, and specifying the matcher configuration:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  return NextResponse.redirect(request.url.replace('/profile', '/'));
}

export const config = {
  matcher: '/profile',
};

In this example, the middleware function checks if the request URL path is /profile and redirects the user to the homepage.

For the conditional statement approach, we can modify the code as follows:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  if (request.nextUrl.pathname === '/profile') {
    return NextResponse.redirect('/hello');
  }
  return NextResponse.next();
}

In this case, the middleware checks the request URL path and redirects the user to the /hello route if the path is /profile.

Middleware in Next.js goes beyond just handling redirections. It also allows for URL rewrites, which can be useful for legacy URL support or SEO optimization. By changing redirect to rewrite in the previous examples, the URL in the browser will stay the same (/profile), but the response content will change to the content from the /hello route.

Using Cookies

Lastly, let's explore the use of cookies and headers in middleware. We can modify our middleware to handle user preferences for themes and add a custom header for all responses:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const response = NextResponse.next();

  // Handle user theme preference
  const themePreference = request.cookies.get('theme');
  if (!themePreference) {
    response.cookies.set('theme', 'dark');
  }

  // Add a custom header
  response.headers.set('Custom-Header', 'Custom Value');

  return response;
}

In this example, we first check if the user has a theme preference stored in a cookie. If not, we set the theme to 'dark' by adding a cookie. Then, we add a custom header to the response, which can be useful for passing additional information or for debugging purposes.

As you can see, middleware in Next.js is a powerful tool that allows you to effectively control and intercept the request-response cycle, enabling redirects, URL rewrites, and the manipulation of headers and cookies. By mastering middleware, you can enhance the routing experience in your Next.js applications and create more robust and customizable user experiences.

"Middleware in Next.js is a powerful feature that offers a robust way to intercept and control the flow of requests and responses within your applications." - Next.js Documentation

Conclusion

In summary, we've learned how to define middleware in Next.js, explore the two main approaches (custom matcher configuration and conditional statements), and apply middleware to handle redirections, URL rewrites, and the management of cookies and headers. This knowledge will help you take your Next.js applications to the next level by leveraging the flexibility and control that middleware provides.

Mastering Tailwind CSS: Overcome Styling Conflicts with Tailwind Merge and clsx

Sheraz Manzoor — Tue, 03 Sep 2024 18:38:20 +0000

People has been asking me to write something on some soft topics for beginners in my email, as I write mostly for Mid-level or senior. So, here is a new article for you beginners, specially for UI Developers 😍.

Today, let's explore the common challenges developers face when working with Tailwind CSS and how to overcome them using the powerful combination of Tailwind Merge and clsx.

What's the problem?

When using Tailwind CSS, you often want to pass custom class names to your components, just like you would with a native HTML element, which allows you to style your components dynamically and override the default styles. However, this can lead to conflicts when the custom class names clash with the base Tailwind classes.

The problem with Tailwind is these conflicts are not predictable. You don't know the outcome really. It doesn't matter if you put this at the front of the class list or at the end, in both cases when you have a conflict, you don't really get the result that you expect.

The default behavior of Tailwind doesn't always align with our intuition, where we expect the last class to take precedence in case of a conflict.

Introducing Tailwind Merge

The finest solution to this tricky problem is a utility function called Tailwind Merge. This function intelligently merges conflicting Tailwind classes. It makes sure that the last class wins, which aligns with our expectations.

import { twMerge } from 'tailwind-merge';

const containerClasses = twMerge(
  'bg-blue-500 text-white px-4 py-2 rounded',
  'bg-red-500'
);

In example above, the twMerge function takes the base Tailwind classes and the custom class name as arguments, and returns the merged result. This way, the bg-re-500 class will override the bg-blue-500 class, as expected.

Handling Conditional Classes

Another common scenario is when you need to apply different classes based on a condition, such as a component's state. Tailwind Merge makes this easy to manage as well:

const buttonClasses = twMerge(
  'bg-blue-500 text-white px-4 py-2 rounded',
  'bg-green-500',
  isLoading && 'bg-gray-500'
);

In this case, if the isLoading variable is true, the bg-gray-500 class will be added to the final class string.

Introducing clsx

While Tailwind Merge solves the problem of conflicting classes, some developers prefer to use an object-based syntax for conditional classes. This is where the clsx library comes in handy.

import clsx from 'clsx';

const buttonClasses = twMerge(
  clsx({
    'bg-blue-500 cursor-not-allowed': !loading,
    'bg-gray-500 cursor-pointer': loading,
  }),
  'text-white px-4 py-2 rounded'
);

By using clsx, you can now define your conditional classes in an object-based format, which some developers find more intuitive.

Combining the powers of Tailwind Merge and clsx

To get the best of both worlds, you can combine Tailwind Merge and clsx using a custom utility function:

import { twMerge } from 'tailwind-merge';
import clsx from 'clsx';

export const cn = (...inputs: ClassValue[]) => {
  return twMerge(clsx(inputs));
};

This cn (short for "class names") function first passes the input classes through clsx, which handles the object-based conditional classes, and then passes the result to Tailwind Merge to resolve any conflicts.

Now, you can use this cn function in your components with both syntaxes:

const buttonClasses = cn(
  {
    'bg-blue-500': !pending,
    'bg-gray-500': pending,
  },
  'text-white px-4 py-2 rounded'
);

const buttonClasses = cn(
 'text-white px-4 py-2 rounded', pending ? 'bg-blue-500' : 'bg-gray-500' 
);

This approach allows you to leverage the strengths of both Tailwind Merge and clsx together, providing a flexible and intuitive way to manage your component styles.

Conclusion

In conclusion, understanding and mastering the use of Tailwind Merge and clsx can greatly improve your experience when working with Tailwind CSS. By combining these tools, you can effectively manage class conflicts, conditional styles, and create reusable, well-structured components.

Zod vs. Valibot: Which Validation Library is Right for Your TypeScript Project?

Sheraz Manzoor — Wed, 28 Aug 2024 12:46:15 +0000

In a TypeScript world, solid validateing libraries an are essential to your data-structures adheres expected types and restraints. While Zod and Valibot are libraries performing similar functions. It helps on reducing the boilerplate for validation in both libraries and catching error messages early, enforcing data integrity. Both two are available, So what should you choose? I am going to cover the features, performance and use-cases of Zod and Valibot in this blog post hopefully help you get a clear idea.

Why validation libraries matter?

Now that we've established when you should use a validation library in TypeScript, lets dive into the comparison. With compile-time strong typing, TypeScript ensures type checks as you code but not at runtime so invalid data can still lead to corruption or unexpected behavior. Validation libraries help with this by making sure that your data not only fits the type definitions, but also obeys constraints like minimum lengths and formats or ranges.

What are Zod and Valibot?

Zod, TypeScript first schema declaration and validation. It has a simple and concise syntax. With Zod, you can easily define schemas for your data structures with chasey validation and TypeScript type inference.

Valibot is a validation library that implements this approach and offers it in an flexible yet powerful API for data validation/transformation. It intends to be more featureful than certain other libraries, so it might satisfy the validation requirements for some large form.

Now, let's compare Zod and Valibot across various criteria.

1. Ease of use:

Zod:

Zod offers an intuitive and straightforward API that's easy to learn, especially for developers familiar with TypeScript and functional programming paradigms.

import { z } from "zod";
const UserSchema = z.object({
  name: z.string(),
  age: z.number().int().positive(),
  email: z.string().email(),
  profile_url: z.string().url()
});

const user = UserSchema.parse({
  name: "Sheraz",
  age: 19,
  email: "sheraz.dev121@gmail.com",
  profile_url: "https://www.linkedin.com/in/sheraz-manzoor-842934222/"
});

Valibot:

Valibot also provides a declarative and readable syntax, making it easy to define complex validation rules without much boilerplate.

import * as v from 'valibot'; // 1.2 kB

const UserSchema = v.object({
  name: v.string(),
  age: v.number().int().positive(),
  email: v.pipe(v.string(), v.email()),,
  profile_url: v.string().url(),
});
const user = parse(UserSchema, {
  name: "Sheraz",
  age: 19,
  email: "sheraz.dev121@gmail.com",
  profile_url: "https://www.linkedin.com/in/sheraz-manzoor-842934222/",
});

2. Performance

Zod:

Zod is optimized for performance and handles validation efficiently. However, in extremely performance-critical applications, there might be minor overheads due to its comprehensive feature set.

Valibot:

Valibot emphasizes performance and is designed to be lightweight and fast. Benchmarks often show Valibot performing slightly better than Zod, especially in scenarios involving large and complex schemas.

3. Flexibility

Zod:

Zod is extremely flexible, enabling you to create complex schema definitions or even perform custom validations and data transformations. It also has support for unions, intersections, and recursive schemas.

Valibot:

Valibot allows developers a high level of flexibility to define the complex validation rules and custom validators in no time.

4. Type Inference

Zod:

Zod excels in type inference. By doing that, it auto-generates the TypeScript types from your schemas, so you never forget to update any of them and keep both TsTypes and validation schema up-to-date.

const UserSchema = z.object({
  name: z.string(),
  age: z.number().min(1),
});

type User = z.infer<typeof UserSchema>;
// Equivalent to:
// type User = {
//   name: string;
//   age: number;
// };

Valibot:

Valibot allows developers a high level of flexibility to define the complex validation rules and custom validators in no time.

import * as v from 'valibot';
const UserSchema = v.object({
  name: v.string(),
  age: v.pipe(v.number(), v.minValue(1)),
});

type User = v.InferInput<typeof UserSchema>;

5. Community and ecosystem

Zod:

Zod has a larger and more active community, resulting in extensive documentation, tutorials, and third-party integrations. Its popularity means more resources are available for learning and troubleshooting.

Valibot:

Valibot is relatively newer than Zod but it is also growing steadily. Its documentation is comprehensive, and the community support is increasing, though it may not be as extensive as Zod's yet.

Use Cases

To illustrate how Zod and Valibot can be applied in real-world scenarios, let's explore a few use cases examples.

Simple Data Validation

Zod:

const ProductSchema = z.object({
  id: z.string(),
  price: z.number().positive(),
});

const product = ProductSchema.parse({
  id: "123",
  price: 19.99,
});

Valibot:

import * as v from 'valibot';
const ProductSchema = object({
  id: v.string(),
  price: v.pipe(v.number(), v.minValue(0)),
});

const product = ProductSchema.parse({
  id: "123",
  price: 19.99,
});

Nested Schemas

Zod:

const AddressSchema = z.object({
  street: z.string(),
  city: z.string(),
  zip: z.string().length(5),
});

const UserSchema = z.object({
  name: z.string(),
  address: AddressSchema,
});

const user = UserSchema.parse({
  name: "Bob",
  address: {
    street: "456 Elm St",
    city: "Metropolis",
    zip: "12345",
  },
});

Valibot:

import * as v from 'valibot';
const AddressSchema = v.object({
  street: v.string(),
  city: v.string(),
  zip: v.pipe(v.string(),v.toMinValue(5),v.toMaxValue(5)),
});

const UserSchema = object({
  name: v.string(),
  address: AddressSchema,
});

const user = UserSchema.parse({
  name: "Bob",
  address: {
    street: "456 Elm St",
    city: "Metropolis",
    zip: "12345",
  },
});

Custom Validations

Zod:

const PasswordSchema = z.string().min(8).refine((val) => /[A-Z]/.test(val), {
  message: "Password must contain at least one uppercase letter",
});

const userPassword = PasswordSchema.parse("SecurePass1");

Valibot:

import * as v from 'valibot';
const PasswordSchema= v.custom<string>((password)=>
    typeOf password=== 'string' ? /[A-Z]/.test(password):false
)

const userPassword = PasswordSchema.parse("SecurePass1");

Validating API data

Scenario

Imagine you're building an application that fetches user data from a public API like JSONPlaceholder. You want to ensure that the data returned by the API conforms to your expected schema before using it in your application. If the data doesn't match the schema, you want to handle it gracefully.

Zod:

import { z } from 'zod';

// Define the schema for the expected API data
const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  username: z.string(),
  email: z.string().email(),
  address: z.object({
    street: z.string(),
    city: z.string(),
    zipcode: z.string().regex(/^\d{5}-\d{4}$/),
  }),
});

// Fetch data from the API
async function fetchData() {
  try {
    const response = await fetch('https://jsonplaceholder.typicode.com/users/1');
    const data = await response.json();

    // Validate the data using Zod
    const parsedData = UserSchema.parse(data);
    console.log('Data is valid:', parsedData);
  } catch (error) {
    console.error('Invalid data:', error.errors);
  }
}

fetchData();

Valibot:

import * as v from 'valibot';
// Define the schema for the expected API data
const UserSchema = v.object({
  id: v.number(),
  name: v.string(),
  username: v.string(),
  email: v.pipe(v.string(), v.email()),,
  address: v.object({
    street: v.string(),
    city: v.string(),
    zip: v.pipe(v.string(),v.toMinValue(5),v.toMaxValue(5)),
  }),
});

// Fetch data from the API
async function fetchData() {
  try {
    const response = await fetch('https://jsonplaceholder.typicode.com/users/1');
    const data = await response.json();

    // Validate the data using Valibot
    const parsedData = parse(UserSchema, data);
    console.log('Data is valid:', parsedData);
  } catch (error) {
    console.error('Invalid data:', error);
  }
}

fetchData();

Conclusion

Zod and Valibot are both efficient validation libraries designed for smooth integration with TypeScript, guaranteeing robust solutions for runtime data validation. Here is a brief summary of how to select which option to use.

Choose Zod if:

You want a well-established library with a large number of users and ecosystem.
You look for cutting-edge features with which you can enrich validation and data transformation.
You love enriched documentation and numerous resources for learning the library from scratch.

Choose Valibot if:

You would like the active speed and lightness of a library to have a minor influence on your application’s general performance.
You enjoy flexible, declarative syntax to define advanced validation rules.
You are willing to collaborate with the library that is under consistent upgrading and is regarded as a young solution.

If you have no experience about validating data, I will highy suggest to use Zod first, because it has a huge community and there's lot of information on internet regarding it. But if you have worked with Zod already, I will suggest to use a mix of Zod and Valibot. For small or medium level schemas use zod, as it will be easy to use there without effecting performance. For large and complex schemas use Valibot, as it excels Zod in terms of performance.

Ultimately, both libraries will serve you well in ensuring data integrity and type safety in your TypeScript projects. It might be beneficial to experiment with both in a small project to see which aligns better with your development style and project requirements.

Happy Coding! 😊

Type ✔ Vs Interface ❌: Why you should chose type over interface in typescript.

Sheraz Manzoor — Thu, 08 Aug 2024 14:28:50 +0000

I have come to a solution that you should always use types over interfaces. Let's breakdown why!!

Interfaces can only specify objects, but type alias can specify objects and everything else. Let's say we have a single Address field and with type you'll define its type like this:

type Address = string;
const address: Address = '123 Hallway'

But you can't do such stuff with interface like:

interface Address = string; //error
const address: Address = '123 Hallway'

Because interface alias can only define objects. We'll need to change structure altogether if we want to use interface like:

interface Address {
    address: string;
}
const address: Address = {
    address: '12 3 Hallway'
}

That's first problem with interfaces.

type alias can define Union types and interface alias can't: Let's user can have multiple or a single address:

type Address = string | string[] ;
const address: Address = '123 Hallway'
const newAddress: Address= ['123 Hallway', 'Flag Plaza']

string | string[] is called a Union type, address can a string, or an array of string.

You can do such stuff with interface alias.

types alias can easily use utility types. Interface can do but it will look ugly, for example consider a User Object:

type User = {
    name: string;
    age: number;
    created_at: Date;
}

Now, let's say we have a guest Object, that is not logged in but we can check when it was created (first landed on the page). In this scenario, guest is like a user but not an actual user. We want to have created_at property in Guest from User In type alias we do it like:

     type Guest = Omit<User, 'name' | 'age'>

Technically it is possible with interface but see how it works:

type Guest extends Omit<User, 'name' | 'age'> {}

It works but it is an ugly syntax, isn't it?

Sometimes you will need to describe tuples. Here is how we describe it with type alias

type Address = [string, number, string] ;
const address: Address = ['Hallway', 2, 'Abdul Plaza']

But with interface, see how we do it:

type Address extends Array<number | string> {
    0: string
    1: number;
    2: string;
}

const address: Address = ['Hallway', 2, 'Abdul Plaza']

Ugly syntax again.

With types alias we can extract types very easily.

const love_bonito ={
    level: 1,
    store_id: 'scad_12hdedhefgfeaa',
    country: ['US','PK','IND'],
    user: {
        user_id: "blah',
        username: 'nishat',
        likes: 421,
    },
};

// let's extract type for love_bonito
type LoveBonito = typeOf love_bonito;

// or even something inside love_bonito
type User = typeOf love_bonito.user;

Bonus for this is that if we already now level is always one and nothing else, we can do that as well:

const love_bonito ={
    level: 1,
    store_id: 'scad_12hdedhefgfeaa',
    country: ['US','PK','IND'],
    user: {
        user_id: "blah';
        username: 'nishat';
        likes: 421;
    },
} as const

// let's extract type for love_bonito
type LoveBonito = typeOf love_bonito

// or even something inside love_bonito
type User = typeOf love_bonito.user

Now level will be inferred as 1, not as any number.

With interface alias you can redeclare an interface,

interface Home {
    rooms: number;
    light_bulbs: 12;
    rented_to: "Abu Turab";
}

interface Home {
   fans: 16;
}

// final type 

interface Home {
    rooms: 3;
    light_bulbs: 12;
    rented_to: "Abu Turab";
    fans: 16;
}

We can't redeclare type alias. You might thing, "Oh! Sheraz, here, this is a plus point of interface", but actually its not!!!

It sounds confusing, to have multiple declarations with the same identifier throughout your codebase. It seems really confusing to me.

Suppose you are working with a team, you knew about type of an object (types declared with interface), but somebody in your team redeclares and changes it, what would you do.

But with type alias this problem is sorted out as well. If you redeclare a type it throws an error

duplicate identifier

The name of library is TYPESCRIPT not INTERFACESCRIPT. That might be funky but yeah, why would a company chose to name their library TYPESCRIPT and not IBTERFACESCRIPT. If company is preferring type over interface, so why don't you? 😆

Conclusion

Always prefer types over interfaces. Some devs say that interfaces load faster than types... But that happened in past. Now a days there's no difference regarding performance. There are some use cases where you might need interfaces, but it does not mean that you should interfaces all the time.

Forem: Sheraz Manzoor

Coding is dead; Engineering is not.

Answer to the question.

The death of Coding

What coding was? And why it wasn't enough?

Why Engineering will always survive?

Here's my new blog post, I had been working and testing Nextjs 15 for two months and here's a summary of it.

What's new Nextjs 15?

What's new Nextjs 15?

React 19 RC Support

@next/codemode CLI

Turbopack Dev (Stable)

React Compiler (Experimental)

Hydration Error Improvements.

Caching Updates

Partial Prerendering (Experimental)

unstable_after API (Experimental)

How to deal with a slow API, a story in two parts.

Understanding React's `use` API

A Sneak Peek into React’s use API: Simplifying Async Data Fetching

Why is use a Game-Changer?

How Does it Work?

Is use Ready for Production?

🚀 Introducing My Personal Tech Blog: CodePanda.online 📝

💻 What to Expect on CodePanda:

Different Ways to fetch data in Reactjs

Simple Fetch Method

Axios

React Query

Server-Side Fetching with Next.js

Conclusion

[Boost]

Good Commit ✔ VS. Bad Commit ❌: Best Practices for Git

Sheraz Manzoor ・ Jul 19 '24

Introduction to Next.js Middleware: How It Works with Examples

Creating Middleware

Redirecting

Using Cookies

Conclusion

Mastering Tailwind CSS: Overcome Styling Conflicts with Tailwind Merge and clsx

What's the problem?

Introducing Tailwind Merge

Handling Conditional Classes

Introducing clsx

Combining the powers of Tailwind Merge and clsx

Conclusion

Zod vs. Valibot: Which Validation Library is Right for Your TypeScript Project?

Why validation libraries matter?

What are Zod and Valibot?

1. Ease of use:

2. Performance

3. Flexibility

4. Type Inference

5. Community and ecosystem

Use Cases

Simple Data Validation

Nested Schemas

Custom Validations

Validating API data

Scenario

Conclusion

Choose Zod if:

Choose Valibot if:

Type ✔ Vs Interface ❌: Why you should chose type over interface in typescript.

Conclusion

`@next/codemode` CLI

`unstable_after` API (Experimental)

A Sneak Peek into React’s `use` API: Simplifying Async Data Fetching

Why is `use` a Game-Changer?