DEV Community: Olatunde Adedeji

Mastering SOLID Principles in Python: A Guide to Scalable Coding

Olatunde Adedeji — Tue, 04 Jul 2023 18:17:43 +0000

SOLID principles are a set of software design principles that aim to help software developers write scalable and maintainable codes. These standard principles for software design are the Single responsibility principle, Open-closed principle, Liskov substitution principle, Interface segregation principle, and Dependency inversion principle. Before the SOLID principles adoption, software developers faced several challenges related to writing codes that are easier to maintain and understand. Tech folks that design with codes faced issues related to code becoming tangled and difficult to understand, which was sometimes referred to as spaghetti code. This made it difficult to make changes or add new features to the codebase and could result in bugs and other unintended issues.

Another prevailing problem precedent to SOLID was code rigidity, where making changes to one part of the codebase would require changes to many other parts of the codebase. This made it difficult to make changes to the codebase without introducing bugs or breaking existing functionality. We also experienced a lack of modularity, where code was not divided into smaller, more manageable components. This made it difficult to reuse code and made the codebase more difficult to understand and maintain.

SOLID principles were introduced by Robert C. Martin, also known as Uncle Bob, in the early 2000s to address these and other challenges by providing a set of best practices for writing maintainable and scalable code. With the SOLID creed, software developers can create code that is easier to understand, easier to maintain, and more flexible in the face of changing requirements.
Next, we discuss the components of SOLID principles.

What are SOLID Design Principles

SOLID principles are software design best practices formulated to help software developers write maintainable, scalable, and flexible code.

Let's delve deeper into understanding SOLID principles with some Python code examples to drive SOLID creed into our blood streams:

The five SOLID principles are:

Single Responsibility Principle (SRP): A class should have a single responsibility or a single job
Open/Closed Principle (OCP): A class should be open for extension but closed for modification.
Liskov Substitution Principle (LSP): derived classes should be substitutable for their base classes.
Interface Segregation Principle (ISP): Clients/classes that use an interface should not be forced to depend on interfaces they do not use.
Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions.

Next, we will slice each principle and sprinkle some Python codes on these best practices to help us understand the SOLID principles better.

Single Responsibility Principle

The Single Responsibility Principle (SRP) is a fundamental SOLID principle that states that a class should have single responsibility or a single job. This principle helps in making the code more maintainable, testable, and reusable.

Let's buttress the point with a healthcare application.

To demonstrate the single responsibility principle using a sample Python code, let's consider a case study of a healthcare application. Suppose we have a class called Patient that has the following properties: name, age, gender, blood_group, patient_id, medical_history, appointments, and treatments.

However, the Patient class violates the SRP principle because it has too many responsibilities. It stores patient data, medical history, appointments, and treatments all in one class. A better approach would be to separate the concerns of patient data storage and appointment scheduling into two separate classes.

A code example is provided below to illustrate this:

class Patient:
    def __init__(self, name, age, gender, blood_group, patient_id, medical_history, appointments, treatments):
        self.name = name
        self.age = age
        self.gender = gender
        self.blood_group = blood_group
        self.patient_id = patient_id
        self.medical_history = medical_history
        self.appointments = appointments
        self.treatments = treatments

    def get_patient_data(self):
        # return patient data

    def get_medical_history(self):
        # return medical history

    def get_appointments(self):
        # return appointments

    def get_treatments(self):
        # return treatments

    def schedule_appointment(self, date):
        # schedule an appointment

    def add_treatment(self, treatment):
        # add a new treatment

The preceding Patient class violates the SRP principle because it has too many responsibilities. We can refactor the code and separate concerns by creating a PatientData class and an AppointmentScheduler class.

class PatientData:
    def __init__(self, name, age, gender, blood_group, patient_id, medical_history, treatments):
        self.name = name
        self.age = age
        self.gender = gender
        self.blood_group = blood_group
        self.patient_id = patient_id
        self.medical_history = medical_history
        self.treatments = treatments

    def get_patient_data(self):
        # return patient data

    def get_medical_history(self):
        # return medical history

    def get_treatments(self):
        # return treatments


