Forem: Smilepk

React.js Basics – The DOM, Components, and Declarative Views Explained

Smilepk — Wed, 30 Mar 2022 03:45:47 +0000

React.js is an open source JavaScript library for creating user interfaces. It was created by Facebook back in 2013.

Demand for React developers is skyrocketing, which means that having knowledge of this library is definitely going to be worth it! Some of the popular websites built using ReactJS include Dropbox, Netflix, and Instacart – and the list goes on.

Now, the common question that comes to everyone's mind is do we really need a JavaScript library, just for creating user interfaces? We can do the same using just HTML and CSS, right?

So what makes React so popular rather than just using vanilla HTML, CSS, and JavaScript? For that, let's first look at the 2 main features of React:

Declarative Views
Component Based Approach
Of course there is more to React than this, but we'll focus on these two features here. Before moving on and learning more about these features, we must clearly understand the browser DOM.

What is the DOM?
The DOM (Document Object Model) represents the web page as a tree structure. Any piece of HTML that we write is added as a node, to this tree.

With JavaScript, we can access any of these nodes (HTML elements) and update their styles, attributes, and so on. This means that the DOM enables JavaScript to access and modify the web page easily.

Now, any tree must have a root node, right? Here, the root node is document. Are you wondering where this document node came from? Well, it's part of the browser. Any HTML tag you write is going to be a direct or indirect child of the root node document.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/eocedkmthldy7lcedm4n.jpeg)
DOM tree with root node as document
The below image shows the equivalent conceptual tree structure of the DOM:

Browser DOM tree

Now hopefully you have a clear understanding of the browser DOM. So let's dive into the two main features of ReactJS‌ that we're gonna discuss today, namely its component-based approach and declarative views.

Component-Based Approach
Everything in React is a component. A web page is a collection of components.

Think of a component like a regular function in any programming language. What are the main advantages of functions? Reusability, abstraction, and avoiding redundant code, right?

Same with components in React. Don't get confused with the code in the below images, as we are using a mix of HTML and JavaScript. Hang in there, we will come to that in a second.

The above image represents a component called Card (since the function name is Card). As mentioned earlier, functions or components can be reused any number of times. That is exactly what we are doing in the below image. We are reusing the Card component () four times. Keep in mind that, writing is equivalent to . (Stick to the former notation, since it's more common).

Card Component reused multiple times
Congrats if you thought of this! The four components are written inside another component called Home (since the function name is Home, ). Congrats again if you thought of this!

Of course you can reuse the component, which in turn is a collection of many components. That is, we can nest any number of components inside other components.

Now comes a big question: if components are going to be nested like we mentioned, what is the topmost component? It's the component (provided by React). Any custom component that you write is going to be a direct or indirect child of the App component in React.

On a high level, the whole component structure looks like a tree with the root node as App.

Also keep in mind that component names have their first letter capitalized. This convention is used to distinguish between a React component and a regular HTML tag.

What happens if you don't capitalize the first letter of a component name? There will be an ambiguity, whether it is an HTML tag or a React component.

In the below image, the Navbar, Carousal, Services and so on are all components. Components altogether form the home page or Home component of a website. Neat, isn't it?

Home page consisting of Navbar, Carousal, Services etc components
Components are laid out in the order in which they should appear in the page. Here, the Navbar comes first, at the top, then the Carousal comes below the Navbar, so on and so forth.

If you carefully observe the above images, we are using a mix of both JavaScript and HTML. This is known as JSX (Javscript XML). This is just a nice way to

Weird isn't it ? This is JSX
In the above image, we are assigning HTML to a variable named element, just like we assign values to variables in JavaScript. Of course, you can now reuse this variable (element) anywhere in your code like this:

Output of the above code
And that's it about components in React. Now let's move onto the next feature.

Declarative Views in React
In React, we don't actually interact with the browser DOM. Yes, you heard it right! We interact with the virtual DOM, which is an exact copy of the browser DOM, but in memory.

Yeah! We are dealing with a new DOM, other than the browser DOM. This means that any React component that we write is inserted as a child to the virtual DOM.

You must be wondering, what why do we need this virtual DOM when we already have the browser DOM? The virtual DOM is the reason React renders so quickly and efficiently.

When we update the browser DOM (when not using React), it takes a significant amount of time to lay out the elements and repaint the screen for the user to see changes. This involves a huge section of the DOM tree being repainted.

But, when using React, updates happen in the virtual DOM first. Then, the browser DOM and virtual DOM are diffed or compared to see if there are any updates made to virtual DOM that must be reflected or updated in the browser DOM.

If there are any, only then are updates made to the browser DOM to match the virtual DOM. And these updates are only made at places where updates are to be carried out. This means that the entire browser DOM is not updated as previously mentioned. This improves speed and efficiency.

Only part of the DOM is getting updated, instead of whole
Advantages of React
Now that you know the main features of React, let's understand the advantages of using it.

Code Maintainability, because we can now reuse components and break complex logic into smaller parts.
Fast and Performant, because only part of the browser DOM is updated instead of the whole thing.
One way Data Flow, which means that data flow is possible only from the parent component to child components. That is, components are nested, with the top most component being App. This keeps everything modular.
Easy to learn and use, development time is less and learning curve is small.
Suppose you want to build a complex web application. You want it to be fast and performant, and you don't have a lot of time to develop it. In this case, React should be on top of your list!

Now you hopefully understand why React is so popular even though we can build a website with just HTML, CSS, and JavaScript.

Now let's see, how to set up React on your machine and create a brand new project.

How to Start a New React Project
Step 1 – Install Node
Before even thinking about React, you must have Node installed properly. This is because by installing Node you also get npm, which is a package manager for JavaScript. Think of it as an application you can use to download additional libraries, which you might need in your project.

Download and install it from here: https://nodejs.org/en/download/ (Download the LTS version).

After installation, open your terminal (Mac or Linux) or command prompt (Windows) and type in npm -v and it should output something like this:

Step 2 – Create your React app
Now, it's time to install a tool which makes it easy to build a React project. Congrats! You may have guessed that I'm talking about create-react-app.

Type in the command npm install create-react-app and wait for few seconds.

Step 3 – Set up your React web app
Now let's start setting up our very first React web application. Let's name it myreactapp.

For starting a new React project, type in the following command: npx create-react-app myreactapp.

The general syntax is npx create-react-app (and note that it's npx not npm, don't get confused :) ).

Continuation of above image

‌Step 4 – Open your new React app
Now it's time to see our React app in action. For that, move into the created project (myreactapp as we created it in the previous step) by using the command cd myreactapp and type in the following: npm start.

Now this command opens up a browser with our newly created React App:

And that's it! You have successfully setup React on your machine, and have started a brand new project.

And now you are ready to grasp bigger concepts in React! Happy hacking

You don’t always need a CMS

Smilepk — Tue, 08 Mar 2022 17:00:11 +0000

When it comes to websites, blogs, and whatnot, we often expect to find a CMS power these systems.

I get a lot of questions about what CMS powers my blog.
And I'll explain that while telling you why you don't always need a CMS.

What is a CMS
Let's first take a look at what a CMS is. It stands for "Content Management System", and as the name implies, it can be used to manage the content for a website.

Some famous CMSs are WordPress, Contentful, Wix, Shopify, etc.

There is a big rise of "headless" CMS, which means a CMS that serves as an API.
You have this system in place, and your website calls this API to retrieve the content.

CMSs are great for people who want to edit content and don't particularly know what to do with markdown, uploading files to a server, etc.

So when building websites for clients, it's often an excellent solution to pick a CMS that works for them.

What I run my blog on
I run my blog on a low-tech solution.
It has no CMS, but plain markdown files are parsed to plain HTML and uploaded to a server.

However, this is automated, so I don't have to do that physically, but there is still no content management system to alter the content.

So how does this work, you ask?

I open my project in my IDE of choice (Visual Studio Code, or WebStorm) and start changing my markdown files.
Either you edit the existing ones or create new ones for new blog posts.

Once I'm done, I push the changes to my git branch, which automatically triggers a GitHub action.

This GitHub action starts the build command on my Eleventy project (soon to be Astro), which converts all these markdown to HTML output.
Once this process is done, the HTML files get placed in a "static" branch.

Which trigger Cloudflare pages to pull the latest changes from this branch.
Cloudflare will do a git pull on this branch, and voila, the new changes are online!

This all happens in about a minute or so.

Why you don't always need a CMS
And for me, that's the main reason I don't need a CMS. It can be such an over-engineered solution.

I like to write content, markdown is the easiest way to write anyway, so I prefer it.

And once the content is written, I don't want to hassle with logging in to a system, copy-pasting the content and pressing publish.

(Although this is roughly the same amount of time)

Another downside to these systems is that they need upkeep. The CMS gets a new version, and you need to update it.
Something goes wrong, and you won't be able to push new content.
And worse of all, they can get hacked, meaning your website could be at risk.

