DEV Community: Mosimi Akinlabi

How to replace a single-page application with a different page in React Router

Mosimi Akinlabi — Fri, 23 Feb 2024 20:16:32 +0000

React Router is an npm package that enables you to construct dynamic routing in your web application, as Create React App(CRA) does not include page routing. This tutorial will walk you through changing your single-page application to another page, such as the one that registers new users.

Prerequisite
You should have a basic understanding of React and Javascript to fully comprehend this tutorial. If you don’t, start by looking here and here.

Make sure you have react-router-dom installed from the node package manager at nodejs.

Folder Organisation
Assume for the purpose of this tutorial that you have a folder called screens that contains javascript files with the names Home, Overview, Timeline, FAQ (Frequently Asked Questions), Register screen, and then a Navbar.

The screens are stacked on top of each other in App.js as a single-page application like this:

Assuming that you want to replace all of the screens with the register screen when a user clicks on the register button in the navbar of your web application. The trick is to arrange all of the pages to sit on one page to make up the main page. Then you wrap it with <Routes> </Routes> like this:

Your home page should look like this:

Finally, you go to your navbar.js to handle the logic of replacing the home screen with the register screen. Your navbar should look like this:

All of your screens should now be accessible from your navbar. You should also be able to replace your single-page application with the register screen when a user clicks on the register button.

HTTP Response Codes Cheatsheet: What do they even mean?

Mosimi Akinlabi — Fri, 24 Nov 2023 01:15:05 +0000

HTTP response status codes are used by servers to indicate when a specific HTTP request has been successful or if it has encountered some sort of error.

Understanding status codes and how to utilise them can allow you to rapidly diagnose site faults and minimise downtime on your site. These status codes are the internet equivalent of a conversation between your browser and the server.

Responses are grouped into five classes. The first digit of the status code defines the class of response, while the last two digits do not have any classifying or categorization role. The standard defines five classes:

Informational Responses (100–199)
Successful Responses (200–299)
Redirection Messages (300–399)
Client Error Responses (400–499)
Server Error Responses (500–599)

Informational Responses

An informational response indicates that the server received the request and is thinking through it. It is issued temporarily while the request processing continues. It alerts the client to wait for a final response.

The message consists of the status line and optional header fields only and is terminated by an empty line.

100 Continue

This status code indicates that the server has received the request headers, and the client should proceed to send the request body. That is in the case where a body needs to be sent, like a POST request. After a request is denied due to incorrect headers, it would be inefficient to send a large request body to the server.

To have a server check the request's headers, a client must send Expect: 100-continue as a header in its initial request and receive a 100 Continue status code in response before sending the body. The request’s body should not be sent if the client receives an error code of 403 (Forbidden)or 405 (Method Not Allowed).

A response of 417 Expectation Failed indicates that the request should be repeated without the Expect header, as it indicates that the server does not support expectations.

This temporary response indicates that the client should continue the request or ignore the response if the request is already finished.

101 Switching Protocols

In response to a client's upgrade request header, the server sends this status code, which specifies the protocol the server is moving to. This simply means the client has asked the server to switch protocols, and the server has agreed to do so.

102 Processing

This status code means that although the request has been received and is being processed by the server, a response is not yet available. By doing this, the client is kept from time out and thinking that the request was lost. This status code is deprecated.

103 Early Hints

This status code is used to return some response headers before the final HTTP message. It is primarily intended to be used with the _Link _header. It lets the user agent know to start preloading resources while the server prepares a response.

Successful Responses

A successful response indicates the request was successful and the browser got the expected response from the server. This class of status codes indicates the action requested by the client was received, understood, and accepted.

200 OK

This is an indication of a successful HTTP request. The response you get will depend on the request method used.

In a GET request, the response will contain the resource that has been fetched and transmitted in the message body.

In a POST request, the resource contains a description of the result of the action, which is transmitted through the message body.

201 Created

