DEV Community: gisellec60

Shortcuts

gisellec60 — Sat, 17 Aug 2024 17:34:57 +0000

Fetch API

gisellec60 — Mon, 09 Oct 2023 00:27:50 +0000

Fetch API - One of the requirements for my phase-5 capstone project with FlatIron School was to write a technical blog. I could'nt decide what to write about since the list of topics seemed endless. However, as I began to develop my app, I found myself running into problems with handling responses coming Fetch API. It didn't take long for me to realize I didn't understand how it worked. I knew there was something called the promise and it had something to do with response ojects being return and .then() running aftwards, but I was just fudging my way through, throwing code and the wall and seeing what stuck so to speak. I found I was taking so much time working through those errors that it chewed up precious time better spent writing and perfecting functionality. Hence, The Promise...Then

Fetch API
Fetch API is an interface to getting or fetching resources. Fetch() requires one argument which is the path to the resource you want to fetch. It's a powerful way to make HTTP request in Javascript.

Promises:
A promise is an JavaScript object that represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

A Promise may have one of three states:

Pending: The initial state; neither filled nor rejected.
Fulfilled : The operation completed sucessfully and the resulting value is available
Rejected: The operation failed, and an error reason is available.

A promise starts in a pending state. That means the process is not complete. If the operation is successful, the process ends in a fulfilled state. And, if an error occurs, the process ends in a rejected state.

For example, when you request data from the server by using a promise, it will be in a pending state. When the data arrives successfully, it will be in a fulfilled state. If an error occurs, then it will be in a rejected state. You can attach callbacks to a Promise using the .then() and .catch() methods. The .then() method is called when the Promise is fulfilled, while the .catch() method is called when the Promise is rejected.

In my research I found there's alot that can be said about promises. You can actually create them but that's beyond the scope of this blog. Right now I want to discuss how to make use of them in conjunction with Fetch API!!! So let's get to it!!!

Using the Fetch API
The Fetch API really is simple to use. You call fetch() and provide the url of the resource you're trying to fetch. The fetch() returns a promise that resovles to a response object.

fetch('https://api.example.com/data')
  .then(response => {
    console.log(response);
  })
  .catch(error => {
    console.error('Error fetching data:', error);
  });

In the example above, we are fetching data from https://api.example.com/data. The fetch() method returns a Promise(* in the fulfilled state that resovles to a response*), and we are using the .then() method to handle the successful response and the .catch() method to handle any errors.

The Response object that we receive in the .then(response) method contains several properties and methods that can be used to extract the data from the response object. Some of the most commonly used properties and methods are as follows:

response.ok: A boolean value that indicates whether the request was successful (status code in the range 200-299) or not.
response.status: The status code of the response (e.g., 200, 404, 500, etc.).
response.statusText: A status message corresponding to the status code (e.g., "OK", "Not Found", "Internal Server Error", etc.).
response.headers: An object representing the headers of the response.
response.json(): A method that returns a Promise that resolves to the JSON object resulting from parsing the response's body text as JSON.
response.text(): A method that returns a Promise that resolves to the response's body text as a string.

        fetch(`/dancers/${values["email"]}?action=none`)
        .then(res => {
            if (!res.ok){ 
                throw new Error('Network response was not ok');
             }
             return Response.json() //Returns a promise that resolves to Json data
            })    
        .then((dancer) => {     
            setDancer(dancer)
            handleShowDancer()
        }) 
        .catch(error => {
            console.log("Error Returned",error);    
            // onError(error) 
            setError(error)
        })
    }

In this example (using code from my app), we first check if the response.ok property is true. If it is not, we throw an error that will be caught by the .catch() method. Otherwise, we call the response.json() method, which returns a Promise that resolves to a response that is then resolved to the JSON data. We then use another .then() method to handle the JSON data.

The idea that we can fetch data in other formats, like text and binary data(images, audio, files etc) also intrigued me.

fetch('https://api.example.com/data.txt')
  .then(response => {
    if (!response.ok) {
      throw new Error('Network response was not ok');
    }
    return response.text(); // text instead of json
  })
  .then(text => {
    console.log(text);
  })
  .catch(error => {
    console.error('Error fetching data:', error);
  });

Fetch with Async/Await
Another technique I've been very curious about is Async/Await. This is another way I've seen the fetch method used. According to the documentation I just read we:

Declare an async function. This tells JavaScript that the function will contain asynchronous code.
Inside the async function, use the await keyword before calling the fetch() method. This tells JavaScript to wait for the Promise to resolve before continuing with the rest of the code.
Use try/catch blocks to handle errors.