Not saying it's impossible, but a static website is harder to hack. You would either need to hack my GitHub repo or my Cloudflare account, which are quite complex challenges.

Conclusion
I don't want to hate on CMS. They are a fantastic system that should be used.

But if you are a developer, consider if you need it?
Perhaps you can make your life easier, but going low-tech as well.

Thank you for reading, and let's connect!

How to Build and Deploy a Backend App with Express, Postgres, Github, and Heroku

Smilepk — Sat, 05 Mar 2022 20:55:37 +0000

In this article , we will be find how to build and deploy an image management application backend.

It will be able to store a record of an image in the database, get the image's record back from the database, update the record, and even delete the record completely as the case may be.

To achieve all of this, we will be using Express (a Node.js framework), Postgres (a database), Cloudinary (a cloud based image storage), GitHub (for version control/storage) and Heroku (a hosting platform).

These tools are all free. So you don’t have to bother about how to go about paying for them. Thanks to these great innovators.

Prerequisites
If you are new to most of these technologies, I would advise you go through my other tutorial on how to create a server and upload images to Cloudinary.

If you are totally to Postgres, then check out this tutorial.

Whenever you are ready, let’s get to work!

How to Store and Retrieve an Image Record
Create Database and Table
So you'll want to start by cloning this project if you don't already have it.

In your pgAdmin:

Create a database and name it tutorial
Create a table and name it tutorial
Create a Login/Group Role and name it tutorial. (Do not forget to give it all privileges.)
Back in your project directory, install the node-postgres (npm i pg) and make-runnnable (npm i make-runnable) packages.

In your package.json file, replace the contents of the

"scripts" with "create": "node ./services/dbConnect
createTables". We will use this to execute the dbConnect file we are about to create.

Create a services/dbConnect file to contain the following code:


const pg = require("pg");

const config = {
  user: "tutorial",
  database: "tutorial",
  password: "tutorial",
  port: 5432,
  max: 10, // max number of clients in the pool
  idleTimeoutMillis: 30000,
};

const pool = new pg.Pool(config);

pool.on("connect", () => {
  console.log("connected to the Database");
});

const createTables = () => {
  const imageTable = `CREATE TABLE IF NOT EXISTS
    images(
      id SERIAL PRIMARY KEY,
      title VARCHAR(128) NOT NULL,
      cloudinary_id VARCHAR(128) NOT NULL,
      image_url VARCHAR(128) NOT NULL
    )`;
  pool
    .query(imageTable)
    .then((res) => {
      console.log(res);
      pool.end();
    })
    .catch((err) => {
      console.log(err);
      pool.end();
    });
};

pool.on("remove", () => {
  console.log("client removed");
  process.exit(0);
});

//export pool and createTables to be accessible from anywhere within the application
module.exports = {
  createTables,
  pool,
};

require("make-runnable");

Now we are all set to create the table in our database. If you are ready, let's rock and roll!

Execute the following code in your terminal:

npm run create

If the image below is your result, then you are good to go:

Check your pgAdmin, and you should have your table seated properly in your database like in the image below:

Alright, it's been a long road. It's time to unite Node, Postgres, and Cloudinary.

How to Create Endpoints to Store and Retrieve Image Records
Endpoint 1: Persist Image
First, require the dbConnect.js file on the top of the app.js file like so:

const db = require('services/dbConnect.js');

Then in the app.js file, make a new endpoint (persist-image) with the following code:

// persist image
app.post("/persist-image", (request, response) => {
// collected image from a user
const data = {
title: request.body.title,
image: request.body.image,
}

// upload image here
cloudinary.uploader.upload(data.image)
.then().catch((error) => {
response.status(500).send({
message: "failure",
error,
});we
});
})

Replace the then block with the following code:

.then((image) => {
db.pool.connect((err, client) => {
// inset query to run if the upload to cloudinary is successful
const insertQuery = 'INSERT INTO images (title, cloudinary_id, image_url)
VALUES($1,$2,$3) RETURNING *';
const values = [data.title, image.public_id, image.secure_url];
})
})

The image.public_id and image.secure_url are gotten as part of the details returned for an image after the image has been successfully uploaded to Cloudinary.

We are now keeping a record of the image.public_id and image.secure_url (as you can see in the code above) in order to use it to retrieve, update, or delete the image record when we see fit.

Alright, let's move forward!

Still in the then block, add the following code under the query we created:

// execute query
client.query(insertQuery, values)
.then((result) => {
result = result.rows[0];

    // send success response
    response.status(201).send({
      status: "success",
      data: {
        message: "Image Uploaded Successfully",
        title: result.title,
        cloudinary_id: result.cloudinary_id,
        image_url: result.image_url,
      },
    })
  }).catch((e) => {
    response.status(500).send({
      message: "failure",
      e,
    });
  })

So our persist-image endpoint now looks like this:

// persist image
app.post("/persist-image", (request, response) => {
// collected image from a user
const data = {
title: request.body.title,
image: request.body.image
}

// upload image here
cloudinary.uploader.upload(data.image)
.then((image) => {
db.pool.connect((err, client) => {
// inset query to run if the upload to cloudinary is successful
const insertQuery = 'INSERT INTO images (title, cloudinary_id, image_url)
VALUES($1,$2,$3) RETURNING *';
const values = [data.title, image.public_id, image.secure_url];

  // execute query
  client.query(insertQuery, values)
  .then((result) => {
    result = result.rows[0];

    // send success response
    response.status(201).send({
      status: "success",
      data: {
        message: "Image Uploaded Successfully",
        title: result.title,
        cloudinary_id: result.cloudinary_id,
        image_url: result.image_url,
      },
    })
  }).catch((e) => {
    response.status(500).send({
      message: "failure",
      e,
    });
  })
})

}).catch((error) => {
response.status(500).send({
message: "failure",
error,
});
});
});

Now let's test out all our hard work:

Open your postman and test out your endpoint like the image below. Mine was successful. Hope yours had no errors too?

Alright, it's been a long road. It's time to unite Node, Postgres, and Cloudinary.

How to Create Endpoints to Store and Retrieve Image Records
Endpoint 1: Persist Image
First, require the dbConnect.js file on the top of the app.js file like so:

const db = require('services/dbConnect.js');
Then in the app.js file, make a new endpoint (persist-image) with the following code:

// persist image
app.post("/persist-image", (request, response) => {
// collected image from a user
const data = {
title: request.body.title,
image: request.body.image,
}

// upload image here
cloudinary.uploader.upload(data.image)
.then().catch((error) => {
response.status(500).send({
message: "failure",
error,
});
});
})

Replace the then block with the following code:

The image.public_id and image.secure_url are gotten as part of the details returned for an image after the image has been successfully uploaded to Cloudinary.

We are now keeping a record of the image.public_id and image.secure_url (as you can see in the code above) in order to use it to retrieve, update, or delete the image record when we see fit.

Alright, let's move forward!

Still in the then block, add the following code under the query we created:

// execute query
client.query(insertQuery, values)
.then((result) => {
result = result.rows[0];

    // send success response
    response.status(201).send({
      status: "success",
      data: {
        message: "Image Uploaded Successfully",
        title: result.title,
        cloudinary_id: result.cloudinary_id,
        image_url: result.image_url,
      },
    })
  }).catch((e) => {
    response.status(500).send({
      message: "failure",
      e,
    });
  })

So our persist-image endpoint now looks like this:

// persist image
app.post("/persist-image", (request, response) => {
// collected image from a user
const data = {
title: request.body.title,
image: request.body.image
}

  // execute query
  client.query(insertQuery, values)
  .then((result) => {
    result = result.rows[0];

    // send success response
    response.status(201).send({
      status: "success",
      data: {
        message: "Image Uploaded Successfully",
        title: result.title,
        cloudinary_id: result.cloudinary_id,
        image_url: result.image_url,
      },
    })
  }).catch((e) => {
    response.status(500).send({
      message: "failure",
      e,
    });
  })
})

}).catch((error) => {
response.status(500).send({
message: "failure",
error,
});
});
});

Now let's test out all our hard work:

Open your postman and test out your endpoint like the image below. Mine was successful. Hope yours had no errors too?

Alright, it's been a long road. It's time to unite Node, Postgres, and Cloudinary.

How to Create Endpoints to Store and Retrieve Image Records
Endpoint 1: Persist Image
First, require the dbConnect.js file on the top of the app.js file like so:

const db = require('services/dbConnect.js');
Then in the app.js file, make a new endpoint (persist-image) with the following code:

// persist image
app.post("/persist-image", (request, response) => {
// collected image from a user
const data = {
title: request.body.title,
image: request.body.image,
}

// upload image here
cloudinary.uploader.upload(data.image)
.then().catch((error) => {
response.status(500).send({
message: "failure",
error,
});
});
})

