DEV Community: John Raptis

Thoughts on Legacy Code and How to Live With it

John Raptis — Sat, 04 Dec 2021 14:54:32 +0000

Let's start with one statement before we even define what legacy code is.

You will never get rid of legacy code, you can only learn how to deal and live with it.

So what is legacy code anyway? You might fall into the trap of thinking that is just old code. This kind of answer is over-simplistic and doesn't reflect reality. Legacy code, yes, can be old, but old code is not necessarily considered legacy just because it is old. With this approach, your own very code you wrote yesterday, is legacy by now. So what is happening?

There is a why we write code that might end up as legacy. There is also the how and what. That we shall discuss later.

Legacy code has all or at least one of the following characteristics. It is a black box, difficult or impossible to extend and there is no documentation on how it works. And the scary thing is that we are writing it as we speak if don't consider all the above.

The "why" we write code that most likely ends up as legacy is outside of the actual coding and implementation aspect of things. It has to do more with the business side of things. If you are an indie maker or a small startup you are more likely to build fast and revisit later. In today's day and age if you haven't taken this route you most likely don't have a business. You don't even know if you are going to be live till next week and every resource you have you drop it toward what is going to have the maximum return and value for your company. Eventually, you will have a hint that your business is viable, where you should start considering the effects it will have for your business in the future. Everyone is talking about a rewrite of the entire codebase, which never happens and there are good reasons for this as well.
If a company, from a startup, becomes a scale-up or even bigger, it usually has some dark place in the codebase from the early days. I have heard stories of entire repositories being deemed never to be seen by the team except for some lone genius.

All the above are why this happens. It is more of a business decision, derived from business needs that is causing this. It is a reality and it's almost certain it will stay that way. So acknowledging the problem is vital in order to move to practical ways of combating the problem. You can hack your way through when it comes to adding new features but inevitably everything will blow in your face, sooner or later.

Many companies never took off because they were too focused on the code to be perfect and there are companies that shipped crapy code that did really well but then they were crushed by their own weight due to not being able to make changes anymore.

It's ok to hack something fast to push the business forward but you need a way to get out of the ditch you are slowly digging for yourself. It is called technical debt for a reason. It means you are going to pay for in the future with your time, or someone else's time.

So having a pragmatic and effective approach is vital.

Refactor vs Rewrite

As mentioned above the first thing you might think of is to start from a clean slate. This is not a good idea unless you have the recourses and a dedicated team to do so which is rare, or the codebase is extremely large and want to do some kind of rebrand and get rid of entire sections and features, which a rewrite might be the best decision to be made. In a Maintainable podcast episode, Swizec Teller talked about this and made a great point regarding a rewrite, amongst other great points.

If you refactor the majority of a codebase where nothing from the original code exists, were you rewriting or refactoring?

I remember in my first job looking at codebases of various websites we were maintaining that used some old framework. I couldn't hold myself to ask in my naivety, why aren't we rewriting all of this mess? Turns out that this would be a terrible idea. Besides the business cost in terms of hours, code — although old — works and has stood the test of time. It survived bug fixes and live quality assurance based on user feedback. Rewriting it will likely introduce new bugs and off we go again.

In this post, Joel Spolsky makes a strong case against rewrites and takes a more pragmatic, real-life approach.

As developers we find the idea of a rewrite appealing because it is easier — at least that is what we think. The old code might look ugly but it is code that works. It's easier to judge code written before us and think we have a better solution often ignoring what business logic the old code serves and what edge case it was trying to solve. It is hard to read code and understand it so we have the impulse to avoid it.

It's harder to read code than to write it. — Joel Spolsky

Although I generally agree with the premise that a rewrite is not often justifiable, in some cases, it might make sense. If a section in a project can't be expanded anymore or if doing so needs hacks and workarounds, some things are not being used anymore and it's isolated, starting from scratch can be the right thing to do.

Documentation

The most evident solution when dealing with this is writing documentation. Documentation is one of those things that all developers agree upon but few do, at least in a practical and efficient way. Some keep everything in their head, hoping they remember it while others take the let's write a novel approach. They write an endless amount of it which makes it incredibly hard to update, resulting in a disorganized, outdated mess. This is not helpful since you are making an extra effort to cut through the noise and find not only what you need, but if you need it at all in the first place.

"I didn't have time to write a short letter, so I wrote a long one instead" - Mark Twain

It's is far easier to write lots of mindless documentation just for the sake of writing it than to be brief, concise and, make sense. Bullet points are better than paragraphs and short explanatory sentences are better than long-winded explanations. It is pretty much an art in and of itself.

Having a link at a prominent place in the source code linking to a doc describing all the technical decisions that took place, can be helpful for your future self and co-workers. Explaining how and why you chose a particular solution or approach and pointing out quirks and possible edge cases will make a world of difference next time you visit the code and decide to make improvements.

Learn how to write good technical documentation which is short, easy to skim, easy to update, and in the place where it's needed. Easier said than done, right?

Extendibility

A piece of code might work but it is really dead if you can't extend it. Sure it can work as expected and still generate revenue for the company but one-day shit will hit the fan. You can minimize the problem by keeping things isolated so it doesn't affect the rest of the code though this can't be a permanent solution.

You really don't want to end up in a situation wherein order to add a new feature, you have to make changes and preserve code that is based on old practices or technologies you no longer support just to fill a business need.

Usually, when you write new stuff they will depend on some legacy system, depending on the size. The larger the size of the codebase, the more challenging it will be to fix if systems are not isolated from each other. That is why having code that is tightly coupled is considered a bad idea. The more the coupling, the more the complexity.

Swyx has a great read on how we should optimize for change and gave great insights on how we should design our abstractions and anything we code with that in mind. And the reason for this is to solve the requirements volatility problem, where changes in the specs of our product happen all the time whether we like it or not. We don't prepare ourselves for this kind of scenario so when a requirement changes it finds us unprepared so we write a "temporary" implementation. This usually doesn't happen just once, so all the previous hacks pile up and cause our codebase to mummify. Once all this sloppiness established itself it becomes increasingly hard to get rid of.

Hard-to-delete code drives out easy-to-delete code over time

So optimizing your code for change and making it easier to delete, ironically makes it easier to extend in time and you will not produce legacy code today.

Practical Implementation

In general, the code you write today is old code by tomorrow. So much of it has to do with how we write code and with what intention. Is your intention to be seen as clever or is it to help all the future developers that will come probably long after you are gone. Since we don't know what is going to be built, it is sane to make it easy to change code in the future. This has some ethical aspect to it from the developer's side to leave the codebase in a bit better condition than it was found.

I love the phrase by Swizec Teller again from the Maintainable podcast episode.

It's easier to fix code that is repeated than code that is abstracted in the wrong way

It is far better to detour from so-called best practices and make it easier for another person to come and change stuff than have complex logic that is difficult to decipher and which will certainly break things if you try to refactor it.

The goal here is to slowly make incremental changes on legacy systems. When that option stops, that is where code starts being legacy. Code that changes is the only constant.

Testing

An obvious but often overlooked way is to write tests which too can be done incrementally. Each time you visit a certain section — depending on the case — you can add unit tests. Or you can start testing more generic things like if a user is logged in. Having code that is really tightly coupled together might lead you to start testing the outer layers of a section, and gradually achieving full coverage. Then you can start moving stuff around more easily. The only downside in this approach is that often legacy codebase's don't even have tests or test infrastructure implemented which you have to do extra work for that. But regardless of the initial hustle, it will prove itself to be a valuable tool down the line.

Faceless Changes