class AppointmentScheduler:
    def __init__(self, patient_data):
        self.patient_data = patient_data
        self.appointments = []

    def get_appointments(self):
        # return appointments

    def schedule_appointment(self, date):
        # schedule an appointment

In the preceding refactored code, we have separated concerns and created two classes. The PatientData class stores patient data, medical history, and treatments, while the AppointmentScheduler class handles appointment scheduling.

With the single responsibility principle implemented, we have made the code more maintainable, testable, and reusable.

Next up on the list is the oOpen/closed principle.

Open/Closed Principle

The Open/Closed Principle (OCP) is another component of the SOLID principle that states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. In other words, we should be able to extend the behaviour of a class without modifying its source code. This principle promotes code reusability and maintainability.

Let's continue with the healthcare application use case and demonstrate the open/closed principle using Python code. Suppose we have a class called Billing that calculates the bill for the patient's treatment.

This is how the Billing class can be written without adhering to the open/closed principle:

class Billing:
    def __init__(self, patient, amount):
        self.patient = patient
        self.amount = amount

    def calculate_bill(self):
        # calculate bill based on treatment amount
        if self.patient.insurance == 'HMO':
            self.amount = self.amount * 0.8
        elif self.patient.insurance == 'PPO':
            self.amount = self.amount * 0.9

        return self.amount

The preceding Billing class violates the OCP principle because if we want to add a new type of insurance, we have to modify the source code of the Billing class, which can introduce bugs and make the code difficult to maintain.

To comply with the OCP principle, we can modify the Billing class to use a strategy pattern. We can create an abstract Insurance class and have specific insurance classes extend it. The Billing class can then accept an instance of the Insuranceclass, which will be used to calculate the bill.

Let's create an Insurance abstract class:

from abc import ABC, abstractmethod

class Insurance(ABC):
    @abstractmethod
    def calculate_discount(self, amount):
        pass

The preceding code defines an abstract class with the name Insurance using the Python standard library's abc module, which stands for Abstract Base Classes. The ABC class serves as the base class for all other abstract classes.

TheInsurance class contains a single abstractmethod named calculate_discount. An abstract method is a method that is declared in the abstract class but does not have an implementation. Instead, any subclass of the Insurance class must provide an implementation for this method.

In this case, the calculate_discount method takes in an amount parameter and returns a discounted amount based on the specific insurance policy. By defining this method as abstract in the Insurance class, any concrete implementation of an insurance policy must provide its implementation of this method.

Now, let's implement two insurance classes (HMOPolicy and PPOPolicy) that extend the Insurance class.

class HMOPolicy(Insurance):
    def calculate_discount(self, amount):
        return amount * 0.8

class PPOPolicy(Insurance):
    def calculate_discount(self, amount):
        return amount * 0.9

The preceding snippets define two concrete classesHMOPolicy and PPOPolicy, which inherit from the abstract Insuranceclass. Both concrete classes implement thecalculate_discountmethod, providing their implementation of the method defined in theabstractclass. TheHMOPolicy class overrides thecalculate_discountmethod to provide a discount of 20% (0.8) on the givenamount`. This means that if a patient is covered by an HMO insurance policy, they will receive a 20% discount on their medical bills.

Likewise, the PPOPolicy class overrides the calculate_discount method to provide a discount of 10% (0.9) on the given amount. This means that if a patient is covered by a PPO insurance policy, they will receive a 10% discount on their medical bills.

Finally, the modified Billing class now looks like this:

`
class Billing:
def init(self, patient, amount, insurance_policy):
self.patient = patient
self.amount = amount
self.insurance_policy = insurance_policy

def calculate_bill(self):
    # calculate bill based on treatment amount
    return self.insurance_policy.calculate_discount(self.amount)

The preceding code defines a Billing class that takes three parameters in its constructor: patient, amount, and insurance_policy. The patient parameter is a string that represents the name of the patient, the amount parameter is a numerical value that represents the treatment cost, and the insurance_policy parameter is an object that implements the Insurance class (or its subclass).