async function fetchData() {
  try {
    const response = await fetch('https://api.example.com/data');
    if (!response.ok) {
      throw new Error('Network response was not ok');
    }
    const data = await response.json();
    console.log(data);
  } catch (error) {
    console.error('Error fetching data:', error);
  }
}

fetchData();

So we declare an async function called fetchData. Inside the function, we use the await keyword before calling the fetch() method and the response.json.

Giselle Smith is a FullStack Software Developer Engineer student at Flatiron School

References:
Asynchronous JavaScript for Beginners
How to use promises
https://www.altcademy.com/blog/how-to-use-the-javascript-fetch-api-to-get-data/

The Scheduler

gisellec60 — Thu, 24 Aug 2023 20:14:14 +0000

The Scheduler was born out of the need for a more robust volunteer scheduling system for my church. The app manages the scheduling of the volunteers by enabling a user to add, modify, and delete a volunteer or schedule, and query the schedule by date or username. Ideally only people with admin privileges will be able to make any changes to the schedule, but everyone will be able to query the schedule. Currently there are no admin privileges set for the app so everyone has full access.

The Scheduler consist of 4 tables:

Volunteer
Schedule
Role
Volunteers_Role

Diagram table relationships:

fig(1)

Schedule

class Schedule(Base):
    __tablename__ = 'schedules'

    id = Column(Integer, primary_key=True)
    date = Column(DATE, nullable=False)
    swappout_id = Column(Integer,nullable=True)

    vol_id = Column(Integer, ForeignKey('volunteers.id'))
    role_id = Column(Integer, ForeignKey('roles.id'))

fig(2)

Because Schedule has a one-to-many relationship with Volunter and Role, foreign keys were created for both tables to manage the relationship

Example One-to-Many

ipdb>    schedule = session.query(Schedule).filter(Schedule.date == "2023-08-16").all()

ipdb> schedule
[Schedule: 3, Swapped: 19, Volunteer: 5, Role: 4, Date: 2023-08-16 , Schedule: 29, Swapped: , Volunteer: 7, Role: 2, Date: 2023-08-16 ]

ipdb> [sched.vol_id for sched in schedule]
[5, 7]

ipdb>  [sched.role_id for sched in schedule]
[4, 2]

Because schedule object returned a list (one-to-many) I iterated over the list using a list comprehension to pull out the volunteer ids. Notice that one instance of schedule also return multiple role ids.

Volunteer

fig(3)

class Volunteer(Base,Validate):
    __tablename__ = "volunteers"

    id = Column(Integer, primary_key=True)
    first_name = Column(String, nullable=False)
    last_name = Column(String, nullable=False)

    email = Column(String, unique=True)
    phone = Column(String, nullable=False)
    username = Column(String, unique=True)
    floater = Column (Boolean, nullable=False)
    week = Column(Integer, nullable=False)
    assigned = Column(String, nullable=False)

    roles = relationship('Role', secondary='volunteer_role',
                          back_populates='volunteers')
    schedules = relationship('Schedule', backref=backref('volunteer'))

Besides a primary key the volunteer table has two relational fields. roles is used for managing the relationship between the Role and Volunteer tables through the association table, Volunteers_Role. This is necessary because of the many-to-many relationship between Volunteer and Role. When dealing with a many-to-many relationship it is necessary to have an intermediary table to connect the two tables. back_populates is a relational parameter that tells sqlalchemy to link the volunteer table to the role table.

Schedule has a one-to-many relationship with Volunteer so the schedules relational field is used to manage that relationship.

fig(4)

Role

fig(5)

class Role(Base):
    __tablename__ = 'roles'

    id = Column(Integer, primary_key=True)
    position = Column(String, nullable=False)

    volunteers = relationship('Volunteer', secondary='volunteer_role',
                          back_populates='roles')
    schedules = relationship('Schedule', backref=backref('role'))

Like the Volunteer table the Role table has two relational fields. volunteers which manages the relatationship between Role and Volunteer through the association table Volunteer_Role. Also like the Volunteer table sqlalchemy uses the back_populates parameter to point roles back to volunteers.

Also like the Volunteer table, schedules is used to manage the one-to-many relationship between Schedule and the Role tables.

fig(6)

Volunter_Role

volunteer_role = Table (
     'volunteer_role',
     Base.metadata,
     Column('vol_id', ForeignKey('volunteers.id')),
     Column('role_id', ForeignKey('roles.id'))
)

Because the volunteer_role table is the association table that manages the many-to-many relationship between volunteers and roles you will see that some volunteers (vol_ids) are in the table more than once. You can also role_ids are in this table multiple times.

So in the Volunteer table back_populates links role back to volunteer and in the Role table back_populate links volunteer to role. They have what we call a bi-directional relationship with each returning a collection of the other.

fig(7)

