For me, that something was swipeActions, the swipe-from-the-edge buttons you see in iOS Mail. My app already rendered each row inside a SwiftUI List, so wiring up Edit / Skip / Delete swipe actions should have been one line of SwiftUI. Except @expo/ui did not expose it.

This post walks through building it as a local Expo module. The result is around 80 lines of Swift, around 30 lines of TypeScript, and one npm install to wire up. If you have never written Swift before, that is fine. I will explain the Swift-specific bits as we go.

View or modifier? The choice is forced

Before any code, a decision: do you build this as a native view or a native modifier?

A native view is what npx create-expo-module --local creates by default. You expose a SwiftUI view to JS, and JS renders it like any other component.

A native modifier is what Expo UI uses for things like font(...) or onTapGesture(...). They do not render anything on their own, they style or extend an existing view. Think of them as the SwiftUI equivalent of styled-components mixins, except they can also attach behaviour like gestures and lifecycle callbacks.

For swipeActions, the choice is forced by SwiftUI itself. .swipeActions(edge:allowsFullSwipe:content:) only works when SwiftUI sees it attached to a row inside a List. If you wrap the row in a custom view, SwiftUI no longer sees a row inside a list, it sees a generic view containing your wrapper containing the row, and .swipeActions becomes a no-op. So, modifier it is.

Creating the module

npx create-expo-module@latest --local swipe-actions

This creates modules/swipe-actions/ with a sample WebView component, Android files, and a web fallback. For a SwiftUI-only modifier you can throw most of it away. Here is the final structure I ended up with:

modules/swipe-actions/
├── expo-module.config.json
├── package.json
├── index.ts
└── ios/
    ├── SwipeActions.podspec
    ├── SwipeActionRecord.swift
    ├── SwipeActionsModifier.swift
    └── SwipeActionsModule.swift

The config narrows to iOS:

{
  "platforms": ["apple"],
  "apple": { "modules": ["SwipeActionsModule"] }
}

And the package.json is just a name plus main:

{
  "name": "swipe-actions",
  "version": "1.0.0",
  "main": "index.ts",
  "types": "index.ts",
  "private": true
}

The podspec needs one line beyond the default, a dependency on ExpoUI, which is what gives us access to the modifier registry:

s.dependency 'ExpoModulesCore'
s.dependency 'ExpoUI'

The Swift side, in three small files

We will go bottom-up. A "record" that describes one swipe action, a modifier that consumes those records, and a module that registers the modifier so JS can use it.

A quick Swift primer for RN devs

A few Swift concepts come up in the next sections. If you already know Swift, skip this.

• struct and class are like JS classes, but struct is a value type (copied when passed around) and class is a reference type. SwiftUI uses structs almost everywhere because views are cheap to recreate.

• protocol is Swift's word for interface. When a type "conforms to" a protocol, it is promising to provide certain methods or properties.

• ? after a type means "optional", essentially the same as T | null in TypeScript. String? is a string or nil.

• @PropertyWrapper (anything starting with @) is a Swift annotation that adds behaviour to a property, similar to a decorator.

• some View is a return type that means "some specific type that conforms to View, the compiler will figure out which one." You will see it on every SwiftUI view's body.

That is enough to read everything below.

A record per action

Each swipe action has an id, a label, an optional icon, an optional tint colour, and an optional role. In Expo's SwiftUI extension, anything you decode from JS params follows the Record protocol and uses @Field to mark which properties come from the JS side:

// SwipeActionRecord.swift
import ExpoModulesCore
import SwiftUI

final class SwipeActionRecord: Record {
  @Field var id: String = ""
  @Field var label: String = ""
  @Field var systemImage: String? = nil
  @Field var tint: Color? = nil
  @Field var role: String? = nil
}

Two things to notice. First, @Field var tint: Color? = nil. ExpoModulesCore decodes hex strings like "#FF3B30" from JS straight into a SwiftUI Color. No manual parsing on either side. Second, role is a string rather than a Swift enum, because the JS side sends "destructive" or "cancel" and decoding into custom Swift enums needs extra setup that is not worth it for two values.

systemImage refers to SF Symbols, Apple's built-in icon library. Names like "trash", "pencil", and "forward.fill" map to icons that ship with iOS, so you do not need to bundle anything.

The modifier

This is the heart of it. A type that conforms to both SwiftUI's ViewModifier protocol (so SwiftUI can apply it) and Expo's Record protocol (so it can be decoded from JS params):

// SwipeActionsModifier.swift
import ExpoModulesCore
import SwiftUI

struct SwipeActionsModifier: ViewModifier, Record {
  @Field var leading: [SwipeActionRecord] = []
  @Field var trailing: [SwipeActionRecord] = []
  @Field var allowsFullSwipe: Bool = false

  var eventDispatcher: EventDispatcher?

  init() {}

  init(from params: Dict, appContext: AppContext, eventDispatcher: EventDispatcher) throws {
    try self = .init(from: params, appContext: appContext)
    self.eventDispatcher = eventDispatcher
  }

  func body(content: Content) -> some View {
    content
      .swipeActions(edge: .trailing, allowsFullSwipe: allowsFullSwipe) {
        ForEach(trailing, id: \.id) { action in
          actionButton(action)
        }
      }
      .swipeActions(edge: .leading, allowsFullSwipe: allowsFullSwipe) {
        ForEach(leading, id: \.id) { action in
          actionButton(action)
        }
      }
  }

  @ViewBuilder
  private func actionButton(_ action: SwipeActionRecord) -> some View {
    let role: ButtonRole? = {
      switch action.role {
      case "destructive": return .destructive
      case "cancel":      return .cancel
      default:            return nil
      }
    }()
    Button(role: role) {
      eventDispatcher?(["swipeActions": ["id": action.id]])
    } label: {
      if let icon = action.systemImage {
        Label(action.label, systemImage: icon)
      } else {
        Text(action.label)
      }
    }
    .tint(action.tint)
  }
}

There is a lot happening here, so let's walk through it.

The two init methods exist because Record requires a no-argument init() for the decoding machinery. The second init is the one Expo actually calls when wiring this up, and it takes the decoded params plus an EventDispatcher, then forwards the params to the standard Record init and stashes the dispatcher.

The eventDispatcher is not a @Field. It is a regular stored property. This trips people up because most other things on a Record are @Fields. The dispatcher does not come from JSON params, it is injected by the registry at registration time, which is why it gets its own init parameter.

func body(content: Content) -> some View is the method every ViewModifier implements. content is the view this modifier is being applied to (in our case, the List row). We return a new view that takes that content and stacks two .swipeActions calls onto it, one for each edge.

ForEach(trailing, id: \.id) is SwiftUI's loop. The \.id syntax is a "key path", Swift's way of saying "use the id property of each element as the React-style key." Inside the closure, $0 is shorthand for the current element (Swift's equivalent of an arrow function's first arg).

actionButton builds a single button. The @ViewBuilder annotation lets us use if/else inside to conditionally include a Label (icon plus text) or a plain Text. When the button is tapped, we call eventDispatcher with a dictionary. That dictionary travels back to JS as an event payload.

One subtle but important detail: the key in ["swipeActions": ["id": action.id]] must match the modifier's type identifier (the \(type field on the JS side, which we will see in a moment). Expo UI registers event listeners in a map keyed by \)type, so if you dispatch under any other name the event silently disappears into nothing. If your event handler is not firing, this is the first thing to check.

Registering the modifier

// SwipeActionsModule.swift
import ExpoModulesCore
import ExpoUI

public class SwipeActionsModule: Module {
  public func definition() -> ModuleDefinition {
    Name("SwipeActions")

    OnCreate {
      ViewModifierRegistry.register("swipeActions") { params, appContext, eventDispatcher in
        try SwipeActionsModifier(
          from: params,
          appContext: appContext,
          eventDispatcher: eventDispatcher
        )
      }
    }

    OnDestroy {
      ViewModifierRegistry.unregister("swipeActions")
    }
  }
}

Module is the Expo base class that every native module extends. definition() is where you describe what the module exposes: its name, lifecycle hooks, methods, views, and so on.

OnCreate and OnDestroy are lifecycle hooks. Registering inside OnCreate rather than at the top level is not optional, the docs call this out specifically to avoid a threading race where the registry is read before your modifier is added.

The third parameter of the registration closure (eventDispatcher) is what gets threaded into the modifier's secondary init. That is the missing link from the previous section.

The JavaScript side

The TS layer is small. It does two things: convert a friendly per-action onPress callback API into a structure that can be serialised across to native, and dispatch incoming events back to the right callback by id.

// index.ts
import { createModifierWithEventListener } from "@expo/ui/swift-ui/modifiers";

export type SwipeActionRole = "destructive" | "cancel";

export interface SwipeActionConfig {
  id: string;
  label: string;
  systemImage?: string;
  tint?: string;
  role?: SwipeActionRole;
  onPress: () => void;
}

export interface SwipeActionsParams {
  leading?: SwipeActionConfig[];
  trailing?: SwipeActionConfig[];
  allowsFullSwipe?: boolean;
}

export function swipeActions(params: SwipeActionsParams) {
  const handlers = new Map<string, () => void>();
  for (const a of params.leading ?? []) handlers.set(a.id, a.onPress);
  for (const a of params.trailing ?? []) handlers.set(a.id, a.onPress);

  const stripPress = ({ onPress, ...rest }: SwipeActionConfig) => rest;

  return createModifierWithEventListener(
    "swipeActions",
    ({ id }: { id: string }) => handlers.get(id)?.(),
    {
      leading: (params.leading ?? []).map(stripPress),
      trailing: (params.trailing ?? []).map(stripPress),
      allowsFullSwipe: params.allowsFullSwipe ?? false,
    }
  );
}

