DEV Community: Dev Kadiem

Advanced ReactJS Tutorial: Master Context In A Few Simple Examples

Dev Kadiem — Fri, 31 Mar 2023 12:30:09 +0000

ReactJS logo

React Context transfers data between different levels of your application without "Prop Drilling." It provides a way to pass data through the components tree.

Prop Drilling

To further understand react Context, we must first understand the problem it solves. Prop drilling occurs when we continue passing data to child components in an endless way, even though some of those components don't use it; they receive it to pass it to their children.

Let's take a typical example, a counter app.

export default function App() {
  const [counter, setCounter] = useState(0);

  return (
    <div>
      <AddOneButton setCounter={setCounter} />
      <Counter counter={counter} />
    </div>
  );
}

It has two children components, one to increase the count and another to show the current count.

const AddOneButton = ({setCounter}) => {
  return (
    <button onClick={() => setCounter((value) => value + 1)}>Add One</button>
  )
}

const Counter = ({counter}) => {
  return (
    <p>Count: {counter}</p>
  )
}

Now let us say we have a new component called Container that wraps the AddOneButton.

const Container = ({setCounter}) => {
  return <AddOneButton setCounter={setCounter} />
}

And now, inside the App we render the new Container component.

<Container setCounter={setCounter} />

Now it's clear that Container acutely does not need the setCounter function, we passed it just because AddOneButton needs it, and this what known as "Prop Drilling" this is why we need the Context Api.

NOTE

In this case, we can mitigate the use of prop drilling by making the Container component a generic component and passing AddOneButton as a child.

const Container = ({children}) => {
  return (
    {children}
  )
}

export default function App() {
  const [counter, setCounter] = useState(0);

  return (
    <div>
      <Container>
        <AddOneButton setCounter={setCounter} />
      </Container>

      <Counter counter={counter} />
    </div>
  );
}

Context with useState

now that we understand prop drilling, we can start using Context Api, but before that, we need to decide what way we will implement Context; there are mainly two ways either with useState or useReducer in this section, we will do it using useState, let us start by importing the required modules.

import {createContext, useContext} from "react";

Then we create the Context and its provider.

export const CounterContext = createContext(null);

export const CounterContextProvider = ({ children }) => (
  <CounterContext.Provider value={useState(0)}>
    {children}
  </CounterContext.Provider>
);

the createContext function initializes the Context, the provider will wrap our application (only the components inside the provider will have access to data), and because we are using context API we don't need to pass anything to Container or Counter components.

export default function App() {
  return (
    <CounterContextProvider>
      <Container />
      <Counter />
    </CounterContextProvider>
  );
}

Now to access the data, we shall use useContext hook.

const Container = () => {
  return <AddOneButton />;
};

const AddOneButton = () => {
  const [, setCounter] = useContext(CounterContext);
  return (
    <button onClick={() => setCounter((value) => value + 1)}>Add One</button>
  );
};

const Counter = () => {
  const [counter] = useContext(CounterContext);
  return <p>Count: {counter}</p>;
};

Context with useReducer

Note: It's recommended to use useReducer if our state is more complex.

Let us start by importing the required modules.

import { createContext, useContext, useReducer } from "react";

Now let's create a reducer and plug it into our context data.

const reducer = (state, action) => {
  switch(action.type) {
    case "increment":
      return state + 1;
    default:
      return state
  }
}

export const CounterContext = createContext(null);

export const CounterContextProvider = ({ children }) => (
  <CounterContext.Provider value={useReducer(reducer, 0)}>
    {children}
  </CounterContext.Provider>
);

The hook returns a tuple, the first element is the value, and the second is the dispatch function.

const Container = () => {
  return <AddOneButton />;
};

const AddOneButton = () => {
  const [, dispatch] = useContext(CounterContext);
  return (
    <button onClick={() => dispatch({type: "increment"})}>Add One</button>
  );
};

const Counter = () => {
  const [counter] = useContext(CounterContext);
  return <p>Count: {counter}</p>;
};

And basically, that's how context Api works.

Typescript, NextJS, Strapi, and GraphQL: An Overview Of How I Created My Blog

Dev Kadiem — Fri, 03 Feb 2023 04:48:18 +0000

First things first, let's introduce the stack we are going to use. Typescript is "Is a strongly typed programming language that builds on JavaScript, giving you better tooling at any scale." in simple words, Typescript enhances coding safety and enables more OOP for the web.