Ok, this might seem odd. But the true test that you don't have and don't generate legacy code today - at least as much - is if anyone in your team can go and make changes throughout the codebase. And the newcomers have a way of discovering how to work with it without the need to ask around for clarification. This doesn't mean you don't have places in the codebase where things aren't messy, but at least there is a way to navigate through. When your codebase doesn't depend on one single person, that is a healthy sign.

You want to make yourself unnecessary and detach your ego from the code.

Within teams that is also a sign of seniority. To be able to tackle the issue of dealing and working with legacy systems.

Conclusion

Nothing of the aforementioned can happen overnight. Incrementally is the keyword here.

To summarize, we learned what legacy code is. It is code that we are not able to extend. We can co-exist with legacy code and start improving it with just as much documentation that is easy to update and always be in a semi-rewrite(aka refactor) mode.

As engineers, we solve problems that happen to be soluble by code. Code is just a tool so it doesn't make sense to get too attached to it. Eventually, any code you have written will slowly fade away, so go on and find the next interesting problem to solve.

Frontend Data Normalization

John Raptis — Thu, 29 Oct 2020 15:47:30 +0000

Many times in our applications we are dealing with complex state that contains deep nesting. This makes it difficult to work with since we have to make many manipulations to present our data the way we want. What we commonly do is normalize our data.

This has many benefits:

We get a more flat structure, meaning that we are not dealing with deep nesting as much.
Our data structure consists primarily of objects that have their own id. Relationships are being created with id.
We avoid data duplication.

There are libraries that can help with this like Normalizr where you automate the process and have more options, but in this article we are going to do it by hand with plain JavaScript.

Note: This is a well know pattern in Redux to simplify your state and treat it more like a database. We will cover this in a future article.

In our state below, notice that we have an array of object that each object has it's own array of objects as well.

const posts = [
  {
    id: "1",
    name: "name 1",
    body: "Lorem ipsum . . .",
    comments: [{ id: "11", comment: "Lorem comment . . ." }],
    author: "Joe Doe",
    data: "2020-10-20",
  },
  {
    id: "2",
    name: "name 2",
    body: "Lorem ipsum . . .",
    comments: [
      { id: "12", comment: "Lorem comment . . ." },
      { id: "13", comment: "Lorem comment . . ." },
      { id: "14", comment: "Lorem comment . . ." },
    ],
    author: "Marry Doe",
    data: "2020-10-20",
  },
  {
    id: "3",
    name: "name 3",
    body: "Lorem ipsum . . .",
    comments: [
      { id: "15", comment: "Lorem comment . . ." },
      { id: "16", comment: "Lorem comment . . ." },
    ],
    author: "Anna Doe",
    data: "2020-10-20",
  },
  {
    id: "4",
    name: "name 4",
    body: "Lorem ipsum . . .",
    comments: [{ id: "17", comment: "Lorem comment . . ." }],
    author: "Jim Doe",
    data: "2020-10-20",
  },
]

Let's say we want to find a specific comment from a specific post.

One thing we might do is first find the post we want and then chain another higher order function to find the comment we are looking for. The example below it's not that bad but imagine working with lots of data. You can save some operations by normalizing your data.

Note: This has something to do with BigO notation. Simply put, BigO notation tells you the number of operations an algorithm will make. We will cover this in a future article as well.

const findComment = posts
  .find(post => post.id === "2")
  .comments.find(comment => comment.id === "12")

Here we are using a reduce higher order function to assign an object to a certain key. In our case we associate each object with a key which is it's own id.

Eventually we want to have a posts object that contains an byId object of each post and an allIds array with all the posts ids

const normalizedPosts = posts.reduce((data, item) => {
  data[item.id] = item
  return data
}, {})

const postIds = posts.map(post => post.id)

const state = { posts: { byId: normalizedPosts, allIds: postIds } }
console.log(state)

output:

 {
    posts: {
        byId: {
            "1": {
                id: "1",
                name: "name 1",
                body: "Lorem ipsum . . .",
                comments: [{id: "11", comment: "Lorem comment . . ."}],
                author: "Joe Doe",
                data: "2020-10-20"
            },
            "2": {
                id: "2",
                name: "name 2",
                body: "Lorem ipsum . . .",
                comments: [
                    {id: "12", comment: "Lorem comment . . ."},
                    {id: "13", comment: "Lorem comment . . ."},
                    {id: "14", comment: "Lorem comment . . ."}
                ],
                author: "Marry Doe",
                data: "2020-10-20"
            },

            . . .
            allIds: ["1", "2", "3", "4"]
        }
    }
}

Instead of looping an array we can access a specific post by id.

console.log(state.posts.byId[2])

output:

 {
    id: "2",
    name: "name 2",
    body: "Lorem ipsum . . .",
    comments: [
        {id: "12", comment: "Lorem comment . . ."},
        {id: "13", comment: "Lorem comment . . ."},
        {id: "14", comment: "Lorem comment . . ."}
    ],
    author: "Marry Doe",
    data: "2020-10-20"
 },

And if we want to access all posts we do it with the allIds arrays.

console.log(state.posts.allIds.map(id => state.posts.byId[id]))

output:

[{…}, {…}, {…}, {…}]

Notice that in each object of posts we have a comments array. Wouldn't it be nice if that was normalized to?

One way to approach this is normalizing the comments first and then the post itself.

Now doing all the normalization within the reduce method is a bit verbose. We can abstract it to it's own reusable function named normalizeBy.

const normalizeBy = key => {
  return (data, item) => {
    data[item[key]] = item
    return data
  }
}

const normalizedPostsAndComments = posts
  .map(p => ({ ...p, comments: p.comments.reduce(normalizeBy("id"), {}) }))
  .reduce(normalizeBy("id"), {})

console.log(normalizedPostsAndComments[2].comments[12])

If we log it to console the output will look something like be this.

output:

"2" : {
    id: "2",
    name: "name 2",
    body: "Lorem ipsum . . .",
    comments: {
        "12": {id: "12", comment: "Lorem comment . . ."},
        "13": {id: "13", comment: "Lorem comment . . ."},
        "14": {id: "14", comment: "Lorem comment . . ."}
    },
    author: "Marry Doe",
    data: "2020-10-20"
},

We can further abstract our state by separating our comments from within the post and keep an array of comments that belong to a post. We are going to keep the comments arrays though in each post but only contain the id of each comment.

const nomalizedComments = posts
  .map(post => post.comments)
  .flat()
  .reduce(normalizeBy("id"), {})

const commentIds = posts
  .map(post => post.comments)
  .flat()
  .map(comment => comment.id)

const nomalizedPosts = posts
  .map(post => ({
    ...post,
    comments: post.comments.map(comment => comment.id),
  }))
  .reduce(normalizeBy("id"), {})

const postIds = posts.map(post => post.id)

const state = {
  posts: {
    byId: nomalizedPosts,
    allIds: postIds,
  },
  comments: {
    byId: nomalizedComments,
    allIds: commentIds,
  },
}

console.log(state)