createModifierWithEventListener is the helper Expo UI uses internally for onTapGesture, onAppear, refreshable, and friends. It returns a config object with a \(type (which must match the string we registered on the Swift side) and an eventListener. When the host view renders, it scans its modifiers for event listeners and registers them by \)type.

The stripPress step is necessary because functions cannot cross the JS-to-native boundary as props. We pull the callbacks into a JS-side Map keyed by id, send only the serialisable fields across, and let the single event listener dispatch to the right callback when the native side fires ["swipeActions": ["id": "delete"]].

Wiring it into a screen

From the JS side, you apply it like any other modifier. Drop it into the modifiers array on a row inside a List:

import { swipeActions } from "swipe-actions";
import { List, HStack } from "@expo/ui/swift-ui";

<List>
  <HStack
    alignment="center"
    modifiers={[
      swipeActions({
        leading: [
          {
            id: "archive",
            label: "Archive",
            systemImage: "archivebox",
            tint: "teal",
            onPress: handleArchive,
          },
        ],
        trailing: [
          {
            id: "delete",
            label: "Delete",
            systemImage: "trash",
            tint: "#FF3B30",
            role: "destructive",
            onPress: handleDelete,
          },
          {
            id: "edit",
            label: "Edit",
            systemImage: "pencil",
            tint: "#0A84FF",
            onPress: handleEdit,
          },
        ],
        allowsFullSwipe: false,
      }),
    ]}
  >
    {/* content */}
  </HStack>
</List>

For TS resolution, add the local module to your root package.json:

"swipe-actions": "file:./modules/swipe-actions"

npm install symlinks it under node_modules/.

cd ios && pod install (or npx expo run:ios) autolinks the native side. Done.

Wrapping up

The full source is small enough to read in one sitting, around 110 lines across four files. The hardest part was not writing it, it was figuring out which 110 lines to write. If you are extending Expo UI with your own modifiers, the pattern is the same every time: a Record for params, a ViewModifier that consumes them, an EventDispatcher injected via a secondary init, and a Module that registers the whole thing in OnCreate. Once you’ve built one, the next time is much easier since you’re just repeating the same pattern.

This is where Scrum changes the narrative. It is not just a set of meetings or a to-do list; it is a framework designed to bring order to chaos. If you want to move from frantically putting out fires to delivering consistent value, you need to understand not just what Scrum is, but why it works.

The Foundation of Empirical Control

To understand Scrum, you have to let go of the idea that you can predict the future. Traditional project management assumes we know everything at the start. Scrum assumes we know very little. It is founded on Empiricism, which means making decisions based on what is actually happening, not what we hope will happen.

This approach relies on three non-negotiable pillars.

• Transparency requires that significant aspects of the process must be visible to those responsible for the outcome. There is no hiding bad news.

• Inspection involves frequently checking the Scrum artefacts and progress towards a Goal to detect undesirable variances.

• Adaptation is the ability to adjust the process or material immediately if the inspection reveals issues.

These pillars are supported by five core values: Commitment, Focus, Openness, Respect, and Courage. Without these values, the pillars crumble, and Scrum becomes a hollow shell.

The Team Structure

You cannot play a professional sport with a random crowd of people. You need a dedicated, optimised squad. In Scrum, the team structure is designed for flexibility and speed. We follow the "Two Pizza Rule" famously coined by Jeff Bezos. If you cannot feed the entire team with two pizzas, the group is too large. Ideally, a Scrum Team is 10 people or fewer.

Within this small group, we strip away the traditional hierarchy. There are no managers here, only three distinct roles that balance each other out.

The Product Owner is the visionary. They are responsible for maximising the value of the product. They manage the Product Backlog and clearly communicate the what and the why. They are the single voice of the stakeholder.

The Scrum Master is the servant-leader. They are not a project manager who assigns tasks. Instead, they coach the team, remove impediments that block progress, and ensure the Scrum framework is understood and enacted.

The Developers are the professionals who do the work. They are self-organising and cross-functional. They alone decide how to turn the Product Owner’s vision into a working Increment.

Scrum Events

The heartbeat of Scrum is the Sprint, a fixed time-box of one month or less, which acts as a container for four other formal events designed to ensure inspection and adaptation.

Here is exactly how each event works.

1. The Sprint

• Time-box: One month or less (usually 2 weeks).

• The Concept: This is the container for all other events. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. It is a period of focus.

2. Sprint Planning

• Time-box: Maximum 8 hours for a one-month Sprint (usually 4 hours for a 2-week Sprint).

• How it works: This event lays out the work to be performed for the Sprint. It addresses three specific topics:

  • Topic One: The Why (Sprint Goal). The Product Owner proposes how the product could increase its value in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

  • Topic Two: The What. The Developers select items from the Product Backlog to include in the current Sprint. This is where we must look at two critical metrics:

    • Velocity: This is the team's historical speed. It is a measure of how much work (usually in story points) the team successfully completed in previous Sprints. It tells us how fast we usually run.

    • Capacity: This is how much time we actually have available right now. We calculate this by taking the total available hours of the team and subtracting holidays, meetings, and time off. It tells us how much fuel is in the tank for this specific trip.

  • Topic Three: The How. For each selected item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This often involves breaking stories down into tasks of one day or less.

3. The Daily Scrum

• Time-box: 15 minutes. Strictly.

• How it works: This is an internal meeting for the Developers. It is not a status report to the Scrum Master or management. The purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.

  • The Format: Many teams use three simple questions:

    1. What did I do yesterday that helped the Team meet the Sprint Goal?

    2. What will I do today to help the Team meet the Sprint Goal?

    3. Do I see any impediment that prevents me or the Team from meeting the Sprint Goal?

4. Sprint Review

• Time-box: Maximum 4 hours for a one-month Sprint.

• How it works: This is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog.

  • The Demo: The Scrum Team presents the results of their work to key stakeholders. This is not a PowerPoint presentation; it is a demo of working software.

  • The Feedback: The group discusses what was done, what was not done, and what to do next. The Product Backlog may be adjusted to meet new opportunities.

5. Sprint Retrospective

• Time-box: Maximum 3 hours for a one-month Sprint.

• How it works: This occurs after the Sprint Review and prior to the next Sprint Planning. While the Review inspects the product, the Retrospective inspects the process. The team discusses:

  • What went well?

  • What went wrong?

  • What can we improve in the next Sprint?

  • The Outcome: The team must identify at least one concrete improvement to implement in the upcoming Sprint.

Now, I can see some of you rolling your eyes. You are reading this list and thinking, "Great, more meetings. Just what I needed."

But here is the truth: The goal of Scrum is actually to reduce the number of meetings you have to attend. By condensing all the planning, syncing, and reviewing into these five predictable, time-boxed events, we eliminate the need for all those random, unstructured "quick syncs" and status updates that interrupt your flow. The strategy is to get the talking done efficiently so that for the rest of the time, the Developers can focus on the only thing that matters: actually building the product.

Scrum Artefacts

In a complex environment, ambiguity is the enemy. To fight this, Scrum uses three specific artefacts to ensure everyone is looking at the same thing. If these artefacts are not transparent, decisions will be flawed and risk will increase.

1. The Product Backlog

• What it is: An ordered list of everything that is known to be needed in the product. It is the single source of truth for requirements.

• Refinement: This is an ongoing activity where the Product Owner and Developers add details, estimates, and order to items. We need to get items to a "Ready" state, meaning they are clear enough to be selected in a Sprint Planning meeting.

• Monitoring Progress: The Product Owner tracks remaining work using a Release Burndown Chart. This visualises the trend of work remaining across the entire project timeline, helping to forecast a likely completion date.

2. The Sprint Backlog

• What it is: The set of Product Backlog items selected for the Sprint, plus the plan for delivering them. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint.

• Ownership: The Sprint Backlog belongs solely to the Developers.

• Monitoring Progress: The Developers use a Sprint Burndown Chart. This tracks the total work remaining in the Sprint on a daily basis. If the line is not trending down, the team knows immediately that they need to adapt their plan.

3. The Increment and the Definition of Done

• What it is: The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

• The Definition of Done (DoD): This is the most critical concept for quality. It is a formal description of the state of the Increment when it meets the quality measures required for the product. It is a shared contract. If a Product Backlog item does not meet the DoD, it cannot be released or even presented at the Sprint Review. It returns to the Product Backlog.

Example: A Team-Wide Definition of Done

• Code is written, peer-reviewed, and merged to the main branch.

• Unit tests are written and passing.

• Feature is deployed to the test environment.

• No critical or high-severity bugs are open.

• User documentation has been updated.

DoD vs. Acceptance Criteria It is vital to distinguish the DoD from Acceptance Criteria.

• Acceptance Criteria are specific to a single ticket (e.g., "As a user, when I click 'Reset Password', I receive an email within 2 minutes").

• DoD applies to every ticket (e.g., "The code must be reviewed").

The DoD ensures that we are not just building features, but building a high-quality, maintainable product. Transparency is only achieved when "Done" means the same thing to everyone.

Avoiding Common Implementation Traps

Even with the best intentions, teams often drift back into old habits. Recognising these common anti-patterns is the final step in mastering Scrum.

One frequent mistake is treating the Scrum Master as a team boss or secretary. When the team relies on the Scrum Master to assign work or organise every detail, they lose their self-organisation. The Scrum Master is a coach, not a commander.

Another trap is allowing work to bleed over from one Sprint to the next. This usually happens when stories are too large or the team is overly optimistic. It destroys the value of the Sprint as a hard deadline. The fix is to break stories down into smaller, manageable chunks that can definitely be finished within the time-box.

Finally, the most dangerous mistake is skipping the Retrospective. Teams often feel they are "too busy" to stop and talk about their process. This is short-sighted. The Retrospective is the engine of improvement. Without it, you will never get faster, and you will never fix the systemic issues slowing you down.

The Final Truth: Scrum Reveals, It Does Not Fix