Example: Many-to-Many
fig(8)

ipdb> volunteer.username
'Laura_Beltran'

ipdb> volunteer.roles
[Role id: 2, Position: usher , Role id: 4, Position: prayer ]
ipdb>

An instance of volunteer can have many roles. Notice volunteer is using the roles relational attribute to list all the roles pertaining to the volunteer Lauar_Beltran.

A role can have many volunteers
fig(9)

ipdb> role.position
'greeter'
ipdb>
ipdb> [role.username for role in role.volunteers]
['Victoria_Romero', 'Samuel_Mcclain', 'Emily_Wallace', 'Rodney_Woods']
ipdb>

As you can see an instance of role can return many volunteers. Notice role is using the volunteers relational attribute to list all the volunteers who are prayers.

Now that we see how the tables relate to each other, lets take a closer look at The Scheduler

The Scheduler

The Scheduler is a Command Line Interface or CLI app, enabling the user to interact with it from the command line. The cli file that envokes the scheduler is...wait for it...scheduling.py

fig(10)

Ok, I can see you're not impressed, so lets take a look at what it does and see if we can change your mind!

fig(11)

Because the The Scheduler is a cli the interface is very simple but effective. It begins with a menu that allows you to select the action you want to perform.

Add Volunteer

fig(12)

When the user selects Add Volunteer they are taken to the "Add Volunteer" screen where they are prompted to enter specific information about the volunteer. Notice at every prompt is the opportunity to quit the application by hitting x except the last prompt, that's because by then the user is most likely commited to the process.

It finishes by displaying a message containing the user's full name, username which is created internally, and the role they'll be serving in. The user then hits enter to exit and return to the menu.

Notice Tom Cruise #41 in the volunteer database:

fig(13)

The Scheduler uses the ORM (Object Relational Mapper), SQLAlchemy with Python to make this all happen. Now let's take a look at the code that makes up the Add Volunteer method.

Note: The CLI code for this app is pretty big because of all the validation that takes place, so because of that I'm going to limit the code shown to just the sqlalchemy.

With that said lets get to it!!!

The CLI does the job of validating each attribute below. Once it's satisfied all the data entered is valid it calls the add_volunteer method. The usernamne is generated by putting an "_" between the first and last name. As you'll see later on the usernamne is used extensivley to identify the volunteer so it needs to be unique. Because the possibility of having more than one person with the same first and last name is very high, the add_volunteer method checks to see if it exist, if it does it appends a random interger between 1-50 to the username.

fig(14)

def add_volunteer(fname, lname, email, phone, floater, week, position="prayer"):
            username = f"{fname}_{lname}"
            username_exist = session.query(Volunteer).filter(Volunteer.username == username).first()
            if username_exist:
                username = username + "_" + str(random.randint(1,50))  
            assigned = "No"  
            role = session.query(Role).filter(Role.position == position).first()
            volunteer = Volunteer(
                     first_name = fname, 
                     last_name = lname,
                     email = email,
                     phone = phone,
                     username = username,
                     floater = floater,
                     week = week,
                     assigned = assigned
            )
            session.add(volunteer)
            volunteer.roles.append(role)
            session.commit()
            return volunteer

volunteer.roles.append(role)
Using the relationship attributes on the volunteer and role tables the Volunteer_Role table is populated.

Delete Volunteer

Tom Cruise has become very busy working on "Mission Impossible: Maverick" so we're going to remove him and give him the space he needs to film the movie.

fig(15)

As you can see Tom has been removed and free to persue his acting career.

fig(16)

After all the validation is done the cli calls the delete_volunteer method.

Get Tom's information from the volunteer table,
Tom role association is removed from Volunteer_Role
if Tom is on the schedule that schedule instance is removed.
Tom is removed from the volunteer table

fig(17)

def delete_volunteer(username):
        volunteer = session.query(Volunteer).filter(
                    Volunteer.username == username).first()

        # Delete Volunteer _Role association from volunteer_role table
        [volunteer.roles.remove(role) for role in volunteer.roles]

        # Delete volunteer from schedule
        if volunteer.schedules:
            [session.delete(schedule) for schedule in volunteer.schedules]

        # Delete Volunteer
        session.delete(volunteer)
        session.commit()

fig(18)

if volunteer.schedules:
            [session.delete(schedule) for schedule in volunteer.schedules]

Fig(18) shows the one-to-many relationship between the volunteer and the schedule. The schedules side of the relationship produces a collection, in this case is a list, that's then iterated over to get the needed information.

Modify Volunteer

Mary Spalding has just been married and wants to change her last name, email handle and role.

