Blog Posts

Netlify-Blog


TypeScript's static type system helps us catch errors during development. When we run our code, the JavaScript runtime
determines how to behave by identifying the type of each value.

For some values, such as the primitives string and number, we can identify the type at runtime using the typeof operator.
However, for other constructs like functions, there is no corresponding runtime mechanism to identify their specific types or signatures.

In the example below, the JavaScript interpreter accesses a property called **toLowerCase** and calls it. In the next line,
it attempts to call message directly.

Ex
```ts
const message = "Hello World"

message.toLowerCase();

//calling mesage
message();
```


Assuming we don't know the initial value of **message**, we cannot reliably predict the results of running this code.
The behaviour of each operation depends entirely on the value stored in message and whether that value is callable.

If we run `message.toLowerCase()`, we receive the same string in lowercase. However, the next line calls `message()`, and
the code fails with an exception: `TypeError: message is not a function`.

Predicting what code will do before it runs isn't always as straightforward as the example above. Consider the following:

```ts
function fn(x) {
	return x.flip();
}
```

This function will only work if it is passed an **object** with a callable **flip** method. Because JavaScript lacks a static type system,
it cannot alert us to type errors before the code is executed. The only type-checking JavaScript provides is **dynamic typing** —running
the code to see what happens.

In this context, a **type** is a concept describing which values can be safely passed to a function. TypeScript acts as a
**type-checker** to enforce these descriptions.

Static type systems describe the shapes and behaviors of our values before
we run our programs. Consequently, running the first sample with TypeScript will trigger an error message before
the code ever executes:

```ts
const message = "Hello World";

message();

// This expression is not callable.
// Type 'String' has no call signatures.
```

While JavaScript provides primitives like string and number, it does not verify that you have assigned or
used them consistently. TypeScript, on the other hand, does.

In the following example, TypeScript highlights unexpected behavior when calling a property that does not
exist on an object.

This is a significant improvement over the JavaScript interpreter, where the result
is often silently ambiguous:

```ts
const user = {
	name: "Tom",
	age: 32,
};

user.location;
// > returns undefined
```

In TypeScript, the same code produces a clear error:

```ts
interface User {
	name: string;
	age: number;
}

const user: User = {
	name: "Tom",
	age: 32,
};

user.location;
// > Property 'location' does not exist on type '{ name: string; age: number; }'.
```








Predicting code behaviour before execution.

How TypeScript handles Type Inference

In order to achieve a smooth dropdown animation without a dedicated JavaScript library, we have to address a common CSS limitation:
the **height** property cannot transition between a fixed value like 0 and auto. <br />
CSS cannot transition between:
```css
 height: 0;
 height: auto;
```

This limitation often leads to "snapping" menus or causes developers to reach out for Framer Motion or GSAP just to open a simple dropdown.

### 1. A Solution with HTML

This implementation uses three specific techniques to achieve a smooth, weighted feel:

I. **Custom Timing function**<br />
Instead of a generic ease, we use a custom Bézier curve: **ease-in-out** (cubic-bezier(0.4,0,0.2,1). This mimics real-world
weight-starting fast, and settling with a smooth deceleration

```html
 <div
        id="dropdown-menu"
        class="grid grid-rows-[0fr] opacity-0 transition-all duration-500 ease-in-out overflow-hidden
               bg-white border-b shadow-xl">
    ...
    

</div>
```



II. **CSS Grid for dynamic height**    <br />
We animate **grid-template-rows** instead of the **height** property. <br />
In CSS Grid, animating from **0fr** to **1fr** only works, as long as the direct child of
the grid item has **min-height:0** (see below) and the container users **overflow:hidden**.

    - **Closed**: grid-rows[0fr]
    - **Open**: grid-rows[1fr] <br />

    The browser calculates the height of the internal content dynamically, and transitions between states correctly.


```html
<div class="min-h-0">
    ...
    
</div>
```




III. **The Staggered effect** <br />
To create a cascading reveal effect, the links cannot be static. They must slide up into place while the menu rolls down, and so we use **transition-delay** classes.

```html
<nav class="flex flex-col p-8 gap-6">
    <a
        href="#"
        class="nav-link text-lg font-semibold border-b pb-2 opacity-0 -translate-y-4
                     transition-all duration-500 delay-100 text-slate-800">Home
    </a>
    <a
        href="#"
        class="nav-link text-lg font-semibold border-b pb-2 opacity-0 -translate-y-4
                 transition-all duration-500 delay-200ms text-slate-800">Products
    </a>
    <a
        href="#"
        class="nav-link bg-indigo-600 text-white text-center py-4 rounded-xl font-bold opacity-0
                 scale-95 transition-all duration-500 delay-300ms">Sign In
    </a>
</nav>
```


## CodePen (HTML/TailwindCSS)

To see this work in a CodePen click <a target="_blank" href="https://codepen.io/editor/Stefano-JD/pen/019cf017-b99c-7150-acf7-fde41ffab559">here</a>. Or copy/paste the
code below into the HTML body of your page, and add the tailwind CDN.
```html

    <script src="https://cdn.tailwindcss.com"></script>
  </head>

  <body class="bg-slate-50">
    <div class="fixed top-0 w-full bg-white shadow-md font-sans z-50"><div class="flex justify-between items-center p-4 border-b bg-white relative z-10">
        <span class="font-bold text-xl text-indigo-600">CakeStack®</span><button id="menu-btn" class="p-2 px-4 bg-neutral-100 hover:bg-neutral-200 rounded-md transition-colors font-medium">Menu</button></div>
        <div id="dropdown-menu" class="grid grid-rows-[0fr] opacity-0 transition-all duration-500 ease-in-out overflow-hidden bg-white border-b shadow-xl">
        <div class="min-h-0"><nav class="flex flex-col p-8 gap-6"><a href="#"  class="nav-link text-lg font-semibold border-b pb-2 opacity-0 -translate-y-4 transition-all duration-500 delay-100 text-slate-800"
            >Home</a>
            <a href="#" class="nav-link bg-indigo-600 text-white text-center py-4 rounded-xl font-bold opacity-0 scale-95 transition-all duration-500 delay-300">Sign In</a>
          </nav></div></div>
        </div>

    
    <script>
      ...
        // Toggle Curtain Height and Opacity
        curtain.classList.toggle("grid-rows-[1fr]", isOpen);
        curtain.classList.toggle("grid-rows-[0fr]", !isOpen);
        curtain.classList.toggle("opacity-100", isOpen);
        curtain.classList.toggle("opacity-0", !isOpen);
      });
    </script>
  </body>
</html>
```


### 2. Component Logic with React/NextJS

Ensure the menu wrapper follows this structure:
```js
 import Link from 'next/link';

 <div className={`grid transition-all duration-500 ease-curtain ${isOpen ? 'grid-rows-[1fr] ' +
'   opacity-100'
    : 'grid-rows-[0fr] opacity-0'}`}>
    <div className="overflow-hidden">
        {/* Nav Links with staggered delays */}
        <Link className={`transition-all delay-100 ${isOpen ? 'translate-y-0' : 'translate-y-4'}`}>
        Home</Link>
        <Link className={`transition-all delay-300 ${isOpen ? 'translate-y-0' : 'translate-y-4'}`}>
        Sign In</Link>
    </div>
 </div>
```

Smooth drop-down animation without JS libraries

Drop-down animation with Tailwind

There's no single approach that works for all situations

What is Agile

Understanding where the HTML content is generated.

Server-Side Rendering

Everything is an object. This assertion underlies Object-Oriented Programming (OOP). In this paradigm, objects are
well-defined data structures, each with its own properties (attributes) and the capability to execute its own procedures (methods).

Some of the primary benefits of this approach include well-structured codebases and programs that are easier to modify,
debug, maintain, and reuse.

In JavaScript, the class syntax is simply **syntactic sugar** over function constructors and Prototypal Inheritance.
When we share data or functionality between objects —for example, a child object accessing a parent object’s methods or
properties —we are utilizing the built-in prototype system.

### How the Prototype Chain Works
- When you access a property, the JavaScript interpreter first looks at the instance object itself.
- If the property is not found, it travels up the prototype chain using the __proto__ pointer.
- It searches the linked prototype objects until it finds the property or reaches `Object.prototype` (the root).
- When a new object is created in JavaScript, we are instantiating a reference to a specific location in memory and
its corresponding prototype.

### The Four Principles of OOP
The core of OOP is built upon four pillars:
1. Encapsulation,
2. Abstraction,
3. Inheritance, and
4. Polymorphism.

#### 1. Encapsulation
Encapsulation ensures that all properties and methods of an object are kept self-contained and protected from outside
interference. Within an object, we can define both private and public members.

While private variables and methods
are inaccessible to other objects, public ones provide a controlled interface for interaction.
This prevents the internal state of an object from being modified unexpectedly by external code.

```js
let employee = {
    baseSalary: 50000,
    overtime: 10,
    rate: 20,
    // This method uses 'this' to access its own encapsulated data
    getWage: function() {
        return this.baseSalary + (this.overtime * this.rate);
    }
};

 console.log(employee.getWage()); // 50200
```


#### 2. Abstraction

Abstraction helps isolate the impact of code changes; if an update is made, it only affects the **internal implementation
details** of a class rather than the external code.

Think of a music player: you see a "Play" button, but the complex circuitry required to decode the audio is
hidden inside. We interact with the technology on the surface without needing to understand its internal mechanics.
By hiding internal complexity and exposing only essential features, we prevent "leaking" implementation details that
the rest of the program does not need to manage.

#### 3. Inheritance

Through the inheritance mechanism, a class can derive features, properties, and methods from another class. In JavaScript,
this is achieved through the **prototype chain**. This promotes reusability and ensures that shared functionality is not
duplicated in memory.

#### 4. Polymorphism

Polymorphism (meaning "many shapes") allows different objects to be treated as instances of the same general type
through a shared interface. It helps eliminate long **if/else or switch statements** by allowing each unique object to
implement its own specific version of a common method. When that method is called, the object performs the action
according to its own logic.

Example:
```js
// Each element (Circle, Square, Triangle) has its own render logic,
// but we can call .render() on all of them in one loop.

elements.forEach(element => element.render());
```

### Key Benefits of OOP

 - **Encapsulation**: Reduces complexity and increases reusability.
 - **Abstraction**: Isolates the impact of changes by hiding implementation details.
 - **Inheritance**: Eliminates redundant code by sharing logic across objects.
 - **Polymorphism**: Refactors messy conditional logic into clean, object-specific behaviour.






OOP is a paradigm focused on modeling systems as collections of objects, where each object represents a specific aspect of the system's data and behaviour.

Object-Oriented Programming Paradigm

What is Scrum


JavaScript can generally only make calls to URLs that reside on the same origin as the script's location.
This security restriction is known as the **Same-Origin Policy**.

Cross-Origin Resource Sharing (CORS) is a browser-based security mechanism that controls how a web page interacts
with resources from a different origin. In modern web development, you typically encounter CORS when using the
**fetch** API, **XMLHttpRequest**, or other tools to communicate with a backend hosted on a different domain or port.

For example, if a JavaScript application attempts to make an AJAX call to an API running on a different domain,
the request would be blocked by the Same-Origin Policy unless the server explicitly permits it.

Most of the time, a script running in a user's browser only needs to access resources from its own origin.
Therefore, the restriction on cross-origin access is a vital security feature. However, there are legitimate
scenarios where cross-origin access is necessary —such as a React app fetching web fonts or data from a dedicated API backend.

```js
//Same-origin policy
https://example.com

//Can only access responses from
https://example.com

//But not from
https://api.other.com
```

When you call another origin, the browser automatically attaches an **Origin** header to your request

Ex:
```js
//Origin: https://example.com
```

If a server is configured for CORS, its response will include specific headers, such as **Access-Control-Allow-Origin**.
If these headers are missing or incorrect, the browser blocks the response, and a CORS error appears in the developer console.

### Simple vs Preflight Requests
For simple requests (such as GET, POST, or HEAD using standard headers), the browser sends the request directly
and verifies the response headers. The Access-Control-Allow-Origin header may specify a single domain or use * to allow any origin.

If the request includes credentials—such as cookies or HTTP authentication—the server must also include the
**Access-Control-Allow-Credentials** header.

If a request does not meet the "simple" criteria, the browser performs an automatic __preflight__ request using the
**OPTIONS** method. This preliminary call determines the server's capabilities. The actual request is only sent
if the preflight is approved.

An example of a preflight request:
```js
//Request
curl -i -X OPTIONS localhost:3000/api/ping \
-H 'Access-Control-Request-Method: GET' \
-H 'Access-Control-Request-Headers: Content-Type, Accept' \
-H 'Origin: http://localhost:3000'
```

This request essentially asks the server: "I would like to make a GET request using 'Content-Type'
and 'Accept' headers from this origin. Is that permitted?"

The server responds with **Access-Control-*** headers to indicate whether the subsequent request is allowed. Key headers include:
- **Access-Control-Allow-Origin**: Specifies which origin can access the resource.
- **Access-Control-Allow-Methods**: A comma-separated list of permitted HTTP methods.
- **Access-Control-Allow-Headers**: A list of custom headers allowed in the actual request.
- **Access-Control-Max-Age**: The duration (in seconds) the preflight response can be cached.


A typical response to the preflight example might look like this:
```text
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Vary: Access-Control-Request-Headers
Access-Control-Allow-Headers: Content-Type, Accept
Content-Length: 0
Date: Fri, 05 Apr 2020 11:41:08 GMT
Connection: keep-alive
```

In this case, the `Access-Control-Allow-Origin: *` header allows the request from any origin.
The **Access-Control-Allow-Headers** echoes the requested headers, confirming they are acceptable for the actual request.






















Understanding when CORS is needed and its security benefits.

Cross-Origin Resource Sharing (CORS)

Resource A is dependent on Resource B, and vice versa.

What is a Circular dependency

Pros and cons of Static Site Generation (SSG)

Static Site Generation

Updating content without a full site rebuild (ISR)

Incremental Static Regeneration


### Building Better Software

In object-oriented programming, writing code that works is only half the battle. The real challenge is writing code that is easy to
maintain, understand, and extends as your project grows. This is where **SOLID** comes in -a set of five design principles that serve as
the gold standard for clean architecture.

#### 1. Single Responsibility Principle
A class should have only one job to do, and everything within it should be closely related, thus promoting reusability. If a class handles
too many things, it becomes fragile; changing one part of the logic might accidentally break another.

**Ex**: <br />
A `TodoList` class that manages tasks and handles file saving. By splitting the responsibilities: the list logic in one class and the data persistence
in another, we're adhering to the principle.

```js
class TodoList {
    constructor() {
        this.items = [];
    }
    addItem(text) { this.items.push(text); }
    removeItem(index) { this.items.splice(index, 1); }
    toString() { return this.items.toString(); }
}

class DatabaseManager {
    saveToFile(data, filename) {
        fs.writeFileSync(filename, data.toString());
    }
}
```

### Open-Closed Principle
Software entities should be open for extension, but closed for modification. We should be able to add new features or functionality without changing any of the existing
code of the class.

**Ex**: <br />
A `DeveloperFilter` class with specific methods like **filterByName** or **filterByLanguage**. Everytime we add a new prop on Developer class, we have to
update its method in the filter class. By refactoring the property-based filters, no longer need to modify the source code as the data structure evolves.
```js
class DeveloperFilter {
    // This method is "closed" to modification but "open" to any property you pass
    filterByProp(array, propName, value) {
        return array.filter((item) => item[propName] === value);
    }
    // filterByName √ removed
    // filterByPosition √  removed
}

class Developer {
	constructor(name, position) {
		this.name = name;
        // Adding position will not change DeveloperFilter
		this.position = position;

	}
}
```

### Liskov Substitution Principle
A **Child** class should be able to do everything that a **Parent** class can. Objects of a superclass should be replaceable with objects of its
subclasses without breaking the application.
If Square is a subclass of Rectangle, we should be able to use **Square** anywhere we use **Rectangle**

Whenever extending a child's class does not fulfill the behaviour of its parent, rethink hierarchy. We might just need a more general parent class (e.g. Shape) instead
of forcing a relationship that doesn't fit.


### Interface Segregation Principle
They provide a contract for our classes and methods. No client should be forced to depend on methods it does not use. In TypeScript, we use interfaces
to define the structure or shape of an object and specify the properties and methods that an object has or should have.

**Ex**: <br />
A **Vehicle** interface with both **drive()** and **fly()** methods forces a standard Car class to implement a fly() method it doesn't need.
By splitting the Vehicle interface, we no longer have to implement interfaces we don't need.

```ts
interface ICar {
	drive(): string;
}
interface IPlane {
	fly(): string;
}

// Regular car
class Car implements ICar {
	public drive(): string {
		return 'Running Down A Dream';
	}
}

// Car from the future
class CovertToPlane implements ICar, IPlane {
	public drive(): string {
		return 'Running Down A Dream'
	}
	public fly(): string {
		return 'Learning To Fly & Free Falling';
	}
}
```


### Dependency Inversion Principle
High-level modules should not depend on low-level modules. Both should depend on abstractions. Our main logic
shouldn't be too tightly coupled to specific tools or databases.

**Ex**: <br />
A **PersistenceManager** class that uses `if (db instanceof FileSystem)` is too dependent on specific **low-level** classes.
If we add a new database type, we would have to rewrite the high-level manager class.

The PersistenceManager class doesn't need to know which type of data storage it is, so we standardise the interface of the low-level classes.

```js
class PersistanceManager {
  saveData(db, data) {
    // It doesn't care if FileSystem, ExternalDB, LocalStorage
    db.save(data);
  }
}
```



