Scrum is often described as "simple to understand, difficult to master". That is the understatement of the century. Many teams fail because they treat Scrum like a magic wand, expecting it to instantly solve their deadlines and bug counts. But Scrum is not a solution; it is a mirror. When you start running Sprints correctly, the framework will ruthlessly expose every crack in your process. You will see clearly where your requirements are vague, where your testing is slow, and where your team lacks focus. That transparency can be uncomfortable. But if you have the courage to stare into that mirror and adapt rather than ignore what you see, you will stop just "doing Agile" and start actually delivering value.

Declaring a variable in javascript

Just in case you don't already know there are three ways of declaring a variable in javascript know to mankind (bots too these days 🤖): var, let and const.

var

Ah, var, a relic of JavaScript's earlier days, presumably crafted by developers hammering away on Windows XP using Notepad as their trusty sidekick. It's notorious for turning straightforward code into a head-scratching puzzle.

Variables declared with var can be both re-assigned and re-declared, setting the stage for some truly perplexing bugs. 😬

let

The cooler, younger sibling introduced in ES6. Variables declared with let can be reassigned but not re-declared within the same scope. It's not necessary to initialise them at the point of declaration.

const

Also debuting in ES6, const is for constants. Reassigning them will throw an error. You must initialise const variables when you declare them.

Variable Scope

Scope defines where variables can be accessed within your code. If you declare a variable inside a function, it's only accessible within that function, not outside. Scope comes in three flavours: global, function, and block.

function daScope() {
  const fullName = "Eren Yeager";
  console.log(fullName); // Outputs: Eren Yeager

  if (true) {
    const titan = "mix veg";
    console.log(titan); // Outputs: mix veg
  }

  console.log(titan); // Error: titan is not defined
}

daScope();

This code neatly illustrates block scoping. However, var plays by its own rules, it's function-scoped, so it can be accessed anywhere within the function.

function daScope() {
  const fullName = "Eren Yeager";
  console.log(fullName); // Outputs: Eren Yeager

  if (true) {
    var titan = "mix veg";
    console.log(titan); // Outputs: mix veg
  }

  console.log(titan); // Outputs: mix veg, no error!
}

daScope();

Think that’s quirky? Check out this scenario:

function greetingCreator() {
    var greeting = "Hello";

    if (true) {
        var greeting = "Hi";  // This redeclares and reassigns `greeting` 🤯  
        console.log(greeting); // Output: "Hi"
    }

    function displayGreeting() {
        console.log(greeting);
    }

    displayGreeting(); // Output: "Hi"
}

greetingCreator();

Both outputs are "Hi", demonstrating that var does not recognise block scope, but only function scope. The greeting inside the if block affects the same greeting declared at the function's start.

Variable Shadowing

To avoid the chaos of var, we use let, which enables variable shadowing. Here, if a variable declared in a nested scope has the same name as one in an outer scope, it shadows the outer variable without affecting it.

function greetingCreator() {
    let greeting = "Hello";

    if (true) {
        let greeting = "Hi"; // A new, shadowed `greeting`
        console.log(greeting); // Output: "Hi"
    }

    function displayGreeting() {
        console.log(greeting); 
    }

    displayGreeting(); // Output: "Hello"
}

greetingCreator();

Illegal Shadowing

And then there’s illegal shadowing, brought to you by var, of course:

function greetingCreator() {
    var greeting1 = "Konichiwa";
    let greeting2 = "Hello";

    if (true) {
        let greeting1 = "Hajime Mashite"; // This is fine
        console.log(greeting1); // Output: "Hajime Mashite"

        var greeting2 = "Hi"; // Error: Identifier 'greeting2' has already been declared 
        console.log(greeting2);  
    }

    function displayGreeting() {
        console.log(greeting2); 
    }

    displayGreeting();  
}

greetingCreator();

Javascript Execution Context

JavaScript's execution context is one of the most fundamental concepts to grasp to understand how code executes, particularly how scopes, hoisting, closures, and asynchronous callbacks work. Let's take a detailed look at how JavaScript handles execution context through a step-by-step example.

Consider this JavaScript code snippet:

var x = 10;
let y = 20;

function multiply() {
    var z = x * y;
    console.log(z);
    return z;
}

function display() {
    let a = 5;
    console.log(a);
    multiply();
}

display();
console.log(x);

Here’s how JavaScript processes this code:

When the script loads, JavaScript creates a Global Execution Context. This global context performs two main actions during the creation phase:

• Variable Environment Creation: Here, all the variable and function declarations are hoisted. Variables declared with var are initialised to undefined, and functions are hoisted with their definitions. Variables declared with let and const remain uninitialised at this point and are in a temporal dead zone.

• Scope Chain Establishment: Sets up the scope chain, which determines the variable access throughout the code.

• This Value Determination: For global execution context, this refers to the global object (window in browsers, global in Node.js).

After hoisting, the environment looks something like:

// Global Execution Context (GEC) starts

// Hoisted during the creation phase of GEC
var x = undefined; // 'var' variables are initialized as undefined
let y;             // 'let' and 'const' are in Temporal Dead Zone (TDZ) and not initialized
function multiply() { /* function body is fully hoisted */ }
function display() { /* function body is fully hoisted */ }

// Execution phase of GEC begins
x = 10; // 'x' is now assigned a value
y = 20; // 'y' is assigned a value and comes out of TDZ

function display() {
    // New Function Execution Context for display
    let a = 5; // Local 'let' declaration, only exists within display
    console.log(a); // Logs 5
    multiply();     // Calls multiply, creating a new context for multiply
}

function multiply() {
    // New Function Execution Context for multiply
    var z = x * y;  // 'var' declared and calculated using global x and y
    console.log(z); // Logs 200
    return z;       // Returns 200, multiply context will be popped off the stack after return
}

display();          // Calls display, logs 5, then 200 from multiply
console.log(x);     // Back in GEC, logs 10

// Both multiply and display Function Execution Contexts have been popped off
// Back in the GEC until script ends, at which point GEC is also remove

• Global Execution Context Setup: At the start, JavaScript engine hoists function declarations and var variables in the global scope.

• Function Calls & Scope: When display and multiply functions are called, they each create their own execution contexts.

  • display Function Context: Contains its own local variables (e.g., a) and accesses functions and variables from the global scope.

  • multiply Function Context: Accesses global variables (x and y) and has its own local variable (z).

• Execution Flow: After display calls multiply, multiply computes a result and finishes, popping its context off the stack. Then display finishes, returning control to the global context.

• End of Execution: After all function contexts resolve, and the script completes, the global context is finally popped off the execution stack.

Hoisting

Hoisting is JavaScript's behaviour of moving variable and function declarations to the top of their scope during the compilation phase, before any code is executed. This means that declarations are processed before any line of code runs, giving the illusion that they are "hoisted" to the top.

Imagine you walk into a classroom and see the teacher’s notes already written on the board. You didn’t see her write them, but somehow they were there before the class even started. That’s hoisting in JavaScript — the interpreter sneakily moves declarations to the top of their scope before any code is run.

But there’s a twist.

Hoisting doesn’t actually move your code physically. What it does is register certain declarations, just the declarations, not the initialisations, during the compilation phase, before your code runs. So when execution begins, JavaScript already knows about the existence of variables and functions, it just might not know their values yet.

Let’s break it down.

var Hoisting

console.log(hoistedVar); // undefined
var hoistedVar = 42;

You might expect this to throw an error, but nope, it prints undefined. Why? Because var hoistedVar is hoisted to the top like this:

var hoistedVar;       // Declaration is hoisted
console.log(hoistedVar); // undefined (default value for hoisted `var`)
hoistedVar = 42;      // Initialization stays where it is

That’s classic var behaviour. Its declarations are hoisted and automatically initialised with undefined.

Function Hoisting

greet(); // "Hello!"

function greet() {
  console.log("Hello!");
}

This works beautifully because function declarations are fully hoisted, both the name and the body. Think of it like JavaScript giving your functions a VIP backstage pass. They’re not just invited early, they come fully dressed and ready to perform.

But here's a curveball:

greet(); // TypeError: greet is not a function

var greet = function () {
  console.log("Hi!");
};

Even though greet is declared with var, it’s hoisted as a variable, not as a function. So what gets hoisted?

var greet;     // Only the declaration is hoisted
greet();       // greet is undefined at this point → TypeError
greet = function () {
  console.log("Hi!");
};

This is why function declarations and function expressions behave differently when it comes to hoisting.

Now enter let and const...

You might think let and const are also hoisted. Technically, they are. But not in the way you'd hope.

console.log(a); // ❌ ReferenceError
let a = 10;

Even though the let a declaration is hoisted, it's not accessible until the line where it's declared. The period between the start of the scope and the actual declaration is known as the Temporal Dead Zone (TDZ).

Variables in the TDZ cannot be accessed, not even to check if they exist.

if (true) {
  console.log(name); // ❌ ReferenceError
  let name = "Zoro";
}

Try to sneak a peek at name before its declaration, and JavaScript slaps you with:

ReferenceError. But... why?

Well, welcome to the Temporal Dead Zone.

Temporal Dead Zone (TDZ)

Sounds scary, right? Like a place in a sci-fi movie where time and logic cease to exist. And honestly, that’s not far off.

The Temporal Dead Zone is the time between a variable being hoisted and being initialised, where accessing it will throw an error.

Here’s the deal:

• let and const are hoisted, but unlike var, they are not initialised with undefined.

• Until the line where they are declared is actually executed, they're in the TDZ, a forbidden zone.

• If you try to access them in that zone, JavaScript throws a ReferenceError, basically saying:
  “Hold your horses! You can’t use this yet.”

Let’s break it down:

function sayHi() {
  console.log(name); // 🚨 ReferenceError
  let name = "Zoro";
}
sayHi();

Why does this error happen?

Even though name is hoisted to the top of the function’s scope, it’s in the TDZ from the beginning of the scope until the line let name = "Zoro"; is actually run.