What you see below is the purpose of the Volunteer_Role table. Mary's id is 44 and right now she's an usher and the usher id is 2. So the association table (Volunteer_Role) is associating Mary's id with the usher id.

fig(19)

fig(20)

Here we see Mary stepping through the prompts. We her changing her last name to Spalding-Wilson and her email to spalding-wilson@gmail.com

fig(21)

Notice Mary's current role as usher is listed. It's important to remember there is no foreign key for role.id in the Volunteer table. The Scheduler is able to list the usher in association with Mary because of the Volunteer_Role table and the relational parameters provided to both tables.

fig(22)

The Scheduler is processing the changes and prints the message "Change was successful". The user then hits enter to exit and return to the menu.

Now let's take a look at the database.

Volunteer_Role:
Mary's role association has changed from 2 (usher) to 1 (greeter)

fig(23)

Volunteer
Mary's last name changed to Spalding-Wilson and her email changed to spalding_wilson@gmail.com

fig(24)

All the changes have been persisted to the database!

fig(25)

Ahem...the code...

During the validation phase the cli collects all the validate information into an object called changes using "role" as the key and "value" as the value. The object is then passed to the modify_volunteer method along with the usernamne. Using the items() object method, it's loop through changing the information based on the role passed in. If the role is being changed then we have to modify the Volunteer_Role table by removing the association to the old role and adding an association to the new role. This is how we're able to see the role changed from 2 to 1 in the fig(19) and fig(23) above.

 def modify_volunteer(username, changes):
        volunteer=session.query(Volunteer).filter(Volunteer.username == username).first()
        for key,value in changes.items():
            if key == "role":
               role = session.query(Role).filter(Role.position == value).first()
               volunteer.roles.append(role)
            if key == 'old':
               for role in volunteer.roles:
                   if role.position == value:
                      volunteer.roles.remove(role)
            setattr(volunteer,key,value)
        session.commit()
        return volunteer

Add to Schedule

Let's add Mary to the schedule.

fig(26)

Hmmm... looks like someone forgot Mary is not longer an usher . Remember she changed her role to greeter fig(23).

fig(27)

Mary Spalding has been successfully added to the schedule.
Let's check the Schedule table to make sure change was persisted to the database

fig(28)

Remember the Schedule contains two foreign keys; one for Role and one for Volunteer fig(2). Mary's id, 44 and the role id for greeter which is 1. We see the date is the date entered, 2023-09-03.

CLI validates information entered by user and then passes it to the add_to_schedule method. The datetime.strptim method is used to convert the date to a python format. The method get an instance of th volunteer and role and useed them to create an instance of a schedule thats then added to the schedule table.

fig(29)

def add_to_schedule(username,position,input_date):

        schedule_date = datetime.strptime(input_date, '%Y-%m-%d').date()

        volunteer = session.query(Volunteer).filter(Volunteer.username == username).one()
        role = session.query(Role).filter(Role.position == position).one()

        schedule = Schedule(
            date = schedule_date,
            vol_id = volunteer.id,
            role_id = role.id
        )
        volunteer.assigned = "Yes"
        session.commit()
        session.add(schedule)
        session.commit()

Modify Schedule

Mary has decided she will not be in church on Sep 3 so she'll need to change the date.

fig(30)

Now let's check the Schedule to make sure the date has been changed.

fig(31)

Yes! The date was changed from 2023-09-03 to 2023-09-10.
Make note of the shedule id 54

Once again CLI validation is complete and informaion is passed to the modify_schedule.

date is converted to python
get an instance of the role passed in
get an instance of the volunteer passed in
filter on the above information we get an schedule object

Just like we did for modify_volunteer we use the object changes to store the "change data" in key value pairs. Using a for loop we interate over the object using the items() method to seperate the key value pairs. Changes are made based on the key and value stored.

fig(32)

def modify_schedule(username, input_date, role, changes):

        schedule_date = datetime.strptime(input_date, '%Y-%m-%d').date()
        role = session.query(Role).filter(Role.position == role).first()
        volunteer=session.query(Volunteer).filter(Volunteer.username == username).first()

        schedule = session.query(Schedule).filter(Schedule.vol_id == volunteer.id,
               Schedule.date == schedule_date, Schedule.role_id == role.id).first()

        for key,value in changes.items():
            if key == "username":
               user = session.query(Volunteer).filter(Volunteer.username == value ).first()
               print(green(f'\nchanging username from {username} to {value}...\n')) 
               schedule.vol_id=user.id
            elif key == "role":
                new_role = session.query(Role).filter(Role.position == value ).first()
                print(green(f'\nchanging role from {role.position} to {new_role.position}...\n')) 
                schedule.role_id=new_role.id
            else:
                new_date = datetime.strptime(value,'%Y-%m-%d').date()
                print(green(f'\nchanging date from {schedule_date} to {new_date}...\n')) 
                schedule.date=new_date

