Blog Posts


Typescript's static typing system helps us catch errors during development.
When we run our code, the way that our JavaScript runtime chooses what to do is by figuring out the **type** of the value.

For some values, such as the primitives **string** and **number**, we can identify their type at runtime using
the **typeof** operator. But for other things like **functions**, there's no corresponding runtime mechanism to identify their types.

In the example below, the JS interpreter access a property called **toLowerCase**, and then calls it. In the next line, it tries to call **message** directly.

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

message.toLowerCase();

//calling mesage
message();
```


But assuming we don't know the value of **message**, we can't reliably say what results
we'll get from trying to run any of this code. The behaviour of each operation depends entirely on what value
we have in 'message', and on whether 'message' is callable.

If we try to run `message.toLowerCase()`, we'll get the same string only in lower-case.
Now the next line calls `message()`, and the code fails with an exception: 'TypeError: message is not a function'.

But predicting what the code will do before it runs isn't always as straight forward as shown here above.

Consider the following example

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

This function will only work, if given an **object** with a callable **flip** method, but JS doesn't have a static type system
so it can't tell us about most type errors before we run the code. The only type-checking JS provides is **dynamic typing** - running the code to see what happens.

Seen in this way, a type is the concept of describing which values can be passed to a function **fn**, and Typescript as a type-checker does that for us.

Static type systems describe the shapes and behaviours of what our values will be when we run our programs.
So that when we run this first sample with Typescript will give us an error message before we run the code.

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

message();

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



Javascript provides language primitives like 'string' and 'number', but it doesn't check that you've consistently assigned these.
Typescript on the other hand does.

In this example, Typescript is able to highlight unexpected behaviour in your code when we call a property that
doesn't exist on an object, and unlike the response we get from the JS interpreter, which isn't so obvious

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

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


In Typescript, the same code produces an error about **location** not being defined.

```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 what the code will do before it runs

Typescript's Static Typing System


JavaScript can only make calls to URLs that live on the same origin as the location where the script is running (Same-Origin policy).

Cross-Origin Resource Sharing (CORS) is a security mechanism built-into browsers that controls when a web page can interact with resources
from a different origin than the one that served the page. This is useful because in JavaScript you bump into CORS when you use **fetch**,
**XMLHttpRequest**, or other APIs to talk to a backend that lives on another origin or domain.

For example, if a JS app wishes to make an AJAX call
to an API running on a different domain, it would be blocked from doing so thanks to the same **origin-origin** policy.

Most of the time a script running in the user's browser would only ever need to access resources on the same origin. So the fact that JS
can't normally access resources on other origins is a good thing for security.

However, there are legitimate scenarios where cross-origin access is desirable or necessary. For example, if you're running a React App
that makes calls to an API backend running on a different domain to get web fonts.

```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
```

When a server has been configured to allow cross-origin resource sharing, the response will include CORS headers like **Access-Control-Allow-Origin**;
if not, the browser blocks access and you see a CORS error in the console.

For simple requests like GET, POST or HEAD with standard headers, the browser just sends the request and checks the response headers for
**Access-Control-Allow-Origin**, which can be a specific origin or domain or '*' to allow any origin. <br />
If the response includes credentials: cookies, HTTP authentication, the server must also send **Access-Control-Alow-Credentials**.

If a request does not meet the criteria for a **simple** request, the browser will instead make an automatic **preflight** request using
the OPTIONS method. This call is used to determine the exact capabilities of the server. Only if the the preflight is approved will the browser
send the actual request.

An example of such a request might look like this:
```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 basically says: "I would like to make a GET request with the Content-Type and Accept
headers from origin. Is that possible?"

The server will include some Access-Control-* headers within the response to indicate whether
the request that follows will be allowed or not. These include:

- **Access-Control-Allow-Origin**: The origin that is allowed to make the request, or * if a request can be made from any origin
- **Access-Control-Allow-Methods**: A comma-separated list of HTTP methods that are allowed
- **Access-Control-Allow-Headers**: A comma-separated list of the custom headers that are allowed to be sent
- **Access-Control-Max-Age**: The maximum duration that the response to the preflight request can be cached before another call is made

The response would then be examined by the browser to decide whether to continue with the request or to abandon it.

So a response to the earlier 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 2019 11:41:08 GMT
Connection: keep-alive
```

The **Access-Control-Allow-Origin** header, in this case, allows the request to be made from any origin, while the **Access-Control-Allow-Methods**
header describes only the accepted HTTP methods.

If a given HTTP method is not accepted, it will not appear in this list. In this example, **Access-Control-Allow-Headers** echos back the
headers that were asked for in the OPTIONS request.
This indicates that all the requested headers are allowed to be sent.






















Circumstances under which is needed, and its benefits

Cross-Origin Resource Sharing


Everything’s 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 run 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.

Prior to ES6, JavaScript aimed to emulate traditional **class-based** languages like Java, C++, and Python. But JS remains the most
popular among them, despite of being much less of a class-based language.

In the JS way, 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/ props,
we use the built-in prototype system.


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


### Principles of OOP:
 - Encapsulation,
 - Abstraction,
 - Inheritance and
 - Polymorphism.


#### 1. Encapsulation
 - The principle of encapsulation entails that all properties and methods of an object are kept self-contained and safe from outside interference.
 - Within an object, we can define both private and public members. Private variables and methods are inaccessible to other objects,
 - whereas 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 changes made to the code so that if something goes wrong, the change will only affect
the implementation details of a class and not the outside code.

Think of a music player: you see a "Play" button, but the complex circuitry required to decode the audio is hidden inside.
We understand and know the technology on the surface but might not know how it works inside or might not have an urge to understand how it works.
By hiding internal complexity and only exposing the essential features, we prevent "leaking" implementation details that the rest of
the program doesn't need to know about.

#### 3. Inheritance
Under the Inheritance mechanism, a class inherits the features, props, and/ or methods of another class. In JS, this is achieved
through the **prototype chain**, at the same time promotes reusability, and ensures that shared functionality isn't 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 behavior.






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 behavior.

Blog Posts

Typescript's Static Typing System

Cross-Origin Resource Sharing

Object-Oriented Programming Paradigm