output:

 {
    posts: {
        byId: {
            "1": {
                id: "1",
                name: "name 1",
                body: "Lorem ipsum . . .",
                comments: ["11"],
                author: "Joe Doe",
                data: "2020-10-20"
            },
            "2": {
                id: "2",
                name: "name 2",
                body: "Lorem ipsum . . .",
                comments: ["12". "13", "14"],
                author: "Marry Doe",
                data: "2020-10-20"
            },
            "3": {
                id: "3",
                name: "name 3",
                body: "Lorem ipsum . . .",
                comments: ["15", "16"],
                author: "Anna Doe",
                data: "2020-10-20"
            },
            "4": {
                id: "4",
                name: "name 4",
                body: "Lorem ipsum . . .",
                comments: ["17"],
                author: "Jim Doe",
                data: "2020-10-20"
            }
        },
        allIds: ["1", "2", "3", "4"]
    },
    comments: {
        byId: {
            "11": {id: "11", comment: "Lorem comment . . ." },
            "12": {id: "12", comment: "Lorem comment . . ." },
            "13": {id: "13", comment: "Lorem comment . . ." },
          "14": {id: "14", comment: "Lorem comment . . ." }
            "15": {id: "15", comment: "Lorem comment . . ." },
            "16":   {id: "16", comment: "Lorem comment . . ." }
            "17": {id: "17", comment: "Lorem comment . . ." },
        }.
        allIds: ["11", "12", "13", "14", "15", "16", "17"]
    }
}

Now we can access

a specific post or comment
all the posts or comments
all the comments of a specific post

// 1
console.log(state.posts.byId[2])
console.log(state.comments.byId[13])

// 2
console.log(state.posts.allIds.map(id => state.posts.byId[id]))

// 3
console.log(
  state.posts.byId[2].comments.map(commentId => state.comments.byId[commentId])
)

Data normalization makes complex state more manageable. This is an example of how to approach data normalization so you can build on top of this. This is in no way the right way of doing things but it will give you an overview.

Now go and make the complex, simple.

If you like what you read consider joining my newsletter.

Fake API with JSON Server

John Raptis — Fri, 31 Jan 2020 20:15:09 +0000

This post was originally published in my blog

Many times as developers we want a quick back-end to fetch data from. Instead of a real API we just want to have some fake data to play with. Whatever the reason is, a fake API comes in handy during development.

For this we are going to use a package called json-server.

We are going to set up a quick server and explore some cool features that ship with json-server. There are more features included like pagination and filtering but here are the one's that I found myself grabbing the most.

As always you can dig into the documentation.

Here is the source.

Basic Server

First we are going to init a package.json file in our project. . .

mkdir fake-api
cd fake-api
npm init -y

Note: With the -y flag we are going to skip the prompt process.

. . . and install json-server

npm install json-server

We are going to create a db.jsonfile where our data going to be stored just like a server.

{
    "songs": [
        {
            "title": "Africa",
            "band": "Toto",
        },
        {
            "title": "Fkj",
            "band": "Moments",
        }
    ]
}

In our package.json file we are going to add the following script.
All we are doing here is watching in our db.json file for changes which is hosted in port 3001.

"json": "json-server --watch db.json --port 3001"

Now if we run npm run json our server is running.

Generate Random Data

In an index.js file we are going to generate some random users.

let names = ['Mary', 'John', 'Mike', 'Paul', 'Anna', 'Chris'];
let ages = [34, 56, 12, 22, 24, 54];

module.exports = () => {
    const data = { users: [] };
    for (let i = 0; i < 10; i++) {
        let randomName = names[Math.floor(Math.random() * names.length)];
        let randomAges = ages[Math.floor(Math.random() * ages.length)];
        data.users.push({ id: i, name: `${randomName}`, age: `${randomAges}` });
    }
    return data;
}

Our script will look like this.

"db": "json-server --watch index.js --port 3002"

And again by running npm run db we have yet another server.

Custom Routes

Many times when we are building our fake API we want our endpoints to mimic a real case scenario.
We might want our url's to look something like this.

http://localhost:3004/rock/songs
http://localhost:3004/rock/bands
http://localhost:3004/classical/pieces
http://localhost:3004/classical/artists

So how we do this?

Our db.json will have the typical JSON format.

{
    "rock_songs": [
        {
            "title": "Africa",
            "band": "Toto"
        },
        {
            "title": "Fkj",
            "band": "Moments"
        }
    ],
    "rock_bands": [
        {
            "name": "Toto"
        },
        {
            "name": "Boston"
        }
    ],
    "classical_pieces": [
        {
            "title": "Prelude in C Major"
        },
        {
            "tilte": "Toccata and fugue in d minor"
        }
    ],
    "classical_artists": [
        {
            "name": "Alexander Scriabin"
        },
        {
            "name": "Johann Sebastian Bach"
        }
    ]
}

Then we create a routes.json with the following.

{
    "/": "/",
    "/rock/songs": "/rock_songs",
    "/rock/bands": "/rock_bands",
    "/classical/pieces": "/classical_pieces",
    "/classical/artists": "/classical_artists"
}

On the left side is how we want our endpoint to look like, and in the right the corresponding array in our db.json file.

We will adjust our script . . .

"custom:routes": "json-server db.json  --routes routes.json --port 3003"

. . .and if we run npm run custom:routes we get our custom endpoints.

Basic Git commands you should know

John Raptis — Fri, 03 Jan 2020 17:25:47 +0000

This post was originally posted in johnraptis.dev

Git and Github play an essential role in every developers workflow. They give us a very sophisticated way to keep track of our projects history. Knowing how to use them give us the ability to work more efficiently.

The purpose of this article is more of a reminder or general overview and to have things grouped in one place, rather than a comprehensive guide. I think the official documentation does a very good job in that respect.

prerequisites

Have Git installed in your system.
Have a Github account and know the basics of creating a repository.

But first a quick reference.

So what is Git?(Quickly)

Git is a system that tracks changes in our code. You will often hear it being referred as 'version control'. Why?
Because it keeps a history of all previous versions of our source code. This gives the ability to have multiple developers working in parallel and sharing code. In order to do that we would have a local Git repository which lives locally in our computer, and a remote Git repository which lives in a server(Github, Gitlab, etc..).

git config

In order to work locally we will have to set our username and email.
This information will be used when we are doing commits to remote repositories, and should match you Github profile credentials.

We can do this globally.

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

. . . or in a single repository.

git config user.name "John Doe"
git config user.email johndoe@example.com

To check your information you can either do

git config user.name
> Joe Doe

git config user.email
> johndoe@example.com

git config --list

which returns them as part of a list

. . .
. . .
. . .
user.name=John Doe
user.email=johndoe@example.com

git init

Initialize or reinitialize and existing repository with a .git folder that tracks our project locally.

git add . / git add

When we make a change we want to commit it to our local repository. But before we do that the code has to be added to the staging area. The staging area keeps track of the files that are about to be committed.

To have a better understanding of git you should have the following mental frame in mind.
Git has three states. The first is if a file is modified, which means any change you might have done. The second is if a file is staged, which means if you prepared the file to be committed. And lastly if a file is committed, which means that our changes have been stored to our local repository, ready to be pushed.

To add a single file to the staging area you type...

git add [name-of-file]
//ex  git add index.html

or with the . you add all the files that has been changed.

git add .

git commit -m "message"

Now that we added our code to the staging area, we are ready to commit the file. We also give a descriptive name like "form added" or "updated version". etc. . .

git status

With git status we can see in which phase our files currently are. Which files are modified, which ones are in our staging area or being committed and in which branch we currently are.

git log

With log we see all the commits from the very beginning up until now. It also shows the name of who authored the commit and the date.

Branches

We can create other branches as well to work on other versions or parts of our project. By default we commit all our code to the main branch which is called master. We can merge branches together if needed.( this will be covered later)

To create another branch.

git branch [name_of_branch]

git branch new_branch

To switch branches.

git checkout [name_of_branch]

git checkout new_branch

To create a new branch and switch into the new branch with one command.

git checkout -b [name_of_branch]

git checkout -b new_branch

To delete a branch.

git branch -D [name_of_branch]

git branch -D new_branch

...and to see a list of all your branches

 git show-branch

git merge