Now compare this to var:

function sayHi() {
  console.log(name); // undefined
  var name = "Zoro";
}
sayHi();

This time you get undefined, because var is hoisted and initialised with undefined. Not smarter, just sneakier.

The TDZ is Actually a Good Thing

Yes, I said it. The TDZ is your friend. It exists to prevent weird bugs and enforce better coding practices. If a variable is in the TDZ, it means:
“This thing has not been safely initialised yet, don't touch it.”

Without the TDZ, it would be a lot easier to write confusing or broken code. So, while it may feel like JavaScript is being overly strict, it’s actually trying to help you out.

Hoisting interview questions

1. Why doesn’t this function run as expected?

console.log(foo());
var foo = function () {
  return "done";
};

Output:
TypeError: foo is not a function

What’s wrong here?
The var foo is hoisted, but its value is set to undefined at the top. So when foo() is called, it's actually calling undefined().

How to fix it?
Use a function declaration instead of a function expression if you need to call the function before it's defined:

function foo() {
  return "done";
}
console.log(foo());

Or, move the function expression below the console.log if you're using modern patterns like const or let.

2. What’s happening here with let and shadowing?

let a = 10;

function test() {
  console.log(a);
  let a = 20;
}
test();

Output:
ReferenceError

What’s wrong here?
At first glance, you might think a will be 10. But inside the function, let a creates a new a in the block scope, and it’s in the Temporal Dead Zone when console.log(a) runs.

How to fix it?
If you want to access the outer a, don't redeclare it with let inside the function:

let a = 10;

function test() {
  console.log(a); // 10
}
test();

If you need a new a, define it after you've logged the outer one:

function test() {
  console.log(a); // 10
  let aNew = 20;
}

3. What’s going on with these var declarations?

var count = 5;

(function () {
  if (false) {
    var count = 10;
  }
  console.log(count);
})();

Output:
undefined

What’s wrong here?
You might expect count to be 5, but the inner var count is hoisted to the top of the IIFE and initialised as undefined, even though the if block never runs.

So inside the function, count is undefined due to hoisting, not 5 from the outer scope.

How to fix it?
Use let or const to keep block scoping:

var count = 5;

(function () {
  if (false) {
    let count = 10;
  }
  console.log(count); // 5
})();

Or rename variables to avoid this subtle collision.

4. Why is this loop printing unexpected values?

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}

Output:
3
3
3

What’s wrong here?
The var i is function-scoped, not block-scoped. So all three callbacks share the same i and print its final value after the loop ends.

How to fix it?

Use let for block scoping:

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}

Or use an IIFE to capture the current i:

for (var i = 0; i < 3; i++) {
  (function (j) {
    setTimeout(() => console.log(j), 100);
  })(i);
}

5. Why does this throw when you access foo inside bar?

function foo() {
  console.log("outer foo");
}

function bar() {
  console.log(foo);
  function foo() {
    console.log("inner foo");
  }
}
bar();

Output:
[Function: foo]

Wait... it doesn’t throw?

Actually no, but here's the twist, this often catches people off-guard.

What’s really happening?
The function foo inside bar is hoisted to the top of bar's scope. So when console.log(foo) runs, it’s actually logging the function itself, not calling the outer foo.

Follow-up:
Change console.log(foo) to foo() what happens?

function bar() {
  foo(); // this calls the inner foo, not the outer one
  function foo() {
    console.log("inner foo");
  }
}
bar();

The output is "inner foo" because the inner declaration overshadows the outer one.

Fix (if you want the outer one):
Rename the inner function or avoid redeclaring functions with the same name.

6. Why does this function behave differently based on where it’s declared?

"use strict";

if (true) {
  function test() {
    console.log("block");
  }
}
test();

Output:
In some environments: ReferenceError

Why is this tricky?
Function declarations inside blocks are a grey area in JavaScript. In strict mode, function declarations are not block-scoped in older engines, and behaviour can vary between browsers.

In modern JavaScript, this should throw a ReferenceError, because test is scoped only inside the if block.

How to fix it?
Use function expressions or const if declaring inside a block:

if (true) {
  const test = () => console.log("block");
  test();
}

Or, declare it outside the block if it needs wider visibility.

That’s a Wrap

I know you are having a blast but the show must end here, I have to feed my pet (virtual pet 🫠). On the bright side you can now tackle any hoisting and scoping related interview questions like a pro. Next time we meet, I’ll let you in on another JavaScript mystery. Spoiler alert: PROMISES!

Understanding Objects

Objects in JavaScript can be seen as collections of properties and methods. You can think of an object as a box that contains items, where each item has a name (a key) and a value. These values can be data or functions (methods).

Creating Objects

• Object Literals: This is the simplest way to create an object in JavaScript. You simply list its properties and methods inside curly braces {}.

const person = {
  name: "Kira",
  age: 30,
  greet: function() {
    console.log("Hello, my name is " + this.name);
  }
};

person.greet(); // Output: Hello, my name is Kira

• Constructor Functions: You can create objects using constructor functions, which are regular functions that are used to create objects with the new keyword. This pattern is similar to class instantiation in other languages.

function Person(name, age) {
  this.name = name;
  this.age = age;
  this.greet = function() {
    console.log(`Hello, my name is ${this.name}`);
  };
}

const person = new Person('Kira', 30);
person.greet(); // Output: Hello, my name is Kira

Imagine constructor functions as a blueprint for a building. Every time you want to build a new house (object), you use the same blueprint but can customise the size, color, etc.

Classes: Modern Blueprint for Creating Objects

Introduced in ES6, classes in JavaScript are a syntactic sugar over the prototype-based OO pattern. They provide a clearer and more concise way to create objects and handle inheritance. Classes are to JavaScript what blueprints are to architects, a plan to build objects.

class Person {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  greet() {
    console.log(`Hello, my name is ${this.name}`);
  }
}

const alice = new Person("Kira", 28);
alice.greet(); // Output: Hello, my name is Kira

Think of a class as a cookie cutter and objects as the cookies made with it. Each cookie (object) will have the same shape (properties) and features (methods), but you can make as many as you want from the same cutter (class).

Abstraction: Simplifying Complexity

Abstraction is like the dashboard of your car. When you drive, you don't need to understand the complex mechanisms behind the brake system, the engine's inner workings, or how fuel gets injected. You just use the brake pedal, the gas pedal, and the steering wheel. Abstraction in programming hides the complex reality while exposing only the necessary parts.

In JavaScript, while we don't have interfaces or abstract classes like in other languages, we achieve abstraction by limiting access to certain components and exposing only what's necessary through the class's methods.

Let's consider a real-world analogy: a TV remote. You have buttons like power, volume, and channel change. Internally, the remote does a lot of work (sending infrared signals, for example), but you don't need to know that. You just use the buttons.

Translating this to JavaScript, let's imagine we're creating a class for a MusicPlayer. The complexity of how the music is loaded and played is hidden from the user, who interacts with simple methods like play, pause, or skipTrack.

class MusicPlayer {
  #currentTrack;
  #playlist;

  constructor(playlist) {
    this.#playlist = playlist;
    this.#currentTrack = 0;
  }

  play() {
    console.log(`Playing: ${this.#playlist[this.#currentTrack].name}`);
    // Code to play the music
  }

  pause() {
    console.log("Music paused.");
    // Code to pause the music
  }

  skipTrack() {
    this.#currentTrack = (this.#currentTrack + 1) % this.#playlist.length;
    this.play();
  }

  // More methods to interact with the music player
}

// The user interacts with the MusicPlayer through its public methods,
// without needing to understand its internal workings.
const myPlaylist = [{ name: "Song 1" }, { name: "Song 2" }];
const myMusicPlayer = new MusicPlayer(myPlaylist);
myMusicPlayer.play(); // Outputs: Playing: Song 1
myMusicPlayer.skipTrack(); // Outputs: Playing: Song 2

In this example, the #currentTrack and #playlist properties are kept private within the MusicPlayer class (with the help of # prefix), preventing external access. This encapsulation is a key aspect of abstraction, where the user of the MusicPlayer does not need to know or understand how tracks are managed or how the play functionality is implemented. They only need to interact with the public methods provided, such as play, pause, and skipTrack.

Through abstraction, we simplify the usage of complex systems, making them more accessible and user-friendly. This concept, while more abstract (pun intended) in JavaScript, is crucial for creating clean, maintainable, and easy-to-use code.

Encapsulation: Keeping Secrets

Encapsulation in OOP is like owning a house with a garden. You are free to do whatever you want inside your property without letting anyone else know about it. You might have a dog that can freely roam within the fences, but it's not visible or accessible from the outside. In programming, encapsulation means keeping some of the object's properties and methods private, so they can't be accessed from outside the object. This is where JavaScript uses the # prefix to denote private properties or methods.

class BankAccount {
  #balance;

  constructor(initialBalance) {
    this.#balance = initialBalance;
  }

  deposit(amount) {
    if (amount > 0) {
      this.#balance += amount;
      console.log("Deposit successful");
    }
  }

  getBalance() {
    return this.#balance;
  }
}

Inheritance: Standing on the Shoulders of Giants

Inheritance allows a class to inherit properties and methods from another class. Imagine you're writing a fantasy novel. You create a general class called Character with properties like name, strength, and magic. Then, you decide to create specific character types like Warrior and Mage. Instead of writing completely new classes from scratch, you let Warrior and Mage inherit the properties and methods from Character and add their unique attributes or methods.

class Character {
  constructor(name, strength, magic) {
    this.name = name;
    this.strength = strength;
    this.magic = magic;
  }
}

class Warrior extends Character {
  constructor(name, strength, magic, weapon) {
    super(name, strength, magic);
    this.weapon = weapon;
  }
}

class Mage extends Character {
  constructor(name, strength, magic, spell) {
    super(name, strength, magic);
    this.spell = spell;
  }
}