With this status code, it means a new resource has been created due to the request succeeding. This type of response is typical for a POST request, or some PUT requests.

202 Accepted

This status code means that the request has been accepted for processing but has not been completed. The request might eventually get acted upon or not and may be disallowed when processing occurs.

This is because it is noncommittal since there is no way HTTP can send an asynchronous response indicating the outcome of the request. It is meant for cases where another server handles the request.

203 Non-Authoritative Information

This indicates that the server has received a 200 OK from its origin but it is returning a modified version of the origin’s response.

It is mostly used for backups or mirrors of another server.

204 No Content

This means that the server has received the request and processed it, but is not returning any content.

The headers may be useful in this scenario.

205 Reset Content

This indicates that the user agent or user should reset the document that sent the request. No content is usually returned.

206 Partial Content

This response code indicates that the range header sent from the client has requested only part of a resource.

The range of header is used by the client to enable resuming of interrupted downloads or split a download into multiple simultaneous streams.

207 Multi-Status

The message body from this request is usually an XML message. Such a body can contain multiple response codes and information about multiple resources, depending on how many sub-requests were made.

226 IM Used

IM stands for Instance-Manipulation. This response code means a server has successfully processed a request for the resource.

The response obtained is a representation of what happens when the current instance is subjected to one or more instance manipulations.

Redirection Messages

A redirection message is sent after you get redirected. It indicates that the request was received, but there was a redirect of some kind. This class of status code indicates that the client must take additional action to complete the request.

The additional action may be carried out by the user agent with no user interaction only if the method used in the second request is GET or HEAD. The user agent may also redirect the request. The user agent should be able to detect and intervene to prevent cyclical redirects.

300 Multiple Choices

This status code indicates that the request has more than one response. The user agent or user is prompted to choose one.

301 Moved Permanently

This status code means that the URL of the requested resource has been changed permanently and all requests should be directed to the given URL.

302 Found

This response code means that the URL of the requested resource has been changed on a temporary basis and further changes may be made to the URL in the future. Therefore, the same URL should be used by the user agent or user in future requests.

303 See Other

When the status code is displayed for a GET request, it usually indicates that the response can be found at another URL. When received in response to a POST or PUT or DELETE request, it indicates that the client should presume that the server has received the data and should send a GET request to the given URL.

304 Not Modified

This is meant for caching purposes. By caching, it means data is stored in temporary storage locations so it can be accessed faster. It also tells the user agent or user that the response has not been modified so the client can continue to use the same cached version of the response.

307 Temporary Redirect

This response code means that the user agent or user should get the requested resource at another URL using the same HTTP method. That is, if a POST request is used in the original request, a POST request should be used in the second request. However, future requests should still use the original URL as it is on a temporary basis.

308 Permanent Redirect

This means that the resource has been relocated permanently to another URL. However, the same HTTP method should be used in the second request as the first one.

Client Error Responses

This class of status codes indicates that the site or page could not be reached. This simply means that the request was made but the page is not valid. This error is from the website’s side of the conversation and often appears when a page does not exist on the site.

This class of status code is intended for situations in which the error seems to have been caused by the client. The message from the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition except when it is responding to a HEAD request. Any request method can use these status codes.

400 Bad Request

This status code indicates that the server cannot process the request due to client errors like malformed request syntax, invalid request message framing or deceptive request routing.

401 Unauthorised

This response simply means "unauthenticated". That is, the client must authenticate itself to get the requested response. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.

Also, some sites incorrectly issue HTTP 401 when an IP address is banned from the website (usually the website domain) and that specific address is refused permission to access a website.

402 Payment Required

The main aim for creating this status code was to use it for digital payment systems, however, this status code is used very rarely and no standard convention exists.

For example, Google Developers API uses this status code if a developer has exceeded the daily limit on API requests.
Sipgate uses this status code if an account does not have sufficient funds to start a call.

Shopify uses this status code when the store has not paid its fees and has been temporarily disabled.