The calculate_bill() method calculates the patient's bill based on the amount of the treatment cost and the discount provided by the insurance policy. The method calls the calculate_discount() method of the insurance_policy object and passes the treatment cost (self.amount) as a parameter to the method. The calculate_discount() method of the insurance_policy object calculates the discount based on the type of insurance policy and returns the discounted amount. In short, the Billing class calculates the patient's bill based on the treatment cost and the type of insurance policy they have.

With the open/closed principle implemented, the Billing class is easier to maintain and extend. We can now add new insurance types by creating new classes that extend the Insurance class without modifying the source code of the Billing class.

And that's not all with SOLID principles, we have next on the list, the Liskov substitution principle.

Liskov Substitution Principle

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. In other words, if a function takes an object of a superclass as a parameter, it should also be able to accept objects of its subclasses without causing any errors or unexpected behaviours.

Let's continue with the healthcare application example and demonstrate the Liskov substitution principle using Python code. Suppose we have a class called Patient with a method called pay_bill that pays the bill for the patient's treatment.

Without Liskov substitution principle implemented, Patient class could be written this way:
`
class Patient:
def init(self, name, balance):
self.name = name
self.balance = balance

def pay_bill(self, amount):
    if self.balance >= amount:
        self.balance -= amount
        print(f"Paid {amount} for the treatment")
    else:
        print("Insufficient balance. Please add funds")

The above Patient class violates the LSP principle because if we create a subclass that has a different implementation of the pay_bill method, it may cause unexpected behaviours when passed into a function that expects an object of the Patient class.

To adhere to the LSP principle, we can modify the Patient class to have a more general behaviour for the pay_bill method. We can create a new subclass called InsuredPatient that extends the Patient class and has its implementation of the pay_bill method.

Now, let's take a look at the modified Patient and InsuredPatient classes:

`
class Patient:
def init(self, name, balance):
self.name = name
self.balance = balance

def pay_bill(self, amount):
    self.balance -= amount
    print(f"Paid {amount} for the treatment")

class InsuredPatient(Patient):
def init(self, name, balance, insurance_policy):
super().init(name, balance)
self.insurance_policy = insurance_policy

def pay_bill(self, amount):
    discounted_amount = self.insurance_policy.calculate_discount(amount)
    super().pay_bill(discounted_amount)

`
In the preceding modified code, we created a new subclass called InsuredPatient that extends the Patient class and has its implementation of the pay_bill method. The InsuredPatient class also accepts an instance of the Insurance class, which will be used to calculate the discounted bill amount.

By adhering to the Liskov substitution principle, we can now pass an object of the InsuredPatient class into a function that expects an object of the Patient class without causing any unexpected behaviours.

Moving right along, we have the interface segregation principle to discuss.

Interface Segregation Principle

The Interface Segregation Principle (ISP) states that clients should not be forced to depend on interfaces they do not use. This means that classes should not be forced to implement interfaces with methods that they do not need.

In the context of the healthcare application, let's say we have an interface called Treatment that defines a method called treat_patient that takes a Patient object as a parameter and performs some treatment on the patient.

Here's an example of how the Treatment interface can be written:

class Treatment(ABC): @abstractmethod def treat_patient(self, patient: Patient): pass
Now let's say we have two classes called Surgery and Medication that implement the Treatment interface. The Surgery class implements the treat_patient method by performing surgery on the patient, while the Medication class implements the treat_patient method by administering medication to the patient.

However, the problem with the above design is that not all patients require surgery or medication. For instance, a patient with a broken arm may only require a cast and not surgery or medication. Therefore, it would be better to create separate interfaces for each type of treatment.

With the interface segregation principle followed, this is how the modified code looks like:

class Surgery(ABC): @abstractmethod def perform_surgery(self, patient: Patient): pass

class Medication(ABC):
@abstractmethod
def administer_medication(self, patient: Patient):
pass

Now we have two separate interfaces - Surgery and Medication. These interfaces define methods that are specific to their respective treatments. This allows the classes that implement these interfaces to only implement the methods that they need, and not be forced to implement unnecessary methods.

With the interface segregation principle adhered to, we have improved the modularity and maintainability of our code, making it easier to add new treatments in the future without impacting the existing code.

Interestingly, the SOLID story doesn't end with the interface segregation principle, we still have the dependency inversion.

Dependency Inversion Principle Principle

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules, both should depend on abstractions. In other words, the details should depend on the abstractions, not the other way around.

In the context of the healthcare application, let's say we have HospitalManager class responsible for managing the treatments for all the patients in the hospital. This class currently has a dependency on the Surgery and Medication classes, which are low-level modules.

To adhere to the dependency inversion principle, we need to introduce an abstraction between the HospitalManager class and the Surgery and Medication classes. One way to achieve this is by defining an interface called TreatmentStrategy that defines the execute_treatment method:

class TreatmentStrategy(ABC): @abstractmethod def execute_treatment(self, patient: Patient): pass
Now, we can modify the Surgery and Medication classes to implement the TreatmentStrategy interface:

`
class Surgery(TreatmentStrategy):
def execute_treatment(self, patient: Patient):
# perform surgery on patient