NextJS is a framework that "Enables you to create full-stack web applications by extending the latest React features" in simple words, NextJS is an upgrade over the widely used ReactJS library.

Strapi is an open-source headless CMS. CMS stands for "content management system," allowing us to create, manage, modify, and publish content in a user-friendly interface without programming knowledge. Headless means there is no built-in end-user UI; we can use whatever frontend technology we want.

GraphQL is "A query language for APIs and a runtime for fulfilling those queries with your existing data" in simple words, it's a language used to query data and get the fields you want.

Note: this is an overview, which means there are aspects I will not go over, such as styling and best HTML tags; this blog is meant to showcase the functionality of creating a Blog using the technologies mentioned above.

Initializing The Project

Now, let's create the folders using the command line (because it's cooler), so the first command is to create a folder containing all our files.

mkdir my-personal-website

Now, let's create folders for both NextJS and Strapi.

cd my-personal-website
mkdir frontend, strapi

Initialize Strapi

cd strapi
npx create-strapi-app@latest . --ts --quickstart

Parameter @latest means it will install the latest version, . means we want to create the project in the current folder, then — ts means it will use TypeScript, and lastly — quickstart it will install with default settings; when the installation finishes, it will open a new window on the address /admin/auth/register-admin, asking you to create a new admin account; go ahead and create a new account. Note: using — ts is optional since I won't change the source code in this post.

Initialize NextJS

cd frontend
npx create-next-app@latest . --ts

And lastly, remember to init a Github repo, but I'll not cover it in this post.

Starting with Strapi

I like to start with the backend in my projects, so I will start with Strapi as it's considered a backend.

Installing Graphql

One advantage of using Strapi is its easy integration with Graphql. To install the Graphql plugin, we need the run the following command.

npm run strapi install graphql

If you encounter the _Duplicate "graphql" modules error, don't worry; it's easy to fix; all you need to do is to delete the node_modules folder and package-lock.json , then we need to reinstall packages.

rm node_modules
rm package-lock.json
npm install
npm run strapi dev

After successful installation, we can now visit the URL /graphql.

Creating The Blog Post Collection

Open the Strapi homepage on URL http://localhost:1337/admin/, and after you sign in, go to the Content-Type Builder page, click on Create new collection type button, then in the Display name field, fill it in with an appropriate name; I will choose Blog Post , then click continue.

Now, we are in fields selection for our new collection; you can customize it however you want; for the sake of simplicity, I will add three fields, a Text field for the title, another Text field for the description, and lastly, a Rich Text field for the body, next click save.

Now that we have a collection, we need to populate it with data, go to Content Manager , and now we can see the newly created collection, click on it, then Create new entry button, and fill it with any data you want, then click save and publish.

Accessibility Option 1: Publicly Accessible

Before we can access our data through Graphql, we need to make it accessible; you can make it publicly accessible or only for authenticated users. I will choose a publicly accessible collection since I'm not storing sensitive data.