Stripe uses this status code for failed payments where parameters were incorrect, like blocked fraudulent payments.

403 Forbidden

This status code means that the client does not have access rights to the content, that is, it is unauthorised, so the server is refusing to give the requested resource. Here, the request contained valid and correct data that was understood by the server but refused to take action.

This may be a result of the user not having the necessary permissions for a resource, needing an account, or attempting a prohibited action like creating a duplicate record where only one is allowed.

Authentication is usually refused by the server when this status code is returned. The request should not be repeated.

404 Not Found

In an API, this status code means that the endpoint and request are valid but the resource itself does not exist. In a browser, it means the URL is not recognized.

It is the most well-known status code because of its frequent occurrence on the web.

405 Method Not Allowed

Here, this status code indicates that the request method is known by the server but is not supported by the target resource. For example, an API may not allow calling DELETE to remove a resource from its endpoint or a GET request on a form that requires data to be presented via POST.

406 Not Acceptable

This status code is sent when there is no content that matches the criteria given by the user agent. This simply means that the requested resource is only capable of generating unacceptable content for the headers in the request.

407 Proxy Authentication Required

This is similar to 401 unauthorised but authentication needs to be done by a proxy. Proxy here means a server application that acts as an intermediary between the client requesting a resource and the server providing the resource.

The client must first authenticate itself with the proxy before the requested resource can be provided.

408 Request Timeout

This means that the client did not produce a request within the time that the server was prepared to wait and would like to shut down the idle connection. The client may repeat such requests without modifications at a later time.

Also, note that some servers may shut down the connection without sending this message.

409 Conflict

This indicates that a conflict has occurred. When a request cannot be processed because of conflicts with the current state of the server, this status code is sent as a response.

410 Gone

This status code is sent when the requested content has been permanently removed from the server with no forwarding address. Upon receiving a 410 status code, the client should not request the resource in the future as it is no longer available and will not be available again.

411 Length Required

This status code indicates that the server rejected the request because the Content-Length header field is not defined and is required by the server.

412 Precondition Failed

This status code indicates that the client has indicated some preconditions in its headers that the server does not meet.

413 Payload Too Large

Here, the request load is larger than the limit allowed by the server. Hence, the server might close the connection or return a retry-after header field.

414 URI Too Long

URI stands for Uniform Resource Identifier and they allow a client to identify a resource. For this status code, however, it is displayed when the URI requested by the client is longer than a server can process.

It is often the result of too much data being encoded as a query string of a GET request, in which case it should be converted to a POST request.

415 Unsupported Media Type

This means that the server has rejected the request because the media format of the requested data is not in a supported format.

416 Range Not Satisfiable

This status code indicates that the range specified in the range header field of the request is outside the size of the target URI’s data and the request cannot be fulfilled.

417 Expectation Failed

This response code means that the server cannot meet the expectation indicated by the expect request header field.

421 Misdirected Request

You get this response when the request is directed at a server that is not able to produce a response.

422 Unprocessable Entity

This response code means that the request was well-formed but was unable to be processed due to semantic errors. And by semantic error, it means that the program produces incorrect results when executed.

423 Locked

You get this response when the resource being requested is locked.

424 Failed Dependency

This response code means that the request failed due to the failure of a previous request.

425 Too Early

This status code indicates that the server will not risk processing a request because it might be replayed.

426 Upgrade Required

This status code indicates that the server will not process the request using the current protocol but will do so after the client upgrades to a different protocol.

428 Precondition Required

This status code indicates that the server is trying to prevent a conflict. It requires the request to be conditional so as to prevent the lost update problem.

429 Too Many Requests

You get this response when you have sent too many requests in a particular amount of time.

431 Request Header Fields Too Large

You get this response when the server won’t process the request because its header fields are too large. You may need to reduce the size of your request header field to get the server to process your request.

451 Unavailable For Legal Reasons

This status code indicates that the user requested a resource that is censored legally. The server operator has received a legal demand to deny access to such resources.

