When people think of landing a software development job, the spotlight usually falls on coding. And yes, coding is the foundation — without it, we wouldn’t even be here. But here’s the real secret: coding alone won’t get you hired, and it certainly won’t help you thrive once you’re in.

Let’s talk about the often-overlooked skills that make you stand out in interviews and workplaces, even if your code looks just like the next applicant’s.

1. Communication: Explaining Tech Without Jargon

It’s one thing to write a function, and another to explain what that function does to a product manager who’s never written a line of code.

• In interviews, being able to clearly explain your approach to a problem is often valued more than brute-force coding speed.
• At work, you’ll be explaining bugs, features, and ideas to people who don’t think in semicolons.

👉 Pro tip: Practice explaining your latest project to a non-tech friend. If they understand it, you’ve nailed it.

2. Problem-Solving Mindset: Code Is Just the Tool

Think of coding as the hammer. The real skill is knowing what to build with it. Employers look for developers who:

• Can break down messy, vague problems into smaller, solvable pieces.
• Don’t panic when the first solution doesn’t work.
• See the bigger picture, not just the “for loop” in front of them.

👉 Example: Instead of just writing an algorithm to “sort data,” think about why the data needs sorting and how the end-user will benefit. That’s problem-solving.

3. Teamwork: Because No One Builds Alone

You could be the fastest coder in the room, but if you don’t know how to work with others, progress will stall.

• Most real-world projects are team efforts — designers, testers, product managers, and other developers.
• Good teamwork means listening, respecting deadlines, and sometimes even adjusting your style to fit the team.

👉 Remember: “collaboration over competition” gets projects shipped faster.

4. Adaptability: Tech Changes Overnight

Frameworks, libraries, and languages evolve faster than you can finish that online course.

• Employers want people who can learn and adapt quickly.
• It’s less about knowing every tool and more about showing you can learn new ones when the time comes.

👉 Example: You don’t need to know every detail of Kubernetes to get hired. But if you show you can pick it up, that’s gold.

5. Time Management & Prioritization

Being a developer isn’t about writing the most lines of code — it’s about writing the right lines of code at the right time.

• Can you prioritize urgent tasks?
• Do you know when to stop perfecting and just ship?
• Can you balance deep focus with quick team check-ins?

👉 Those who manage time well are often trusted with bigger responsibilities sooner.

6. Curiosity & Continuous Learning

This one’s underrated but powerful. Companies love developers who are curious and self-driven:

• Exploring side projects shows initiative.
• Asking “why” instead of just “how” makes you valuable in shaping product decisions.
• Staying updated on trends keeps your team future-ready.

👉 A curious dev isn’t just an employee; they’re a growth engine.

Final Thoughts

Yes, you need to code well to be a developer. But here’s the truth: the best jobs and the best growth go to developers who mix coding with strong human and problem-solving skills.

So next time you’re brushing up on your technical prep, take a moment to practice explaining concepts, working in teams, and staying adaptable. These are the skills that set you apart when ten candidates have written the same working solution.

Because in the end, companies aren’t just hiring code. They’re hiring people who can turn code into impact.

Hey there! 👋

If you’ve been working with Next.js, you probably know how often we end up juggling API routes, fetch calls, and server logic just to do something simple like submit a form or talk to a database. Well, say hello to Server Actions — a neat way to run server-side code directly from your components.

In this article, I’ll break it down for you and give you real-world examples you can start using today. No fluff, just practical stuff. Let’s dive in.

What Are Server Actions?

Think of Server Actions as functions that live on the server but can be called from your client-side components.

Traditionally, you’d have to:

1. Create an API route in pages/api.
2. Write a fetch() call from your component to hit that API.
3. Handle responses and errors.

With Server Actions, you skip the API route. You just call a server function like a normal function, and Next.js handles the rest.

Why This is Awesome

• Simpler code: Fewer files, less boilerplate.
• Secure: Secrets like API keys or database credentials stay on the server.
• Faster dev: No need to manage separate endpoints for simple actions.

How Server Actions Work (Super Simple Example)

Let’s start with a basic example: adding a user to a database.

// app/actions.js
"use server";  // This marks the function as a server action

export async function addUser(user) {
  // Pretend database call
  const result = await database.users.create({ data: user });
  return result;
}

// app/page.jsx
import { addUser } from "./actions";

export default function Page() {
  const handleAddUser = async () => {
    const user = { name: "Shipra", email: "shipra@example.com" };
    const result = await addUser(user); // runs on the server automatically
    console.log("User added:", result);
  };

  return <button onClick={handleAddUser}>Add User</button>;
}

See that? No fetch() required. Next.js handles the client-server communication automatically.

Think of it like this: the button on your page tells the server, “Hey, add this user!” The server does the work safely, then sends back the result. You don’t see the messy API calls or database secrets — Next.js handles it all behind the scenes. Simple, clean, and secure.

Real-World Example #1: Form Submission

Imagine you have a contact form:

// app/actions.js
"use server";

export async function submitContactForm(data) {
  // Imagine sending an email or saving to a DB
  await sendEmail({
    to: "team@example.com",
    subject: "New Contact Form Submission",
    body: `Message from ${data.name}: ${data.message}`,
  });
  return { success: true };
}

// app/page.jsx
import { submitContactForm } from "./actions";

export default function ContactForm() {
  const handleSubmit = async (e) => {
    e.preventDefault();
    const data = { name: "Shipra", message: "Hello there!" };
    const response = await submitContactForm(data);
    if (response.success) alert("Form submitted successfully!");
  };
  return (
    <form onSubmit={handleSubmit}>
      <button type="submit">Send Message</button>
    </form>
  );
}

No extra API endpoints, no manual fetch(). Just click a button, and your server-side logic runs safely.

Real-World Example #2: CRUD Operations

Server Actions are perfect for database operations. Let’s say you want to delete a user:

// app/actions.js
"use server";

export async function deleteUser(userId) {
  return await database.users.delete({ where: { id: userId } });
}

// app/page.jsx
import { deleteUser } from "./actions";

export default function UserList({ users }) {
  const handleDelete = async (id) => {
    await deleteUser(id);
    alert(`User ${id} deleted!`);
  };
  
  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>
          {user.name} <button onClick={() => handleDelete(user.id)}>Delete</button>
        </li>
      ))}
    </ul>
  );
}

Notice how the client code stays super clean, but all database logic runs securely on the server.

How This Delete Example Works

1. Server-side deletion
   In app/actions.js, the deleteUser function is marked with "use server". This tells Next.js that this function runs only on the server, where it safely interacts with the database to delete a user by their ID.
2. Calling it from the client
   In the UserList component, each user has a “Delete” button. When clicked, handleDelete calls deleteUser(id). Even though it looks like a normal function call, Next.js automatically sends it to the server.
3. Getting feedback
   Once the server finishes deleting, the client gets the result. Here, we simply show an alert to let the user know the deletion happened.
4. User experience
   The user clicks → the server deletes → the client reacts. No API routes, no exposing secrets, just clean and safe code.

Tips for Using Server Actions

1. Mark them with "use server" — this is what tells Next.js it should run on the server.
2. Keep secrets safe — passwords, API keys, database URLs, etc., should always stay in server actions.
3. Use async/await — most server actions involve asynchronous operations like DB queries or network requests.
4. Handle errors gracefully — even though they run on the server, you still want to catch and display errors properly.

When to Use Server Actions