Lets say you made some changes in your new branch and want to merge it to the master branch. Head to the master branch and run the merge command with the name of the branch you want to take the code from.

git merge [new_branch]

// in master branch
git merge new_branch

git push

After you commit your code to your local Git repository you will want to push your code to a remote Git repository so other people can view and pull your code. With git push we will have to specify the origin and which branch we want to push.

origin is the url of our remote Git repository. It's something like this.

// remote url https://github.com/[username]/[repository-name].git

git push origin master

git pull

Now lets say we are working alongside other developers. Everyone is working on different stuff and we want to get the latest version of our source code, so everyone can be in the same page. In this case we have to pull the code from the remote Git repository, everyone is pushing to(in our case Github), to our local Git repository.

git clone

With git clone you copy a remote repository locally in your machine.

git clone https://github.com/[username]/[repository-name].git

git remote set-url /git remote add

Now in some cases you might want to change the URL of an existing repository, or add a new URL so we can push our code to a second repository as well.

To add a remote URL

git remote add origin https://github.com/[username]/[repository-name].git

Note: The name origin is a convention. It could be anything, like banana.

To replace an existing URL

git remote set-url origin https://github.com/[username]/[repository-name].git

To see a list of our repository remote URL's

git remote -v

origin  https://github.com/[username]/[repository-name].git (fetch)
origin  https://github.com/[username]/[repository-name].git (push)

If you want to add a second remote URL you still do git remote add but with a different name, other that origin.

git remote add banana https://github.com/[username]/[repository-name].git

Our list again

git remote -v

origin https://github.com/[username]/[repository-name].git (fetch)
origin https://github.com/[username]/[repository-name].git (push)
banana https://github.com/[username]/[repository-name].git (fetch)
banana https://github.com/[username]/[repository-name].git (push)

git diff

Show's us the difference between our commits and our working tree. What is in the staging area, waiting to be committed. You can also see difference between branches and such if you dig deeper.

git reset

Goes back in time to a specific version of our code. Since we are dealing with different states we will use different flags in each case.

Let's say you made some changes and committed them. Now you want to return to the previous version that was committed. Since each commit comes with a unique number you can do.

git reset --soft 9e5e6a4

By adding the --soft flag we will go back to those commits but our staging area and working directory will stay as is. If we do a git commit we will commit our current changes from the staging area.

git reset --mixed 9e5e6a4

If we do the same but we use the --mixed flag instead, we will go back again up until the staging area of that commit.

If we do git commit nothing will happen since the staging area matches the what is ready to be committed.

git reset --hard 9e5e6a4

And by adding the --hard flag the same will apply but the changes will go back to the working directory, like nothing was added or committed.

To learn more about reset you can check this.

using ssh

If you don't want to be prompt to type your username and password each time you make a push you can provide an ssh key to your Github settings so Github can identify you.

To generate a new SSH key type

ssh-keygen

This will generate a public and a private file named id_rsa.pub and id_rsa respectively. It will ask you where to save the files. By default it saves them in the users folder with a folder name .ssh.
Head to your Github profile settings and look in the sidebar for SSH and GPG keys section.
Press New SSH key. In here you name and paste your public SSH key.

When creating a new repository you will have the option to set the URL of your repository as HTTPS or SSH.
Choose SSH so the whole process can work.

If you want to change the URL from an existing repository first created with HTTPS , you can do the following.

As we saw before

The git remote -v will list your repo's path.

git remote -v

origin https://github.com/[username]/[repository-name].git (fetch)
origin https://github.com/[username]/[repository-name].git (push)

With git remote set-url

git remote set-url origin git@github.com:USERNAME/REPOSITORY.gi

Check again

git remote -v

origin git@github.com:[username]/[repository-name].git (fetch)
origin git@github.com:[username]/[repository-name].git (push)

Now each time you make a push Github knows who you are.

Up and running with Redux Toolkit

John Raptis — Wed, 25 Dec 2019 09:46:08 +0000

A couple weeks ago I wrote a post about Using Redux with Classes and Hooks. In this post I will take that same example app I made and rewrite it using Redux Toolkit.

RTK(Redux Toolkit) is a new way to write Redux. It takes away the somewhat annoying parts of Redux, like scattered file structure, store configuration and cumbersome boilerplate.

RTK provides us with some cool functions and utilities that take care a lot of repetitive code for us.

Since this is a brief starter example, I highly recommend taking a look at the official documentation, which I think is very well written.

Here is the finished code. If you want to see the 'vanilla' version go to the master branch.

Let's start

Prerequisites

Have worked with Redux and understand the basics of it.

Goals

Convert a 'vanilla Redux' app into a 'RTK' app.

First some brief explanation and then we will jump to the code.

To install RTK run

npm install --save @reduxjs/toolkit

configureStore

In a typical Redux app we set our store with createStore. That's fine but most times you are copy pasting code which is prone to bugs. configureStore takes care of that. It also combines our slice reducers and any kind of middleware we might have.
It uses Redux Thunk by default and enables the use of the Redux DevTools.

Since we have some middleware applied by default if we want to apply more than that we have to define all of them explicitly. The default one's will no longer apply. What we can do in this case is to use the getDefaultMiddleware like so.


const store = configureStore({
  reducer: rootReducer,
  middleware: [...getDefaultMiddleware(), our middleware]
})

createAction

In regular Redux we create an action creator that returns an action type we declared somewhere else and a payload.
createAction is a helper function that simplifies the whole process.

Regular Redux

import { ADD_SONG } from "./types" // somewhere else

export const addSong = song => {
    return {
        type: ADD_SONG,
        payload: song,
    }
}

with createAction

export const addSong = createAction("ADD_SONG")

createReduce

In regular Redux the norm is looping our action types in a switch statement and returning the specified function that updates our state. createReducer simplifies the process yet again. It takes two arguments. The first is an initial state and the second is an object with all of our action. It also uses by default the Immer library that allows us to write immutable code with mutable like syntax.(Seems like you are mutating the state but you are not).

Regular Redux

export default function(state = initialState, action) {
    switch (action.type) {
        case ADD_SONG:
            return {
                songs: [action.payload, ...state.songs],
            }
        default:
            return state
    }
}

With createReducer