Delete Schedule

Mary decided she wants to be removed from the schedule for that day.

fig(33)

Someone forgot Mary had previously changed her date from Sept 3 to Sept 10. fig(31)

fig(34)

Schedule was removed for Mary for Sep 10, 2023.

fig(35)

Notice the schedule id 54 has been removede from the schedule table.

As my husband likes to say...Good Stuff!!!

You see the CLI validation at work in fig(33). The CLI first checked to see if Mary had a schedule for that date. Using a list comprehension we look over the list produced by volunteer.schedules checking the date and removing it when we find a match. Because a volunteer can have more than one schedule we check to see if this is the only schedule by checking the size of the list. If the size = 1 then we know thats the only schedule and we can change the volunteer's assigned status to "No".

fig(36)

def delete_schedule(username, input_date):
        schedule_date = datetime.strptime(input_date, '%Y-%m-%d').date()
        volunteer = session.query(Volunteer).filter(Volunteer.username == username).first()
        [session.delete(schedule) for schedule in volunteer.schedules if schedule.date == schedule_date]
        if(len(volunteer.schedules) == 1 ):
            volunteer.assigned = "No"
        print(f"Removing {volunteer.first_name} {volunteer.last_name} from the schedule for {input_date}... ")
        session.commit()

## Query Schedule by Date

Let's see if anyone else is scheduled for Sep 10, 2023:

fig(37)

After validation the date is passed into query_by_date(). The date is pythonized (I'm sure that's not a word). We get a list of all the schedules that match that date. If the list size == 0 then we know there are no schedules for that date else we loop through the list creating a volunteer and role object for each schedule in the list and print them out.

fig(38)

    def query_by_date(input_date):
        schedule_date = datetime.strptime(input_date, '%Y-%m-%d').date()
        schedules = session.query(Schedule).filter(Schedule.date == schedule_date).all()

        if len(schedules) == 0:
            print (red(f"\nSchedule date: {input_date}\n"))
            print (red("<---No schedule--->"))
        else:  
            print (green(f"\nSchedule date: {input_date}\n"))  
            for schedule in schedules:
                volunteer = session.query(Volunteer).filter(Volunteer.id == schedule.vol_id).first()
                role = session.query(Role).filter(Role.id == schedule.role_id).first()
                print (green(f"{volunteer.first_name} {volunteer.last_name}: {role.position}"))

Let's use a date that actually has somone scheduled:

fig(39)

Query Schedule by Name

Now let see if Mary is on the schedule

fig(40)

Oops! I misspelled her name but the app allowed me to re-enter. As we see Mary does is not on the schedule at all.

Again we see CLI validation at work. I misspelled her name and the CLI caught by checking if the user existed.

Lets see if Kara Rivera is scheduled to serve:

Here the one-to-many relationship is clearly seen between the volunteer and the schedule and the role and the schedule . Kara is serving in multiple roles on multiple dates.