To access it publicly, go to Settings, then roles, click on Public , scroll down to the collection you created (in my case, it's Blog-post), click it, then tick find and findOne.

Accessibility Option 2: Authenticated Only

However, should you choose the authenticated way, here is how to do it. There are two ways to achieve this; the first one is to create API Token in the settings page, then we need to attach it with our requests by adding it to the headers as an Authorization header and setting the value to be bearer , the second way is to create a new entry in the User collection, via Content Manager page, then send a Post request to /api/auth/local with an attached JSON body containing identifier which could be either the username or email, and password, of the newly created user in the User collection, NOT THE ADMIN ACCOUNT WE CREATED IN INITIALIZE STRAPI.

{
 "identifier": "email or username",
 "password": "password"
}

If the request were successful, you would get a response containing the JWT field, and now we need to do the same thing, send it with each request via headers in an Authorization header and set the value to be bearer .

Now to access it, go to Settings, then roles, click on Authenticated , scroll down to the collection you created (in my case, it's Blog-post), click it, then tick find and findOne.

Testing Graphql Endpoint

To access Graphql go to /graphql, and now, we can see the input field on the left side; here, we will put our queries to query our Strapi application, an example of a query:

query {
  blogPosts {
    data {
      id
      attributes {
        title
        description
        body
      }
    }
  }
}

And in my case, the response is:

  "data": {
    "blogPosts": {
      "data": [
        {
          "id": "1",
          "attributes": {
            "title": "test",
            "description": "test",
            "body": "test"
          }
        }
      ]
    }
  }
}

Testing Rest Endpoint

All we need to do is send a GET request to /api/blog-posts/. An example of a response would be:

{
    "data": [
        {
            "id": 1,
            "attributes": {
                "title": "test",
                "description": "test",
                "body": "test",
                "createdAt": "2023-01-30T20:28:28.141Z",
                "updatedAt": "2023-01-30T20:28:29.027Z",
                "publishedAt": "2023-01-30T20:28:29.025Z"
            }
        }
    ],
    "meta": {
        "pagination": {
            "page": 1,
            "pageSize": 25,
            "pageCount": 1,
            "total": 1
        }
    }
}

We have finished the Strapi section and will continue with NextJS.

Starting With NextJS

Create a new directory inside the pages directory and name it blog ; next, create a new index.tsx file and initialize a basic react component.

import {NextPage} from "next";

interface Props {
}

const About: NextPage<Props> = (Props) => {
    return (
        <p>About Page</p>
    )
}

export default About;

Now we are to visit blog and view the About Page.

Creating Interfaces

We will need a few interfaces; let's start by creating a common folder containing all of our basic modules, then create another folder called types which will contain all our types and interfaces then create a new typescript I will name BlogInterfaces ; now let the first interface, which is going to IBlogIdentification and it will contain our identification field; in our case, it's the id of the blog post.

export interface IBlogIdentification {
    id: string
}

Next, we need an interface to hold the blog fields' title, description, and body; name it IBlogFields.

export interface IBlogFields {
    title: string,
    description: string,
    body: string
}

Next, we need an interface for blog attributes we will receive from the GraphQL query; name it IBlogAttributes.

export interface IBlogAttributes {
    attributes: Partial<IBlogFields> & Pick<IBlogFields, 'title'>
}

I have used Partial and Pick utility types to make all of IBlogFields fields optional except title.

Lastly, we will need an interface to handle the whole blog entry; name it IBlog.

export interface IBlog extends IBlogIdentification, IBlogAttributes{}

Now let's update the Props interface on the blog page.

interface Props {
    blogs: IBlog[]
}

GraphQL Works

Before we start fetching data, we need to do GraphQL Works. First, we need to install two packages to be able to interact with GraphQL; we will need the graphql and @apollo/client packages.

npm i graphql, @apollo/client

Second, we need to write the queries; we will need three queries, the first to list blogs, the second is to get a single blog, and the third is to get the list of blog Ids'; in the common folder, create a new folder and call it graphql, then create a new file and call it queries.tsx, and add the following queries.

export const LIST_BLOG = gql(`query {
  blogPosts {
    data {
      id
      attributes {
        title
      }
    }
  }
}`)

export const SINGLE_BLOG = gql(`query ($blogId: string!) {
  blogPosts(filters: {id: {eq: $blogId}}) {
    data {
      id
      attributes {
        title
        description
        body
      }
    }
  }
}`)

export const LIST_ID = gql(`query {
  blogPosts {
    data {
      id
    }
  }
}`)

The third thing we need is to store Strapi's address, and the most convenient way is to store it inside the env variables; NextJS already comes with a built-in environment variable module, so there is no need to install dotenv, all we need to do is to go to next-config.js, and add the following export.

module.exports = {
  env: {
    STRAPI_ADDRESS: "http://127.0.0.1:1337/graphql"
  },
  nextConfig,
}

And the last thing we need is an ApolloClient to be to connect with the GraphQL server, inside the graphql folder, create a new file and name it client.tsx, then add the following code.

import {ApolloClient, InMemoryCache, NormalizedCacheObject} from "@apollo/client";

const client: ApolloClient<NormalizedCacheObject> = new ApolloClient({
    uri: process.env.STRAPI_ADDRESS,
    cache: new InMemoryCache(),
});

export default client;

Note: the cache is a way for the ApolloClient to cache results, it's a big topic and out of scope for this post. More info can be found here.

Fetching Data

Now we can start implementing the fetching procedure; let's start by creating the getStaticProps function:

export const getStaticProps: GetStaticProps<Props> = async () => {

}

We are going to use getStaticProps because it will pre-render the page at build time, and the data will not be changing consistently; there is no need to send a request to our CMS every time.

Now we can start querying Strapi; let's get a list of blogs.

    const {data} = await client.query({query: LIST_BLOG})
    const blogs: IBlog[] = data.blogPosts.data;

    return {
        props: {
            blogs
        }
    }

Displaying Blog List

Now that we can retrieve a list of blogs, we can start displaying them; we need new folders. To make it easier, I will show a demo below of my project structure.

common
--elements
----blog
------BlogTitle.tsx

modules
--blog
----BlogCardList.tsx

We need two files, BlogTitle will render the title of a blog, and BlogCardList will use BlogTitle to render a list of blogs, let's start with BlogTitle.

interface Props {
    title: string
    isClickable: boolean
    blogId?: string
}

const BlogTitle: NextPage<Props> = ({title, isClickable, blogId}) => {
    if(isClickable && blogId) {
        return (
            <Link href={`/blog/${blogId}`}>{title}</Link>   
        )
    } else {
        return (
            <p>{title}</p>
        )
    }
}

Note: Because I know in the commercial version, I will be using the blog title in multiple locations, and it will have more props and functionality attached to it, I chose to make the blog title a separate component; however, you can choose not to.

Now to the list of cards.

interface Props {
    blogs: IBlog[]
}

const BlogCardList: NextPage<Props> = ({blogs}) => {
    return (
        <div>
            {blogs.map((blog, i) => {
                return (
                    <div key={i}>
                        <BlogTitle 
                            title={blog.attributes.title} 
                            isClickable={true} 
                            blogId={blog.id}
                        />
                    </div>
                );
            })}
        </div>
    )
}

export default BlogCardList;

Now to show the list, we need to add BlogCardList to about page.

const Blog: NextPage<Props> = ({blogs}) => {
    return (
        <BlogCardList blogs={blogs}/>
    )
}

Now if we go to /blog, we should see a list of blog titles.

Displaying A Single Blog Post

Let's start creating the individual blog post page, create a new file, and call it [id].tsx inside the blog directory inside the pages directory, initialize a new basic react component.

import {NextPage} from "next";
import {IBlog} from "@/common/types/BlogInterfaces";

interface Props {
    blog: IBlog
}

const client = new ApolloClient({
    uri: process.env.STRAPI_ADDRESS,
    cache: new InMemoryCache()
});

const Blog: NextPage<Props> = ({blog}) => {
    return (
        <p>Blog Here<p/>
    )
}

export default Blog;

We are going to utilize NextJS's getStaticPaths and getStaticProps functions, more info can be found here.

export const getStaticPaths: GetStaticPaths = async () => {
    const {data} = await client.query({query: LIST_ID })
    const ids: IBlogIdentification[] = data.blogPosts.data;

    const paths = ids.map(id => {
        return {params: {...id}}
    })

    return {
        paths,
        fallback: true
    }
}

export const getStaticProps: GetStaticProps<Props> = async ({params}) => {
    console.log()
    const {data} = await client.query({query: SINGLE_BLOG, variables: {blogId: params!.id}})
    const blog: IBlog = data.blogPosts.data[0];

    return {
        props: {
            blog
        }
    }
}

And now, we can access the blog data inside the component.

const Blog: NextPage<Props> = ({blog}) => {
    console.log(blog)
    return (
        <div>
            <p>{blog.id}</p>
            <p>{blog.attributes.title}</p>
            <p>{blog.attributes.description}</p>
            <p>{blog.attributes.body}</p>
        </div>
    )
}

Now our blog is functional; we can retrieve and display a list of blogs and a single blog post.

Upgrade Your Development Skills: Introduction to SOLID Principles

Dev Kadiem — Thu, 26 Jan 2023 08:26:56 +0000

A clear distinction between junior and senior developers is how well senior developers future-proof their programs; one way of achieving this is to use a well-known code or rules, like SOLID principles, which Robert C. Martin developed in his essay, "Design Principles and Design Patterns."

SOLID is an acronym for single responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion principle, and it's important to state that SOLID is mainly for OOP.

It's important to recall that this is an introduction; thus, I will use easy scenarios, and the examples shown are for learning purposes only and not for commercial use. Lastly, I'll use sudo code to make it reachable to most people.

Single Responsibility Principle

The single responsibility principle states, "A class should have only one reason to change." According to the previous state, each class is responsible for only one part during the software lifespan.

To kick off the article, I'll create a simple User class:

class User {
    function profile()
    function login()
    function register()
    function sendVerificationEmail()
}

As we can see, the class is responsible for more than one part, and my way of applying the principles is the following:

class User {
    function profile()
}

class Authentication {
    function login()
}

class Signup {
    function register()
    function sendVerificationEmail()
}

We now have three classes, each responsible for only one part.

Open Closed Principle

The open-closed principle states, "A class should be open to extension but closed to modifying." According to the previous state, each class should be written in a way that allows the addition of functionality but does not allow alteration of its core.

To demonstrate a demo of this principle, I'll create another User class but this time, it will have a variable called type:

class User {
    var type

    constructor(var type) {
        this.type = type
    }

    function doSomething() {
      if(type == "normal") {
        // ...
      } else if(type == "professional") {
        // ...
      }
    }

    // ...
}

User normalUser = new User("normal")
User professionalUser = new User("professional")

The class is open for modification because type has a direct influence on the class's functionality; this is an example of why we need the open-closed principle. Let's see an example of how to apply the principle here:

abstract class User {
    abstract function doSomething()
}

class NormalUser Inherits User {
    function doSomething() {
      // ...
    }
}

class ProfessionalUser Inherits User {
    function doSomething() {
      // ...
    }
}

User normalUser = new NormalUser()
User professionalUser = new ProfessionalUser()

By implementing the principle, we can write a more precise functionality.

Liskov Substitution Principle

The Liskov substitution principle states, "if S is a subtype of T, then objects of type T may be replaced with objects of type S" Liskov substitution is better explained with an example:

abstract class Employee {
    abstract function getBonus()
}

class HardWorkingEmployee Inherits Employee {
    function getBonus() {
        // ...
    }
}

class LackingEmployee Inherits Employee {
    function getBonus() {
        Error
    }
}

And now, to instantiate an instance of HardWorkingEmployee class:

Employee employee = new HardWorkingEmloyee()
employee.getBonus()

The example above would work perfectly, now let's change HardWorkingEmployee with LackingEmployee:

employee = new LackingEmployee()
employee.getBonus()

The example above would not work because, LackingEmployee does not implement bonus function, even though they both are of type Employee, and that is a violation of the Liskov Substitution; an easy fix for this situation is the following:

abstract class Employee {
    // ...
}

interface EligableForBonus {
    function getBonus()
}

class HardWorkingEmployee Inherits Employee, EligableForBonus {
    function getBonus() {
        // ...
    }
}

class LackingEmployee Inherits Employee {
    // ...
}

Now LackingEmployee does not inherit any non-implemented functionality.

Interface Segregation Principle

The interface segregation principle states, "Clients should not be forced to depend upon interfaces that they do not use." It means that when a class inherits a parent, it should implement all of its functionality.

interface UserFunctions {
    function function1()
    function function2()
    function function3()
    function function4()
}

class User inherits UserFunctions {
    function function1() {
      // ..
    }

    function function2() {
      // ..
    }

    function function3() {
      // ..
    }

    function function4() {
      Error
    }
}

The User class does not implement function4 and thus, it violates the interface segregation principle; one way of fixing it is the following:

interface CoreUserFunctions {
    function function1()
    function function2()
    function function3()
}

interface ExtraUserFunctions {
    function function4()
}

class BasicUser inherits UserFunctions {
    function function1() {
      // ..
    }

    function function2() {
      // ..
    }

    function function3() {
      // ..
    }
}

class UpgradedUser inherits UserFunctions, ExtraUserFunctions {
    function function1() {
      // ..
    }

    function function2() {
      // ..
    }

    function function3() {
      // ..
    }

    function function4() {
      // ..
    }
}

Now we have BasicUser and UpgradedUser and both fully implement what they inherit.

Dependency Inversion Principle

The Dependency Inversion Principle states, "The interaction between high level and low level modules should be thought of as an abstract interaction between them." It means that if we have interactions between high-level and low-level modules or classes, we should add a middle layer because they both operate at different levels of complexity.

class DataAccesslayer {
    function saveToDatabase(data) {
        // ...
    }
}

class User {
    DataAccesslayer dataAccesslayer
    dataAccesslayer.saveToDatabase(data)
}

The example above does not implement the Dependency inversion principle, thus any modification to DataAccessLayer might means we need to modify User class also, a better implementation would be like this:

interface DataAccesslayerInterface {
    function saveToDatabase(data)
}

class DataAccesslayer inherits DataAccesslayerInterface {
    function saveToDatabase(data) {
        // ...
    }
}

class User {
    DataAccesslayerInterface dataAccesslayer
    dataAccesslayer.saveToDatabase(data)
}

Now we have an abstraction layer, which means that modification on DataAccesslayer will no longer need modification on User class because the abstraction layer does not change; thus function signature does not change

Python Django: Create a more secure database by using a custom field

Dev Kadiem — Tue, 17 Jan 2023 17:19:05 +0000

One way of enhancing the security of a database is by encrypting it. Luckily by utilizing Django, we can do this automatically. We only need the signing and models packages from the core Django packages.

Let's start by importing the required packages:

from django.core import signing
from django.db.models import TextField

First, the signing is a cryptographic signing package; it allows encrypting and decrypting using the SECRET_KEY found in settings.py; more info can be found at the bottom, and we need the TextField because we will extend the default one with more functionality.

Now let's create and init the new field. I'll name it EncryptedTextField:

class EncryptedTextField(models.TextField):
    def __init__(self, *args, **kwargs):
        super(EncryptedTextField, self).__init__(*args, **kwargs)

Now for the encrypting part:

    def get_db_prep_save(self, value, connection):
        value = super().get_db_prep_value(value, connection)
        if value is None:
            return value

        if len(value) == 0:
            return value

        return ((signing.dumps(str(value))).encode('utf-8')).decode('utf-8')

The get_db_prep_save is a function that runs when we try to save data to the database; we are getting the raw data by get_db_prep_value and then return an encrypted version of it return ((signing.dumps(str(value))).encode('utf-8')).decode('utf-8'). More info can be found at the bottom.

Now for the decrypting part:

    def from_db_value(self, value, *args, **kwargs):
        if value is None:
            return value

        if len(value) == 0:
            return value

        return signing.loads(value)

The def from_db_value is a function that runs when we try to get data from the database, value here represents the encrypted data, so we need to decrypt it, which is done here return signing.loads(value). More info can be found at the bottom.

Example of usage:

public_api = EncryptedTextField()

Example of a full code:

from django.db.models import TextField
from django.core import signing

class EncryptedTextField(models.TextField):
    def __init__(self, *args, **kwargs):
        super(EncryptedTextField, self).__init__(*args, **kwargs)

    def get_db_prep_save(self, value, connection):
        value = super().get_db_prep_value(value, connection)
        if value is None:
            return value

        if len(value) == 0:
            return value

        return ((signing.dumps(str(value))).encode('utf-8')).decode('utf-8')

    def to_python(self, value):
        return value

    def from_db_value(self, value, *args, **kwargs):
        if value is None:
            return value

        if len(value) == 0:
            return value
        return signing.loads(value)

Links to more info:

The signing package: https://docs.djangoproject.com/en/4.1/topics/signing/
The get_db_prep_save function:
https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.get_db_prep_save
The from_db_value function:
https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.Field.from_db_value

Do you know why array[index] is n(1)?

Dev Kadiem — Mon, 16 Jan 2023 16:14:29 +0000

When I started working in web development, I had no idea why array[index] is n(1) because I was primarily working with high-level languages, and the mystery carried on with me until I started working with low-level language Rust.

To answer why it's n(1), we must first understand what a pointer is: an object that stores a memory address. Thus when we use a pointer, we are accessing a memory location rather than the underlying data.

As for the array data structure, an array is a collection of elements stored in a contiguous memory location; it fulfills an entire row of memory addresses with no spaces or gaps between elements.

Now that we have defined what a pointer and array are, it won't be a surprise when I say that when we instantiate an array, we create a pointer (The naming differs between languages)

let arr = [1,2,3,4,5]

Now that we know that arr is a pointer (with extra data like length, size), it's safe to say that arr is pointing to the memory address of the first element of the array. In other words, the memory address of arr and the memory address of arr[0] is the same.

Lastly, an example would make everything clear. Let's say that arr is in memory location 10, which means that the first element is also in memory location 10; now, assuming that Number in Javascript is 8 Bytes, the second element will be in location 18, and the third will be in 26.

arr[0] -> stored in memory location 10
arr[1] -> stored in memory location 18
arr[2] -> stored in memory location 26

And that is why array[index] is n(1) because all we need to get is the memory location of the first element + (Data size in bytes * index).