• Form submissions
• Database CRUD operations
• Sending emails or notifications
• Anything that involves server-side secrets

Basically, anywhere you used to create a mini API endpoint, server actions can replace it.

Wrapping Up

Server Actions are a game-changer for Next.js developers. They make your code cleaner, your secrets safer, and your development faster.

If you’ve been frustrated by constantly switching between components and API routes, Server Actions will feel like a breath of fresh air.

Next step? Go try them in a small form or database operation — you’ll get hooked quickly!

When we start with Flutter, most of us stick to the classics: Container, Row, Column, and maybe ListView. But Flutter’s widget catalog is massive, and many powerful widgets often fly under the radar.

In this article, I’ll walk you through 10 underrated Flutter widgets that can seriously speed up your workflow, reduce boilerplate, and make your apps more polished. I’ll keep it friendly and practical, with small examples you can drop right into your code.

1. FractionallySizedBox

Ever struggled with responsive layouts where you want a widget to take, say, 70% of the width? This widget saves the day.

FractionallySizedBox(
  widthFactor: 0.7,
  child: ElevatedButton(
    onPressed: () {},
    child: Text("70% Width Button"),
  ),
)

Instead of juggling MediaQuery and manual calculations, this widget does it cleanly.

2. AspectRatio

Perfect for keeping consistent proportions (great for videos, cards, or images).

AspectRatio(
  aspectRatio: 16 / 9,
  child: Container(
    color: Colors.blue,
    child: Center(child: Text("16:9 Box")),
  ),
)

No more guessing heights when you already know the width.

3. ClipRRect

Rounded corners made easy — without manually setting borderRadius everywhere.

ClipRRect(
  borderRadius: BorderRadius.circular(20),
  child: Image.network("https://via.placeholder.com/150"),
)

It’s one of the simplest ways to polish your UI.

4. LimitedBox

Ever had a ListView child grow infinitely because no constraints were given? LimitedBox keeps things under control.

ListView(
  children: [
    LimitedBox(
      maxHeight: 200,
      child: Container(color: Colors.red),
    ),
  ],
)

Especially handy when mixing scrollable and non-scrollable widgets.

5. Expanded + Spacer

Yes, you know Expanded, but do you use Spacer? It’s a clean way to add flexible empty space.

Row(
  children: [
    Text("Left"),
    Spacer(),
    Text("Right"),
  ],
)

Cleaner than adding an Expanded(child: Container()).

6. Wrap

Tired of Row or Column overflowing with widgets? Wrap makes items automatically move to the next line.

Wrap(
  spacing: 8,
  runSpacing: 4,
  children: List.generate(10, (i) => Chip(label: Text("Item $i"))),
)

Your UI will thank you when text or chips don’t fit.

7. ReorderableListView

Need drag-and-drop reordering? Flutter gives it to you out of the box.

ReorderableListView(
  onReorder: (oldIndex, newIndex) {},
  children: List.generate(
    5,
    (i) => ListTile(
      key: ValueKey(i),
      title: Text("Item $i"),
    ),
  ),
)

Saves you from reinventing the wheel with custom drag logic.

8. AnimatedSwitcher

Want smooth transitions when swapping widgets? Try this.

int _count = 0; 

AnimatedSwitcher(
  duration: Duration(milliseconds: 300),
  child: Text(
    '$_count',
    key: ValueKey(_count),
    style: TextStyle(fontSize: 30),
  ),
)

Whenever _count changes, the widget fades beautifully.

9. DraggableScrollableSheet

Think of the bottom sheet that expands in Google Maps — that’s this widget.

DraggableScrollableSheet(
  builder: (context, controller) {
    return Container(
      color: Colors.white,
      child: ListView.builder(
        controller: controller,
        itemCount: 30,
        itemBuilder: (_, i) => ListTile(title: Text("Item $i")),
      ),
    );
  },
)

It adds a slick UX with minimal code.

10. FittedBox

Say goodbye to overflowing text or icons — this widget automatically scales them down.

FittedBox(
  child: Text(
    "This is a very very very long text",
    style: TextStyle(fontSize: 30),
  ),
)

A lifesaver when designing for multiple screen sizes.

Flutter’s beauty lies in its widget ecosystem. Once you explore beyond the basics, you’ll find widgets that feel like secret weapons — making your UI more responsive, interactive, and elegant with less effort.

The next time you’re wrestling with layouts or animations, try reaching for one of these underrated gems. They might just save you hours of development.

👉 Over to you: Which of these widgets do you use most, and which one surprised you?

The Bhagavad Gita wasn’t written for boardrooms. No KPIs, no org charts, no corporate speak. Yet, as someone who’s spent years navigating meetings, deadlines, and internal politics, I’ve found its lessons more useful than any productivity hack or leadership course.

Here’s what this 2,000-year-old text has taught me about handling modern work life.

1. Do the Work, Drop the Outcome

“You have a right to perform your duty, but not to the fruits of your actions.” — Gita 2.47

Corporate culture is outcome-obsessed — targets, bonuses, recognition. But the Gita teaches detachment: focus on the work itself, not what it might bring.

This mindset shift reduces stress and boosts consistency. When your motivation isn’t tied to results, you become more resilient and less reactive. Ironically, you often perform better too.

2. Get Clarity in the Chaos

At the start of the Gita, Arjuna is paralyzed by doubt — stuck between duty and emotion. Krishna doesn’t hand him easy answers. He reframes the whole situation.

That’s the move: zoom out. When the job feels overwhelming, don’t just push harder. Step back. Ask bigger questions. What’s my role here? What really matters?

Perspective beats panic.

3. Balance Is a Skill, Not a Luxury

“Yoga is skill in action.” — Gita 2.50

Work-life balance is nice. But the Gita talks about a deeper kind of balance — emotional steadiness, presence without attachment.

In corporate life, that looks like staying calm in conflict, being unfazed by praise or criticism, and knowing when to act versus when to pause. This isn’t passivity. It’s power under control.

4. Follow Your Swadharma (True Role)

“It is better to fail in your own dharma than to succeed in the dharma of another.” — Gita 3.35

You weren’t built to copy someone else’s career path.

The Gita says: know your nature and act from it. In work terms, that means aligning with roles and projects that fit your values, strengths, and energy — even if it’s not the fastest path to the top.

Authenticity scales better than imitation.

5. Ego Is the Real Enemy

The higher you rise, the easier it is to mistake your title for your identity.

The Gita warns against this. Ego blocks growth. It makes you defensive, blinds you to feedback, and isolates you from your team.

Humility isn’t just noble — it’s practical. It makes you a better learner, a better listener, and a better leader.

Final Thought: Ancient Wisdom, Modern Edge

The Gita doesn’t offer a career plan. It offers something deeper: a mindset. One that anchors you in clarity, steadiness, and purpose — no matter what’s happening around you.

In the world of corporate hustle, that’s not just spiritual advice. That’s strategic advantage.

When you’re working on a small app, handling form data in TypeScript feels simple. You create a quick interface or type, pass it to your form library like react-hook-form, and move on.

But things change once the project gets bigger.

In large projects, you don’t just have one form. You have 10, 20, even 30 forms — all with different fields, create/edit modes, multilingual labels, conditional inputs, and sometimes role-specific logic.

That’s where problems start:

• You begin duplicating the same fields across multiple files.
• Types for similar forms drift apart over time.
• Bugs creep in when one part of your app expects a slightly different structure.
• Maintenance becomes painful — especially when teams grow.