Server Error Responses

This class of status codes indicate when a valid request was made by the client but the server failed to complete the request. A response status code of this kind indicates that the server is aware that it has encountered an error or is incapable of performing the request.

The message from the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition except when it is responding to a HEAD request. Any request method can use these status codes.

500 Internal Server Error

You get this generic error message when the server has encountered a situation it does not know how to handle.

501 Not Implemented

This usually means that the server does not recognize the request method and such request method is not supported therefore it cannot be handled.

502 Bad Gateway

This usually indicates that the server got an invalid response from the upstream server while working as a gateway to get the response needed to handle the request.

503 Service Unavailable

This status code is sent as a response to indicate an error that is temporary. Here, the server is not yet ready to handle the request usually because the server is down for maintenance or is overloaded.

504 Gateway Timeout

This usually indicates that the server did not get a response in time while acting as a gateway from the upstream server.

505 HTTP Version Not Supported

This means the server does not support the HTTP version used in the request.

506 Variant Also Negotiates

This means that the server has an internal configuration error where a transparent content negotiation for the request results in a circular reference.

507 Insufficient Storage

The request could not be completed because the server was unable to store the representation needed to successfully complete the request.

508 Loop Detected

This means an infinite loop was detected while processing the request.

510 Not Extended

This usually means that the server requires further extension to the request to fulfil it.

511 Network Authentication Required

This indicates that the client needs to authenticate to gain network access.

How to Differentiate Between Put and Post Request In Rest API

Mosimi Akinlabi — Mon, 06 Nov 2023 15:42:42 +0000

I remember asking myself this question when I started learning API methods. You are not alone, as many developers struggle to tell the difference between the POST and PUT methods when building and designing a system.

To understand this article better, it is important to understand the meaning of Rest API. REST (Representational State Transfer) is simply a style of software architecture. Easy! And, as described in a dissertation by Roy Fielding, REST is an “architectural style” that basically exploits the existing technology and protocols of the Web.
While Restful API is typically used to refer to web services implementing such “architectural style” (REST).

Now that the concept of REST API is clear, RESTful web services use HTTP methods to communicate with clients. The HTTP method used by the client will determine how the server will respond to the request. The PUT and POST are examples of HTTP methods used in RESTful web services.

Key Difference

The PUT method is used to update an existing resource, while the POST method is used to create a new resource. What this simply means is that PUT is used for updates to existing data, while POST creates a new object for new data to be created.

How It Works

When the POST method is used to create a resource on the server, the resource is created as a subordinate resource to the URL that the POST method provides. For example, in a flight tracking system where users look up the status of an “American Airlines flight”, the URL will look like this:
www.example.com/flights/AA123

The PUT method, on the other hand, requires the exact URL of the resource to be updated. For example, to update the status of the flight, the PUT operation includes a JSON or XML payload to describe the new status.

PUT URL: www.example.com/flights/AA123
PAYLOAD: {"status": "ontime", "gate": "b12"}

It is a common occurrence in database-based applications that the exact URL of the resource is not known. The newly created resource is identifiable by a value that gets generated after the resource’s data is recorded.

An example of such an occurrence is a primary key-based identifier. If you need to create a resource that is subordinate to the URL provided, you should use a POST method, not a PUT method.

When you use the POST method, all the information needed to create a new resource is provided as JSON or XML in the request’s payload. REST demands that the new URL created be sent back to the calling program as a location header. This allows the calling program to use the PUT method for future updates.

This is why the difference between a PUT and POST method is often phrased as; to create an object, use a POST, while the PUT method should be used for updates.

Idempotence

Idempotent means that a certain operation can be applied many times without the result changing.

PUT is idempotent, while POST is not idempotent. This simply implies that when you use the PUT method to call "create user” multiple times, you should still get one user as long as the value is the same. Multiple identical PUT requests will have the same effect as a single request.

In contrast, for POST requests, new records get created when duplicate data is sent.

Status Code