Replace the then block with the following code:

The image.public_id and image.secure_url are gotten as part of the details returned for an image after the image has been successfully uploaded to Cloudinary.

We are now keeping a record of the image.public_id and image.secure_url (as you can see in the code above) in order to use it to retrieve, update, or delete the image record when we see fit.

Alright, let's move forward!

Still in the then block, add the following code under the query we created:

// execute query
client.query(insertQuery, values)
.then((result) => {
result = result.rows[0];

    // send success response
    response.status(201).send({
      status: "success",
      data: {
        message: "Image Uploaded Successfully",
        title: result.title,
        cloudinary_id: result.cloudinary_id,
        image_url: result.image_url,
      },
    })
  }).catch((e) => {
    response.status(500).send({
      message: "failure",
      e,
    });
  })

So our persist-image endpoint now looks like this:

// persist image
app.post("/persist-image", (request, response) => {
// collected image from a user
const data = {
title: request.body.title,
image: request.body.image
}

  // execute query
  client.query(insertQuery, values)
  .then((result) => {
    result = result.rows[0];

    // send success response
    response.status(201).send({
      status: "success",
      data: {
        message: "Image Uploaded Successfully",
        title: result.title,
        cloudinary_id: result.cloudinary_id,
        image_url: result.image_url,
      },
    })
  }).catch((e) => {
    response.status(500).send({
      message: "failure",
      e,
    });
  })
})

}).catch((error) => {
response.status(500).send({
message: "failure",
error,
});
});
});

Now let's test out all our hard work:

Open your postman and test out your endpoint like the image below. Mine was successful. Hope yours had no errors too?

Open your Cloudinary console/dashboard and check your media Library. Your new image should be sitting there comfortably like mine below:

And now to the main reason why we are here: check the images table in your pgAdmin. Mine is what you see below:

Oohlala! We made it this far. Please take a break if you need one. I will be here waiting when you return. :)

If you are ready, then let's retrieve the image we persisted a moment ago.

Endpoint 2: Retrieve Image
Start with this code:

app.get("/retrieve-image/:cloudinary_id", (request, response) => {

});

Next, we will need to collect a unique ID from the user to retrieve a particular image. So add const { id } = request.params; to the code above like so:

app.get("/retrieve-image/:cloudinary_id", (request, response) => {
// data from user
const { cloudinary_id } = request.params;

});

Add the following code just below the code above:

db.pool.connect((err, client) => {
// query to find image
const query = "SELECT * FROM images WHERE cloudinary_id = $1";
const value = [cloudinary_id];
});

Under the query, execute the query with the following code:

// execute query
client
.query(query, value)
.then((output) => {
response.status(200).send({
status: "success",
data: {
id: output.rows[0].cloudinary_id,
title: output.rows[0].title,
url: output.rows[0].image_url,
},
});
})
.catch((error) => {
response.status(401).send({
status: "failure",
data: {
message: "could not retrieve record!",
error,
},
});
});

Now our retrieve-image API looks like this:

app.get("/retrieve-image/:cloudinary_id", (request, response) => {
// data from user
const { cloudinary_id } = request.params;

db.pool.connect((err, client) => {
// query to find image
const query = "SELECT * FROM images WHERE cloudinary_id = $1";
const value = [cloudinary_id];

// execute query
client
  .query(query, value)
  .then((output) => {
    response.status(200).send({
      status: "success",
      data: {
        id: output.rows[0].cloudinary_id,
        title: output.rows[0].title,
        url: output.rows[0].image_url,
      },
    });
  })
  .catch((error) => {
    response.status(401).send({
      status: "failure",
      data: {
        message: "could not retrieve record!",
        error,
      },
    });
  });

});
});

Let's see how well we did:

In your postman, copy the cloudinary_id and add it to the URL like in the image below:

YEEESSS! We can also retrieve our image.

If you are here, then you deserve a round of applause and a standing ovation for your industriousness.

Congratulations! You just reached a great milestone.

The code for storing and retrieving image records is here.

How to Update and Delete an Image Record
We will now see how to delete and update an image record as the case maybe. Let's begin with the delete endpoint.

Delete Endpoint
In the app.js file, start with the following code:

// delete image
app.delete("delete-image/:cloudinary_id", (request, response) => {

});

Next, we want to get the unique ID of the image we want to delete from the URL, that is cloudinary_id. So inside the code above add:

const { cloudinary_id } = request.params;

We now start the deleting process.

First, we delete from Cloudinary. Add the following code to delete the image from Cloudinary:

cloudinary.uploader
.destroy(cloudinary_id)
.then((result) => {
response.status(200).send({
message: "success",
result,
});
})
.catch((error) => {
response.status(500).send({
message: "Failure",
error,
});
});

At this point, our API can delete the image from Cloudinary only (you can check it out in postman). But we also want to get rid of the record we have in our Postgres database.

Second, we delete from our Postgres database. To do so, replace the code in the then block with the following query:

db.pool.connect((err, client) => {

  // delete query
  const deleteQuery = "DELETE FROM images WHERE cloudinary_id = $1";
  const deleteValue = [cloudinary_id];

})
Execute the query with the following code underneath it:

// execute delete query
client.query(deleteQuery, deleteValue)
.then((deleteResult) => {
response.status(200).send({
message: "Image Deleted Successfully!",
deleteResult
});
}).catch((e) => {
response.status(500).send({
message: "Image Couldn't be Deleted!",
e
});
});

So our Endpoint should look like this:

// delete image
app.delete("/delete-image/:cloudinary_id", (request, response) => {
// unique ID
const { cloudinary_id } = request.params;

// delete image from cloudinary first
cloudinary.uploader
.destroy(cloudinary_id)

// delete image record from postgres also
.then(() => {
  db.pool.connect((err, client) => {

  // delete query
  const deleteQuery = "DELETE FROM images WHERE cloudinary_id = $1";
  const deleteValue = [cloudinary_id];

  // execute delete query
  client
    .query(deleteQuery, deleteValue)
    .then((deleteResult) => {
      response.status(200).send({
        message: "Image Deleted Successfully!",
        deleteResult,
      });
    })
    .catch((e) => {
      response.status(500).send({
        message: "Image Couldn't be Deleted!",
        e,
      });
    });
  })
})
.catch((error) => {
  response.status(500).send({
    message: "Failure",
    error,
  });
});

});

The time has arrived for us to put our Endpoint to the test.

The following is my Cloudinary media library with two images I uploaded already. Take note of their unique ID (public_id).

If you don't already have that, please use the persist-image endpoint to upload some images.

Now let's proceed to postman:

Notice, the unique ID as it matches one of the image in my Cloudinary media library.

From the output, we executed the DELETE command and that deleted one ROW from our image TABLE in our database.

Now this is my media library with one of the images remaining:

Walahhhh... We are now able to get rid of an image.

Do take a break if you need one. ✌🏾

If you are ready, I am ready to update images.

Update Image API
Below the delete-image API, let's start creating the update-image API with the following code:

// update image
app.put("/update-image/:cloudinary_id", (request, response) => {

});

All codes will live in there.

Collect the unique Cloudinary ID and new image details from the user with the following code:

// unique ID
const { cloudinary_id } = request.params;

// collected image from a user
const data = {
title: request.body.title,
image: request.body.image,
};

Delete the image from Cloudinary with the following code:

// delete image from cloudinary first
cloudinary.uploader
.destroy(cloudinary_id)
// upload image here
.then()
.catch((error) => {
response.status(500).send({
message: "failed",
error,
});
});

Next, upload another image to Cloudinary. To do that, enter the following code into the then block:

() => {
cloudinary.uploader
.upload(data.image)
.then()
.catch((err) => {
response.status(500).send({
message: "failed",
err,
});
});
}

Now let's replace our initial record with the new image details. Replace the content of the then block with the following:

(result) => {
db.pool.connect((err, client) => {

        // update query
        const updateQuery =
          "UPDATE images SET title = $1, cloudinary_id = $2, image_url = $3 WHERE cloudinary_id = $4";
        const value = [
          data.title,
          result.public_id,
          result.secure_url,
          cloudinary_id,
        ];
      });
    }

We execute the query using the following code just beneath the query declaration:

// execute query
client
.query(updateQuery, value)
.then(() => {

            // send success response
            response.status(201).send({
              status: "success",
              data: {
                message: "Image Updated Successfully"
              },
            });
          })
          .catch((e) => {
            response.status(500).send({
              message: "Update Failed",
              e,
            });
          });

At this point, this is what I have:

// update image
app.put("/update-image/:cloudinary_id", (request, response) => {
// unique ID
const { cloudinary_id } = request.params;

// collected image from a user
const data = {
title: request.body.title,
image: request.body.image,
};

// delete image from cloudinary first
cloudinary.uploader
  .destroy(cloudinary_id)

  // upload image here
  .then(() => {
    cloudinary.uploader
      .upload(data.image)

      // update the database here
      .then((result) => {
        db.pool.connect((err, client) => {
        // update query
        const updateQuery =
          "UPDATE images SET title = $1, cloudinary_id = $2, image_url = $3 WHERE cloudinary_id = $4";
        const value = [
          data.title,
          result.public_id,
          result.secure_url,
          cloudinary_id,
        ];

        // execute query
        client
          .query(updateQuery, value)
          .then(() => {

            // send success response
            response.status(201).send({
              status: "success",
              data: {
                message: "Image Updated Successfully"
              },
            });
          })
          .catch((e) => {
            response.status(500).send({
              message: "Update Failed",
              e,
            });
          });
        });
      })
      .catch((err) => {
        response.status(500).send({
          message: "failed",
          err,
        });
      });
  })
  .catch((error) => {
    response.status(500).send({
      message: "failed",
      error,
    });
  });

});

It's testing time!

This is my postman in the image below:

Take note of the unique cloudinary ID which matches the image left in my Cloudinary media library.

Now take a look at my Cloudinary media library in the image that follows:

Take note of the new image replacing the initial one in my media library above.

Also, see that the unique Cloudinary ID matches that in my database with the new title. See image below:

Yayeh! You did awesomely great! 💪

We just completed an image management application with Node.js, Cloudinary and Postgres.

Code Optimisation With Express Routing
Express Routing enables us to make our Node.js code more optimized or give it a more modular structure by separating the business logic from the controllers. We want to use that to clean up our code so far.

We'll begin by creating a new folder with the name routes in the root directory:

mk dir routes

In the routes folder, create a file with the name: routes.js.

For Windows:

echo . > routes.js

For Mac:

touch routes.js

Empty the routes.js file if anything is there and enter the following code:

const express = require('express');

const router = express.Router();

module.exports = router;

Add the following code above the last line:

const cloudinary = require("cloudinary").v2;
require("dotenv").config();
const db = require("../services/dbConnect.js");

// cloudinary configuration
cloudinary.config({
cloud_name: process.env.CLOUD_NAME,
api_key: process.env.API_KEY,
api_secret: process.env.API_SECRET,
});

Back in the App.js file, delete the following code:

const cloudinary = require("cloudinary").v2;
require("dotenv").config();
const db = require("./services/dbConnect.js");

// cloudinary configuration
cloudinary.config({
cloud_name: process.env.CLOUD_NAME,
api_key: process.env.API_KEY,
api_secret: process.env.API_SECRET,
});

Move all the APIs to routes.js.

Change all occurence of app to router carefully.

My routes.js file now looks like this.

Back in the app.js file, import the routes.js file like so:

// import the routes file
const routes = require("./routes/routes")

Now register the routes like so:

// register the routes
app.use('/', routes);

This is my app.js file at the moment:

const express = require("express");
const app = express();

// import the routes file
const routes = require("./routes/routes")

// body parser configuration
const bodyParser = require("body-parser");
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

// register the routes
app.use('/', routes);

module.exports = app;

It's time to test and see if our routes are still working like before.

Make sure yours are working like mine below:

persist-image

update-image

delete-image

Wow! We have been able to separate our routes from our app.js file.

The code for this is here.

Even though our routes.js file is still lengthy, we have a good basis to separate our business logic from our controllers. The time has arrived to do just that.

How to Move Each Endpoint to a Different File
Begin by creating a new folder in the routes folder and name it controllers.

In the controllers folder, create 5 files and name them after the 5 endpoints.

Our folder and files should be structured as follows:

Back in the routes.js file, let's work on the image-upload API. Cut the following code:

(request, response) => {
// collected image from a user
const data = {
image: request.body.image,
};

// upload image here
cloudinary.uploader
.upload(data.image)
.then((result) => {
response.status(200).send({
message: "success",
result,
});
})
.catch((error) => {
response.status(500).send({
message: "failure",
error,
});
});
}

In the imageUpload file, equate the code you already cut from the image-upload endpoint to exports.imageUpload like so:

exports.imageUpload = (request, response) => {
// collected image from a user
const data = {
image: request.body.image,
};

// upload image here
cloudinary.uploader
  .upload(data.image)
  .then((result) => {
    response.status(200).send({
      message: "success",
      result,
    });
  })
  .catch((error) => {
    response.status(500).send({
      message: "failure",
      error,
    });
  });

}

Now let's import what is necessary for this code to work. So this is my imageUpload file right now:

const cloudinary = require("cloudinary").v2;
require("dotenv").config();

// cloudinary configuration
cloudinary.config({
cloud_name: process.env.CLOUD_NAME,
api_key: process.env.API_KEY,
api_secret: process.env.API_SECRET,
});

exports.imageUpload = (request, response) => {
// collected image from a user
const data = {
image: request.body.image,
};

// upload image here
cloudinary.uploader
  .upload(data.image)
  .then((result) => {
    response.status(200).send({
      message: "success",
      result,
    });
  })
  .catch((error) => {
    response.status(500).send({
      message: "failure",
      error,
    });
  });

}

Let's import and register the imageUpload API in the routes.js file like so:

const imageUpload = require("./controllers/imageUpload");

// image upload API
router.post("image-upload", imageUpload.imageUpload);

Now we have this line of code pointing to the imageUpload API in the imageUpload.js file from the routes.js file.

How awesome! Our code is more readable.

Make sure to test the API to be sure it's working properly. Mine works perfectly. See image below:

Now, it's your turn!

Apply what you have learnt to the other APIs. Let's see what you have got.

I will be waiting on the other side...

If you are here, then I believe you have done yours and they're working perfectly – or at least, you already gave it your best shot. Kudos!

Checkout mine here.

Congratulations. You are awesome :)

The code optimisation code is here.

Alright, on to the next step.

How to Deploy to GitHub And Heroku
Now that we've completed our application, let's deploy it on Heroku so that we can access it even without being on our laptop where the code was written.

I will be walking you through uploading our application to GitHub and deploying it to Heroku.

Without further ado, let's get our hands dirty.

How to Upload the Code to GitHub
Uploading or pushing to GitHub is as easy as eating your favorite meal. Check out this resource to learn how to push your project from you local machine to GitHub.

How to Deploy to Heroku
Let's begin by creating an account on Heroku.

If you have created an account, you may have been prompted to create an app (that is a folder where your app will be housed). You can do that, but I will do mine using my terminal since the terminal comes with a few added functionalities that we will need later.

Open your project in a terminal if you have not done so already. I will be using the VS Code integrated terminal.

Install Heroku CLI:

npm install heroku

heroku login

Create an app. It can have any name. I am using node-postgres-cloudinary.

heroku create node-postgres-cloudinary

Go to your Heroku dashboard and you will find the newly created app.

Waalaah!

That is how mine looks in the image above. I have some apps there already but you can see the one I just created.

Let's now add the PostgreSQL database to the app.

How to Add Heroku Postgres
Click on the app you just created. It will take you to the app's dashboard.

Click on the Resources tab/menu

In the Add-ons Section, search and select Heroku Postgres.

Make sure you select the Hobby Dev - Free plan in the pop-up window that follows:

Click on the provision button to add it to the app like so:

Click on the Heroku Postgres to take you to the Heroku Postgres dashboard.

Click on the settings tab:

Click on View Credentials:

In the Credentials, we are interested in the Heroku CLI. We will be using it in a bit

Back to the terminal.

Let's confirm if the Heroku Postgres was added successfully. Enter the following in the terminal:

heroku addons

Yeeeeaaaah! It was added successfully.

Before we proceed, make sure that your PostgreSQL path is set correctly if you are on Windows. Follow this link to learn how to set a path. The path should be like this: C:\Program Files\PostgreSQL<VERSION>\bin.

The version will depend on the one installed on you machine. Mine is: C:\Program Files\PostgreSQL\12\bin since I am using the version 12.

The following image might be helpful:

You may have to navigate to the folder where PostgreSQL is installed on your machine to find out your own path.

Login into the Heroku Postgres using the Heroku CLI from our Heroku Postgres credentials. This is mine – yours will be different:

heroku pg:psql postgresql-slippery-19135 --app node-postgres-cloudinary
If you got an error, it is most likely because your path is not set properly.

How to Prepare our Database Connection to Match Heroku's
At the moment, my database looks like this:

const pg = require("pg");

const config = {
user: "tutorial",
database: "tutorial",
password: "tutorial",
port: 5432,
max: 10, // max number of clients in the pool
idleTimeoutMillis: 30000,
};

const pool = new pg.Pool(config);

pool.on("connect", () => {
console.log("connected to the Database");
});

If you try connecting Heroku to this, you are going to get an error. This is because Heroku has a connection string setup already. So we have to setup our connection such that Heroku can easily connect.