Polymorphism: Many Forms, One Interface

Polymorphism allows objects of different classes to be treated as objects of a common superclass. It's like having a universal remote control that can operate your TV, DVD player, and stereo system. Each device has its specifics, but the remote sends commands in a way each device understands. In programming, polymorphism lets us design objects that share certain properties or methods but implement them differently.

class Animal {
  makeSound() {
    console.log("Some generic sound");
  }
}

class Dog extends Animal {
  makeSound() {
    console.log("Bark");
  }
}

class Cat extends Animal {
  makeSound() {
    console.log("Meow");
  }
}

const myDog = new Dog();
const myCat = new Cat();

// Though myDog and myCat are instances of different classes,
// we interact with them through the common interface of makeSound().
myDog.makeSound(); // Bark
myCat.makeSound(); // Meow

Summary:

• Objects: Entities storing data and functionality, akin to containers holding various items, in JavaScript represented by key-value pairs.

• Classes: Blueprint for creating objects with predefined properties and methods, resembling cookie cutters generating cookies of uniform shape and features.

• Abstraction: Hiding complex implementation details and revealing only necessary functionalities, akin to using a TV remote without needing to understand its internal workings.

• Encapsulation: Bundling data and methods within a class while restricting access to certain components, similar to owning a house with a private garden, hidden from external view.

• Inheritance: Mechanism allowing a class to inherit properties and methods from another class, comparable to building on top of existing structures, inheriting their qualities.

• Polymorphism: Ability for objects of different classes to be treated as instances of their parent class, akin to a universal remote control operating various devices, each responding to commands differently.

In summary, JavaScript's approach to OOP allows you to structure your code in a way that is both powerful and flexible, enabling you to build complex applications more efficiently. Through understanding and applying these concepts, you're equipped to dive deeper into the language and explore its capabilities further. Remember, the key to mastering these concepts is practice and real-world application. Happy coding!

Benefits of Testing

1. Early Bug Detection: Testing helps identify bugs and issues early in the development cycle, preventing them from propagating further and causing more significant problems down the line.

2. Refactoring Facilitation: When refactoring code, tests provide a safety net, ensuring that the existing functionality remains intact while making changes.

3. Improved Code Quality: Writing tests forces developers to consider various edge cases and error conditions, leading to more robust and reliable code.

4. Documentation: Tests serve as a form of documentation, illustrating how functions and components should behave, making it easier for new team members or future developers to understand the codebase.

When to Start Testing

The timing of when to start writing tests is crucial. If a project is still in the early iteration phase with potential breaking changes to requirements, it may not be the best time to invest heavily in testing. However, once the product becomes more stable and the scope for breaking changes decreases, it's an ideal time to start writing tests, especially for critical modules.

Types of Tests

There are several types of tests commonly used in JavaScript development:

1. Unit Tests: Unit tests verify the correctness of individual units, such as functions, classes, or small modules, in isolation.

2. Integration Tests: Integration tests focus on verifying how different units or components of an application work together as a whole.

3. End-to-End Tests: End-to-End (E2E) tests simulate user interactions with the entire system, testing the application from start to finish.

AAA Pattern

The AAA (Arrange, Act, Assert) pattern is a structured approach to writing unit tests that helps in making them more readable, maintainable, and consistent. Here's what each step involves:

1. Arrange: In this step, you set up the test environment, including any necessary data or configuration required for the test to run. This could involve instantiating objects, defining variables, or setting up mock dependencies.

2. Act: This step involves executing the code under test, typically by calling a function or method with the arranged inputs.

3. Assert: In the final step, you verify that the actual output or behaviour matches your expected outcome. This is where you use assertion functions like expect from testing libraries to check if the results are correct.

Vitest

Vitest is a popular testing library for JavaScript, and it provides several functions to help you write and organise your tests effectively.

• describe(name, fn): This function is used to group related tests together. The name parameter is a string that describes the group, and the fn parameter is a callback function containing the tests.

• it(name, fn) or test(name, fn): These functions are used to define individual test cases. The name parameter is a string that describes the test case, and the fn parameter is a callback function containing the test logic.

• expect(value): This function is used to start an assertion. It returns an object that provides various matcher functions to assert different conditions.

• toBe(value): This matcher is used to check if the actual value is strictly equal (===) to the expected value.

• toBeUndefined(): This matcher checks if the actual value is undefined.

• toBeNull(): This matcher checks if the actual value is null.

• toBeTruthy(): This matcher checks if the actual value is truthy (evaluates to true).

• toBeFalsy(): This matcher checks if the actual value is falsy (evaluates to false).

Here's an example that demonstrates the use of these functions:

import { sum } from './sum';

describe('sum', () => {
  it('should add two positive numbers', () => {
    // Arrange
    const a = 2;
    const b = 3;

    // Act
    const result = sum(a, b);

    // Assert
    expect(result).toBe(5);
  });

  it('should return 0 if both arguments are 0', () => {
    expect(sum(0, 0)).toBe(0);
  });

  it('should return the same value if one argument is 0', () => {
    expect(sum(5, 0)).toBe(5);
    expect(sum(0, 7)).toBe(7);
  });
});

Test-Driven Development (TDD)

Test-Driven Development (TDD) is an approach where tests are written before the application code. The three steps in TDD are:

1. Write a failing test.

2. Write just enough code to make the test pass.

3. Refactor the code if necessary, ensuring that the tests still pass.

Let's go through a more real-world example of the TDD process for a simple shopping cart functionality.

1. Write the first failing test:

import { ShoppingCart } from './ShoppingCart';

describe('ShoppingCart', () => {
  it('should initialize with an empty cart', () => {
    const cart = new ShoppingCart();

    expect(cart.items).toEqual([]);
    expect(cart.totalPrice).toBe(0);
  });
});

Run the test: It will fail because the ShoppingCart class doesn't exist yet.

2. Write the minimal code to make the test pass:

export class ShoppingCart {
  constructor() {
    this.items = [];
    this.totalPrice = 0;
  }
}

Run the test: It should now pass.

3. Write another failing test:

import { ShoppingCart } from './ShoppingCart';

describe('ShoppingCart', () => {
  it('should initialize with an empty cart', () => {
    const cart = new ShoppingCart();

    expect(cart.items).toEqual([]);
    expect(cart.totalPrice).toBe(0);
  });

  it('should add an item to the cart', () => {
    const cart = new ShoppingCart();
    const item = { name: 'Book', price: 10 };

    cart.addItem(item);

    expect(cart.items).toContainEqual(item);
    expect(cart.totalPrice).toBe(10);
  });
});

Run the tests: The second test should fail because we haven't implemented the addItem method yet.

4. Write the code to make the new test pass:

export class ShoppingCart {
  constructor() {
    this.items = [];
    this.totalPrice = 0;
  }

  addItem(item) {
    this.items.push(item);
    this.totalPrice += item.price;
  }
}

Run the tests: Both tests should now pass.

5. Write another failing test:

import { ShoppingCart } from './ShoppingCart';

describe('ShoppingCart', () => {
  it('should initialize with an empty cart', () => {
    const cart = new ShoppingCart();

    expect(cart.items).toEqual([]);
    expect(cart.totalPrice).toBe(0);
  });

  it('should add an item to the cart', () => {
    const cart = new ShoppingCart();
    const item = { name: 'Book', price: 10 };

    cart.addItem(item);

    expect(cart.items).toContainEqual(item);
    expect(cart.totalPrice).toBe(10);
  });

  it('should remove an item from the cart', () => {
    const cart = new ShoppingCart();
    const item = { name: 'Book', price: 10 };

    cart.addItem(item);
    cart.removeItem(item);

    expect(cart.items).toEqual([]);
    expect(cart.totalPrice).toBe(0);
  });
});

Run the tests: The third test should fail because we haven't implemented the removeItem method yet.

6. Write the code to make the new test pass:

export class ShoppingCart {
  constructor() {
    this.items = [];
    this.totalPrice = 0;
  }

  addItem(item) {
    this.items.push(item);
    this.totalPrice += item.price;
  }

  removeItem(item) {
    const index = this.items.indexOf(item);
    if (index !== -1) {
      this.items.splice(index, 1);
      this.totalPrice -= item.price;
    }
  }
}

Run the tests: All three tests should now pass.

You can continue this cycle by writing tests for additional requirements, such as handling duplicate items, applying discounts, or implementing checkout functionality. The TDD approach ensures that you write testable code from the beginning and that your codebase remains well-covered by tests as it grows in complexity.

Here are a few more examples of tests you could write for the shopping cart:

• Test adding multiple items to the cart and verifying the correct total price

• Test removing an item that doesn't exist in the cart (edge case)

• Test adding and removing the same item multiple times

• Test applying a discount code and verifying the discounted total price

• Test checking out the cart and resetting the cart state

By following the TDD approach and continuously writing tests before implementing new features or refactoring existing code, you can ensure that your codebase remains robust, maintainable, and easy to extend or modify in the future.

Conclusion

Testing is an essential practice in JavaScript development, providing numerous benefits such as early bug detection, facilitation of refactoring, improved code quality, and documentation. By understanding when to start testing, the qualities of a good test, and the different types of tests available, developers can write more robust and reliable code. Tools like Vitest and the TDD approach can further enhance the testing process and contribute to a more efficient and high-quality software development lifecycle.

Understanding "this" - The Magic Pointer:

The 'this' keyword in JavaScript is like a magic pointer that helps your code understand what it's currently working with. It dynamically represents the specific object or value where a function is being used, allowing you to interact with different parts of your code.

Imagine you're a barista in a cafe, and you have various tasks like brewing coffee or cleaning. 'this' is like a helpful finger pointing to the coffee cup or milk frother, guiding you on what you should focus on at any given moment.