We saw the CLI doing it job validating the information enter in fig(40). We create an object for the username and an object for all volunteers. If the volunteer is not assigned, no need to go any further and we print the full name and the message "No schedule" else let's see if I remember what I did here and why:
for each schedule in the list of schedules for the username were going to
going loop through the roles to see if the role_id matchs the schedule.role_id
Then we check if there is a swappout_id (I'll get to that)
if there is a swappout_id were going to loop through all the volunteers to get the name that matches the swappout.id and print that information out with swappout information
if no swappout_id print without the swappout information.

def query_by_name(username):
        volunteer = session.query(Volunteer).filter(Volunteer.username == username).first()  
        volunteers = session.query(Volunteer).all()
        roles = session.query(Role).all()

        if volunteer.assigned == "No":
            print(red(f"\n{volunteer.first_name} {volunteer.last_name} \n"))
            print (red("<---No schedule--->"))
        else:
            print(green(f"\n{volunteer.first_name} {volunteer.last_name} \n"))
            for schedule in volunteer.schedules:
                for role in roles:
                    if role.id == schedule.role_id:
                        if schedule.swappout_id:
                            for vol in volunteers:
                                if vol.id == schedule.swappout_id:
                                    print(schedule.date.strftime("%B %d, %Y"),":" + role.position, "<" + vol.username + ">")
                        else:
                            print(schedule.date.strftime("%B %d, %Y"), ":" + role.position)

Swap - Notice the schedule has a swapp_id field. Sometimes volunteers swap dates. For historical purposes swapp0ut_id holds the id of the volunteer who was swapped out.

Giselle Smith

Giselle is a Software Development Engineer FullStack studying at FlatIron School.

Resources:
Disappointed Face: https://gifdb.com/gif/disappointed-face-boy-blink-g97pz8zfml7oypt1.html

Carlton Dance: https://tenor.com/view/carlton-dance-ya-yes-fresh-prince-of-bel-air-carlton-banks-gif-17061920

useContext

gisellec60 — Sun, 02 Jul 2023 23:00:40 +0000

What is useContext and how do we use it.

I'll have to admit, I have a selfish reason for writing this blog on useContext...it's so I can understand how to use it because I have a feeling I'll need it for my next project.

useContext is another popular hook in react that allows data to be managed globally. It provides the ability to share data through a tree of nested components without passing it manually... a process known as prop drilling.

Let me explain...
Let's say we have a parent and 3 child components and state is set in the parent component. Inorder for child #3 to have access to a value in state set by its parent it would have to be passed down through props to child #1, and child #2 to get to child #3.

import {useState } from "react"

export default function Parent() {

const [fruit, setFruit] = useState("apple")   

return (
  <div>
  <p className="para"> 
     The Parent would love to have an {fruit}
     and give one to Child3. So the Parent will have to pass the    
     fruit to Child1fruit to Child1 who will pass it to Child2 
     who will pass it to Child3 so that Child3 can enjoy the 
     fruit.
  </p> 
     <Child1 fruit={fruit} />
 </div>    

  );
}                                                                          

function Child1 ({fruit}) {
    return (
      <div> 
        <p className="para">fruit passed to Child2  </p> 
        <Child2 fruit={fruit} />
     </div> 
   )
}

function Child2 ({fruit}) {
  return(
    <div>
       <p className="para">fruit passed to Child3  </p> 
       <Child3 fruit={fruit} />
    </div>
  ) 
}

function Child3 ({fruit}) {
  return 
   <p className="para"> Child3 can now enjoy the {fruit}! </p>
}

Output:

Notice the Parent component passes fruit down to Child1 which inturn passes fruit down to Child2 which passes fruit down to Child3, without ever using it. This is the only way the Parent component can get fruit to the Child3 component. This process of passing data down through an heirachy is called prop drilling

This may not look like much of a problem right now, but imagine you have an application with a heirarchy of nested compoenents that runs deep and is complex. Managing such an application can become confusing and hard to maintain. React's answer to this problem is to create context.

Let's redo our example above using the useContext hook:

import {useState, useContext, createContext} from "react"

const FruitContext = createContext("")

export default function Parent() {

  const [fruit, setFruit] = useState("apple")   

  return (
     <div>
        <p className="para"> 
        The Parent would love to have an {fruit} and give one to Child3 without
        going through Child1 and Child2. 
        </p> 
        <FruitContext.Provider value={fruit}> 
           <Child1  /> 
        </FruitContext.Provider>
     </div>    

  );
}
 function Child1 () {
    return (
        <div> 
            <p className="para">Skip Child1  </p> 
            <Child2  />

        </div> 
      )
}
function Child2 () {
  return(
    <div>
       <p className="para">Skip Childl2  </p> 
       <Child3 />

    </div>
  ) 
}

function Child3 () {
  const fruit = useContext(FruitContext);
  return <p className="para"> Child3 can now enjoy the {fruit}! </p>
}

Output

As you can see Child3 has access to fruit without it ever being passed down through the heirarchy of components. Instead of passing fruit down as a prop through the tree, Child3 was able to access fruit by the use of useContext,

A closer look...

Step1 - We create the context object. In the case above the context object is FruitContext.

const FruitContext = createContext("")

Step2 - The context object had a property called the Provider and the provider takes a value which in this case is the state variable fruit. The provider is wrapped around the component at the top of the tree so that every component in the tree from that point on has access to context object.

 export default function Parent() {
     const [fruit, setFruit] = useState("apple")
     return (
     <div>
        <p className="para"> 
         The Parent would love to have an {fruit} and give one to 
         Child3 withoutgoing through Child1 and Child2. 
        </p> 
        <FruitContext.Provider value={fruit}> 
           <Child1  /> 
        </FruitContext.Provider>
     </div>    

  );
 }

I made the statement, The provider is wrapped around the component at the top of the tree so that every component in the tree **from that point on has access to context object.** That's because any component not in the wrapper does not have access to context provider.

Example:

export default function Parent() {
     const [fruit, setFruit] = useState("apple")
     return (
         <ChildA fruit={fruit}  />
         <FruitContext.Provider value={fruit}> 
            <p> The Parent would love to have an {fruit} </p> 
            <Child1 />
         </FruitContext.Provider>
    )
 }

In the example above the ChildA component does not have access to FruitContext. So for ChildA and its children to have access to the state variable fruit it will have to be manually passed down through props.

Ok, moving along...

Step3 - We then use the useContext() hook to gain access to the state variable:

function Child3() {
  const fruit = useContext(FruitContext);
  return <p> fruit prop not passed to Child3 but Child3 has the {fruit} now! </p>
}

Imagine...
You have a component tree that runs 26 components deep(ChildA-ChildZ) and during development you decide that the Parent and ChildZ need to share a state varaible. Without creating context you would have to manually pass the state variable through each component starting at ChildA down through ChildZ. That's 26 levels deep for those of us counting.

export default function Parent() {
     const [fruit, setFruit] = useState("apple")
      return (
         <p> The Parent would love to have an {fruit} </p> 
         <ChildA fruit={fruit}/>
     )  
 }

// Components ChildB({fruit})-ChildY({fruit}) 

function ChildZ({fruit}) {
   return <p>ChildZ has the {fruit} now! </p>
}

However, by creating context you would:

import the useContext and createContext hook
create the context object
wrap CHildA in the context provider
Skip to ChildZ and give it access to fruit via useContext(ContextProvider)

import ({useContext, createContext, useState}) from "react"
const FruitContext = createContext("")
export default function Parent() {
     const [fruit, setFruit] = useState("apple")
     return (
          <FruitContext.Provider value=(fruit)>
            <ChildA/>
          <FruitContext.Provider>  
    )  
 }
// Skip Components ChildB-ChildY 
...
function ChildZ() {
  const fruit = useContext(FruitContext);
  return <p>ChildZ has the {fruit} now! </p>
}

In the case above we can easily see how ineffficient prop drilling would be in passing fruit down a deeply nested hierarchy of components.

NOTE: Something to make note of is when a context value changes the calling component will re-render. If rendering becomes expensive there is a possible solution called memo. A component re-renders whenever it parent re-renders even if its props have not changed. Memo allows you to create a component that will not re-render when the parent re-renders as long as its props have not changed. The component in the case is said to have been "memoized". This process will help with optimization by cutting down on unneccessary rendering. Click here for more information.

Conclusion:

The useContext Hook solves the problem of prop drilling down a deeply nested tree of components
To use the useContext hook you have to first import both useContext and createContext from react.
createContext creates a context "Provider" that takes a value.
The context provider is wrapped around the top level component and every component down the tree has access to the value provided by the context provider.
useContext is how a child component gets access to the actual data in the context provider.
If rendering becomes expensive memo may be a solution.

So,What is "this"?

gisellec60 — Wed, 10 May 2023 20:14:07 +0000

This

In short this is a special object created by and used in the global/window or function execution context....what???

Execution context??? Yeah I know..., I hate when someone introduces a term or concept without explaining what it is and how it relates to the current topic, so I'm going to take a little time to explain "execution context", before discussing the this keyword.

What is an "execution context"?
When JavaScript begins it creates an environment called the "execution context". The execution context is responsible for transforming and executing code.

The global execution context is created when a JavaScript script starts to run, and represents the global scope. A function execution context is created when a function is called, and represents the function's local scope.

The execution context is made up of two phases: creation and execution.

Creation: This is when the execution context is created and the environment is setup. Variable and functions values are determined along with the scope chain for the execution context.

Execution: This phase is where the code is executed. This is where function calls are evaluated along with any statements or expressions.

Okay, so now that we got that out of the way... what does execution context have to do with "this"?

Well, I'm glad you asked...

The this keyword represents the object that is executing the current piece of code. Remember we said a global execution context is created when JavaScript first runs? Well, during that time a special object called "this" is also created and is bonded to the global/window object. Likewise, when a function is invoked the function's execution context is created along with the this keyword which is bonded to the object executing the code in the function.

example:

name.f() =>  this.f()

this represents the object which in this case is "name", executing the function. this always represents the object to the left of the dot.

The value of "this" depends on the context in which it appears: global, function, or class. Let's take a closer look at this and the different contexts in which it can be used.

1. Regular Function
In a regular function (A function this is not the property of an object), this is not associated with an object so it evaluates to the window object using the browser and a global object when using node.js.

function show() {
    console.log(this === global);
}
console.log(show())

node.js: global context

chrome browser: window context

2. Functions as Property of an Object
When a function is called as the property of an object, the execution context is created along with the special object called _this _ which represents the object that owns the function.

const school = {
    level: "High School",
    city:  "Bronx",
    getLevel: function () {
          return this.level
    }
}

In this example, the this object in getLevel() function represents the school object.

Let's take another look at this:

const school = {
    level: "High School",
    city:  "Bronx",
    getLevel: function () {
          return console.log(`I went to ${this.level}school, in the ${this.city}`)
    }
}
console.log(school.getLevel())

Notice the code below and the code above both give the same results. You can also see that "this" in the code above represents "school" below.

const school = {
    level: "High School",
    city:  "Bronx",
    getLevel: function () {
          return console.log(`I went to ${school.level}, in the ${school.city}`)
    }
}
console.log(school.getLevel())

Remember, when you call a function expression that's a property of an object, that function expression's this object is the object on which the function is called i.e., the object to the left of the dot.

3. Constructor
When you use the new keyword to create an instance of a function object, you use the function as a constructor. The following example declares a school function, then invokes it as a constructor:

function school(level) {
   this.level = level
} 
school.prototype.getLevel = function () {
   return this.level
}

let myschool = new school('Elementary School')
console.log(myschool.getLevel())

The expression new school('Elementary School') is a constructor invocation of the school function. JavaScript creates a new object and sets this to the newly created object. This pattern works great with only one potential problem. Now you can invoke the school() as a function or as a constructor. If you omit the new keyword as follows:

let secondary = school("secondary")
console.log(secondary.level)

The value in the school() sets the global object, the secondary.level returns undefined. However to make sure school() is always invoked using constructor invocation:

function school(level){
   if(!(this instanceof school)){
      throw Error ("must use the new operator to call the function")
   }
   this.level = level
}

ES6 introduced a new property called "new.target" that allows you to detect whether a function is called as a simple invocation or as a constructor.

function school(level){
   if(!(new.target)){
      throw Error ("must use the new operator to call the function")
   }
   this.level = level
}

4. Explicit
There are three ways to override the default context object when calling a function: "call" "apply" and "bind".

call()

function getName(prefix) {
  console.log(prefix + this.name)
}
let stevenson = {
    name:"Stevenson"
}
let monroe ={
    name: "Monroe"
}
getName.call(monroe, "My school is ")
getName.call(stevenson, "My school is ")

)
In this example, we called the getName() indirectly using the call() method of the getName function. We passed stevenson and monroe objects as the first arguments of the call() method. The first argument is referred to as the thisArg object which are bonded to _this _ inside the function.