I am going to refactor my database connection file (dbConnect.js) and .env file to make this happen.

dbConnect.js

const pg = require('pg');
require('dotenv').config();

// set production variable. This will be called when deployed to a live host
const isProduction = process.env.NODE_ENV === 'production';

// configuration details
const connectionString = postgresql://${process.env.DB_USER}:${process.env.DB_PASSWORD}@${process.env.DB_HOST}:${process.env.DB_PORT}/${process.env.DB_DATABASE};

// if project has been deployed, connect with the host's DATABASE_URL
// else connect with the local DATABASE_URL
const pool = new pg.Pool({
connectionString: isProduction ? process.env.DATABASE_URL : connectionString,
ssl: isProduction,
});

// display message on success if successful
pool.on('connect', () => {
console.log('Teamwork Database connected successfully!');
});

.env file

DB_USER="tutorial"
DB_PASSWORD="tutorial"
DB_HOST="localhost"
DB_PORT="5432"
DB_DATABASE="tutorial"

With the setup of the dbconnect and .env file, we are ready to export our database and tables from our local machine to heroku postgres.

How to Export Database and Tables
Go to your pgAdmin and locate the database for this tutorial. Mine is tutorial.

Right-Click on it and select Backup. This will bring up a new window.

Enter a name for the SQL file like I did. Select the plain format. Then click Backup. This will save the file to your documents folder.

Locate the file and move it into the project directory. It can be anywhere in the directory but I choose to move mine into the services directory because it holds the database related files.

Back in the terminal, navigate to the folder containing the SQL file and run the following code to add the tables we just exported to the heroku postgres database:

cat |
This is what mine looks like:

cat tutorial.sql | heroku pg:psql postgresql-slippery-19135 --app node-postgres-cloudinary

Did you notice that I changed directory to services (cd services)? That is where my sql file is located.

Wow! We have just successfully exported our database and tables to Heroku.

It is almost over...

How to Tell GitHub that We Made Changes
Add the files we have made changes to:

$ git add .
The period (.) adds all files.

Commit your latest changes:

$ git commit -m "refactored the dbConnect and .env file to fit in to heroku; Added the database SQL file"
Push the committed files:

$ git push origin -u master

Finally deploying our App
Go to you app's dashboard:

Search and select a repo, and click on connect:

Select the branch you want to deploy (in my own case, it is the master branch):

Enable automatic deployment by clicking the Enable automatic deployment button as in the image above.

Click on the Deploy button in the manual deploy

We will not have to do all this for subsequent deployments.

Now you have a button telling you to "view site" after build is completed. Click it. This will open your app in a new tab

Oh no! A bug? Application error??

Don't worry, it just a small issue. Something you should never forget to do while making deployments. Most hosting service will require it.

How to Fix the Heroku Application Error
Get back to the root directory of your project.

Create a file and name it Procfile (it has no extension).

In the file, enter the following code:

web: node index.js

This directs Heroku to the server file (index.js) which is the entry point of the application. If your server is in a different file, please modify as required.

Save the file and push the new changes to GitHub.

Wait 2 to 5 minutes for Heroku to automatically detect changes in your GitHub repo and render the changes on the app.

You can now refresh that error page and see your hard work paying off:

You can also test the retrieve image route and see it working.

Congratulations! What a feat you have attained.

Other routes (persist-image, update-image, and delete-image) will not be working because we have not provisioned or added cloudinary add-on. It is as simple as the PostgreSQL one we just did. So you can give it a shot.

Conclusion
We started this tutorial with the aim of learning how to build a backend application using Express, Postgres, Cloudinary, Github and Heroku.

We learned how to store, retrieve, delete, and update an image record. We then organised our code with Express Routing, pushed it to GitHub, and deployed it on Heroku. That was a lot.

I hope you will agree that it was worth it because we learnt a lot. You should try adding the Cloudinary add-on yourself to sharpen your knowledge even more.

Thanks for reading!

React Context API vs Zustand State Manager

Smilepk — Sat, 19 Feb 2022 17:37:31 +0000

This article will show a practical performance comparison between the usage of React Context API and the Zustand State Manager library by solving one scenario with the above-mentioned approaches.
In the production level frontend application that uses React JS, we may need to manage the state. Indeed that is why we focus on frontend frameworks or libraries most of the time. When it comes to the manage our application state globally, we meet lots of state managers or state management patterns and utilities. As we know React JS is quite statable in the market and because of that we can get multiple approaches to manage our frontend application’s state. In this article, I am going to compare the React Context API and the Zustand State Manager with a practical example.
First of all, let's understand what we are going to build.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9gp69pmk8bopcio77kxw.png)

This application contains two main components that show the final winner called the winner component. It will compare the scores achieved by Player A and Player B then show the real-time results. Individual Player' component has their own behavior. By pressing those plus and minus icon buttons scores of each team will be increased or decreased respectively.
I am going to create a Next.js Application for this demo. with that, I will create two routes one for the solution with Context API and the other with the Zustand.


npx create-next-app@latest
# or
yarn create next-app

yarn create next-app
Create a new Next.js Application using the above command and give it a proper name in the installation process. after completing the installation get your app up and running. Then under the pages directory, I created two files called “context-page” and “zustand-page”

Let's take our first approach using Context API.
This is how we keep the Player scores in the store.


{
     teamA, // Team A's score
     teamB, // Team B's score
     increaseTeamAScore, // Increase Team A's score by one
     decreaseTeamAScore, // Decrease Team A's score by one
     increaseTeamBScore, // Increase Team B's score by one
     decreaseTeamBScore, // Decrease Team B's score by one
}

By keeping in mind of above store design, let’s create our context.

Now we are going to create context-page.js file. This will include the components that we talk earlier with a diagram.

Easy Peasy..!! We Created our first solution with Context API. Go to the route below and check the functionality. Since we are
http://localhost:3000/context-page

Okay, now you can see our solution's appearance is fine and working as we expected. Let’s have a look at this solution from a performance perspective. To do that first of all I am going to term on the “Highlight updates when components render.” feature that comes with React Dev Tools Profiler. I’ll go to the Profiler tab and then click on the Gear icon placed on the top right side. Then I will check the option.

Once that option is enabled, you can see that highlighted sections. It is happening because when we wrap the component tree with Context, it will always rerender all components under the Context Prover when the context change happens.
When we increase or decrease the score of Team A, actually we do not need to rerender the Team B components. since the entire components are wrapped with the StoreContextProvider and actions have done to the Team A component will affect to context, the Team B component also going to reprint. That is why the Team B component also going to be highlighted by the Profiler.
Because scores are compared inside the Winner component, it should rerender. But we do not need to rerender the Team B component. That is the issue with the Context API. It is going to rerender the entire scope that is wrapped with the context provider. But in the real world, we are expecting to rerender changed components only.
To overcome such scenarios, We can take different actions. We can use state managers such as Zustand or libraries like “use-context-selector”. In today's post, I am going to use the Zustand state manager library to overcome this issue.
The store design is the same as above and let's have a deep dive in the Zustand library.
Create a Zustand store.

You can see it is easy to create our store with Zustand and create all action methods to deal with the state. Now we will see how to subscribe a component to the store.

You can see how easily we can subscribe to the store that we created. That is the power of Zustand. It is a small, fast, and scalable barebones state-management solution using simplified flux principles according to their documentation and now we know because we started to use that too.
With the above introduction to Zustand, Let’s create our solution with the help of Zustand. First of all, install the package to our Application.
yarn add zustan # or dnpm install zustand
Then let’s create the “zustand-page.js” file with the solution.

Okay, we have addressed the same problem but with a different solution. We can see the expected behavior achieved and now let’s see how the rerendering happens.

According to the Profiler, now you can see how the rerenders happen. With the help of Zustand, we have achieved the perfoamce issue too. And the creation of the store and subscribing to the Components are also pretty straightforward.
There are a lot more features offered with the Zustand. You can go through their documentation and find more.
Thank you for reading 🙏.
It would help me a lot 😁
React
React Context Api
Prop Drilling

Context Api
3

Control React Applications From Cypress Tests

Smilepk — Thu, 17 Feb 2022 11:56:03 +0000

How to access and change the internal component state from end-to-end tests using cypress-react-app-actions.
In the previous blog post Access React Components From Cypress E2E Tests I have shown how the test code could get to the React component's internals, similar to what the React DevTools browser extension does. In this blog post, I will show how to use this approach to drastically speed up end-to-end tests. The idea is to control the application by setting its internal state rather than using the page UI in every test. We will split a single long test into individual tests, each starting the app where it needs it to be in an instant, rather than going through already tested UI commands. It is similar to what I have shown a long time ago in the blog post Split a very long Cypress test into shorter ones using App Actions. But the approach described in this blog post does not need any modifications to the application code, which is a big deal.

A single long test #