I’ve dealt with this firsthand, and I realized something:

Form field types are not just random interfaces — they’re core building blocks.

So instead of defining types locally in every form page, I use a shared strategy — a single TypeScript file that holds all my reusable form field types. I treat fields like full_name, address, or school_info as modular units. I compose them into complete forms based on need.

This simple shift has made my forms cleaner, my validation more consistent, and my life much easier.

The Challenge: Forms Scale Quickly, So I Plan Ahead

As someone who likes to keep code clean and future-ready, I knew early on that handling form data types casually wouldn’t work in a growing project.

When a project is small, you might define form types locally — right where they’re used:

interface LoginForm {
  username: string;
  password: string;
}

That works fine when you’re only dealing with a couple of forms. But in a large-scale application — especially one with multiple roles, dynamic fields, and multilingual flows — forms aren’t small or isolated anymore.

You start encountering forms with:

• 20+ fields
• Shared sections like address, school info, Aadhaar details
• “Create” and “Edit” modes that use the same data shape
• Role-specific visibility (state admin sees more fields than a district user)
• Label localization in 3+ languages (but same data structure)

I didn’t want to wait until it became a mess.
So I designed a strategy early on that keeps things:

• Modular
• Consistent
• Reusable across forms and pages

That meant moving away from defining full form types inline, and instead focusing on field-level types that can be composed like building blocks.

By planning ahead this way, I avoided:

• Repeating types for similar forms
• Losing track of which form used which version of a field
• Writing multiple validation schemas for the same field group

This way, I treat form types the same way we treat components — reusable, predictable, and easy to manage.

My Strategy: Shared TypeScript Types for Forms

Instead of defining types per-page or per-component, I create a central file for all form types. This may seem unconventional in some teams, but it has worked brilliantly in my case.

Folder Structure

/types
  └── formFields.ts

All my reusable form field types live in formFields.ts. I don’t break them out per-page — that creates friction and duplication.

What Goes Inside formFields.ts

Each form or section gets a clearly named type.

// formFields.ts

export interface FullNameField {
  full_name: string;
}

export interface AadhaarInfo {
  aadhaar_last_four: string;
}

export interface SchoolDetails {
  school_name: string;
  udise_code: string;
  academic_year_start: string;
  academic_year_end: string;
}

export interface AddressInfo {
  address_line_1: string;
  address_line_2?: string;
  village_city: string;
  brc: string;
  crc?: string;
  pin_code: string;
}

Composing Types Together

The real power comes when I compose multiple types for larger forms.

export type SchoolForm = FullNameField &
  AadhaarInfo &
  SchoolDetails &
  AddressInfo;

This gives me:

• Strong typing across pages/components
• Easy reuse (e.g., if two pages use AddressInfo)
• Clean validation schemas (with tools like yup or zod)
• Support for create/edit modes with partials if needed

And use it like this in your form:

// SchoolFormComponent.tsx

import { useForm } from 'react-hook-form';
import type { SchoolForm } from '@/types/formFields';

const SchoolFormComponent = () => {
  const { register, handleSubmit } = useForm<SchoolForm>();\

  const onSubmit = (data: SchoolForm) => {
    console.log('Submitted Data:', data);
  }

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      {/* Full Name */}
      <input {...register('full_name')} placeholder="Full Name" />

      {/* Aadhaar Info */}
      <input {...register('aadhaar_last_four')} placeholder="Aadhaar Last 4 Digits" />

      {/* School Details */}
      <input {...register('school_name')} placeholder="School Name" />
      <input {...register('udise_code')} placeholder="UDISE Code" />
      <input {...register('academic_year_start')} placeholder="Academic Year Start" />
      <input {...register('academic_year_end')} placeholder="Academic Year End" />

      {/* Address Info */}
      <input {...register('address_line_1')} placeholder="Address Line 1" />
      <input {...register('address_line_2')} placeholder="Address Line 2 (Optional)" />
      <input {...register('village_city')} placeholder="Village/City" />
      <input {...register('brc')} placeholder="BRC" />
      <input {...register('crc')} placeholder="CRC (Optional)" />
      <input {...register('pin_code')} placeholder="PIN Code" />

      <button type="submit">Submit</button>
    </form>
  );
};

export default SchoolFormComponent;

Now in my project, I am also having language support!
so here is how I achieve that too with this type of form and folder structure.

Support for Multilingual Forms

In my projects, forms often support multiple languages — like English (/en), Hindi (/hi), and Gujarati (/gu). But here’s the important part:

While the language changes, the form structure stays exactly the same.

So instead of defining separate form types for each language (which would be unnecessary and hard to maintain), I use the same TypeScript types — like SchoolForm — across all language versions of the app.

Only Labels Change, Not Data

What actually changes is:

• Field labels (like “Full Name” or “School Name”.
• Placeholders, error messages, and section headings

These are all handled by internationalization libraries like next-intl or react-i18next.

For example:

<label>{t('full_name')}</label>
<input {...register('full_name')} placeholder={t('enter_full_name')} />

So whether the user is on /en/school, /hi/school, or /gu/school, the SchoolForm type remains unchanged:

type SchoolForm = FullNameField & AadhaarInfo & SchoolDetails & AddressInfo;

This keeps the validation, API payloads, and logic identical, which simplifies testing and maintenance — you’re only switching the UI language, not the data shape.

Edit vs Create Mode Handling

Another thing I often need is support for both Create and Edit modes using the same form.

In Create mode:

• All fields are usually empty
• Validation is strict (e.g., required fields)

In Edit mode:

• Most fields are pre-filled with existing data
• Some fields may be optional, or skipped

Now, instead of writing a separate type like EditSchoolForm, I simply reuse the original type but make all fields optional using TypeScript’s built-in Partial<> utility:

type PartialSchoolForm = Partial<SchoolForm>;

This gives me a flexible type where every field is optional:

// Example: Edit form with prefilled data
const { register } = useForm<PartialSchoolForm>({
  defaultValues: {
    full_name: 'Existing Name',
    udise_code: '123456',
    // others may be left blank
  }
});

This is especially useful when:

• You fetch existing data from the API
• You want to let users skip certain fields while editing
• You want to reuse the same UI form without rewriting logic

And best of all — you don’t need to define or maintain separate types for edit and create flows.

If your forms feel overwhelming or hard to maintain, try consolidating your field types into one shared file. Compose them like Lego blocks.

It’s one of those small things that makes a huge difference once your project grows.

💬 Let me know your form handling strategy in the comments. Have a different approach that works for your team? I’d love to hear it.

How I structured a scalable and maintainable codebase for a multilingual, role-based government web application using Next.js 14+ App Router.

Building government-grade applications isn’t just about ticking boxes for functionality — it’s about security, access control, accessibility, and long-term maintainability. Recently, I worked on a multilingual government portal built with Next.js using the new App Router, and supporting multiple user roles (e.g., state admin, school admin, viewer, etc.).

One of the biggest architectural decisions we made early on was: How do we organize our folders and files to scale as the app grows in features, roles, and languages?

In this article, I’ll walk you through the folder structure we landed on, the reasons behind every major decision, and how this structure made our life easier while building, testing, and maintaining the app.

Requirements at a Glance

Before jumping into the code, let me break down the real-world requirements that shaped our folder structure:

• Multi-role Access: Different dashboards, pages, and permissions based on user roles (e.g., viewer, state_admin, country_admin).
• Multilingual Support: URLs are prefixed with the language code (/en, /hi, etc.), and translations are loaded dynamically.
• Multiple Layout Variations: Landing page has a public layout, dashboard pages have a sidebar + header, forms have a simpler layout.
• Route Protection with Middleware: Permissions are enforced both in middleware and per-page logic.
• Reusability and Clarity: Code should be easy to understand and reuse — especially for components, hooks, and types.
• Ease of Testing and Onboarding: Developers should instantly understand where to put and find things.

Project Overview

Let’s take a look at a simplified version of the final folder structure:

app/
├── [lang]/
│   ├── layout.tsx
│   ├── page.tsx              ← Public landing page
│   ├── dashboard/
│   │   ├── layout.tsx        ← Dashboard layout (sidebar + header)
│   │   └── page.tsx
│   ├── user-management/
│   │   ├── page.tsx          ← User list
│   │   ├── create/
│   │   │   └── page.tsx      ← Create form
│   │   └── [id]/edit/
│   │       └── page.tsx      ← Edit form
│   └── ...
├── middleware.ts
├── components/
│   ├── layout/
│   ├── forms/
│   ├── ui/
│   └── ...
├── constants/
├── lib/
│   ├── auth/
│   ├── i18n/
│   └── api/
├── hooks/
├── types/
├── styles/
└── public/

What’s Happening Behind Each Section?

here the explanation is …….

1. Multilingual Routing with [lang]/

We use [lang] as a dynamic segment to prefix all routes:

• /en/dashboard
• /hi/user-management

This allows:

• Clean URL-based language switching.
• Language-specific content and layout logic.
• Easy middleware handling (e.g., redirecting / → /en by default).

Example:

// middleware.ts
const langRegex = /^\/(en|hi)(\/|$)/;
// validate user session & redirect accordingly

2. Page-Level Layout Inheritance

Next.js App Router allows layout composition by nesting.

app/
└── [lang]/
    ├── layout.tsx         ← wraps all child routes
    └── dashboard/
        └── layout.tsx     ← wraps just dashboard and its subroutes

This gives us:

• Public Layout for landing/login.
• Dashboard Layout for sidebar + header.
• Form Layout (optional) for clean create/edit pages.

3. Role-Based Page Access

We use middleware to block access based on roles and page type.

// middleware.ts
if (pathname.includes('/dashboard') && !user.roles.includes('admin')) {
  return NextResponse.redirect(new URL(`/${lang}/403`, request.url));
}

Inside pages, we can still perform fine-grained checks:

if (user.role !== 'country_admin') {
  return <UnauthorizedAccess />;
}

This 2-level check ensures security and user feedback.

4. Clear Component Separation

We divided components into purpose-specific folders:

Folder Purpose layout/ Layouts like SidebarLayout, Header forms/ Composable field blocks, file inputs ui/ Low-level inputs, buttons, toggles modals/ Shared modal components

This makes it easy to reason about whether you’re dealing with structure (layout), business logic (forms), or UI widgets (buttons, inputs).

5. Centralized Constants and Enums

The constants/ folder holds:

• Role definitions
• API route mappings
• Language keys
• Permissions

Example:

export const _ROLES = {
  VIEWER: 'viewer',
  STATE_ADMIN: 'state_admin',
  COUNTRY_ADMIN: 'country_admin',
};

6. types/ and lib/ for Business Logic

We separate data modeling (types/) from utility logic (lib/).

• types/: Form field types, API response models.
• lib/api/: API call wrappers (using Axios/fetch).
• lib/auth/: Login/logout helpers.
• lib/i18n/: Dynamic translation loader and language switcher.

This makes it very easy to:

• Reuse types across frontend/backend
• Mock APIs during testing
• Swap logic without touching UI code

7. Reusable Hooks

All custom hooks go inside hooks/. Examples:

• useUserRole()
• useLanguageSwitcher()
• useFormSubmit()
• useDebouncedSearch()

Hooks isolate logic and keep components clean.

Real Example: Create/Edit Page Flow

Let’s say we want to build /en/user-management/create and /en/user-management/[id]/edit.

Here’s how we did it:

• Created shared form logic inside components/forms/UserForm.tsx
• Loaded the page in:
• app/[lang]/user-management/create/page.tsx
• app/[lang]/user-management/[id]/edit/page.tsx
• Used generateMetadata() for dynamic titles
• Passed mode = 'create' | 'edit' as props to the form

This avoids duplicating code and ensures consistency.

Why This Structure Works in Production

• Discoverability: New devs immediately understand the layout.
• Testing & Reuse: Easy to test logic (in hooks/lib) separately.
• Scalability: Easily add new roles, pages, or languages.
• Security: Enforced role access at middleware and component level.
• Separation of Concerns: Components, types, routes, logic — all live where they belong.

Building a production-grade Next.js app for a multilingual, multi-role government portal is more than routing and styling. It’s about building a scalable foundation that supports your team and future development.

The folder structure I shared here is based on real challenges — not just theoretical best practices. Whether you’re building a school portal, admin dashboard, or citizen-facing app, this structure will help you stay organized and confident.

If you’re starting a complex Next.js project — especially one that involves roles and languages — consider starting with this architecture. It’s served us well in real-world use cases, and it’ll serve you too.

React is fast. But your app? Not so much.

It’s frustrating — you follow best practices, split your components, maybe even use memoization. Still, performance feels off. Sluggish buttons. Delayed renders. Janky transitions.

The truth is: React’s slowness is rarely React’s fault. It’s usually yours. Or rather, it’s what you’re ignoring.

Let’s look at 5 real reasons your app feels slow, and what you can do right now to fix them.

1. 💥 Unbatched State Updates in Event Handlers

React batches state updates inside synthetic events and lifecycle methods. But outside of those (e.g., inside setTimeout, fetch, or Promise.then()), it doesn’t batch by default — which leads to extra re-renders.

The mistake:

setLoading(true);
setData(response.data); // Triggers two renders

The fix (React 18+):

Use startTransition() or flushSync() when necessary:

import { flushSync } from 'react-dom';

flushSync(() => {
  setLoading(true);
});
setData(response.data);

Or combine state:

setState({ loading: true, data: response.data });

Tip: Prefer batching logic or using reducers for grouped updates.

2. 🎢 Useless Re-renders from Unmemoized Components

Even small components re-rendering unnecessarily can bog down your UI — especially in lists, modals, or dashboards.

The mistake:

const Item = ({ data }) => {
  console.log('Rendered'); // Will log way too often
  return <div>{data.label}</div>;
};

The fix:

const Item = React.memo(({ data }) => {
  return <div>{data.label}</div>;
});

Also use useCallback and useMemo to prevent prop changes that trigger children to re-render.

const handleClick = useCallback(() => {
  doSomething();
}, []);

3. 🧠 Not Using Lazy Loading & Code Splitting

Why load the entire app when the user hasn’t even clicked beyond the login screen?

The mistake:

import Dashboard from './Dashboard';

The fix:

const Dashboard = React.lazy(() => import('./Dashboard'));

Wrap with Suspense:

<Suspense fallback={<Spinner />}>
  <Dashboard />
</Suspense>

Also consider tools like:

• React Router’s lazy routing
• Vite or Webpack dynamic imports
• Bundle Analyzer to spot large chunks

4. 📊 Not Virtualizing Large Lists

Rendering 1,000+ DOM nodes is a quick way to kill performance — even if React is fast. Browsers still need to lay them all out.

The fix: Virtualization

Use tools like:

• react-window
• react-virtualized

Example:

import { FixedSizeList as List } from 'react-window';

<List
  height={400}
  itemCount={1000}
  itemSize={35}
  width={300}
>
  {({ index, style }) => <div style={style}>Row {index}</div>}
</List>

Only visible rows are rendered. Huge boost. 🔥

5. ⚠️ Ignoring the DevTools Profiler

If you’re guessing why your app is slow — stop. React ships with a Profiler tool that tells you exactly:

• Which components render too often
• How long renders take
• What props or states changed

How to use it:

1. Install React DevTools
2. Switch to the Profiler tab
3. Record interactions
4. Optimize based on real data

You’ll be shocked how many “small” components render 50+ times unnecessarily.

Final Thoughts

Speed isn’t just about reducing file size — it’s about reducing work. Work React has to do. Work the browser has to do.

So next time your React app feels sluggish:

• Batch your state updates
• Memoize what matters
• Split your code smartly
• Virtualize lists
• Profile with purpose

React gives you the tools. It’s up to you to use them right.

Let your app feel as fast as it truly is. 🚀

Enjoyed the article? Give it a 👏 or two!

Let’s be real — most dashboards start off as a simple list and a couple of buttons. Maybe a login screen, a few forms, and you’re like, “Cool, it’s working!” But then someone says,
“Hey, can we hide this page for viewers?”
“Oh, we also need it in Hindi.”
“And there’s a new form coming… with a slightly different layout.”

Now you’re drowning in if-else conditions, duplicated components, and hardcoded text you’re praying never needs translation.

I’ve been there. That’s exactly why I decided to rebuild my dashboard architecture from the ground up — using Next.js, with a focus on role-based access, clean layouts, and language support that just works.

But this isn’t just another technical breakdown. Think of this like your future self looking back and thanking you for setting things up right the first time.

We’ll walk through:

• Creating separate layouts for different parts of your app — like landing pages, dashboards, and those annoying-but-necessary form pages.
• Setting up middleware so that users only see what they’re allowed to see.
• Adding language support in a way that makes your app ready for a global audience — without breaking your routing.

It’s not about adding features. It’s about making your app feel calm — even when it’s doing a hundred things.

So grab your favorite beverage, open your code editor, and let’s start building a dashboard that’s as smart as it is scalable.

Tech Stack

• Next.js (App Router)
• React Hook Form
• Zod (optional for validation)
• i18next / next-i18next
• TypeScript

One question that might be coming to your mind …..
“why this tech stack?”
Let me clear it for you.

When you’re building something that’s going to grow — especially a dashboard used by different roles and possibly in multiple languages — your tech choices matter. You don’t just want things that work; you want things that stay sane as features multiply. Here’s what I chose and why it makes sense:

Next.js (App Router)

Next.js gives you routing, layouts, and server-side rendering — all out of the box. But with the App Router, things get even cleaner. It supports nested layouts, server components, and dynamic routing in a way that just fits how real dashboards work.
Need a form with no sidebar? A page that only renders when localized? You can structure that beautifully without hacks.

React Hook Form

Forms are everywhere in a dashboard — login, user creation, settings, filters… you name it. react-hook-form makes form handling fast, lightweight, and easy to scale.
You get built-in support for controlled inputs, validation, and dynamic forms without re-render nightmares. Bonus: it plays well with TypeScript.

Zod (optional, but smart)

Zod is the TypeScript-loving validation library I reach for when I want schema-based form validation. While react-hook-form does basic checks, Zod lets you define a shape once and reuse it for both client-side forms and backend validation.
Think of it as your form’s bodyguard — strict, efficient, and reusable.

i18next / next-i18next

Supporting multiple languages shouldn’t be a painful add-on. next-i18next plugs into Next.js and gives you URL-based language routing, namespaced translations, and support for things like plurals and interpolation.
And i18n isn’t just about translation — it's about accessibility, reach, and user trust. If your app might go public (or serve government users), this is essential.

TypeScript

If you’re building something complex (like dashboards with multiple roles, routes, forms, and validations), TypeScript isn’t optional — it’s your safety net.
It catches bugs early, helps your IDE guide you while coding, and makes it easier to refactor confidently when your app inevitably grows.

Middleware (for Role-Based Access Control)

This is the hidden hero of the architecture. Next.js middleware lets you intercept requests before a page even loads. That means you can check the user’s role, block access to certain routes, and redirect them — all without rendering a thing.
It’s cleaner than adding logic on every page, and it keeps your access rules centralized and consistent.

Together, this stack isn’t just trendy — it’s built for clarity, scalability, and maintainability. Each tool solves a real problem that comes up in growing dashboards, and they all play nicely with each other.

Laying the Foundation: Project Structure That Makes Sense

Before we dive into components, routes, or forms, let’s get one thing straight — project structure is everything.

When you’re working with things like:

• A landing page for public visitors
• A dashboard with a sidebar and private routes
• Form pages that look and behave differently
• Multilingual URLs (/en, /hi, etc.)
• And user-based access control

…you need to set up a folder structure that supports all of it — cleanly.

app/
  [lang]/
    layout.tsx              → Global layout (based on language)
    page.tsx                → Landing Page (public)
    dashboard/
      layout.tsx            → Dashboard Layout (sidebar, header, etc.)
      page.tsx              → Dashboard Home
    user-management/
      page.tsx              → List view
      create/
        page.tsx            → Create User Form
      [id]/
        edit/
          page.tsx          → Edit User Form

Why this works:

• [lang] makes localization easy — the URL controls the language context (/en/dashboard, /hi/dashboard).
• Layouts are split: landing pages use a different layout than the dashboard or forms.
• Create/Edit pages have their own clean URLs — no query strings, easy to handle with access control.

This setup keeps things modular, readable, and ready to scale. Whether you’re adding a new feature or applying role checks, you always know where your logic lives.

🛡️ Role-Based Access Control with Middleware

Now that our folder structure is ready, let’s talk about who gets to see what.

In a real-world dashboard, not every user should have access to every page. A school admin shouldn’t access super admin settings. A viewer might only be allowed to see certain sections, and not touch any forms at all. So how do we enforce that?

Instead of cluttering every page with permission checks, we do something smarter — we use middleware.

Middleware in Next.js lets you run logic before a request reaches the page. This is perfect for access control. It’s like a bouncer at the door — only letting the right people into the right rooms.

Here’s how I approached it.

Understanding the Flow

When a user navigates to a route — let’s say /en/user-management/create — the middleware runs before the page loads. At that point, we check:

• Is the user logged in?
• Do they have the right role?
• Are they allowed to access this path?

If anything fails, we stop them right there — either by redirecting to the login page or showing a 403 Forbidden screen.

The Role Logic

I maintain role-based permissions in a centralized config — a simple object where each role is mapped to the routes it’s allowed to access.

When middleware runs, it grabs the current user’s role (usually from a token or session cookie), checks the requested path, and compares it with the allowed paths for that role. If it doesn’t match, access is denied.

No if-else blocks scattered across components. Just one central place to define what each role can and cannot do.

Why Middleware Works Better

If you’ve ever tried to handle access inside components, you know how messy it gets. Flashing pages, state-based checks, awkward redirects — it's not ideal.

Middleware avoids all that. It’s server-first, fast, and completely decouples access control from your UI code. It ensures that restricted pages don’t even begin to render for unauthorized users.

And because our routes are clean (/dashboard, /user-management, etc.), matching paths in middleware becomes straightforward.

This setup makes the app feel smoother and more secure. Users never see parts of the app they’re not supposed to, and developers aren’t stuck adding permission checks on every page.

Language Support with next-i18next

If you’re building an app in a multilingual country like India, supporting more than one language isn’t just a nice-to-have — it’s essential. You want your dashboard to feel personal, familiar, and accessible to users, whether they speak English, Hindi, or any other regional language.

But here’s the challenge: doing i18n right often ends up messy — scattered translation logic, inconsistent labels, weird bugs where only half the page gets translated.

That’s why I chose next-i18next — a powerful wrapper around the popular i18next library, made to work seamlessly with Next.js (especially the App Router).

Let me walk you through how I approached it.

URL-Based Language Routing

Instead of managing language with cookies or query parameters (which gets messy), I used language prefixes in the URL — like /en/dashboard or /hi/dashboard.

This way:

• Your language context is immediately clear.
• Users can share links in their preferred language.
• The router knows exactly what language to render at every level.

All of this becomes super smooth with next-i18next. It automatically detects the language from the URL segment and loads the correct translation files without you writing manual logic.

Translation File Structure

Each namespace (like dashboard, form, common, etc.) has its own translation file — organized by language. For example:

public/
  locales/
    en/
      common.json
      dashboard.json
    hi/
      common.json
      dashboard.json

This lets you split translations logically and load only what’s needed on each page. So if you’re on the dashboard, it only loads the dashboard.json for that language.

Cleaner code, faster loads.

In Components: Using useTranslation

Once it’s all set up, using translations in your components is dead simple:

const { t } = useTranslation('dashboard');
return <h1>{t('welcome_message')}</h1>;

But where does that welcome_message come from?
It lives in your translation files — one for each language. For example:

public/locales/en/dashboard.json

{
  "welcome_message": "Welcome to your dashboard!"
}

public/locales/hi/dashboard.json

{
  "welcome_message": "आपके डैशबोर्ड में आपका स्वागत है!"
}

With this setup, the app automatically picks the right message based on the current language in the URL (like /en/dashboard or /hi/dashboard). You don’t need to write any if (lang === "en") logic anywhere — it just works.

Bonus: Switching Languages

If your header has a language selector, you can use router.push() to switch between /en/... and /hi/... — and the entire app updates instantly. The best part? You’re not manually reloading or juggling state. The URL handles it for you.

In short, next-i18next made the dashboard truly multilingual — in a way that’s clean, scalable, and most importantly, user-friendly.

Component Reusability: Build Once, Use Everywhere

When building dashboards, it’s tempting to just drop in inputs and buttons directly in each form or page. But once your app starts to grow, you’ll quickly realize: every extra field you duplicate is future technical debt.

That’s why I made every input, dropdown, and even date picker into a reusable component.

Here’s an example — let’s say we need a full name field in multiple forms (user form, school form, admin profile form, etc.). Instead of writing the same <input /> logic again and again, I created a reusable form field component using react-hook-form and TypeScript:

// components/FormInput.tsx
'use client';
import { Controller, Control } from 'react-hook-form';

type FormInputProps = {
  name: string;
  label: string;
  control: Control<any>;
  type?: string;
}

const FormInput = ({ name, label, control, type = 'text' }: FormInputProps) => (
  <div className="mb-4">
    <label className="block mb-1 font-medium text-gray-700">{label}</label>
    <Controller
      name={name}
      control={control}
      render={({ field }) => (
        <input
          {...field}
          type={type}
          className="w-full px-3 py-2 border rounded-lg shadow-sm focus:outline-none focus:ring-2 focus:ring-blue-500"
        />
      )}
    />
  </div>
);

export default FormInput;

Now I can use it like this, anywhere:

<FormInput name="fullName" label="Full Name" control={control} />

It looks consistent, behaves properly with form state, and is super easy to maintain. No need to repeat onChange, onBlur, or validation messages in every form.

This strategy works for all kinds of fields — selects, date pickers, file uploads, checkboxes. The more complex your form gets, the more valuable reusability becomes.

UI Layout Strategy: Keeping Pages Clean, Contextual, and Smart

Every part of your app doesn’t look the same — and it shouldn’t.

• Landing pages are clean and simple, with maybe a header and footer.
• Dashboards have sidebars, headers, and user info.
• Form pages often go full-width or remove distractions.

To handle this elegantly, I use layout files in the App Router.

Here’s how it works:

Folder Structure (again, briefly)

app/
  [lang]/
    layout.tsx              → Base layout (e.g., includes language, theme, etc.)
    page.tsx                → Landing page
    dashboard/
      layout.tsx            → Dashboard layout (sidebar, header)
      page.tsx              → Dashboard main view
    user-management/
      create/page.tsx       → Form page (minimal layout)

Base Layout: app/[lang]/layout.tsx

This wraps all pages under a language, and is a good place for global wrappers like theming, font loading, or global providers.

// app/[lang]/layout.tsx
import { ReactNode } from 'react';
import Header from '@/components/Header';

export default function LangLayout({ children }: { children: ReactNode }) {
  return (
    <html lang="en">
      <body className="bg-gray-50 text-gray-800">
        <Header />
        {children}
      </body>
    </html>
  );
}

Dashboard Layout: app/[lang]/dashboard/layout.tsx

This layout wraps all pages inside the /dashboard route. It includes a sidebar on the left and a main content area on the right.

// app/[lang]/dashboard/layout.tsx
import { ReactNode } from 'react';
import Sidebar from '@/components/Sidebar';

export default function DashboardLayout({ children }: { children: ReactNode }) {
  return (
    <div className="flex min-h-screen">
      <Sidebar />
      <main className="flex-1 p-6 bg-white shadow-inner">{children}</main>
    </div>
  );
}

But what is <Sidebar />? Let’s build it too — so when you run the app, it actually renders a usable UI.

Sidebar Component: components/Sidebar.tsx

This is a simple, clean sidebar with active link highlighting, built using next/navigation and clsx:

'use client';

import Link from 'next/link';
import { usePathname } from 'next/navigation';
import clsx from 'clsx';

const links = [
  { href: '/en/dashboard', label: 'Dashboard' },
  { href: '/en/user-management', label: 'User Management' },
  { href: '/en/settings', label: 'Settings' },
];

const Sidebar = () => {
  const pathname = usePathname();

  return (
    <aside className="w-64 bg-gray-100 border-r min-h-screen p-4">
      <h2 className="text-xl font-semibold mb-6">Admin Panel</h2>
      <nav className="flex flex-col gap-2">
        {links.map((link) => (
          <Link
            key={link.href}
            href={link.href}
            className={clsx(
              'px-3 py-2 rounded hover:bg-blue-100 transition',
              pathname === link.href ? 'bg-blue-200 font-medium' : 'text-gray-700'
            )}
          >
            {link.label}
          </Link>
        ))}
      </nav>
    </aside>
  );
};

export default Sidebar;

🔧 Tip: If you’re not using path aliasing (@/components/...), change the import to something like ../../../components/Sidebar.

With this setup:

• The sidebar is consistent across all dashboard pages.
• The active route is highlighted.
• Navigation feels clean and modern.

And best of all — it’s reusable. If you build another section like /school-management later, the layout stays the same — just plug in new pages under it.

What This Renders

When you visit /en/dashboard, this is what you'll actually see on the screen:

• The global header (from the root [lang]/layout.tsx)
• The sidebar (from the /dashboard/layout.tsx)
• The dashboard content (from /dashboard/page.tsx)

And it’ll look clean, responsive, and separate from the layout you get on, say, the landing page or form screen.

✍️ Minimal Layout for Forms

Sometimes you want no sidebar — just a full-width clean form.

That’s easy: simply don’t define a layout in /user-management/create. It will fall back to the base [lang]/layout.tsx, which might just have the header.

Or, if you want to strip even that out — make your own layout.tsx under /user-management/ that renders only the form with a back button.

By breaking layouts up this way, you’re no longer wrapping every component in if (showSidebar) logic.

Form Logic with React Hook Form + Zod

If you’ve worked on dashboards for more than five minutes, you know one thing: forms are everywhere. Whether it’s adding a user, editing a school, applying filters, or submitting settings — forms are the main way users interact with your app.

And they can get messy fast. Different forms need different fields, some need validation, some are reused across multiple pages, and all of them need to behave reliably.

That’s why I chose React Hook Form for form state management — and paired it with Zod for schema-based validation. The result? Clean, efficient, and scalable forms that don’t need rewriting every time requirements change.

Why React Hook Form?

Unlike other form libraries that re-render on every keystroke, react-hook-form is performance-first. It’s also super easy to integrate with any kind of input — native, custom, or even 3rd-party components.

Even better: it works seamlessly with TypeScript, which means your forms are not just functional, they’re type-safe too.

Adding Zod for Schema Validation

While React Hook Form has built-in validation, I wanted more control — especially for complex validations, cross-field rules, and reusability. That’s where Zod comes in.

You define a schema once and use it for both form validation and backend validation if needed. It acts like a contract: the form must match this shape.

A Real Example: Create/Edit User Form

Let’s build a basic user form using react-hook-form, Zod, and the reusable input component we made earlier.

Step 1: The Schema

// schemas/userSchema.ts
import { z } from 'zod';

export const userSchema = z.object({
  fullName: z.string().min(3, 'Full Name is required'),
  email: z.string().email('Invalid email'),
  role: z.enum(['admin', 'viewer', 'editor'], {
    errorMap: () => ({ message: 'Role is required' })
  }),
});

🛠 Step 2: The Form Component

'use client';

import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import { userSchema } from '@/schemas/userSchema';
import FormInput from '@/components/FormInput';
import { z } from 'zod';

type UserFormValues = z.infer<typeof userSchema>;

export default function UserForm() {
  const {
    handleSubmit,
    control,
    formState: { errors },
  } = useForm<UserFormValues>({
    resolver: zodResolver(userSchema),
    defaultValues: {
      fullName: '',
      email: '',
      role: 'viewer',
    },
  });

  const onSubmit = (data: UserFormValues) => {
    console.log('Submitted data:', data);
    // Send to API or dispatch to Redux, etc.
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)} className="max-w-md space-y-4">
      <FormInput name="fullName" label="Full Name" control={control} />
      <FormInput name="email" label="Email" control={control} type="email" />
      <FormInput name="role" label="Role" control={control} />
      <button
        type="submit"
        className="px-4 py-2 bg-blue-600 text-white rounded hover:bg-blue-700"
      >
        Submit
      </button>
      {/* Simple error display (optional) */}
      {Object.values(errors).length > 0 && (
        <div className="text-red-600 mt-2">
          {Object.values(errors).map((err, idx) => (
            <div key={idx}>{err?.message}</div>
          ))}
        </div>
      )}
    </form>
  );
}