In a POST request, a new record gets created for each request, HTTP 201 is sent in response when this is done, and HTTP 409 if duplicates are not allowed. HTTP 200 is sent when the record gets updated, and HTTP 201 if the record is new.

For a PUT request, the server sends a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request if there is no current representation of the data on the server. HTTP 201 will be sent if a new resource is created.

Lastly, in this tutorial, you learned about REST and RESTful web services. You have looked at what distinguishes a PUT request from a POST request, their respective idempotency, and what response a server sends when any of them is executed.

Git Commands: The Ultimate Cheatsheet

Mosimi Akinlabi — Sat, 14 Oct 2023 15:02:03 +0000

Git is a version control system in software development that mirrors a codebase, including its full history, on every developer's computer.

This is referred to as a distributed version control system. It is very important in software development because it is used to track changes in a set of computer files and to coordinate work among programmers who are working collaboratively on a source code to achieve a specific goal.

This cheat sheet contains commonly used and important Git commands for easy reference.

Prerequisites

You should have git installed on your computer, depending on the operating system of your machine(Windows, Linux or Mac). This should be done either through the command line or Git’s website. For more information on the step-by-step guide for installation, check here. Are you finished? Let’s proceed.

Getting and Creating Projects

Use the following commands to create a new Git repository or a copy of an existing one.

(a) git init
This is the first command you must learn if you want to keep your project under revision control. It's also worth noting that running this command in an existing project or repository is safe and will not overwrite any existing files. When you run this command, it will generate an empty Git repository.

(b) git clone
Cloning a repository is the process by which developers obtain a working copy of a main repository, making it easier to track changes and assign tasks to team members. When you clone a repository, it creates a local copy of the main repository on your machine.

Snapshotting

A snapshot is a copy of your project at a specific point in time. Assume you make backups by copying your entire project, zipping it, and adding a label and timestamp. That is a snapshot. Use the following commands to make a snapshot:

(a) git add[file-name.txt]
Before committing to the main repository, you can use this command to create a snapshot of your local repository. It is important to note that before running the commit command, you must add any new or modified files to the index using the add command.

(b) git add-A
This command adds to the staging area all new and changed files in the entire working tree.

(c) git status
This command should be used in conjunction with git add and git commit to see what will be included in the next snapshot. This command displays the working directory state as well as the staged snapshot.

(d) git diff
You can infer what a command does from its name, as you can with most git commands. Git diff displays the differences between commits, commits, and working trees.

(e) git commit
This command logs changes to the repository. It saves the staged snapshot of the project's history. When combined with git add, it depicts the day-to-day workflow of git users.

(f) git notes
This command is used to add, remove, or read notes attached to objects without having to touch the objects. Git notes are commonly used to supplement a commit message without altering the commit itself.

(g) git restore
This command restores working tree files. Another application for this command is to restore specified paths in the working tree with some content from a restore source. IT IS IMPORTANT TO NOTE THAT THIS COMMAND IS EXPERIMENTAL AND THE BEHAVIOR MAY CHANGE.

(h) git reset
This command returns the current HEAD to its original state. This means that it reverses changes made to files in the working directory. It can be used to clean up or remove changes that have not been pushed to a public repository.

(i) git rm
This command deletes files from the working directory.

(j) git mv
This command is used to move or rename a file or directory.

Branching and Merging

Branching and merging refers to the process of making a separate copy of a main codebase to incorporate a local change to it. Use the following commands to achieve this:

(a) git branch
This command can be used to list branches as well as create and delete them. It is simply a general-purpose branch administration tool. It allows for the creation of isolated development environments within a single repository. This is done to make it easier to track changes to the repository and assign tasks to team members.

(b) git branch -a
This returns a list of all branches, whether local or remote.

(d) git branch -d [branch name]
This is used to remove a branch.

(e) git branch-m [old branch name][new branch name]
This is used to rename a local branch.