Imagine our application contains several forms to fill. The test has to fill the first page before the second page appears. Once the second page is filled, the third page is shown. After filling the third page, the form is submitted and the test is done


cypress/integration/single-test.js

/// <reference types="cypress" />
const typeOptions = { delay: 35 }

it('books hotel (all pages)', () => {
  cy.visit('/')

  cy.log('**First page**')
  cy.contains('h1', 'Book Hotel 1')

  cy.get('#first').type('Joe', typeOptions)
  cy.get('#last').type('Smith', typeOptions)
  cy.get('#email').type('my-email@foo.bar', typeOptions)

  cy.get('#field1a').type('Field 1a text value', typeOptions)
  cy.get('#field1b').type('Field 1b text value', typeOptions)
  cy.get('#field1c').type('Field 1c text value', typeOptions)
  cy.get('#field1d').type('Field 1d text value', typeOptions)
  cy.get('#field1e').type('Field 1e text value', typeOptions)

  cy.contains('Next').click()

  cy.log('**Second page**')
  cy.contains('h1', 'Book Hotel 2')
  // we are on the second page

  cy.get('#username').type('JoeSmith', typeOptions)
  cy.get('#field2a').type('Field 2a text value', typeOptions)
  cy.get('#field2b').type('Field 2b text value', typeOptions)
  cy.get('#field2c').type('Field 2c text value', typeOptions)
  cy.get('#field2d').type('Field 2d text value', typeOptions)
  cy.get('#field2e').type('Field 2e text value', typeOptions)
  cy.get('#field2f').type('Field 2f text value', typeOptions)
  cy.get('#field2g').type('Field 2g text value', typeOptions)
  cy.contains('Next').click()

  cy.log('**Third page**')
  cy.contains('h1', 'Book Hotel 3')

  cy.get('#field3a').type('Field 3a text value', typeOptions)
  cy.get('#field3b').type('Field 3b text value', typeOptions)
  cy.get('#field3c').type('Field 3c text value', typeOptions)
  cy.get('#field3d').type('Field 3d text value', typeOptions)
  cy.get('#field3e').type('Field 3e text value', typeOptions)
  cy.get('#field3f').type('Field 3f text value', typeOptions)
  cy.get('#field3g').type('Field 3g text value', typeOptions)
  cy.contains('button', 'Sign up').click()

  cy.contains('button', 'Thank you')
})

The above test takes almost 19 seconds to finish. Of course, it is the slowest end-to-end test in the world, but you have to sit and wait for it, even if you are only interested in changing how it tests the form submission for example.

The app state after the first page #

All the fields we fill on the first page go into the internal state of the application. The application creates a form for each page and passes the change handler function as a prop.


index.js
import Step1 from './Step1.jsx'

handleChange = (event) => {
  const { name, value } = event.target
  this.setState({
    [name]: value,
  })
}

handleSubmit = (event) => {
  event.preventDefault()

  console.log('submitting state', this.state)

  const { email, username } = this.state

  this.setState({
    submitted: true,
  })

  alert(`Your registration detail: \n
          Email: ${email} \n
          Username: ${username}`)
}

<Step1
  currentStep={this.state.currentStep}
  handleChange={this.handleChange}
  email={this.state.email}
/>
<Step2
  currentStep={this.state.currentStep}
  handleChange={this.handleChange}
  username={this.state.username}
/>
<Step3
  currentStep={this.state.currentStep}
  handleChange={this.handleChange}
  password={this.state.password}
  submitted={this.state.submitted}
/>

Thus we can validate that the Step1 component is working correctly by checking the state after we fill the form through the page.


cypress/integration/actions.js

beforeEach(() => {
  cy.visit('/')
})

it('first page', () => {
  cy.log('**First page**')
  cy.contains('h1', 'Book Hotel 1')

  cy.get('#first').type('Joe', typeOptions)
  cy.get('#last').type('Smith', typeOptions)
  cy.get('#email').type('my-email@foo.bar', typeOptions)

  cy.get('#field1a').type('Field 1a text value', typeOptions)
  cy.get('#field1b').type('Field 1b text value', typeOptions)
  cy.get('#field1c').type('Field 1c text value', typeOptions)
  cy.get('#field1d').type('Field 1d text value', typeOptions)
  cy.get('#field1e').type('Field 1e text value', typeOptions)

  cy.contains('Next').click()

  cy.log('Second page')
  cy.contains('h1', 'Book Hotel 2')
})

We are testing the page just like a human user would - by going to each input field and typing text. Once the fields are filled, we click the button "Next" and check if we end up on the second page. But how do we check if the values we typed really were stored correctly by the application?

By getting access to the application state through React internals. I wrote cypress-react-app-actions plugin that gets to the React component from a DOM element, similar to how React DevTools browser extension works.


$ npm i -D cypress-react-app-actions
+ cypress-react-app-actions@1.0.2

We should import the plugin from our spec or from the support file


/ https://github.com/bahmutov/cypress-react-app-actions
import 'cypress-react-app-actions'
// now we can use the child command .getComponent()

Let's see what fields the component has at the end of the test above.

cy.log('Second page')
cy.contains('h1', 'Book Hotel 2')
cy.get('form')
  .getComponent()
  .its('state')
  .then(console.log)

``

The application state object after finishing step one

Tip: you can see all component fields and methods by printing it to the console with cy.get('form').getComponent().then(console.log) command.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lsj0svk123alg2y2a1wb.png)

The component's state should always include the field values we have typed, so let's verify this. We could use "deep.equal" or "deep.include" assertion, or even cy-spok here.

cypress/integration/actions.js

const startOfSecondPageState = {
currentStep: 2,
email: 'my-email@foo.bar',
field1a: 'Field 1a text value',
field1b: 'Field 1b text value',
field1c: 'Field 1c text value',
field1d: 'Field 1d text value',
field1e: 'Field 1e text value',
first: 'Joe',
last: 'Smith',
username: '',
}

beforeEach(() => {
cy.visit('/')
})

it('first page', () => {
...
cy.contains('Next').click()

cy.log('Second page')
cy.contains('h1', 'Book Hotel 2')
cy.get('form')
.getComponent()
.its('state')
.should('deep.equal', startOfSecondPageState)
})


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m0ytmdw6r0qdm8gygock.png)