Final Walkthrough: What We Built & What It Delivers

Let’s take a step back and see the bigger picture.

Over the course of this build, we’ve created more than just a dashboard — we designed a scalable foundation for a real-world admin interface.

Here’s what we now have:

• A clean project structure using Next.js App Router that separates landing pages, dashboard views, and form pages clearly — with language-aware routing built-in.
• Role-based access control using middleware, ensuring users only see what they’re allowed to, without extra logic inside every page.
• Seamless language support with next-i18next, letting us show the entire UI in English, Hindi, or any future language — driven by URL segments and JSON files.
• Fully reusable UI components (like inputs and dropdowns), making forms consistent, accessible, and easy to maintain.
• Smart layout logic using nested layout.tsx files, where landing pages, dashboards, and forms all have their own clean layouts — without one bloated global wrapper.
• Form handling with react-hook-form and Zod, giving us instant validation, strong typing, and reliable submission logic.
• A working Sidebar and form UI, so that when you run this locally and visit a route like /en/dashboard or /en/user-management/create, it actually works and looks good out of the box.

The Output?

A modern dashboard that:

• Supports multiple user roles securely
• Switches languages instantly
• Has structured code ready for teams
• Can scale with new modules and routes effortlessly

No more clutter. No more hacks. Just a solid Next.js-based admin app that’s ready for production.