For example, when you're making a latte, 'this' points to the milk frother so you can froth the milk correctly. If you switch to cleaning, 'this' now points to the cleaning cloth, helping you wipe the counter without any confusion. 'this' is your way of saying, 'Look, I'm talking about this particular thing right now.

Now let's discuss different cases where you might encounter 'this':

Imagine you're the manager of a bustling cafe, where different staff members play specific roles. In JavaScript, "this" is akin to assigning roles to various functions and determining who is doing what.

1. Cafe Overview (Global Context):

   Envision your entire JavaScript program as a bustling cafe. In this lively setting, "this" in the global context is like making announcements to the entire cafe:

    console.log(this); // Output: [object Window]
   

2. Roles of the Barista (Functions):

   Think of functions as different roles within your cafe. The "this" in a function acts like a barista with a specific job, and their role can change based on the scenario.

   • Taking Orders (Regular Function):

       function takeOrder() {
         console.log(this);
       }
     
       takeOrder(); // Output: [object Window]
     

     Regular function, "this" still interacts with the entire cafe.

   • Brewing coffee (Method inside an object):

       const coffeeShop = {
         brewCoffee: function () {
           console.log(this);
         },
         brewLatte: () => {
           console.log(this);
         },
       };
     
       coffeeShop.brewCoffee(); // Output: [object Object] (referring to coffeeShop)
       coffeeShop.brewLatte();  // Output: [object Window]
     

     • brewCoffee (Regular Function): Just like our regular barista, 'this' within brewCoffee refers to the object (coffeeShop) it is a part of. The output is [object Object], indicating it's addressing the specific team within the cafe.

     • brewLatte (Arrow Function): Arrow functions behave differently. They don't have their own 'this' context and instead inherit it from their enclosing scope. In this case, since 'this' inside brewLatte is in the global context (not within a function or object), it refers to the global object ([object Window] in a browser environment).

So, while brewCoffee addresses the cafe team specifically, brewLatte takes on a freelancing role, addressing the global context. Arrow functions are often used in scenarios where you want to maintain the 'this' value from the surrounding scope.

1. New Employee Orientation (Constructor):

   Imagine you need to onboard a new employee for a special role. A constructor, using "this," is like creating a new role within the cafe:

    function Employee(name) {
      this.name = name;
    }
   
    const newBarista = new Employee('Light Yagami');
    console.log(newBarista.name); // Output: Light Yagami
   

   With "this," you're introducing a new barista, Light Yagami, to play a specific role.

Real-world scenarios - Orders and deliveries:

Now, let's spice things up with a real-world scenario involving orders and deliveries.

Taking and Fulfilling Orders:

function Order(orderDetails) {
  this.details = orderDetails;
  this.takeOrder = function () {
    console.log(`Taking order for ${this.details}`);
  };
  this.fulfillOrder = function () {
    setTimeout(() => {
      console.log(`Fulfilling order for ${this.details}`);
    }, 1000);
  };
}

const customerOrder = new Order('Cappuccino');
customerOrder.takeOrder(); // Output: Taking order for Cappuccino
customerOrder.fulfillOrder(); // Output: Fulfilling order for Cappuccino

Event Handling in the Cafe:

const deliveryService = {
  handleDelivery: function () {
    document.getElementById('deliveryButton').addEventListener('click', function () {
      console.log(`Delivering to ${deliveryService.address}`);
    });
  },
  address: '123 Cafe Street',
};

deliveryService.handleDelivery();

In this example, "this" in the event handler refers to the deliveryService, showcasing how "this" can play a role in real-world scenarios.

Conclusion:

Let's see all the roles of "this" in a concise coding showcase:

// Global context
console.log(this); // Output: [object Window]

// Regular function scene
function takeOrder() {
  console.log(this); // Output: [object Window]
}
takeOrder();

// Method scene (Inside an object)
const coffeeShop = {
  brewCoffee: function () {
    console.log(this); // Output: [object Object] (referring to coffeeShop)
  },
  brewLatte: () => {
    console.log(this); // Output: [object Window]
  },
  handleEvent: function () {
    document.getElementById('orderButton').addEventListener('click', () => {
      console.log(`Processing order for ${this.name}`);
    });
  },
};
coffeeShop.brewCoffee();
coffeeShop.brewLatte();  // Output: [object Window]

// Creating new roles (Constructor)
function Employee(name) {
  this.name = name;
}

const newBarista = new Employee('Light Yagami');
console.log(newBarista.name); // Output: Light Yagami

There you have it! You've successfully navigated the "this" maze in JavaScript, exploring roles and functions in both coding exercises and real-world examples. Keep coding and managing your roles with confidence! 🚀

Quick Commands Reference:

1. git stash: Stash your changes.

2. git stash list: List all stashes.

3. git stash show: Show changes in the most recent stash.

4. git stash pop: Apply and remove the most recent stash.

5. git stash apply: Apply the most recent stash (keep it in the stash list).

6. git stash apply stash@{revision}: Apply a particular stash.

7. git stash -u: To stash both tracked and untracked files.

8. git stash clear: Delete all stashes.

9. git stash drop stash@{revision}: Delete a particular stash.

10. git stash branch <branch_name>: Create a new branch from the last stash.

11. git stash branch <branch_name> stash@{revision}: Create a branch from a specific stash.

Why Git Stash?

Unfinished Work and Context Switching:

Imagine you're knee-deep in coding a new feature on the master branch when an urgent bug report comes in. Git stash allows you to stash your ongoing changes, switch to a different branch, fix the bug, and seamlessly return to your feature development.

Branch Switching and Clean Working Directory:

Git stash shines when you need to move between branches swiftly. Instead of committing changes that aren't ready, stash provides a clean slate for branch hopping. It ensures a tidy working directory, making it easier to focus on the task at hand.

Emergency Fixes and Safe Experimentation:

Stash becomes your ally in addressing critical issues without compromising your ongoing work. It's also a safety net for experimenting with changes. Stash lets you try out ideas, and if they don't work, you can effortlessly revert to your stashed state.

Detailed Exploration of Commands:

1. Stashing Your Changes (git stash):

   Use git stash to temporarily store changes without committing.

    git stash
   

2. Listing All Stashes (git stash list):

   See a list of all stashes and their reference numbers.

    git stash list
   

3. Showing Changes in the Last Stash (git stash show):

   Display changes made in the last stash.

    git stash show
   

4. Applying and Popping the Last Stash (git stash pop):

   Apply and remove the last stash.

    git stash pop
   

5. Applying the Last Stash (git stash apply):

   Apply the last stash while keeping it in the stash list.

    git stash apply
   

6. Applying a Specific Stash (git stash apply stash@{revision}):

   Apply a stash by referencing its number (revision).

    git stash apply stash@{3}
   

7. Deleting All Stashes (git stash clear):

   Remove all stashes from the stash list.

    git stash clear
   

8. Stashing untracked files (git stash -u):

   If you want to stash both changes to tracked files and untracked files simultaneously, you can use the -u or --include-untracked option with git stash. This option includes untracked files in the stash.

    git stash -u
   

   Note that untracked files stashed in this way won't be listed in the subsequent git stash list output, as they are not changes that can be applied or popped like changes to tracked files.

9. Deleting a Specific Stash (git stash drop stash@{revision}):

   Discard a specific stash using its reference number.

    git stash drop stash@{2}
   

10. Creating a New Branch from the Last Stash (git stash branch <branch_name>):

    Start a new branch based on the last stash.

    git stash branch <branch_name>
    

11. Creating a Branch from a Specific Stash (git stash branch <branch_name> stash@{revision}):

    Begin a branch from a specific stash using its reference.

    git stash branch <branch_name> stash@{revision}
    

Git Stash in Action: Switching to the Right Branch

Let's say you've mistakenly started coding on the master branch, but your intended changes should be on the existing feature/live-chat branch. Here's how Git stash comes to your rescue:

1. Stash Your Changes on Master:

    git stash
   

2. Switch to the Target Branch:

    git checkout feature/live-chat
   

3. Apply the Stashed Changes:

    git stash apply
   

   • Alternatively, use git stash pop if you want to drop the stash after applying.

4. Commit on the Correct Branch:

    git commit -m "Your commit message"
   

By using Git stash, you've seamlessly switched branches, preserved your changes, and committed them to the correct branch. It's a simple yet powerful workflow that keeps your version control history organised.

Summary:

Git stash is not just a feature; it's a versatile tool that empowers developers to navigate the complexities of software development with finesse and efficiency. Whether you're juggling multiple tasks, experimenting with changes, or addressing urgent issues, Git stash has got your back. As you integrate these stash commands into your workflow, you'll discover a newfound agility in managing your codebase. Happy stashing!

The difference between getting a "meh" answer and a mind-blowing one isn't magic… it’s Prompt Engineering.

Before we dive into the hacks, let's make sure we’re speaking the same language. And don't worry, I’m not going to bore you with a lecture.

The Basics: What are we dealing with?

• AI (The Brain): Think of Artificial Intelligence as a computer trying to mimic a human brain. It solves problems, recognises patterns, and tries to act smart.

• LLMs (The Well-Read Librarian): Large Language Models (LLMs) are a type of AI that have read basically the entire internet. Imagine a librarian who has memorised every book in the library but sometimes forgets which book is non-fiction and which is sci-fi. That's an LLM (like GPT).

• Prompting (The Ask): This is just you texting the AI. The quality of your text (the prompt) determines the quality of its reply. Garbage in, garbage out.

The "Big Bang" of AI: The Transformer

Okay, here is the cool part that most people skip over. AI used to be pretty dumb at reading. It would read a sentence one word at a time, left to right. By the time it got to the end of a long sentence, it often forgot how the sentence started!

Then, in 2017, everything changed.

A team of researchers at Google dropped a research paper with the mic-drop title: "Attention Is All You Need."

They introduced something called the Transformer architecture. Instead of reading word-by-word like a slow student, the Transformer looks at the entire sentence at once. It uses a mechanism called "Self-Attention" to figure out which words relate to each other, no matter how far apart they are.