export default createReducer(initialState, {
    [addSong]: (state, action) => {
        state.push(action.payload)
    },
}

createSlice

If we want to take things to the next level we can use createSlice that somewhat combines createActions and
createReducer. It's basically a function that accepts an initial state, a reducer object(with functions) and a 'slice' name. Actions are being created for us automaftically.

So let do the rewrite and see how do we apply the above.
First we are going to do this with createAction and createReducer and then with createSlice.

We are going to move all of our actions in the songReducers file to keep things tidy. You can play around with the folder structure to find what fits you best.

import { createAction } from "@reduxjs/toolkit"

// Actions
export const addSong = createAction("ADD_SONG")

export const removeSong = createAction("DELETE_SONG")

export const editSong = createAction("EDIT_SONG")

export const updateSong = createAction("UPDATE_SONG", function prepare(
    title,
    index
) {
    return {
        payload: {
            title,
            index,
        },
    }
})

export const cancelEdit = createAction("CANCEL_EDIT")

Two things to note here.

We don't have to import any action types.
We don't need to type the payload since is returned implicitly.

You will notice that updateSong has some additional stuff going on.

Many times you will find yourself wanting to pass more than one parameter or add additional logic to your actions. You can do just that with the prepare function. In our case we want to have two parameters. A title and index.

Now lets rewrite our reducer.

We import our createReducer. We pass it our initial state and a object with all of our actions like so. No switch statements. Just the name of our action will do.

const initialState = [
    { title: "I love redux", editing: false },
    { title: "The redux song", editing: false },
    { title: "Run to the redux hill", editing: false },
]

// Reducer
export default createReducer(initialState, {
    [addSong]: (state, action) => {
        state.push(action.payload)
    },
    [removeSong]: (state, action) => {
        state.splice(action.payload, 1)
    },
    [editSong]: (state, action) =>
        state.map((song, i) =>
            i === action.payload
                ? { ...song, editing: true }
                : { ...song, editing: false }
        ),
    [updateSong]: (state, action) =>
        state.map((song, i) =>
            i === action.payload.index
                ? { ...song, title: action.payload.title, editing: false }
                : song
        ),
    [cancelEdit]: (state, action) =>
        state.map((song, i) =>
            i === action.payload ? { ...song, editing: false } : song
        ),
})

Now we can do this with createSlice which will make things even more tidy and compact.

createSlice will take an initial state, an object of reducers and a slice name. It will generate the actions automatically with the same name as the reducer.

Again you can play around with the folder structure and the naming conventions.
You can check out the ducks way for bundling your reducers and actions.
Here I've created a folder named features and a file named songSlice. Don't forget to import it in your index file in the reducer folder.

It will look something like this.

Note that it seems like I'm mutating the state directly, but I'm not.

import { createSlice } from "@reduxjs/toolkit"

const songSlice = createSlice({
    name: "songs",
    initialState: [
        { title: "I love redux", editing: false },
        { title: "The redux song", editing: false },
        { title: "Run to the redux hill", editing: false },
    ],
    reducers: {
        addSong: (state, action) => {
            state.push(action.payload)
        },
        removeSong: (state, action) => {
            state.splice(action.payload, 1)
        },
        editSong: (state, action) => {
            const song = state[action.payload]
            song.editing = true
        },
        updateSong: {
            reducer(state, action) {
                const { title, index } = action.payload
                const song = state[index]
                song.title = title
                song.editing = false
            },
            prepare(title, index) {
                return { payload: { title, index } }
            },
        },
        cancelEdit: (state, action) => {
            const song = state[action.payload]
            song.editing = false
        },
    },
})

export const {
    addSong,
    removeSong,
    editSong,
    updateSong,
    cancelEdit,
} = songSlice.actions

export default songSlice.reducer

That's was it. Hope you liked it.

I think RTK is a great step for Redux and I'm curious to see how it's going to evolve in the future.

Special thanks to Mark Erikson for the corrections and feedback on Twitter

Using Redux with Classes and Hooks

John Raptis — Sun, 10 Nov 2019 20:01:20 +0000

In this article we are going to see how to use Redux. The state management tool people love to hate.
I personally like it.

Prerequisites

Basic knowledge of React.
Have worked with Hooks.

Source code and demo down below

view source (example with class components is in a different branch named class_example)
view demo

What is Redux(Quickly)?

Redux is a state management tool that helps you control and update your applications state more efficiently.
Redux itself is a standalone library which means it's framework agnostic. You can use it with any framework but it's usually used with React.
Why should you use it? Passing props up and down can get nasty if you are dealing with larger applicatons. With Redux all your state lives in a single place, which encourage good React architecture.

Core Concepts

store: A central place that our state lives. It's created by calling a function.
reducer: Serves our state to the store and updates the state based on actions.
actions: Functions that are being dispatched(called) and tell the reducer what to do. They do that by sending action types.
Provider By wrapping our entire app with the Provider API we can access our store from anywhere in our app.

So the basic flow is:

Actions are being dispatched to the reducer. The reducer listens for the action type within a switch statement. If it doesn't find any match it will return the default(our state). The end result will be passed in a function named createStore to create our store.

Let's start and things will get clearer as we go.

Create your react app and install all of our dependencies.

create-react-app redux-tutorial

npm install redux react-redux

With Classes

We create a components folder with a component called SongList.js.
An actions folders and a reducers folder as well. In the actions folder we will add two additional files. One songActions.js which will handle all our actions and a types.js the we store our actions type names as constants.
In the reducers folder we will add a songReducers.js file that will handle all our reducers and an index file that will bring all our reducers together and combine them in one. In our case we have just one but we could have many.

Our file structure will look something like this.

src
  |
  actions
    |_ songActions.js
    |_ types.js
  components
    |_ SongList.js
  reducers
    |_ index.js
    |_ songReducers.js

Also add this css in index.css. Just to make things look a bit better.

/*
 index.css
*/
ul {    
    list-style: none;    
    max-width: 400px;    
    margin: 0 auto;    
    background: #ddd;    
    padding: 20px;    
    border-radius: 10px;
}

ul li {    
    padding: 5px;    
    margin-bottom: 10px;    
    background: #fff;    
    display: flex;    
    justify-content: space-between;
}

ul li button {    
    border: 2px solid #ddd;    
    background: #ddd;    
    cursor: pointer;   
    margin-left: 4px;
}

ul > form {    
    margin-top: 50px;
}

ul > form input[type="text"] {    
    height: 24px;    
    padding: 4px;    
    border: none;    
    font-size: .9rem;
}

ul > form input[type="submit"] {   
    padding: 8px;    
    border: none;    
    background: #333;    
    color: #ddd;    
    font-size: .8rem;
}

First in our App.js we import our Provider which will wrap our entire app,the createStore function that creates our store and allReducers that is the collection of one or many reducers.

After importing our SongList.js component we store our apps entire state in a store variable.

//
//App.js
//
import React from 'react'
import './App.css'

import { Provider } from 'react-redux'
import { createStore } from 'redux'
import allReducers from './reducers'

import SongList from './components/SongList'

let store = createStore(allReducers);

Then we wrap everything.

. . .
function App() {
  return (
    <Provider store={store}>
      <div className="App">
        <h1>Songs(with the help of Redux)</h1>
        <SongList />
      </div>
    </Provider>
  );
}
. . .

In our songReducers.js file we set our initial state and pass it in our reducer function. In the switch statement we are going to listen for an action. If none is provided or called we are going to set it to return the state by default.

//
// songReducers.js
//
const initialState = {
    songs: [
        {title: 'I love redux'},
        {title: 'The redux song'},
        {title: 'Run to the redux hill'}
    ]
}

export default function(state = initialState, action) {
    switch(action.type) {
        default:
            return state;
    }
}

In our reducers/index.js we import all our applications reducers (in our case just one) and pass them to a function named combineReducer. And it does what the name implies. Combines all of our reducers in one and that is what is passed in the createStore function in App.js

//
// reducers/index.js
//
import { combineReducers } from 'redux';
import songReducers from './songReducers'

const allReducers = combineReducers({
    songs: songReducers
});


export default allReducers;

Now the fun part. Let's bring and consume our state in the SongList.js component. There are a lot to cover here so bear with me.

We import the connect function that will wrap our SongList.js component. With connect we will actually be able to access our state as props.
connect takes four optional parameters, but in our case we will use the first two.
mapStateToProps and mapDispatchToProps. If we use only one of two the one we don't use should be passed as null.

mapStateToProps provide us with the store. Every time the state changes this function will be called

It takes two parameters. state and ownProps.
With state the function is called when the state changes.
With state and ownProps the function is called both when the state changes and when the current component receives props. In our case we just pass state and set songs with the state.songs that was created by our store.

//
// SongList.js
//
. . .
const mapStateToProps = (state) => ({
  songs: state.songs
});
. . .

mapDispatchToProps will provide us with the actions we need to use in our component so we can dispatch them and change our state.

It may be a function or an object. In our case it will be an object of the actions we imported from the songActions.js.

It will look something like this.

//
// SongList.js
//
import React from 'react'
import { connect } from 'react-redux'
import { actionOne, actionTwo } from '../actions/songActions'

. . .

const mapDispatchToProps = {
    actionOne,
    actionTwo,
}

export default connect(mapStateToProps, mapDispatchToProps)(SongList);

Or we can destructure.

export default connect(mapStateToProps, { actionOne, actionTwo })(SongList);

Since we don't have any actions yet we pass null.
Later on we will pass all the actions we need.

const mapStateToProps = state => ({
  songs: state.songs
});

export default connect(mapStateToProps, null)(SongList);

Now we can access the songs we defined in mapStateToProps as props in our component.
We destructure it in our render function.

//
// SongList.js
//
import React from 'react'
import { connect } from "react-redux"

class SongList extends React.Component {

    render() {
        const { songs } = this.props.songs;
        return (
            <ul>
            {songs.map((song, i) => {
                return (
                    <li key={song.title}>
                    {song.title}
                    </li>
                )
            })}
            </ul>
        );
    }
}

const mapStateToProps = state => ({
  songs: state.songs
});

export default connect(mapStateToProps, null)(SongList);

Now let's see how can we add new songs, delete songs and update songs as well.

In the code below we add a form. when input changes we call the onChange function, that sets our local state. On the onSubmit function we dispatch an action with our newSong as a parameter.

Note: that we start to populate our connect function with the actions we are using.

//
// SongList.js
//
. . .
import { addSong } from '../actions/songActions'

. . .

constructor(props) {
    super(props);
    this.state = {
      newSong: '',
    };

    this.onChange = this.onChange.bind(this);
    this.onSubmit = this.onSubmit.bind(this);
    this.remove = this.remove.bind(this);
  }

    onSubmit(e) {
        e.preventDefault();

        const addedSong = {
            title: this.state.newSong
        }

        this.props.addSong(addedSong);
        this.setState({ newSong: '' });
    }    

    onChange(e) {
       this.setState({ [e.target.name]: e.target.value });
    }

    render() {
        const { songs } = this.props.songs;
        return (
            <ul>
            {songs.map((song , i) => {
                return (
                    <li key={song.title}>
                    {song.title}
                    </li>
                )
            })}
            <form onSubmit={this.onSubmit}>
                <input type="text" name="newSong" onChange={this.onChange} />
                <input type="submit" value="Add Song" />
            </form>
            </ul>
        );
    }
}