Feel free to take this, remix it, and scale it to fit your next project or team.

And if this helped you in any way — give it a share, a save, or just drop a comment.
Happy building! 🚀✨

In Part 1 of this series, we laid the groundwork for your journey into the Vue.js ecosystem.

We didn’t just write “Hello World.” We walked through how to install Vue, understand its reactivity system, and see that magical moment when the UI updates automatically in response to your data changes.

We explored:

• What Vue is and why it’s gaining so much popularity
• How it’s different from other frameworks like React or Angular
• How to create your first Vue app with just a <script> tag or via Vite for more serious projects
• The data() method and how it powers Vue's reactivity
• Declaring methods inside the methods object and using them in the template
• How to respond to user events using the @click directive

By the end of Part 1, you hopefully understood how Vue connects your JavaScript logic to the browser’s DOM with minimal friction — and how it does so in a declarative, easy-to-follow way. We built a simple counter to demonstrate how user interactions could drive the application’s behavior. More importantly, we saw just how approachable Vue is, especially for developers coming from a vanilla JavaScript or jQuery background.

That first part was all about getting your hands dirty — to feel how Vue works.

But now it’s time to start building like a developer.

If you’ve made it this far, congratulations — you’re already ahead of most who just browse the docs and leave. You’ve taken action, written some code, and hopefully seen your first Vue app respond to your data in real time. That reactive feel — where the UI updates instantly with your logic — is what makes Vue such a pleasure to work with.