// the end of the first test
cy.get('form')
.getComponent()
.its('state')
.should('deep.equal', startOfSecondPageSt


Thus we can set the app's state to the object startOfSecondPageState and the application will behave as if we went through the form, filling it by typing. It is the same application behaviour.

beforeEach(() => {
cy.visit('/')
})

it('second page', () => {
cy.get('form').getComponent().invoke('setState', startOfSecondPageState)

cy.log('Second page')
cy.contains('h1', 'Book Hotel 2')
// start filling input fields on page 2
cy.get('#username').type('JoeSmith', typeOptions)
cy.get('#field2a').type('Field 2a text value', typeOptions)
cy.get('#field2b').type('Field 2b text value', typeOptions)
cy.get('#field2c').type('Field 2c text value', typeOptions)
cy.get('#field2d').type('Field 2d text value', typeOptions)
cy.get('#field2e').type('Field 2e text value', typeOptions)
cy.get('#field2f').type('Field 2f text value', typeOptions)
cy.get('#field2g').type('Field 2g text value', typeOptions)
cy.contains('Next').click()

cy.log('Third page')
cy.contains('h1', 'Book Hotel 3')
})


[](https://glebbahmutov.com/blog/images/react-app-actions/second.gif)

Beautiful. How does the application finish? Again - it has a certain internal state we can verify.

const startOfThirdPageState = {
...startOfSecondPageState,
currentStep: 3,
username: 'JoeSmith',
field2a: 'Field 2a text value',
field2b: 'Field 2b text value',
field2c: 'Field 2c text value',
field2d: 'Field 2d text value',
field2e: 'Field 2e text value',
field2f: 'Field 2f text value',
field2g: 'Field 2g text value',
}
...
cy.log('Third page')
cy.contains('h1', 'Book Hotel 3')
cy.get('form')
.getComponent()
.its('state')
.should('deep.equal', startOfThirdPageState)


The third page #

We similarly start the third test to verify we can fill the form on the third page. We set the state to the same state object the second test has finished with. Even better - we know the user will submit the form, so we can spy on the component's method handleSubmit.

it('third page', () => {
cy.get('form')
.getComponent()
.then((comp) => {
cy.spy(comp, 'handleSubmit').as('handleSubmit')
})
.invoke('setState', startOfThirdPageState)

cy.log('Third page')
cy.contains('h1', 'Book Hotel 3')
...
cy.contains('button', 'Sign up').click()
cy.contains('button', 'Thank you')

cy.get('form').parent().getComponent().its('state').should('deep.include', {
submitted: true,
username: 'JoeSmith',
})

// the spy is called once
cy.get('@handleSubmit').should('be.calledOnce')
})



[](https://glebbahmutov.com/blog/images/react-app-actions/second.gif)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/38ql60juorhbzn2vz9i6.png)

The third test verifies the form was submitted

It is up to the developer to decide which application internal properties to verify.

Invoking app actions #

We can verify the internal application state and we can call the component's methods. For example, we can call the form's submit method ourselves.

Build Decoupled React Components with Inversion of Control

Smilepk — Mon, 07 Feb 2022 10:47:33 +0000

Imagine you’re implementing an e-commerce checkout, and the product manager has temporally chosen PayPal as payment provider. But it’s planned to change the provider for another one, e.g.: Stripe. Looking for small changes in the future, how would you implement this?
Inversion of Control (IoC) probably will help you in this case.
What is IoC?
IoC is a programming principle where you invert the control flow of a program, it’s used to decouple your code. You can read more about here, let’s go code.

You have the checkout.component.tsx that is responsible for creating the checkout flow. It renders the product list, total of payment and the payment form that is provided by PayPal.


interface Props {}

const CheckoutComponent = (props: Props) => {
  const [products, setProducts] = useState([...products]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState('');

  const total = useMemo(() => ...total, []);

  const onPayError = () => { ... };

  const onPaySuccess = () => { ... };

  const onPay = () => {
     paypal.someMethod(onPaySuccess, onPayError);
  };

  // All the payment stuff goes here

  return (
    <div>
      <div>
        Products:
        <ul>
          {products.map(product => <li key={product.id}>{product.name} - U${product.price}</li>)}
        </ul>
        <p>Total: U${total}</p>
      </div>
      <PaypalForm />
    </div>
  );
};

The problem here is that your checkout flow knows about PayPal, and that can generate a huge refactor in the future.
To prevent this, you can use ElementType and interfaces.


interface ProviderProps {
  onPaymentSucceed: () => void;
  onPaymentError: (error: string) => void;
  onPaymentStart: () => void;
  ... any prop here
}

interface ComponentProps {
  provider: JSX ElementConstructor<ProviderProps>;
}

ProviderProps ensure that any provider will implement the correct methods. ComponentProps forces the checkout flow to receive a provider and mount it, passing the given props.
Now we can create a “dumb” component that knows how to control the screen state, like loading and feedback.


const CheckoutComponent = ({ provider: Provider }: ComponentProps) => {
  const [products, setProducts] = useState([...products]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState('');

  const total = useMemo(() => ...total, []);

  const onPaymentError = (error: string) => setError(error);

  const onPaymentSucceed = () => redirectToHome();

  const onPaymentStart = () => setLoading(true);

  return (
    <div>
      <div>
        Products:
        <ul>
          {products.map(product => <li key={product.id}>{product.name} - U${product.price}</li>)}
        </ul>
        <p>Total: U${total}</p>
      </div>
      <Provider
        onPaymentStart={onPaymentStart}
        onPaymentSucceed={onPaymentSucceed}
        onPaymentError={onPaymentError}
      />
    </div>
  );
};

And the responsible for managing the payment with PayPal can be isolated, totally decoupling the code.


const PayPalProvider = ({ onPaymentSucceed, onPaymentError, onPaymentStart }: ProviderProps) => {
  const handlePayment = () => {
    onPaymentStart();

    paypal.someMethod()
      .then(() => {
        onPaymentSucceed();
      })
      .catch(error => {
        onPaymentError(error.message);
      });
  };

  return (
    <form onSubmit={handlePayment}>
      <PayPalForm />
      <button type="submit">Pay</button>
    </form>
  );
};

Now, you can create a simple container that mount the checkout component and pass the correct props.


import PayPalContainer from './paypal.container';

const CheckoutContainer = () => (
  <CheckoutComponent provider={PayPalContainer} // any props here />
);

You can even create a factory method that returns the correct provider in a scenario you have more than one.


export enum Provider {
  PAYPAL = "PAYPAL",
  STRIPE = "STRIPE"
}

const getSelectedProvider = (): Provider => {...};

const getProviderContainer = (provider: Provider) => {
  switch (provider) {
    case Provider.PAYPAL:
      return PayPalContainer;
    case Provider.STRIPE:
      return StripeProvider;
  }
};

const CheckoutContainer = () => {
  const provider = getSelectedProvider();

  return <CheckoutComponent provider={getProviderContainer(provider)} />;
};

I hope that this article helped you to understand how to use inversion of control with react and how to decouple your code to be more maintainable.

Build with independent components, for speed and scale
Instead of building monolithic apps, build independent components first and compose them into features and applications. It makes development faster and helps teams build more consistent and scalable applications.
OSS Tools like Bit offer a great developer experience for building independent components and composing applications. Many teams start by building their Design Systems or Micro Frontends, through independent components. Give it a try →

Understanding React Lifecycles

Smilepk — Tue, 01 Feb 2022 18:17:04 +0000

Simply and directly, lifecycle refers to the 3 stages that a React component goes through during its existence.
Every component in React goes through three stages which are:

Mounting
Update
Unmounting

It is important that you, as a React developer, know these 3 phases and what methods are associated with each of them. These methods can be overwritten in class components to perform side effects and manage the state of the component.
Let’s take a look at these methods in each of the phases:
Mounting
This is the initial phase of any component. It corresponds to the moment when the component will be inserted in the DOM. That is, when it starts to exist on your browser’s screen.
In this phase there are 4 methods that are executed in the following order:

contructor()
getDerivedStateFromProps()
render()
componentDidMount()

Of these methods, only the third (render) is mandatory when creating a class component. The others are left to the developer to implement or not in their component.

The first, constructor, is used in React components to set the initial state value.
The getDerivedStateFromProps method is used for one purpose only: It allows a component to update its state through a change of props. See two examples of its use here. In the following example I set the state of the counter with the value passed in the prop.
The third and only mandatory is render. When called, it must examine this.props and this.state and return one of the following types: a React element, a Portal, a string, a number, a boolean, or the value null. The render method should remain pure, that is, do not create side effects (such as API calls) in it.

Today it is no longer necessary for you to call the constructor to initialize a state, which eliminates the need for it.
The getDerivedStateFromProps method adds some complexity to our component and overall you won’t need to use it.
This post on the React blog indicates why not to use derived state
Updating
When the component overwrites some props change (i.e. its parent component passes new props) or when the internal state overwrites a change (by this.setState({}) for example) the component enters the updating phase.
Just like in the assembly phase, a defined sequence of methods will be called. They are:
getDerivedStateFromProps()
shouldComponentUpdate()
render()
getSnapshotBeforeUpdate()
componentDidUpdate()
The first method, getDerivedStateFromProps we already know and covered in the assembly phase. Its behavior is the same here in the update phase.

The second method, shouldComponentUpdate will determine whether the methods in the sequence are executed or not. That is, it will determine whether the component should be rendered again or not. This method exists only as a way for us to avoid unnecessary updating, and thus optimize the performance of our applications.
If the this.forceUpdate() method has been called the update will not call shouldComponentUpdate, and the component will be forcefully updated as the name implies.
getSnapshotBeforeUpdate is then called just before the most recently rendered output is committed. It allows your component to grab some information from the DOM (for example, the scroll position) before it is potentially changed.
Any value returned by this life cycle will be passed as a third parameter, called snapshot, to the componentDidUpdate method.
With the DOM updated, the componentDidUpdate method is finally called.

UnMounting

When the component is going to be removed from the DOM, by changing state or props, we are in the disassembly.
Here we have only one life cycle method, which is:

componentWillMount()

This method is executed just before the component is removed. It is used to remove entries and listeners. An example is with the use of setInterval, that even if the component is removed, it will continue to run regardless of the existence of the component that invoked it.

Legacy methods
For creating confusion and some hard-to-solve bugs, some React lifecycle methods are being deprecated. In version 17 they can still be used with the UNSAFE_ prefix in front of their names. To understand more about why they are being deprecated, [see this post on the React blog]
UNSAFE_componentWillMount()
UNSAFE_componentWillReceiveProps()
UNSAFE_componentWillUpdate()
Conclusion
I hope that now you have a better sense of what is the lifecycle! this is definitely a concept that will help you build a better and more predictable UI in the future.

Free React Templates You can Use for Your Projects

Smilepk — Tue, 01 Feb 2022 17:57:34 +0000

Nowadays, the majority of developers use React for their web development projects. React is one of the popular JavaScript libraries for frontend developers, it’s a powerful tool to easily build user interfaces and create web applications.
There are a lot of free React resources that you can use to help you boost your productivity and build projects faster than ever. Templates and themes are the best way to save time when starting a React project. Especially if you just want to quickly build a project without focusing a lot on the design process.
Most of these templates you can start with are open-sourced on GitHub by other developers like you and me. Also, if you’re not a good designer, these templates can definitely help you to improve your project's design and follow UI/UX best practices.
So in this article, I will share with you a list of awesome templates you can use to build anything with React. Let’s get right into it.

Holly Template

Holly is a responsive React template for anyone who wants to create a beautiful landing page to collect

Capture by the author from Holly-react.
You can easily clone the template to your machine using Git. Of course, you might also customize the template as you want and edit the code as well. Here is the live demo if you want to see the design.

Carolina Admin Dashboard Carolina

Carolina Admin Dashboard is a free React template that you can use to build a functional admin dashboard using React.

Capture by the author from Carolina Admin Dashboard.
This professional template is built using the Material UI framework. It has a lot of different components with a clean design structure. Carolina Admin Dashboard is a very useful template to start with, especially if you’re building some kind of analytics web application.
What’s good about this template:
Fully responsive.
Follows UI/UX best practices.
Utilities and helpers are included.
Clean layout and structure.

Open

https://open.cruip.com/

Open is another amazing and free React template for any developer who wants to quickly create a beautiful landing page for any type of project.

Capture by the author from Open.
The template has a very clean and professional design layout that makes you stand out. There are a lot of well-designed reusable components and elements you can benefit from when using this template.
Advantages:
Dark and minimal design layout.
Fully responsive of course.
Custom beautiful icons and elements.
Good for SaaS products, online services, and open-source projects.
You can also have look at a live demo(external link) if you want to see the full design layout.

Treact Treact is an awesome gallery that comes with beautiful React UI templates and components that you can use for free to quickly build any type of project.

Capture by the author from Treact.
Features:
Fully Responsive.
7 Landing Page Demos.
Uses TailwindCSS.
8 Inner Pages.
A lot of well-designed components.
Easy to install and customize.

Next-Portfolio-Dev

Notus NextJS is a Free Tailwind CSS UI Kit And Admin. It's a great theme with nice colours, cool features and build tools to kickstart your project.

Another open-source React Template to help you quickly build a basic developer portfolio website.

Capture by the author from GitHub.
The template uses TypeScript and NextJS and you can customize it as you want. The code is clean and easy to understand. You can see more info on the GitHub repository.
Features:
Easy to install and customize.
Simple clean design with nice illustrations.
Fully responsive.
Dark mode feature.
PWA (for desktop & mobile).
You can deploy it with one click.
100% score on performance, accessibility, and SEO.

Gatsby Starter Ghost

https://demo.jamify.org/

This is a very useful React template if you’re looking to easily create a blog or a publication website where you can share your thoughts and ideas.

Capture by the author from Gatsby Starter Ghost(external link).
The template allows you to easily build lightning-fast websites using Ghost and Gatsby. It’s a good starting point for content-driven sites.
Features:
Fully responsive.
Blazing fast.
Great for SEO.
Clean blog post design and structure.
Easy to install and deploy.

React Nice Resume React Nice Resume is a simple and clean React template that you can use for portfolio websites. Whether you’re a developer, a designer, or a creator, this template is a good fit and starting point for you.

Capture by the author from React Nice Resume.

Features:
Fully responsive.
Nice animated background.
Clean design.
Smooth scrolling to sections.
Easy to install and deploy.
Conclusion
So as you can see, this was a good list of useful React templates that you can use as a starting point and customize them the way you like. Starting with templates is a good way to help you build projects faster and boost your productivity. You don’t have to always start from scratch.

FREE React UI Libraries for Web developers

Smilepk — Sun, 30 Jan 2022 19:53:11 +0000

15 FREE React UI Libraries for Web developers

1: NextUI
2: Mantine
3: Elastic UI
4: Theme UI
5: Chakra UI
6: Material UI
7: ReactStrap
8: BlueprintJS
9: Arco Design
10: React Admin
11: Shards React
12: React Toolbox
13: React Desktop
14: React Bootstrap
15: React Virtualized

React Native uses native Components

Smilepk — Fri, 28 Jan 2022 15:11:52 +0000

What Is React Native?
React Native is a well-known JavaScript-based app framework used for mobile apps and software development. It enables developers to develop natively generated apps for iOS and Android. You can develop a React Native-Based application for various platforms using the same codebase as the software development company.
React Native is one such framework that is used for software development. It allows app development for multiple platforms with a single code base for iOS, Android, Windows with a single code base. React Native is one of the most known and highly used cross-platform for mobile app development

To know the framework and understand the elements for an excellent react application,
you need to go through the basic structure of a React Native,
and some of the basic React concepts, like JSX, state,
and more.

What React Native Can Do
It makes platform-specific versions to share code across platforms where it will be easy to share a code with a single codebase.
Leveraging one team support for two platforms and conveying a standard technology.
Why Use React Native for App Development?
It is a cross-platform and very easy to develop the app.
It is time and cost-effective over other frameworks.
With React Native, complex features and app tasks are made easy to provide a more enhanced app user experience.
You will get all answers from React Native community and libraries for seamless development.
It serves a customized user experience to each user on the same application.
With React Native, detecting bugs are easier as it uses a single codebase for Android and iOS.
Top 7 React Native Components for Software Development
When you decide to develop software with React Native, you must understand the components in React for app designing. As per the platform guidelines, React Native components are useful for developing a robust business app.

Lets' look at some React Native components that every developer needs for robust app development.

React Native Elements React Native as a cross-platform UI toolkit sets a few excellent open-source UI components at one location. Its elements are an execution of the material design system.

It includes a set of general-purpose UI components for application design and overall user experience. The most amazing thing with React Native elements is its themes, which can be changed in the runtime without reloading the application. So, a business can easily focus on logic and develop an attractive app with the visual appearance of your product.

Material Kit – React Native Material Kit of React Native is completely coded with the app template. It is highly recommended to develop apps faster and effectively. It comes with over 200 variations of components such as inputs, buttons, cards, navigations, and more that offer you the freedom of choosing and combining.

All components can take variations in color, that you can easily modify inside our theme file.

Benefits of React Native Material Kit
Google Material Design
Open-Source Fonts
expo.io + iOS/Android
Documentation

React Native Bit Bit is a React Native tool for component-driven app development that is used for quick app development. It is an extensible toolchain for systems that are easy to understand, test, maintain, and simple to collaborate on.

Bit’s USP lies in letting developers to create components outside an application. Developers can then utilize them to compose as many applications as they want with the help of Bit component. Also, developers can alter the functionality of components in the app by adding or removing them from applications.

React Native Base Native Base is easy to access, and our developers use it for an excellent app experience. It is available in the utility-first library that helps you develop a uniform design system across all platforms, including iOS, Android, and Web.

Theme ability is the element offered by React Native known as Native Base and is personalized as per your app theme and component styles.

ARIA, powered by React Native, offers React hooks that allow developers to create accessible design systems in less time than other frameworks.

Advantages of NativeBase
Naturally Beautiful – Native Base crafts a beauty in an app that is inherited in itself, offering attractive components.
Multi-Platform – It supports multiple platforms and is thus easy to develop. You can ask developers to customize app properties using platform-specific mounts.
Accessible – NativeBase is easy to access and use and provides the box effect, including focus management and keyboard navigation.
Customizable – As mentioned, it is a default theme used to add components in the app that are customized as per-app requirements.

Vector Icons – React Native Vector Icons is a known component of React that is Perfect for logos, buttons, and nav/tab bars. It is simple to extend, style, and incorporate into your app development.

React Native with 3,000+ icons in the library helps you find components that fit your needs.

Advantages of Vector Icons Component
It is highly intuitive for designing buttons, logos, and nav/tab bars.
Vector Icons will enable you to import icons faster.
They are simple to extend, style, and integrate into your apps.

React Native Ignite Ignite is a well-known React Native boilerplate which is highly used for software development. React Native Ignite is a collection of Infinite Red’s thoughts on layout, patterns, and stack in one place.

As per the official React website, developers save their development time for around four weeks using React Native Ignite. Also, Ignite contains React Navigation 5, React Native, MobX-React-Lite, AsyncStorage, TypeScript, MobX-State-Tree and is Flipper-ready.

React Native Paper React Native Paper, the last but not the least component of React, is a collection of customizable and production-ready components. If you plan for React Native mobile app development, hire developers who are experienced in React Native Paper as it helps you add interaction that suits almost every use-case design.

One can easily customize features like default colors or make your design with the help of this component. In addition, we utilize the theming support provided by React Native Paper along with the option to switch between dark and light modes.

Advantages of React Native Paper
It is a high-quality, standard-compliant material design library.
It also covers all significant use-cases for app development.
React Native Paper is free and open-source which makes it quickly available.
Its fast, interface, responsive, and works reliably on both platforms.
Conclusion
These are some of the best available UI components of React Native that are highly important for your future software development. React Native with easily access libraries are simple to easy and its components are developers' choices for effective app development. React Native is an optimal choice when incorporated with the parts of native development with React and a best-in-class JavaScript library for building user interfaces.