const mapStateToProps = state => ({
  songs: state.songs
});

export default connect(mapStateToProps, { addSong })(SongList);

In songActions.js we create the addSong function and pass the newSong as payload. Payload is data we pass with the action, second parameter in the switch statement in songReducers.js. We access it as action.payload.

//
// songActions.js
//
import { ADD_SONG } from './types'

export const addSong = (song) => {
    return {
        type: ADD_SONG,
        payload: song
    }
}

Note: It is considered best practice to store the action types as constants in a file named types.js in the actions folder.

//
// actions/types.js
//
export const ADD_SONG = 'ADD_SONG';

Do this with every additional action typey you add.

Now the songReducers.js will look like this. The action.payload is the song parameter we passed in our addSong function.

//
// songReducers.js
//
. . .
export default function(state = initialState, action) {
  switch(action.type) {
    case ADD_SONG:
      return {
        songs: [action.payload, ...state.songs]    
      }
    default:
      return state;
    }
}
. . .

To remove a song we follow the same process.

We create a button. When clicking we call the remove function with the index of the song as a parameter. Again we dispatch the removeSong action.

//
// SongList.js
//
. . .
import { addSong, removeSong } from '../actions/songActions'

. . .

  remove(i) {
        this.props.removeSong(i);
    }

    render() {
        const { songs } = this.props.songs;
        return (
            <ul>
            {songs.map((song , i) => {
                return (
                    <li key={song.title}>
                    {song.title}
                    <button onClick={() => this.remove(i)}>Delete</button>
                    </li>
                )
            })}
            <form onSubmit={this.onSubmit}>
                <input type="text" name="newSong" onChange={this.onChange} />
                <input type="submit" value="Add Song" />
            </form>
            </ul>
        );
    }
}

const mapStateToProps = state => ({
  songs: state.songs
});

export default connect(mapStateToProps, { addSong, removeSong })(SongList);

Lastly to update a song we must change a few things. First we will modify our initialState by adding editing: false in each of our song object. This will control which song is being edited.

//
// songReducers.js
//
. . .
const initialState = {
    songs: [
        {title: 'I love redux', editing: false},
        {title: 'The redux song', editing: false},
        {title: 'Run to the redux hill', editing: false}
    ]
}
. . .

In our songList.js component depending if a songs editing state is true or false, we will render a different li.

//
// SongList.js
//
. . .

render() {
        const { songs } = this.props.songs;
        return (
            <ul>
            {songs.map((song , i) => {
                return (
                    <Fragment key={song.title}>
                    {(!song.editing) ? (
                    <li>
                    {song.title}
                        <span>
                          <button onClick={() => this.remove(i)}>Delete</button>
                          <button onClick={() => this.edit(i, song.title)}>Edit</button>
                        </span>
                    </li>
                        ) : (
                    <li>
                         <form>
                            <input
                            type="text"
                            name="currentVal"
                            value={this.state.currentVal}
                            onChange={this.updatedVal}
                            />
                        </form>
                         <span>
                             <button onClick={() => this.cancel(i)}>Cancel</button>
                             <button onClick={() => this.update(i)}>Update</button>
                        </span>
                    </li>
                        )}
                    </Fragment>
                )
            })}
            <form onSubmit={this.onSubmit}>
                <input
                type="text"
                name="newSong"
                onChange={this.onChange}
                />
                <input type="submit" value="Add Song" />
            </form>
            </ul>
        );
    }

 . . .

With our new adjustments the whole thing looks like this.

//
// SongList.js
//
import React, { Fragment } from 'react'
import { connect } from 'react-redux'
import {
    addSong,
    removeSong,
    editSong,
    updateSong,
    cancelEdit
} from '../actions/songActions'


class SongList extends React.Component {

  constructor(props) {
    super(props);
    this.state = {
      newSong: '',
      currentVal: ''
    };

    this.onChange = this.onChange.bind(this);
    this.onSubmit = this.onSubmit.bind(this);
    this.remove = this.remove.bind(this);
    this.edit = this.edit.bind(this);
    this.update = this.update.bind(this);
    this.cancel = this.cancel.bind(this);
    this.updatedVal = this.updatedVal.bind(this);
  }

    onSubmit(e) {
        e.preventDefault();

        const addedSong = {
            title: this.state.newSong
        }

        this.props.addSong(addedSong);
        this.setState({ newSong: '' });
    }    

    onChange(e) {
        this.setState({ [e.target.name]: e.target.value });
    }

    updatedVal(e) {
        this.setState({ [e.target.name]: e.target.value });
    }

    remove(i) {
        this.props.removeSong(i);
    }

    edit(i, title) {
        this.props.editSong(i);
        this.setState({ currentVal: title })
    }

    update(i) {
        this.props.updateSong(this.state.currentVal, i);
        this.setState({ currentVal: '' })
    }

     cancel(i) {
        this.props.cancelEdit(i);
    }