But right now, you’re likely at a crucial stage.

Maybe you’re asking:

• “How do I loop through items and render lists?”
• “How do I show or hide elements dynamically?”
• “How do I bind a class or style based on some logic?”
• “How do I work with forms the Vue way?”
• “How do I split up my app into smaller components?”

These are all great questions — and that’s exactly what we’re covering in this part.

This article is all about mastering the core building blocks you’ll use daily when working with Vue. These aren’t advanced or obscure techniques — these are the tools that professional Vue developers use every single day.

We’ll take a hands-on approach, showing you practical examples of:

• Vue’s template syntax (v-bind, v-model, v-if, v-for)
• How to style elements dynamically
• Working with events and modifiers
• Building forms with real-time two-way binding
• Creating reusable components
• Communicating between components via props and events

This is where you start thinking in Vue — not just writing code that works, but understanding how and why things work in the Vue ecosystem.

Let’s dive in.

1. Vue’s Template Syntax

Vue uses special HTML attributes (called directives) that begin with v-. These connect your HTML to Vue’s data and logic.

A) v-bind — Bind Attributes Dynamically

<img v-bind:src="imageUrl" />

Shorthand:

<img :src="imageUrl" />

Use it to bind any HTML attribute: href, class, style, etc.

Real-World Example

<a :href="profileLink" target="_blank">Visit Profile</a>