For example, in the sentence "The animal didn't cross the street because it was too tired," an old AI gets confused about what "it" refers to. A Transformer knows instantly that "it" refers to the animal, not the street.

This was a massive breakthrough. It paved the way for every modern AI model we use today (the "T" in GPT literally stands for Transformer!).

So, What is Prompt Engineering?

Prompt engineering is simply the art of whispering into the AI's ear to get exactly what you want. It’s not just asking questions; it’s about setting the stage, giving context, and guiding the AI so it doesn't go off the rails.

Your job as a "Prompt Engineer" is essentially:

1. Designing the perfect question.

2. Testing if it works.

3. Refining it when the AI gets confused.

How to Write Good Prompts (Best Practices)

You do not need to be a coder to be good at this. You just need to be clear. Think of the AI as a really smart intern who has read every book in the world but has zero common sense. If you are vague, it guesses. If you are specific, it delivers.

Here are the techniques the pros use:

1. Don't be Vague (Clear Instructions) If you ask, "Write code," the AI will guess. If you ask, "Write a Python script to calculate the fibonacci sequence," you win. Treat the AI like a really smart intern who needs specific instructions to get the job done right.

2. Give it a Role (Persona) This is my favourite trick. Tell the AI who it is.

• Bad: "Explain quantum physics."

• Good: "You are a wacky high school science teacher. Explain quantum physics using an analogy about donuts."

3. Show, Don't Just Tell (Few-Shot Prompting) Sometimes instructions aren't enough. Give it examples.

• Prompt: "Convert these movie titles into emojis.

  • Star Wars -> ⭐️⚔️

  • The Lion King -> 🦁👑

  • Titanic -> ?" The AI will immediately understand the pattern and give you "🚢🧊".

4. "Show Your Work" (Chain of Thought) If you ask a complex logic question, the AI might guess and get it wrong. If you tell it to "think step-by-step," it acts like a student showing their math homework. It forces the model to reason through the problem, which usually leads to the right answer.

5. Emotional Prompting (Yes, really) Studies have shown that LLMs actually perform better when you add emotional stakes. It sounds weird, but it works.

• The Trick: Add phrases like "This is very important for my career" or "You effectively have a tip of $200 for a perfect solution."

• Why it works: The AI creates a "hyper-focus" state because, in its training data, text surrounded by high urgency usually requires higher quality and precision.

Watch Out for AI Hallucinations

Here is the scary part: AI lies.

Well, it doesn't mean to lie. But remember, LLMs are just predicting the next likely word in a sentence. They aren't fact-checkers. If they don't know the answer, they might confidently make one up. This is called a Hallucination.

• Why? Because it wants to please you by completing the pattern, even if the facts are wrong.

• The Fix: Always verify important facts. Treat the AI as a helper, not the ultimate source of truth.

Under the Hood: How Does It Actually "Understand"? (Embeddings)

You might be wondering, "How does a computer actually understand the concept of an apple? It is just a machine made of sand and electricity."

It uses something called Vector Embeddings, and this is the secret sauce behind modern AI.

1. Turning Words into Numbers Computers cannot read words; they only do math. So, the first thing an AI does is turn every word (or token) into a list of numbers. But it is not just one number like "Apple = 1". That would be too simple. Instead, "Apple" becomes a long list of numbers, like [0.9, -0.2, 0.5, ...]. In models like GPT, this list can be over 1,500 numbers long!

2. The Giant Map (High-Dimensional Space) Imagine a graph.

• If you have 2 numbers, you can plot a point on a 2D piece of paper (X and Y axis).

• If you have 3 numbers, you can plot a point in a 3D cube (X, Y, and Z).

• Now, imagine a space with 1,500 dimensions. Our human brains cannot visualise it, but computers handle it easily.

Every word in the English language gets a specific coordinate in this massive 1,500-dimensional space.

3. The "Angle" of Meaning (Cosine Similarity) Here is the magic part. The AI doesn't just look at where the words are; it measures the angle between them.

• The concept of "King" and "Queen" are different words, but they point in almost the exact same direction in this space.

• "Apple" and "Banana" also point in the same direction (the "Fruit" direction).

• "Apple" and "Car" point in completely different directions.

To find out if two things are related, the computer calculates the "Cosine Similarity" (basically, the angle).

• If the angle is small, the concepts are related.

• If the angle is wide, they are unrelated.

Why does this matter to you? This is how RAG (Retrieval-Augmented Generation) works. When you chat with a PDF or your company's data, the AI converts your question into numbers, searches its database for paragraphs that have a "similar angle" to your question, and reads only those parts to give you an answer.

It is not magic; it is just really, really high-dimensional geometry.

Conclusion

Prompt engineering isn't about memorising a dictionary of secret codes. It’s about communication. It’s about learning how to guide these powerful new tools to do work for you.

Whether you want to code faster, write better emails, or just have a funny conversation, the skill is in how you ask. So go ahead, open up ChatGPT, and try telling it to "think step-by-step" or "act like a pirate." You might be surprised at what you get back.

Syntax:

const defaultAge = age ?? 18;

In the above code snippet if age is not null or undefined defaultAge will be set to age otherwise it will be set to 18.

Before you start screaming that the logical OR (||) will do the exact same thing, hear me out.

The problem with OR (||):

const age = 23;
const defaultAge = age || 18;
console.log(defaultAge); // Output: 23

The above code will work perfectly fine in this case as it will return 18 if age is a falsy value and age otherwise. The problem occurs when we are dealing with values that could be legitimate falsy values, such as the number 0 or an empty string "".

const age = 0;
const defaultAge = age || 18;
console.log(defaultAge); // Output: 18

In this case, the default age is set to 18, even though age has a value of 0, which is a valid age. This unintended behaviour can lead to bugs and unexpected results in your code.

Nullish Coalescing Operator to the rescue 🛟

The Nullish Coalescing Operator (??) provides a solution to the problem mentioned above. It specifically checks for null or undefined values and doesn't treat other falsy values as null or undefined.

const age = 0;
const defaultAge = age ?? 18;
console.log(defaultAge); // Output: 0

Real-world example

export function generateMetadata({ params: { myParams } }) {
  const topic = myParams?.[0] ?? "curated";
  const page = myParams?.[1] ?? "1";

  return {
    title: `Results for ${topic} - Page ${page}`,
  };
}

The above example shows the setting of metadata using params in a next 13 server-component. The topic will show general only if we don't get data from params i.e. if it is null or undefined. Similarly for the page.

Conclusion

The Nullish coalescing operator is a great tool to resolve the issue of unintentional defaults when dealing with falsy values, ensuring that null and undefined are the only triggers for providing default values. By incorporating this operator into your code, you can write cleaner, more robust JavaScript applications with fewer surprises and bugs. So, the next time you find yourself setting default values, consider using the Nullish Coalescing Operator to make your code safer and more concise.

Syntax: arr.reduce(callbackFn, initialValue)

It accepts two arguments, a callback function and an initial value (which is optional by the way).

The callback function accepts 4 arguments:

1. accumulator: It keeps track of the intermediate result as the reduce operation progresses. It starts with the value of the initialValue if provided, or the first element of the array if no initialValue is given.

2. currentValue: This is the current element being processed in the array during the iteration.

3. currentIndex: This is the index of the current element being processed. It is an optional property.

4. array: It is the original array upon which the reduce is being called. It is an optional property.

Let's understand the concept of reduce with an example of a sneaker cart. Consider the following dataset for a sneaker cart:

const sneakers = [
  {
    brand: "Nike",
    type: "Running",
    color: "Black",
    discounted: true,
    price: 100,
    name: "Air Zoom",
  },
  {
    brand: "Adidas",
    type: "Casual",
    color: "White",
    discounted: false,
    price: 80,
    name: "Superstar",
  },
  {
    brand: "Nike",
    type: "Basketball",
    color: "Red",
    discounted: true,
    price: 120,
    name: "LeBron 18",
  },
  {
    brand: "Reebok",
    type: "Training",
    color: "Blue",
    discounted: true,
    price: 90,
    name: "Nano X",
  },
];

• Say we want to count the number of sneakers per brand:

const brandCounts = sneakers.reduce((counts, sneaker) => {
  counts[sneaker.brand] = (counts[sneaker.brand] || 0) + 1;
  return counts;
}, {});
// OUTPUT: { Nike: 2, Adidas: 1, Reebok: 1 }

In the above example, counts is our accumulator and sneaker is our currentValue. The initial value for our accumulator is an empty object {}.

Initially, the accumulator (counts) is an empty object, in the first iteration of the loop we add a key of brand name, which we get from sneaker.brand, to the accumulator and check if the key already exists in the object; if it does, then the count is increased by 1. If it doesn't exist, a new property with the brand name is created, and its value is set to 1. This way, the brandCounts object keeps track of how many sneakers are from each brand in the sneakers array.

This operation is performed on every element of the array and each time we return the updated value of our accumulator (return counts;) and we get our final output as { Nike: 2, Adidas: 1, Reebok: 1 }.

• Now if we want to get the total price of the cart:

const totalCost = sneakers.reduce((total, sneaker) => {
  return total + sneaker.price;
}, 0);
// OUTPUT: 390

• What if we want to get a list of the names of all the sneakers in the cart:

const sneakerNames = sneakers.reduce((names, sneaker) => {
  names.push(sneaker.name);
  return names;
}, []);
// OUTPUT: ["Air Zoom", "Superstar", "LeBron 18", "Nano X"]

Now to practice your newly acquired skill try to use the array reduce method to return the list of sneakers that are discounted.

With this, we conclude this article on the array.reduce() method. I hope you now have a better grasp of how to harness its power for performing cumulative operations on arrays. Whether you're calculating totals, counting occurrences, or aggregating data, array.reduce() proves to be an invaluable tool in your programming arsenal. Stay tuned for more informative content, as we'll continue exploring other exciting JavaScript concepts in the next article. Until then, happy coding and keep honing your skills!