    render() {
        const { songs } = this.props.songs;
        return (
            <ul>
            {songs.map((song , i) => {
                return (
                    <Fragment key={song.title}>
                    {(!song.editing) ? (
                    <li>
                    {song.title}
                        <span>
                            <button onClick={() => this.remove(i)}>Delete</button>
                            <button onClick={() => this.edit(i, song.title)}>Edit</button>
                        </span>
                    </li>
                        ) : (
                    <li>
                         <form>
                            <input
                            type="text"
                            name="currentVal"
                            value={this.state.currentVal}
                            onChange={this.updatedVal}
                            />
                        </form>
                         <span>
                             <button onClick={() => this.cancel(i)}>Cancel</button>
                             <button onClick={() => this.update(i)}>Update</button>
                        </span>
                    </li>
                        )}
                    </Fragment>
                )
            })}
            <form onSubmit={this.onSubmit}>
                <input
                type="text"
                name="newSong"
                onChange={this.onChange}
                />
                <input type="submit" value="Add Song" />
            </form>
            </ul>
        );
    }
}

const mapStateToProps = state => ({
  songs: state.songs
});

export default connect(mapStateToProps, {
    addSong,
    removeSong,
    editSong,
    updateSong,
    cancelEdit
})(SongList);

The songActions.js looks like this.

//
// songActions.js 
//
import {
    ADD_SONG,
    DELETE_SONG,
    EDIT_SONG,
    UPDATE_SONG,
    CANCEL_EDIT
} from './types'

export const addSong = (song) => {
    return {
        type: ADD_SONG,
        payload: song
    }
}

export const removeSong = (index) => {
    return {
        type: DELETE_SONG,
        payload: index
    }
}

export const editSong = (index) => {
    return {
        type: EDIT_SONG,
        payload: index
    }
}

export const updateSong = (title, index) => {
    return {
        type: UPDATE_SONG,
        title,
        index
    }
}

export const cancelEdit = (index) => {
    return {
        type: CANCEL_EDIT,
        index
    }
}

And the songReducer.js looks like this.

//
// songReducers.js
//
import {
    ADD_SONG,
    DELETE_SONG,
    EDIT_SONG,
    UPDATE_SONG,
    CANCEL_EDIT
} from '../actions/types'

const initialState = {
    songs: [
        {title: 'I love redux', editing: false},
        {title: 'The redux song', editing: false},
        {title: 'Run to the redux hill', editing: false}
    ]
}

export default function(state = initialState, action) {
    switch(action.type) {
        case ADD_SONG:
            return {
                songs: [action.payload, ...state.songs]    
            }
        case DELETE_SONG:
            return {
                songs: state.songs.filter((s, i) => i !== action.payload)
            }
        case EDIT_SONG:
            return {
            songs: state.songs.map((song, i) =>
            i === action.payload
            ? { ...song, editing: true }
            : { ...song, editing: false }
                )
            }
        case UPDATE_SONG:
            return {
            songs: state.songs.map((song, i) =>
            i === action.index
            ? { ...song, title: action.title, editing: false}
            : song
        )
            }
        case CANCEL_EDIT:
            return {
        songs: state.songs.map((song, i) =>
            i === action.index ? { ...song, editing: false } : song
        )
            }
        default:
            return state;
    }
}

With Hooks

Using Redux with Hooks is way better. It's has fewer boilerplate and I think is easier to work with.
Although it adds a layer of abstraction, if you know the Class way of doing it first, things will stay pretty lean and self-explanatory.

Our songActions.js and songReducers.js will look exactly the same. The only difference is in our SongList.js component.

Instead of connect we are going to use the useSelector hook to access parts of the state directly, and useDispatch to dispatch actions.

useSelector is somewhat equivalent to mapStateToProps and useDispatch is somewhat equivalent to mapDispatchToProps. They have some differences though which you can check the documentation for details.

//
// SongList.js
//
import React, { Fragment, useState } from 'react'
import { useDispatch, useSelector } from "react-redux"
import {
    addSong,
    removeSong,
    editSong,
    updateSong,
    cancelEdit
     } from '../actions/songActions'

const SongList = () => {
    const dispatch = useDispatch()
    const [newSong, setNewSong] = useState();
    const [currentVal, setCurrentVal] = useState();
    const { songs } = useSelector(state => state.songs)

    const addNewSong = (e) => {
        e.preventDefault();

        const addedSong = {
            title: newSong
        }

        if(addedSong.title) {
            dispatch(addSong(addedSong))
            setNewSong('')
        }
    }    

    const remove = (i) => {
        dispatch(removeSong(i))
    }

    const update = (i) => {
        dispatch(updateSong(currentVal, i))
        setCurrentVal('')
    }

    const edit = (i, title) => {
        dispatch(editSong(i))
        setCurrentVal(title)
    }

    const cancel = (i) => {
        dispatch(cancelEdit(i))
    }

    return (
        <ul>
        {songs.map((song , i) => {
            return (
                <Fragment key={song.title}>
                {(!song.editing) ? (
                <li>
                {song.title}
                    <span>
                        <button onClick={() => remove(i)}>Delete</button>
                        <button onClick={() => edit(i, song.title)}>Edit</button>
                    </span>
                </li>
                    ) : (
                <li>
                    <form>
                        <input type="text" value={currentVal} onChange={e => setCurrentVal(e.target.value)} />
                    </form>
                    <span>
                        <button onClick={() => cancel(i)}>Cancel</button>
                        <button onClick={() => update(i)}>Update</button>
                    </span>
                </li>
                    )}
                </Fragment>
            )
        })}
            <form onSubmit={addNewSong}>
                <input type="text" onChange={e => setNewSong(e.target.value)} />
                <input type="submit" value="Add Song" />
            </form>
        </ul>
    )
}

export default SongList

Conclusion

That is pretty much it. Redux can get more complicated but the core concepts are the ones mentioned.

Darkmode with React Context API(Classes and Hooks)

John Raptis — Tue, 01 Oct 2019 15:05:52 +0000

Darkmode is a small little feature that is pretty common these days. Now I'm not writing this article on why it's cool but I think this is a nice opportunity to learn some concepts that come with this. And it's actually the first example that I came across and made me understand how the React Context API works. First we will do this using Class components and then we will move to functional ones using Hooks.
This article was inspired by reading the docs(really?)

Prerequisites:

Have Node.js and npm installed globally.
Know the basics of React.

Source code and demo down below

view source (example with class components is in a different branch named classComponents)
view demo

What is the Context API?(Quickly)

The Context API is a way to control/handle the state of our application. A central place for all of our data.
Now you will say that 'isn't Redux for that'? And yes Redux does all of that.
You would prefer to use Context API though over something like Redux if you are dealing with a smaller application, where Redux might be a bit of an overkill.

Lets create our darkmode-app and learn as we go.

With Classes

First create you React app with the usual command.

npx create-react-app darkmode-app

Our file structure will look something like this.

assets
    |__ sun.svg
    |__ moon.svg
components
    |__ Navbar.js
    |__ MainBody.js
    |__ ToogleTheme.js
contexts
    |__ThemeContext.js

Three components in a components folder and one in a contexts folder. The later will be our single source of truth. Also we will have an assets folder for our moon and sun icons.

Some css for basic styling. I use scss so go ahead and npm install node-sass as well. Don't forget to change the extension in index.js from .css to .scss.

Our Navbar component ...

import React, { Component } from 'react';
import ToggleTheme from './ToggleTheme';

class Navbar extends Component {

    render() {
        return (
            <div className="navbar">
                <h1>Navbar</h1>
                <ToggleTheme />
            </div>
        )
    }
}

export default Navbar;

... and our MainBody component.

import React, { Component } from 'react';

class MainBody extends Component {

    render() {
        return (
            <div>
                <div className="main-body">
                    <h1>MainBody</h1>
                    <h2>Subtitle</h2>
                    <p>. . . </p>
                </div>
            </div>
        )
    }
}

export default MainBody;