class Medication(TreatmentStrategy):
def execute_treatment(self, patient: Patient):
# administer medication to patient
`

Next, we modify the HospitalManager class to depend on the TreatmentStrategy interface instead of the Surgery and Medication classes:

`
class HospitalManager:
def init(self, treatment_strategy: TreatmentStrategy):
self.treatment_strategy = treatment_strategy

def manage_treatment(self, patient: Patient):
    self.treatment_strategy.execute_treatment(patient)

By doing this, we have inverted the dependency - the HospitalManager class now depends on an abstraction TreatmentStrategy instead of a low-level module Surgery and Medication. This makes the code more flexible and easier to maintain, as we can easily swap out different implementations of the TreatmentStrategy interface without impacting the HospitalManager class.

Overall, the dependency inversion principle helps to reduce coupling and improve the modularity and maintainability of our code.

Summary

SOLID principles are well-accepted software design principles. SOLID principles were developed to address software design challenges by providing a set of best practices for writing maintainable and scalable code. By following SOLID principles, software developers can create code that is easier to understand, easier to maintain, and more flexible in the face of changing requirements.

Other design principles such as GRASP (General Responsibility Assignment Software Patterns), DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid), and YAGNI(You Aren't Gonna Need It) are worth checking out to see how these design principles fit into your project requirements.

Note:
I published the original version on Hashnode. This copy is modified!

How React flirts with data

Olatunde Adedeji — Fri, 22 Jul 2022 16:05:00 +0000

React is the Rolls Royce of frontend development inspiring greatness in designing user interfaces. Undoubtedly, React is a JavaScript library for building user interfaces. React focuses explicitly on building UI for web and mobile applications. React is so popular, flexible, and declarative- the React API does the heavy lifting for you in building user interfaces. React allows you to develop reusable components that are easy to read, scale and maintain.

Essentially, React component consists of a markup mix of HTML, styled by CSS, and with smooth interactivity handled with the help of JavaScript.

React has a large community of developers who are ready to help you all the way in learning and understanding the intricacies of React ecosystem. The die-hard React fans would tell you this is the best time to be a web developer- the wholesome developer experience is eccentric with a great feeling of nothing is impossible with user interface coding!

However, in this article, we are going to learn how React handles data we use in web applications. Data is critical to every web application and React does excellently well in handling data, data in the component state, passing data from one component to another, and fetching data from an API data source. We will explore in specific how React handles data fetching using Fetch API.

Understanding data and its uni-directional flow

Conventionally, data flows in one-way directional movement in React. It means there is only one source that the rest of your application components expect data to come from and that source is a parent component, nowhere else. Technically, in React, data flows from the parent component to the child component. This flow is in form of props. Props are the carrier of component information. Data is not expected to flow from child to parent or child to child. This encourages a definite single source of truth for data. Why would React enforce the uni-directional flow of data?

The reasons are not far-fetched:

It is easier to debug, as we know where data is coming from.
Unidirectional data flow is less prone to errors, as we have more control over our data.
It is more efficient, as the library knows what the boundaries are of each part of the disparate system.

Data in the database

Hardly will you see a web application without a backend service. Of course there are many benefits of keeping your data in a database. Firstly, data persistence improves user experience. Users of your web application will appreciate a system that makes storage and retrieval of data- users information a painless adventure. React shines with its controlled component form ability in capturing user inputs and relaying it back when needed with little or no latency.

Secondly, we need to consider data security and how React rises to occasion. Data security starts from the point of data collection. Are users able to submit HTML contents to your backend service? If yes, are you using React best practices to ensure the right data in the right form get to your database? No developer is ever proud of a system vulnerable to SQL injection. SQL injection describes a scenario a playful or bad actor user exploit the vulnerability of your web applications in injecting exploitative SQL codes in your system that is capable at the extreme case, of CRUD operations. Nobody wants this but you have to expect it and be defensive against SQL injection attacks in your development.

Imagine this gets to execute on your database from your form input fields:

DROP TABLE IF EXISTS dbo.Customers;

It will definitely be embarrassing!

So, handling dangerous form data before the son of a bitch gets to your database is ever more important to retain your job as a developer and to maintain the good credibility of your company or clients. User data sanitization is critical and for React applications, an open source package such as Formik helps reduce the burden of form development. You can even go the extra mile with what the package has to offer to be at the safer end of what goes into your database.

Concept of immutability

Immutability makes data flow easier to understand in React applications. An immutable variable means its value cannot change after being created. Mutability and immutability are frequently used in programming in a rather confusing or probably complex way.

Why are we not using simple terms like can change, modifiable (mutable) or cannot change, not modifiable (immutable)?

These are rather easier to understand anyway this is by the way! Developers' communities are built around folks that love complex words- we are all in it together!

Technically, JavaScript Strings value types are immutable. You can’t directly change its value but you can re-assign it to another value.

var strings =”John Joel”;

You can’t do this:

strings[3] =”p”;

You can only mutate string values with some methods like replace(), trim() etc

React says do not mutate(change) the state property of a component directly. In essence, state values are immutable. But with a caveat, you can only change the state value with a function updater method- setState(). This help instils some sanity into the coding culture and makes debugging easier.

React unequivocally says, how you handle your data is up to you, even mutations. In large React applications, performance tends to be a major reason why we care so much about how data mutate. A change in states naturally can cause React components to re-render. You wouldn't want expensive re-rending to impair the performance of your React applications. In redux, a way to manage complex state data in React. You deal with state mutations through reducers not directly. So, immutability in React encourages a single source of truth of your data. You also tend to have cleaner codes with clarity of your functions' behaviour.

Fetching data from an external data source

Dealing with external data sources in React could be a no-brainer with the right approach. We are going to see how fetching data is loaded into React from an external source using a simple fetch().

Why fetch()? It is native to our browsers. It is right there on the window object- window.fetch. No need of extra package installation. You simply hit the ground running with your Http request handling in a promise based request approach.

Let's make a simple GET request with fetch(). And all we have to do is to include the URL endpoint to which we want to make our request in the Fetch() method.

import React, { useState, useEffect } from 'react';  

const App=()=> { 

    const [people, setPeople] = useState([]); 

    const [isLoading, setIsLoading] = useState(true);  

    useEffect(() => { 

        // GET request using fetch with  useEffect Hook 

        setIsLoading(true); 

        fetch('https://swapi.dev/api/people/') 

            .then(response => response.json()) 

            .then(data => setPeople(data.results)); 

        setIsLoading(false);  

    // Empty dependency array means this effect will only run once 

    }, []); 



    return ( 

        <div> 

            <h5>Get Data from an API Data Source</h5> 

            {isLoading? <p>Loading people...</p>: people.map(person => <p key={person.name}>{person.name},{person.mass}, {person.height}</p>)}            <div> 

                {} 



            </div> 

        </div> 

    ); 

}  

export default App;

Let’s quickly break the code down:

We import useState and useEffect Hooks to bring them to scope in our applications.
The const [people, setPeople] = useState([]) and the const [isLoading, setIsLoading] = useState(true) were set to manage people and isLoading states
We then have useEffect to handle the logic of data fetching from the endpoint
The endpoint URL was passed as parameter to fetch('https://swapi.dev/api/people/')
The .then() callback returns a new promise with the conversion of response to a JSON data
The second .then() callback assign the JSON response data to our state variable-people
We then call on the map() to iterate on the arrays of people objects returned.

In conclusion,

We can see that React shines well among peers in handling data in any web application of any size and complexity. Its uni-directional data flow enables developers to understand where data is coming from and what it is capable of becoming, thus makes debugging easier.

The immutability concepts in React applications optimizes complex applications for better performance. You then ensure you are developing pure components with predictable behaviour since you know how your variables, arrays and objects might behave.

Finally, the understanding of React ability to flirt with data will not be complete without making refence to how React handles data from a data source, a daily application development task for every professional developer. React library for building user interface handle data with a touch of class.

A Succinct Explanation of React.useEffect() Hook

Olatunde Adedeji — Mon, 18 Jul 2022 16:30:00 +0000

React.useEffect() is one of the coolest dudes among React Hooks. If you have been hooked into the world of functional components, this will definitely look familiar else you are probably still deep-necked down into the legacy React applications. You might need some functional React components pills! I must say the team behind React library are aggressively advocating for the use of functional and the Hooks approach to React applications development. It is certainly worth the effort going the Hooking way!

Anyway, useEffect helps React developers appear smarter than they are, taking care of side effects in functional React components with its simplistic touch of syntax constructs.

useEffect(() => { 
    console.log (“Runing side effects”) 
})

Note: This runs every time component renders! You might not want this in reality.

If you like hooking up (no pun intended)- I mean with functional components, I am here to explain how you can do it well with the right understanding. In this article, you will learn and understand how, plus when to use useEffect() Hook.

What is a Hook?

Hooks are special function that allow you to hook into React state and lifecycle methods in functional components. Basically, functional and class approaches are the two major ways to develop a component in React. Hooks work only with the functional components approach. If you stumble on any Hooks in a class component, kindly raise genuine alarm. Something is definitely wrong.

useEffect() handles side effects

The purpose of useEffect() is to handle and mange side effects. And what are these side effects? Side effects are any operation in a function that is not directly related to the final output of the function. If you have probably wanted to fetch data from an API or other data source, ever wanted to tinker with DOM manually in React applications or have a subscription service set up to listen to an emitted event, all these and more are side effects in real life React.

Let‘s take a look at this side-effect of a function using document.title to display name information on a browser.

import React from 'react'; 

function App() { 

  return ( 

    <div> 

   <SayGreeting name="Olatunde"/> 

  </div> 

  ); 

} 

const SayGreeting = (name) => { 

  const greeting= `You welcome, ${name}!`; 

  // Side-effect with DOM manipulation! 

  document.title = `Greetings to ${name}`; 

  // Main expected function output 

  return <div>{greeting}</div>; 

  } 

export default App;

In the preceding snippet, we have a component SayGreeting with a side effect of document.title = Greetings to ${name}; This is obviously a wrong way to add a side-effect to a component. You would rather hand this over to useEffect to handle.

Let's refactor our snippet with useEffect () to manage the side effect of the component:

const SayGreeting = (name) => {  

const greeting= `You welcome, ${name}! `;  

   useEffect(() => {   

   document.title = `Greetings to ${name}`; //Side-effect with DOM manipulation inside useEffect()!  

  }, [name]);  

  // Main expected function output  

  return <div>{greeting}</div>;  

  }

Essentially, components are the basic building block of any React application. So, for any expression of a user interface, at least a component is rendered. The useEffect() can be used to handle the logical part of component while allowing the component to focus on the rendering part. And since we can’t tell React how many times a component should be rendered, we can clearly control how the side effects of any component should be handled in case a component chooses to render multiple times. We can control how the side effects of a component are managed with the useEffect() optional dependency argument.

Intrinsically, a component is capable of two things: rendering and handling side-effects. It is always the best practice to leave the handling of side effects to useEffect().

How to pass argument to useEffect()

The useEffect() hook graciously accepts two arguments: useEffect(callback, [dependencies]);

*The callback is the function containing the side-effect logic.

*The dependency represents optional array of dependency or dependencies.The useEffect() executes callback every time the dependencies change.
This explains the default scenario of useEffect()

useEffect(() => {  
    // Runs every time the component renders  
})  

useEffect(() => {  
    // Runs only on initial render  
}, []) // Optional second argument: dependency array  

useEffect(() => {  
    // Runs only when 'OptionalDataValue' changes  
}, [OptionalDataValue])

Fetching data from an endpoint over a network

Let’s dive into how the useEffect() performs data fetching side effect.

The following component FetchUsers fetches the users list over a specified endpoint on the network:

import React,{useEffect,useState} from 'react';  

function App() { 

  return ( 

    <div>  

   <FetchUsers /> 

  </div> 

  ); 

}  

  function FetchUsers() {  

    const [users, setUsers] = useState([]);  

    useEffect(() => {  

      async function fetchUsers() {  

        const response = await fetch (' https://mocki.io/v1/d4867d8b-b5d5-4a48-a4ab-79131b5809b8');  

        const fetchedUsers = await response.json(response);  

        setUsers(fetchedUsers);  

      }  

      fetchUsers();  

    }, [users]); 

     return (  

      <div>  

        {users.map((user) => <div key={user.name}>{user.name}</div>)}  

      </div>  

    );  

   }  

export default App;

The useEffect() starts a fetch request by calling an async function fetchUsers() after the initial componentDidMount.

When the request completes, setUsers(fetchedUsers) updates the users current state with the already fetched users list.

We set an empty array [] dependency to indicate the useEffect() should run once component is mounted and if any dependency was added to the array which could be a prop or state value-[users]. We will only re-run the useEffect() once the users list changes.

useEffect() and Component lifecycle methods

Components in React undergo three major phases; mounting, updating and unmounting. This explains the relationship of component with the DOM tree. You should be familiar with how React use Virtual DOM on top of the native browser DOM to smartly update the DOM on any state change. This is one of the innovative ideas of React.

So, when the component is mounted on the DOM, componentDidMount() is invoked to perform its side effect operation which could be network requests or mutations in the DOM as explained earlier.

componentDidMount() { 

Console.log (“component mounted successfully”); 

 }

The useEffect() encapsulates the componentDidMount(), componentDidUpdate() and componentWillUnmount()

We will be examining how the useEffect() handle stages in the component lifecycle methods.

Component did mount

With componentDidMount():

useEffect(() => { 
console.log("componentDidMount"); 
};

This runs when the component mount and it runs on every component re-rendering.

We can also look at this:

useEffect(() => {  
console.log("componentDidMount");  
}, []);

In the preceding, an empty second argument array is passed. This means when the component mount and the useEffect() runs once as well. This doesn’t re-run the useEffect() at every re-rendering.

Component will update

With componentWillUpdate():

useEffect(() => {  

console.log("componentWillUpdate"); 

 }, [args]);

The second argument is passed to the useEffect() and any state or props value change will cause the component to update.

Component will unmount

With componentWillUnmount():

useEffect(() => {  

  return () => { 

 console.log("componentWillUnmount"); 

  }; 

 }, [args]);

With the return function running after the side effect, you have a cleanup mechanism to handle the side effect before being re-mounted.

In conclusion,

The useEffect is an important Hook in functional component. We have seen how useEffect() helps with handling of side-effects. Apart from managing side effects, useEffect() Hook enables us to further separate concerns within the component by handling the logical code in component while component faces the task of rendering.

Also with useEffect Hook, we have a lean way of capturing component lifecycles and methods in our React applications regardless of components complex states.

Kindly let me know what you feel about the information on useEffect() Hook, is there any over look concepts or not too clear explanation of useEffect() Hook.

Hello, I'm Olatunde Adedeji

Olatunde Adedeji — Sun, 29 May 2022 17:15:59 +0000

I have been coding for over 6 years.

You can find me on Twitter as @OAAdedeji

I live in Lagos, Nigeria.

I work for Mowebsite as a Full-Stack Engineer.

I mostly program in HTML, CSS, JavaScript, React, Gatsby, Python && PHP.

I am currently accumulating knowledge more about the serverless web and JAM stack ecosystem while implementing things I have learned in regards to startups -HealthTech, FinTech and product leadership.

Nice to meet you.