Export, import, and the class that replaces fifty exports

This was the last of the JavaScript run-up. The stated plan is to finish these fundamentals this week and start Playwright itself immediately after.

Two topics, and they are really one argument. Export and import comes first, it runs into a wall, and classes are the way through the wall.

The setup: one file has things, another file wants them.

// testutil.js
export let BASE_URL = "https://app.vwo.com";

export function formatUpperCaseString(sname) {
    return sname.toUpperCase();
}

let fname = "Pramod";        // no export, so importers cannot reach it

// 155.js
import { BASE_URL, formatUpperCaseString } from './testutil.js';

console.log(BASE_URL);                          // https://app.vwo.com
console.log(formatUpperCaseString("Pramod"));   // PRAMOD

The analogy used in class is worth keeping because it draws the right boundary. Import and export is trade between countries, not family. There is no relationship between the two files. Inheritance is the one with a relationship, and that comes later.

A file can export many things by name, and at most one thing as the default.

// logs/logger.js
export default function log(message) {
    console.log("[LOG] " + message);
}

export function logBetter(message) {
    console.log("[LOGS] " + message);
}

// 157.js - default import, no braces, and the name is yours to pick
import log from './logs/logger.js';
log('Starting');                    // [LOG] Starting

// the named one from the same file still needs braces
import { logBetter } from './logs/logger.js';

Two modules can export the same name. as renames on the way in, which is what makes that survivable:

// 156_test.js - same export name from two different modules
import { BASE_URL as bul_util, formatTestName } from "./utils.js";
import { BASE_URL as bul_testtul, formatUpperCaseString } from "./testutil.js";

console.log(bul_util);                  // https://api.staging.com
console.log(bul_testtul);               // https://app.vwo.com
console.log(formatTestName("login"));   // TC_LOGIN

The alias explanation given was a childhood nickname: the same person, a shorter name for local use.

import * also exists, and the session's position on it was blunt.

A question from the floor drove the whole second half. If a utility file has ten functions, do you write export ten times? What about a hundred?

The answer was that you do not, and the tone was not gentle about it.

This is not theoretical. It is exactly how the framework the 2x batch built is wired: one export class LoginPage, and the spec imports that single name to reach every locator and action on the page.

Before object orientation there was procedural programming: C, COBOL, and everything as a function. For a bank you would write a balance function, an add function, a subtract function, and the data floated separately.

The objection raised in class is that this does not match the world. We live somewhere with relationships, with things inherited from a parent, with information deliberately hidden, and with the same person behaving differently in different company. Procedural code had almost no way to express any of that, so the four ideas that became object orientation are inheritance, polymorphism, encapsulation and abstraction, with classes and objects underneath them.

The consequence to keep: a class costs no memory. Memory is allocated when you create an object from it, and each object gets its own.

class Person {
    #name;
    #age;

    eat() {}
    sleep() {}
}

let pramod = new Person();
let amit   = new Person();

The distinction the session was careful about: pramod is not the object. It is a reference pointing at an object. new Person() on the right is the object; the variable on the left just knows where it lives.

Checked against the repository's own chapter 20 notes, and each of these is the real behaviour:

The # in #name is the JavaScript way of marking a field private, and the reaction it got in class is the point: anyone arriving from Java or Python looks at it and asks what it is, whereas everyone recognises the word private.

That is the argument for TypeScript in one symbol.

The framing used, and it is the one to repeat in an interview: TypeScript is JavaScript plus rules. JavaScript already had object literals that look a bit like classes, but nothing enforced their shape, and at a few thousand tests that stops being survivable. A .ts file compiles to JavaScript before it runs, so the engine never sees TypeScript at all.

Chapters 19 and 20 are written up in the LearningPlaywright3x README, pushed during this session. Two things to know before you follow the run commands.

The second is a version trap worth understanding rather than memorising. The README says ES modules need "type": "module" in package.json or an .mjs extension. On current Node that is no longer true:

node 19_Export_Import/155.js

On Node 22.22.3 that runs fine with no package.json at all, because Node now detects a file using import and treats it as a module. On older Node the same file fails, and the error tells you the fix in the README's own words:

Warning: Failed to load the ES module: 155.js.
Make sure to set "type": "module" in the nearest package.json file
or use the .mjs extension.

Can I change an imported function inside the file that imported it? Yes, though the session moved on quickly. The useful version of this is that imports are live bindings to the exporting module, not private copies.

Is this like importing libraries in Selenium? Yes, close enough to be a fair mental model.

Can there be more than one default export in a file? Syntactically you would be trying to name two things "the main one". There is exactly one default per file, and no limit at all on named exports.

Do we only ever have one file to import from? No. A project has as many modules as it needs, and a single file commonly imports from several, as the alias example does.

Everything so far has been JavaScript. How do we cope when classes switch to TypeScript? By recognising there is nothing new to learn in the switch. All twenty chapters are JavaScript, and TypeScript adds type annotations and a few keywords such as private in place of #. The demonstration was to strip the annotations off a real page object until it was ordinary JavaScript again.

Will we write a class for every page? Yes. Login, inventory, item detail, cart, both checkout steps and checkout complete each get a class. That is the Page Object Model, and it is why this session existed.

• Today's task: watch the Linux basics session on SDET Club, then write your own cheat sheet and post it in the comments. It covers more than forty commands. This came up because ./file.js and ../logs/logger.js in an import path are just relative paths, and that tripped people up.
• AI Fluency part 1 is tonight at 8:00 PM IST, part 2 on Thursday at the same time. Attend live if you can; recordings follow. The companion notes are at AI Fluency: Framework and Foundations.
• Finish Claude 101 and its certification if you have not, then post the certificate on LinkedIn. The recording sits in the SDET Masterclass and takes under an hour at 1.5x. Study guide: Claude 101.
• Claude Code 101 is targeted for the first week of September.
• Class notes board for this batch: the 3x Playwright and AI Mastery Eraser workspace.
• Next up: the constructor, then inheritance, polymorphism, encapsulation and abstraction, all in TypeScript.