Now you might have guessed it. Our state that will control in what mode we are(darkmode / lightmode) must be global and accessible from everywhere. So our changing color theme logic will live in the ThemeContext.js file.

import React, { Component, createContext } from 'react';

export const ThemeContext = createContext();

class ThemeContextProvider extends Component {
    state = {
        lightTheme: true
    }

    toggleTheme = () => {
        this.setState({ islightTheme: !this.state.lightTheme });
    }

    render() {
        const { children } = this.props;
        return (
            <ThemeContext.Provider value={{...this.state, toggleTheme: this.toggleTheme }}>
            {children}
            </ThemeContext.Provider>
        );
    }
}

export default ThemeContextProvider;

Above we imported React and createContext. createContext creates a Context object. We store that in a const named ThemeContext.

We create a component named ThemeContextProvider. This component's state will contain our global data. In this case if lightTheme is true or false.

To provide our components with the necessary data we have the Provider tag that surrounds the components that we want to pass the data to.

In our render function above we are returning our ThemeContext object we created and give it the Provider tag. We pass a value property that accepts the data we want to pass. In this case we pass an object with our state and functions(in our case toggleTheme function toggles our state).

Inside we destructure the children prop that refers to our child components. The ones we are nesting in our App.js file.

Looks like this.

import React from 'react';
import Navbar from './components/Navbar';
import MainBody from './components/MainBody';
import ThemeContextProvider from './contexts/ThemeContext';

function App() {
    return (
        <div className="App">
            <ThemeContextProvider>
                <Navbar />
                <MainBody />
            </ThemeContextProvider>
        </div>
    );
}

export default App;

We provided our data all over our application using Provider with the ThemeContext object. Now we have to catch the data from each of our components. We do this using the Consumer tag.

In our ToggleTheme component we import the ThemeContext object.(NOT the ThemeContextProvider component) and wrap our JSX inside the render function with the ThemeContext.Consumer tag.

import React, { Component } from 'react';
import sun from '../assets/sun.svg';
import moon from '../assets/moon.svg';
import { ThemeContext } from '../contexts/ThemeContext';

class ToggleTheme extends Component {

    state = {
        icon: false
    }

    iconChange = () => {
        this.setState({ icon: !this.state.icon });
    }

    render() {
        return (
            <ThemeContext.Consumer>{(context) => {
                return (
                    <div className="toggle__box">
                        <span>
                        {this.state.icon ? (
                            <img src={moon} className="moon-icon" />                     
                        ) : (
                            <img src={sun} className="sun-icon" />
                        )}
                        </span>
                        <div className="toggle__btn" onClick={context.toggleTheme}>
                            <input type="checkbox" className="checkbox"
                            onChange={this.iconChange}  />
                            <div className="circle"></div>
                            <div className="layer"></div>
                        </div>
                    </div>
                )
            }}</ThemeContext.Consumer>
        )
    }
}

export default ToggleTheme;

Our Consumer expects a function. We pass our context and return our JSX
Note that with onClick we fire the toggleTheme function.

We also have some local state to show the proper icon based on the state of our theme.
With onChange we call the iconChange function that controls which icon should be shown.

In Navbar.js we will change the background color on darktheme. We are going to apply a className based on our lightTheme's state.

Again we import ThemeContext and apply it with the Consumer.

import React, { Component } from 'react';
import ToggleTheme from './ToggleTheme';
import { ThemeContext } from '../contexts/ThemeContext';

class Navbar extends Component {

    render() {
        return (
            <ThemeContext.Consumer>{(context) => {
            const theme = !context.lightTheme ? ' darkmode' : '';
            return (
                <div className={"navbar" + (theme)}>
                    <h1>Navbar</h1>
                    <ToggleTheme />
                </div>
                )
            }}</ThemeContext.Consumer>
        )
    }
}

export default Navbar;

We store a conditional statement in a const named theme and pass it as a className.
The same applies for our MainBody component.

import React, { Component } from 'react';
import { ThemeContext } from '../contexts/ThemeContext';

class MainBody extends Component {

    render() {
        return (
            <ThemeContext.Consumer>{(context) => {
            const theme = !context.lightTheme ? ' darkmode' : '';
                return (
                    <div className={"" + (theme)}>
                        <div className="main-body">
                            <h1>MainBody</h1>
                            <h2>Subtitle</h2>
                            <p>. . . </p>
                        </div>
                    </div>
                )
            }}</ThemeContext.Consumer>
        )
    }
}

export default MainBody;

With Hooks

Now let's rewrite this using Hooks. I personally prefer this way since it's easier to reason about and cleaner for the eye.
Hooks provide us with special functions. There are many but we will use two.

useState()

will allow us to use state in functional components.

useContext()

will allow us to consume context in functional component.

Our Navbar component will change like this.

import React, { Component, useContext } from 'react';
import ToggleTheme from './ToggleTheme';
import { ThemeContext } from '../contexts/ThemeContext';

const Navbar = () => {
    const { lightTheme } = useContext(ThemeContext);
    const theme = !lightTheme ? ' darkmode' : '';
    return (
        <div className={"navbar" + (theme)}>
             <h1>Navbar</h1>
             <ToggleTheme />
         </div>
    )
}

export default Navbar;

We import the useContext function on top and instead of wrapping our content in a Consumer we destructure the state. (In our case the lightTheme).
And that's it.

The same will apply for MainBody.js.

import React, { Component, useContext } from 'react';
import { ThemeContext } from '../contexts/ThemeContext';

const MainBody = () => {
    const { lightTheme } = useContext(ThemeContext);
    const theme = !lightTheme ? ' darkmode' : '';

    return (
        <div className={"" + (theme)}>
            <div className="main-body">
                <h1>MainBody</h1>
                <h2>Subtitle</h2>
                <p>. . .</p>
            </div>
        </div>
    )
}

export default MainBody;

Going forward in our ToggleTheme component we import useContext and useState as well.
With useContext we grab the toggleTheme function and with useState we set the state of our icon.
icon is the default and with setIcon we pass the new value.(takes place in the iconChange function).

import React, { Component, useState, useContext } from 'react';
import sun from '../assets/sun.svg';
import moon from '../assets/moon.svg';
import { ThemeContext } from '../contexts/ThemeContext';

const ToggleTheme = () => {
    const { toggleTheme } = useContext(ThemeContext);
    const [icon, setIcon] = useState(true);

    const iconChange = () => {
        let newIcon = !icon;
        setIcon(newIcon);
    }

    return (
        <div className="toggle__box">
            <span>
            {icon ? (
                <img src={moon} className="moon-icon" />
            ) : (
                <img src={sun} className="sun-icon" />
            )}
            </span>
            <div className="toggle__btn" onClick={toggleTheme}>
                <input type="checkbox" className="checkbox" onChange={iconChange}  />
                <div className="circle"></div>
                <div className="layer"></div>
            </div>
         </div>
    )
}

export default ToggleTheme?

Note in our returned JSX we don't use the this keyword.

Lastly in our ThemeContext.

import React, { Component, createContext, useState } from 'react';

export const ThemeContext = createContext();

const ThemeContextProvider = (props) => {
    const [lightTheme, setLightTheme] = useState(true);

    const toggleTheme = () => {
        setLightTheme(!lightTheme);
    }
    const { children } = props;
    return (
        <ThemeContext.Provider value={{ lightTheme, toggleTheme }}>
             {children}
        </ThemeContext.Provider>
    )
}

export default ThemeContextProvider;

Again we set and change the state with useState. And again note that we don't use the this keyword.

That was it. Now you have the basic logic down. So get to work and try things of your own. That is the best way to learn.

The sooner you hit a wall the better. Trust me.