data() {
  return {
    profileLink: 'https://github.com/yourname'
  };
}

B) v-if and v-else — Conditional Rendering

<p v-if="isLoggedIn">Welcome back!</p>
<p v-else>Please log in.</p>

data() {
  return {
    isLoggedIn: false
  };
}

C) v-for — Loop Through Data

<ul>
  <li v-for="item in shoppingList" :key="item.id">
    {{ item.name }}
  </li>
</ul>

data() {
  return {
    shoppingList: [
      { id: 1, name: 'Milk' },
      { id: 2, name: 'Bread' },
      { id: 3, name: 'Eggs' }
    ]
  };
}

Remember: always include :key when looping to help Vue track changes efficiently.

2. Binding Classes and Styles

Vue allows dynamic styling directly in templates using :class and :style.

A) Binding Classes Conditionally

<p :class="{ active: isActive }">Toggle me</p>

data() {
  return { isActive: true };
}

B) Binding Inline Styles

<p :style="{ color: textColor, fontSize: fontSize + 'px' }">Styled text</p>

data() {
  return {
    textColor: 'red',
    fontSize: 18
  };
}

3. Event Modifiers

Vue provides modifiers to control how events behave.

• .prevent: prevents the default behavior
• .stop: stops the event from bubbling up
• .once: the event is triggered only once

Example:

<form @submit.prevent="handleSubmit">...</form>

This prevents the page from reloading on form submission.

4. Form Handling with v-model

v-model provides two-way binding between inputs and your Vue data.

<input v-model="name" placeholder="Enter your name" />
<p>Hello, {{ name }}!</p>

data() {
  return {
    name: ''
  };
}

Works with input, textarea, select, checkboxes, and radios.

5. Creating Reusable Components

Vue components let you split your app into manageable, reusable parts.

Example: Greeting.vue

<template>
  <p>Hello, {{ name }}!</p>
</template>

<script>
export default {
  props: ['name']
};
</script>

Use it like this:

<Greeting name="Alice" />
<Greeting name="Bob" />

6. Emitting Events from Components

Child components can communicate with parent components by emitting custom events.

Child (Button.vue)

<template>
  <button @click="$emit('say-hi')">Say Hi</button>
</template>

Parent (App.vue)

<Button @say-hi="handleHi" />

methods: {
  handleHi() {
    alert('Hi from child!');
  }
}

Recap: What You’ve Learned

• Use v-bind, v-if, v-for, v-model to build dynamic UIs
• Dynamically bind styles and classes
• Use event modifiers to control DOM behavior
• Handle user input with reactive data
• Create and reuse components with props
• Send events from child to parent with $emit

What’s Next?

In Part 3, we’ll cover:

• Vue CLI or Vite for real-world projects
• Project structure and organization
• Routing with Vue Router
• State management with Pinia
• Building a multi-page Vue application

This was Part 2 of my “Vue.js from Beginner to Expert” series. You can find the link of first part in the beginning of this article or in my profile -> stories.
After covering all these 4 parts, I will also publish a full front-end project using Vue.js.

📚 Part 1: Getting Started with Vue.js — A Beginner’s Friendly Guide

📚 Part 1: Getting Started with Vue.js — A Beginner’s Friendly Guide

• What is Vue.js?
• Why Vue (vs React/Angular)?
• How Vue works (basic idea of reactivity)
• How to add Vue via CDN
• How to create your first Vue app
• Vue instance, data(), and methods
• Simple event handling and binding
• First interactive app (like a counter or todo)

🔗 Part 2: Mastering the Fundamentals — Templates, Loops, and Forms in Vue.js

• Template syntax (v-bind, v-model, v-if, v-for)
• Binding styles and classes
• Event modifiers
• Form handling with v-model
• Creating reusable components
• Passing props and emitting events

🧠 Part 3: Going Modular — Vue CLI, Routing, and State Management

• Installing via Vue CLI or Vite
• File structure and components
• Routing with Vue Router
• Introduction to Pinia (state management)
• Building a small multipage app

⚙️ Part 4: Advanced Vue Concepts — Composition API, Best Practices & Real-World Patterns

• Why and how to use Composition API
• Refs vs reactive
• watch, computed, and lifecycle hooks
• Folder structure and code organization
• Best practices and performance tips
• What to learn next: VueUse, Nuxt, testing

Now, let’s dive into the first article:

📚 Part 1: Getting Started with Vue.js — A Beginner’s Friendly Guide

Are you completely new to Vue.js? You’ve come to the right place. In this guide, we won’t assume you know anything about JavaScript frameworks. We’ll explain what Vue is, why it’s beginner-friendly, and walk you through creating your very first interactive app — all with just a browser and a text editor.

What is Vue.js?

Vue.js (pronounced like “view”) is a JavaScript framework for building interactive web interfaces. It helps you build apps where the content changes dynamically without reloading the page — like counters, forms, dashboards, or even entire websites.

Think of it like this:
👉 HTML builds your page
👉 JavaScript adds interactivity
👉 Vue helps you organize both and make them work together more easily

🧠 Why Choose Vue (Especially as a Beginner)?

• ✅ Simple to start: You don’t need to install anything to try it out.
• ✅ Clean syntax: Looks like regular HTML with a little JavaScript.
• ✅ Fast results: Build something interactive in under 5 minutes.
• ✅ Scales well: You can go from small projects to big apps easily.

🚀 Let’s Create Your First Vue App (No Installation!)

Create a new HTML file called index.html. Paste this into it:

<!DOCTYPE html>
<html>
  <head>
    <title>Vue Hello World</title>
    <script src="https://unpkg.com/vue@3"></script>
  </head>
  <body>
    <div id="app">
      <h1>{{ message }}</h1>
      <button @click="changeMessage">Click Me</button>
    </div>

    <script>
      const { createApp } = Vue;

      createApp({
        data() {
          return {
            message: 'Hello from Vue!'
          };
        },
        methods: {
          changeMessage() {
            this.message = 'You clicked the button!';
          }
        }
      }).mount('#app');
    </script>
  </body>
</html>

🔍 What’s Happening Here?

• {{ message }} — This is Vue’s way of displaying dynamic data.
• @click="changeMessage" — This listens for a click and runs a function.
• The data() method returns reactive values.
• The methods section contains your functions.

✨ Try Editing It Yourself

• Change the text of message
• Add a second button that changes the message to something else
• Add a new piece of data, like a name, and display it

🛠️ Build Your First Small App: A Counter

Here’s a basic counter app:

<div id="app">
  <h2>Counter: {{ count }}</h2>
  <button @click="count++">Increment</button>
  <button @click="count--">Decrement</button>
</div>

<script>
  const { createApp } = Vue;

  createApp({
    data() {
      return {
        count: 0
      };
    }
  }).mount('#app');
</script>

No refresh needed — Vue handles all DOM updates for you.

🧩 What You Learned So Far

• How to include Vue in a webpage
• What data() and methods are
• How to make your page interactive
• How Vue updates the UI reactively

This is the foundation of Vue — and you’ve already created a dynamic app!

👉 What’s Next?

In Part 2, we’ll cover:

• Vue’s special attributes (v-bind, v-for, v-if, v-model)
• Making forms and lists
• Writing reusable components

Stick with me — by the end of this series, you’ll be writing Vue apps with confidence!