apply()

*The apply() method is similar to the call() method in that it also requires a *_thisArg** object to be the first paramenter. Again, thisArg object is bonded to the this keyword inside the function. The only difference between call() and apply() is the second argument passed to apply() is an array:

getName.apply(monroe, ["My school is"])
getName.apply(stevenson, ["My school is"])

bind()

const school = {
    level: "High School",
    city:  "Bronx",
    getLevel: function () {
          return console.log(`I went to ${school.level}, in the ${school.city}`)
    }
}

Now a function expression is a property of an object which is a value that can be stored in a variable:

let level = school.getLevel;

We then call the method using the variable:

console.log(level())

Notice we get undefined instead of the level and city. That's because when you call a function expression without specifying its object, JavaScript sets this to the global object in non-strict mode and undefined in the strict mode. To fix this problem we use the bind() method. The bind() method creates a new function whose this keyword is set to a specified value. We also use a "thisArg" object as the first argument, which becomes the this inside the function.

let level = school.getLevel.bind(school) 
console.log(level())

In school.getLevel.bind(school), school is represents thisArg.
Note: Whatever object you bind the variable to it will use:

let school ={
   level: "High School",
   city: "Bronx",
   getLevel: function () {return (`I went to ${this.level}, in the ${this.city}`)
    }
}

let college ={
    level: "college",
    city: "Atlanta"
}
let level = school.getLevel.bind(college)
console.log(level())

So we bonded school.getLevel.bind to the college object.

5. Arrow Functions
Arrow functions do not create their own execution context but inherits the this from the outer function where the arrow function is defined.

let getThis = () => this;
console.log(getThis() === global)

The arrow function does not create its own execution content. Remember regular functions when invoked create an execution context that also creates the _this _object. Because of this defining a method using an arrow function will cause a problem:

function Car() {
   this.speed = 120
}
Car.prototype.getSpeed = () => {
   return this.speed
}
let car = new Car();
console.log(car.getSpeed());

Conclusion:

Execution Context is responsible for transforming code
There are two phases to the execution context: Creation and Execution
This keyword is a special object created during the execution context creation. This can represents either the object executing the function, the global object or window object.
The context object can be explicitly set by invoking "call" on a function and passing it _thisArg _as the first argument. This allows for the object to be accessed using this from inside the function.
The context object can also be explicitly set by invoking "apply" on the function and passing thisArg as the first argument allowing for the object to be accessed using this from inside the function.
The context object can be bonded to a function using the "bind" method on the function and passing it thisArg. The bind method makes a copy of the function whose this keyword is bonded to a specified object.