Master Table of Contents

• See full index in [01. Introduction]

Who this chapter is for

• Learners who want cleaner code without writing extra boilerplate
• Beginners moving from one-file experiments to real project structure
• Anyone whose code works, but is getting harder to maintain each week

What you’ll learn

• How to use destructuring, spread/rest, and template literals in real coding flow
• How ES modules (import/export) organize code better than copy-paste blocks
• How to structure folders by feature so projects stay manageable

Why this topic matters

As projects grow, “one big file” quickly becomes a nightmare. Modern syntax helps reduce repetitive code, and modules keep logic separated so your app can scale without becoming chaotic.

In real teams, readability and structure matter as much as code that “just runs.”

Core concepts

Destructuring

Use destructuring when it makes intent clearer, not just because it looks modern.

const user = { name: "Alya", role: "student" };
const { name, role } = user;

Spread and rest

These are used constantly for immutable updates and function flexibility.

const numbers = [1, 2, 3];
const all = [...numbers, 4, 5];

ES modules

Modules help you split logic into reusable, testable pieces.

export function greet(name: string) {
	return `Hello, ${name}`;
}

Rule of thumb:

• Export what is reusable.
• Keep private details inside the module.

Step-by-step walkthrough

Step 1 — Replace repetitive access patterns

Replace repetitive obj.something access with destructuring only when readability improves.

Step 2 — Split helpers into module files

Move formatting, validation, and API logic into separate helper files.

Step 3 — Organize by feature

Group related files (components, services, types) by feature/domain.

Target in this chapter: stop dumping unrelated logic into one file.

Practical examples

Example 1 — Modular utility usage

import { greet } from "./greet";
console.log(greet("Nora"));

Expected output:

Hello, Nora

Example 2 — Rest parameters

function sum(...values: number[]): number {
	return values.reduce((a, b) => a + b, 0);
}

Real case:

• This pattern is useful when the number of inputs is dynamic (filters, tags, dynamic forms).

Common mistakes and how to avoid them

• Mixing CommonJS and ESM in the same project -> pick one module style
• Over-destructuring everything -> use destructuring only when clearer
• Creating very deep folder trees too early -> keep structure shallow and practical
• Exporting everything by default -> expose only what other files actually need

Mini Project

• Refactor one existing script into modules:
• types for data contracts,
• utils for helpers,
• main for app flow.

Bonus:

• Add one index file that re-exports helpers cleanly.

Quick practice

• Refactor one object access block with destructuring
• Split one large file into two modules
• Create one index module to re-export helpers
• Explain in one sentence: when is destructuring making code worse, not better?

Key takeaways

• Modern syntax is useful when it improves clarity, not when it looks fancy
• Modules are the foundation of maintainable JavaScript/TypeScript projects
• Simple, consistent structure beats overengineered folder systems

Next step

Continue to [07. Browser Fundamentals Before React]