(f) git checkout
This command allows you to switch branches or restore working tree files. It can also be used to navigate existing branches and check out old commits and file revisions.

(g) git checkout-b [branch name]
This is used to create and switch to a new branch.

(h) git checkout-b [branch name] origin/[branch name]
This clones and switches to a remote branch.

(i) git checkout [branch name]
This command switches to a branch.

(j) git switch
This command is used to navigate between branches. When this command is executed, the working tree is updated to match the branch. IT IS IMPORTANT TO NOTE THAT THIS COMMAND IS EXPERIMENTAL AND THE BEHAVIOR MAY CHANGE.

(k) git merge
This is used to link two or more development histories together.

(l) git merge tool
To resolve merge conflicts, use this command to run merge conflict resolution tools. It is typically executed following a git merge.

(m) git log
This displays commit logs.

(n) git stash
When you want to record the current state of the working directory but return to a clean working directory, use this command. That is, it saves your local changes while reverting the working directory to the main commit.

(o) git worktree
This command is used to manage multiple working trees attached to the same repository. Some of them include:

git worktree add
This command associates a new working tree with the repository and adds extra metadata to it. A work tree is distinguished from others in the same repository in this manner.
git worktree list
This command displays information about each worktree. The main worktree appears first, followed by any linked worktrees.
git worktree lock
This command prevents files from being pruned, moved, or deleted automatically.
git worktree move
This command is used to relocate a worktree.
git worktree prune
This command prunes worktree data.
git worktree remove
This command is used to delete clean worktrees that contain no untracked files and no modified tracked files. Unclean worktrees should be removed with --force. It should be noted that the main worktree cannot be removed.
git worktree repair
This command repairs worktree files that have been moved or corrupted as a result of external factors.
git worktree unlock
This command allows you to prune, move, or delete a worktree.

Sharing and Updating Projects

Use the following commands to share a local change and update it in the main codebase:

(a) git fetch
This command is used to retrieve or download objects and references from a different repository. _git fetch _can retrieve files from a single repository or a URL.

(b) git pull
This command fetches from the main repository and integrates it with another repository or a local branch. It merges changes from your local machine repository into the current branch.

(c) git push
This command uses local refs to update remote or main refs while sending objects required to complete the local ref.

(d) git remote
You can manage the set of repositories whose branches you track with this command.

(e) git submodule
This command allows you to inspect, update, or initialise submodules. Submodules are repositories that are contained within another repository. Although such submodules have a history, the repository in which they are embedded is referred to as a super project.

Inspection and Comparison

Use the following command to inspect a codebase's workflow and compare it to other developers' code:

(a) git show
This command displays one or more objects (blobs, trees, tags, and commits) in a single repository.

(b) git log
This command displays commit logs.

(c) git difftool
This git command allows you to edit and compare them between revisions using common diff tools. Git difftool is a GUI for git diff. It accepts the same options and arguments.

(d) git range-diff
This git command compares two branches and displays the differences.

(e) git shortlog
This git command summarises git log output so that it can be included in release notes and announcements.

(f) git describe
This command assigns a human-readable name to an object based on the available ref.

Patching

Patching is used to distribute changes to others without pushing them to the repository's main branch to make necessary corrections. Use the following commands to achieve this:

(a) git apply
This command applies a patch (diff output supplied) to files or the index.

(b) git cherry-pick
This command applies the changes made by previous commits. This command requires a clean working tree.

(c) git rebase
This git command allows you to move branches around to avoid unnecessary merge commits. It generates a linear history that is simple to comprehend and explore.

(d) git revert
This command undoes some previous commits. Simply put, it restores a working tree to its previous state before a commit as if it never happened.

Debugging

Debugging allows you to search through your commit history to identify when a “bad commit” occurred. Use the following commands to achieve this:

(a) git bisect
This command comes in handy when you're looking for a commit that broke a feature in your project. To find the commit, it employs a binary search algorithm.

(b) git blame
This command displays which author and revision modified each line of a file the most recently.