TypeScript is a programming language that builds upon JavaScript and brings additional features. It introduces static type checking, which means it checks the types of values you're using in your code to catch mistakes early on. As you write your code, TypeScript analyzes it in real time, providing feedback and ensuring you use the correct types effectively. It's like having a helpful friend who analyzes your code as you type, making your coding experience easier and more organized.

Types in typescript

TypeScript has a variety of built-in types that you can use to define your variables. Here are some of the most common ones:

• number: represents numeric values like 42 or 3.14

• string: represents text values like "Hello, world!" or "42"

• boolean: represents boolean values true or false

• null and undefined: represents the absence of a value

• object: represents any object type, including arrays and functions

• any: represents any type, and can be used when you don't know the type of a variable ahead of time

• void: represents the absence of a value, typically used as a return type for functions that don't return anything

In addition to these basic types, TypeScript also supports more advanced types like union types, intersection types, and generics. But more on these later.

Syntax: let variableName: type = value

let num: number = 67

Type Inference

Type inference in TypeScript is like having a clever assistant who can automatically guess and figure out the types of values in your code based on how you use them. It saves you from explicitly declaring types every time, making your code more concise and readable. With type inference, TypeScript analyzes your code and infers the types behind the scenes, making programming faster and more intuitive.

eg: let num = 7

The type of num will automatically be inferred as a number.

In case ts is not able to infer the type, it will set it as any.

To prevent the above scenario from happening we can use noImplicitAny in our config file. As any isn't type-checked, we should avoid using it.

Defining Functions

Defining parameter types:

cont funcName = ( var1: type, var2: type) => {}

Defining return type:

cont funcName = (): type => {}

Example: A function taking in the date and returning the number of days from that date

const getDaysFromDate = (date: Date): number => {
  const today: Date = new Date();
  const timeDifference: number = today.getTime() - date.getTime();
  const daysDifference: number = Math.floor(timeDifference / (1000 * 60 * 60 * 24));
  return daysDifference;
}

Type Alias

A type alias in TypeScript is like giving a nickname to a specific type. It allows you to create a custom name for a type, making your code more expressive and readable. Instead of repeatedly using complex or lengthy type annotations, you can define a type alias once and then use that alias throughout your code.

Eg: you can create a type alias, userD, which you can use anywhere you want to perform any operation on the user.

type UserD = {
    name: string;
    age: number;
}

const updateUser = (user: UserD) => {
    // some code
}

Readonly

The readonly modifier in TypeScript is used to indicate that a property of a type can only be read and cannot be modified. It ensures that once a property is assigned a value, it cannot be changed later.

type UserD = {
    readonly _id: string;
    name: string;
}

Typescript will throw an error if we try to change the value of the _id.

Combining types

type A = { name: string }

type B = A & { isPro: boolean }

now B becomes: { name: string; isPro: boolean }

Defining Arrays

type[] and Array<type>

These are functionally equivalent and can be used interchangeably. The choice between them often comes down to personal preference or the existing coding style within a project.

const arrName: type[] = []

const arrName: Array<type> = []

Specifying length:

We can specify the length an array is supposed to be, if you try to add or remove values from the array, TypeScript will give you an error because it doesn't match the defined length.

const arrName: Array<type, length> = []

ReadonlyArray:

ReadonlyArray type is a built-in utility type that represents an immutable array. It ensures that the array cannot be modified once it is created, preventing any additions, removals, or modifications to its elements.

The ReadonlyArray type is useful when you want to create arrays that should remain constant and not be modified inadvertently.

const arrName: ReadonlyArray<type> = []

A good use case of type aliases can be defining a type of userD for an array of users.

type UserD = {
    id: number;
    name: string;
    age: number;
}

const users: UserD[] = [
    {id: 1, name: 'Mario', age: 20},
    {id: 2, name: 'Luigi', age: 23}
]

Unions

A union in TypeScript is like a combination of different types. It allows you to define a type that can be one of several types. For example, you could have a variable that can be either a number or a string. The types are separated by pipe | symbol.

type id = number | string

type arr = (boolean | string)[]

Tuples

A tuple is an array type that knows exactly how many elements it contains and exactly which types it contains at specific positions.

syntax: type tupleName = [string, number]

eg: let arr: [string, boolean];

if we define arr like this: arr = [23, false] it will throw an error as type of element on index 0 should be a string, not a number.

type Person = [string, number, boolean]

const person: Person = ["John Doe", 30, true]

Interface

The interface is the same as the type alias but with a few additional features:

1. It can be re-opened i.e., we can redefine the interface with some additional properties. E.g.

     interface UserD { 
        name: string;
        age: number;
     }
   
    interface UserD {
        isPro: boolean;
    }
   

   Re-opening interface does not override the previous definition. But it adds the new types with the previous ones. So now UserD contains name, age and isPro.

2. Can extend other interfaces. E.g.

    interface Animal {
      name: string;
      age: number;
      sound(): void;
    }
   
    interface Dog extends Animal {
      breed: string;
      bark(): void;
    }
   

Be careful while naming interfaces, as you might be re-opening some interface present in a file of some library that you downloaded.

Enum

It allows you to define a set of named constants. It helps us define a specific list of options or choices that something can be. For example, if we have a system with three user roles: "Admin", "Moderator", and "User". Instead of using plain strings to represent these roles throughout the code, we can define an enum called "UserRole" with these three members.

enum UserRole {
  Admin = "ADMIN",
  Moderator = "MODERATOR",
  User = "USER"
}

That concludes this blog, you now possess the essential knowledge to seamlessly incorporate TypeScript into your projects. Best of luck on your path to becoming an exceptional software developer, and may your web creations be nothing short of extraordinary!

The most commonly used typefaces on the web are Serif, Sans-Serif, Script, and monospaced fonts.

Serif:

• These fonts are used for established or old-school brands like banks or for fashion magazines and jewellery brands.

• These fonts convey a traditional and formal vibe.

• They can be used for long-form copies, like big paragraphs.

• Some popular serif fonts on the web are Bodoni, Garamond, PT serif, and Noto serif.

Sans Serif:

• These are clean, minimal, and modern-looking fonts.

• These are the most commonly used fonts on modern websites.

• These can be used for long-form copies as they are easy on the eyes of the reader.

• Some popular sans-serif fonts: Inter, Open sans, Space Grotesk, Poppins, and Montserrat

Script:

• These are the fonts that look like they were hand-drawn.

• They provide a warm and personal touch.

• They are not suitable for a long-form copy.

• They are commonly used for logos, headlines, and wedding invitations.

• Popular script fonts: pacifico, dancing script

Monospaced:

• These have each character of a word equally spaced so that we can see each individual character clearly at a glance.

• The personality of monospaced fonts is often seen as practical, precise, and functional.

• Commonly used to show code IDEs.

• Can be used to show code snippets on a website.

• Popular monospaced fonts: Courier, roboto mono

1. Tracking and leading

Tracking:

Tracking or Letter-spacing is the process of simultaneously adjusting the overall space between groups of letters.

• Larger type sizes, such as headlines, use tighter letter spacing to improve readability and reduce space between letters.

• For smaller type sizes, looser letter spacing can improve readability

• Increase letter spacing with uppercase text

• Decrease letter spacing when increasing font size & font weight

Leading:

Leading or line spacing is the vertical distance between two lines.

• When text is very small we need to increase line spacing to make it more readable. Lines should not be too tight but they should also not be too big that you can actually notice the white blocks in between lines.

• And decrease line spacing for large text sizes

• The line height for a paragraph should be around 130 to 150% of the font size. Or you can always use the golden ratio (line height will be = font size * 1.618)

  

  

1. Text wrapping

Try to make each line about 10-11 words or 60 to 80 characters long, for mobile, it becomes 35 to 45 characters. Otherwise, people will have to turn their heads to read the long lines from left to right.

A tick I use to ensure proper text wrapping of each paragraph in my HTML page is using the clamp CSS property and setting the width of the paragraph to 50% of its container with its maximum value to be 75ch (75 characters long) and min width to be 45ch.

Widow

A widow is a very short line – usually one word, or the end of a hyphenated word – at the end of a paragraph or column. A widow is considered poor typography because it leaves too much white space between paragraphs or at the bottom of a page. This results in poor horizontal alignment at the top of the column or page. So try to avoid it.

1. Text Alignment

Left-aligned: Left-aligned text is most common for left-to-right languages like English.

Centre-align: Centred text is best used to distinguish short typographic elements within a layout (such as pull quotes), and is not recommended for long copies.

Right-align: It is the most common setting for right-to-left languages, such as Arabic.

1. Limit the number of fonts you use

Combining typefaces can be very tricky, so to avoid confusion:

• try to reduce the number of typefaces you use in your project and,

• select the combinations that are guaranteed to work.

• Some font families come with both serif and sans serif typefaces so they are guaranteed to work together. PT and Noto are great examples of this.

1. Create a typographic scale

• Make sure you scale up your typography with some rhyme or reason, not some random stuff.

• I suggest using the golden ratio as it almost always works.

• Golden ratio: Basically, you multiply the font size by 1.618 for every increasing step in your scale.

• A useful resource for setting up your type scale is https://typescale.com

  

1. Contrast

The most common ways of giving contrast are using font weight, font size, and color.

• Font weight: We can adjust the weight of the text to make it stand out. Thus the weight of the heading is much higher than that of the paragraph that follows it.

• Font size: When adjusting the size of your typography to improve contrast, it's important to consider hierarchy and proportions and thus Headings and subheadings should be larger than the body text, to make them stand out and guide the reader's eye through the content.

• Color: Adding color to your typography can also help improve contrast. Using a darker color for the text against a lighter background, or vice versa, can create a sharp contrast that makes the text stand out.