Blog Posts


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

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.