DEV Community: Elijah Trillionz

Have little or no use for comments

Elijah Trillionz — Mon, 13 Feb 2023 12:30:50 +0000

The first time I heard about comments, I was told it is meant to document why a code is what/how it is. As nice as it sounded to me, it didn't make so much sense, probably because I was just starting my programming journey.

But it is in fact the reason for comments, a comment that explains what a code is or how a code works simply indicates a bad code.

You wouldn't have to explain what a code does if the code already explains what it does, and how it does it. Here is an example

// get signed in user
const getUser = () => {
  return { name: 'John', age: 22 };
};

What do you think of the comment in the example above? Do you think is necessary? In my opinion, this comment is so unnecessary.

But here is the thing, the developer probably felt he/she should add the comment there because if it should be omitted, then a reader (maintainer/developer) would find it hard to understand which user the function - getUser is getting.

So because the author (developer) is trying to be good, he/she would leave a comment there to make sure whoever maintains it in the nearest future (author included) would not find it hard to know "what" the getUser function does.

So Elijah, how is the comment unnecessary?

Having comments like this all around your project is blatantly bad for maintenance. Because here is the thing, developers hardly maintain comments. Most of us forget it's irrelevant to update a comment after updating its code or we simply forget most times. But that's what leads to bad codes.

Here is an example, if the purpose of the getUser function is to change to getting any random user, let's say by id, then we'd most likely now have

// get signed in user
const getUser = (id) => {
  return users.find((user) => user.id === id);
};

Here is the scenario:
When a reader sees this function being called elsewhere, he/she would clearly have to come to where the function is declared (which could be in a different file) just to know exactly what the code does.

The reader looks for where the getUser function is declared because the function name getUser doesn't really give the full picture of what the function does.

So he/she sees the function and the comment get signed in user and probably goes back with a conclusion of what the code does (which is a wrong conclusion) or gets confused because there is probably another function that gets the signed-in user.

So the thought of "is the code redundant?" comes to the reader's mind, the reader would now have to read the two functions explicitly to know which is which.

This is bad code, especially when they are tons of developers maintaining the project. Because if the first reader finally understands what the getUser function does and doesn't change the code to make it clean, any other reader would go through the same thing the first reader went through.

So what should we do with situations like this?

Get rid of the comment and write a clean code, the first example could be

const getSignedInUser = () => {
  return { name: 'John', age: 22 };
};

and refactoring into the second example could be

const getUserById = (id) => {
  return users.find((user) => user.id === id);
};

When a reader sees getSignedInUser elsewhere, he/she already knows what the function does.

What comments should be for

When your comments are to only explain why a code works the way it does, you'd have little or no use for comments at all.

Here is a simple example from my library (native-json-db) that I refactored. Because I had to refactor most of my projects (that are still in maintenance) after I got a grasp of what my comments should be for and how to make them right:

// verify the newData is an object, useful for javascript users
if (typeof newData !== 'object' || Array.isArray(newData)) {
  return {
    message: 'New data must be an object',
    error: 'INVALID_DATA_TYPE',
    errorCode: 611,
  };
}

In the example above, there is a "what" and a "why" in the comment. The "what" being verify the newData is an object, and the "why" being for javascript users. A reader who sees the condition should already know the code verifies the newData is an object, but the question of why comes to mind. Because this is a typescript project, so why did the author have to validate the newData this way.

If there isn't a comment that explicitly states a reason, the reader may just end up removing the whole condition and then we'd have a bug. So refactoring the comment should only leave the for javascript users there.

While refactoring the code in this library, I found where I resolved a promise when an error occurred rather than the usual reject that I've been using throughout the code. But then I didn't write why I decided to resolve rather than reject.

And now, I don't remember what made me resolve rather than reject. I know it was intentional. But had it been I commented the reason, I wouldn't have had to struggle with my decision there for a minute.

So for decisions you make that you know would lead to a question of "why did I do this like this", or "why did he/she do this instead of this", you should do well to state your reason precisely, to save everyone's time

Necessary comments

There are some cases where comments other than "whys" comments can prove useful, like in tutorials. i.e places that require further explanation and wouldn't require maintenance per se.

Nonetheless, when you create a project that you're sure nobody is coming back to, it is also a good practice to write clean code as much as possible.

Personally, when I work on such projects for learning purposes, I still wanna make sure it is clean and I don't have unnecessary comments. Because I don't want to get used to writing bad code with unnecessary comments.

So I'd recommend using every other type of comment explicitly for teaching purposes for beginners.

Other common necessary usages of comments are in license, and todos (which you shouldn't forget to get rid of when done).

Some common bad comments

Apart from it being generally frustrating, some comments have specific frustrating features. There are several of them, but the common ones are misleading comments, redundant comments, and commented codes.

After refactoring a ton of my projects, these are some of my errors and observations.

Misleading comments

All bad comments can be misleading, but some are definitely misleading. for example;

// updateMany options
interface UpdateManyOptions {
  updateAll: boolean;
}

// updateMany options
interface DeleteManyOptions {
  deleteAll: boolean;
}

In this example, I (the developer) simply copied the UpdateManyOptions block of code (including the comment) for the DeleteManyOptions just for me to forget to update the comment. And as such the comment is quite misleading. Besides both comments are redundant.

Another misleading comment I had was this

  // find object with the key value
  findOne(filter: Object): Promise<Object | null> {}

In the findOne function, there is no key value being passed as a parameter nor is there a variable called key. So that can get confusing for some readers. You could say alright, to not make it misleading let's refactor the comment to find object with filter provided, but then would the comment really be necessary? No, it wouldn't. So Elijah, please get rid of that.

Redundant comments

Like in the example in the previous section, the name of the interface UpdateManyOptions already explains what the interface is for. So what's the essence of the comment? I have a couple of redundant comments like this

  // get the whole data in d document
  get allData(): Promise<Object[]> {
    return new Promise(async (resolve) => {
      resolve(this.dataArr);
    });
  }

The thing about redundant comments is that you'd have to learn about what the code does twice. Because you'd see the comment first and be like get the whole data in d document and end up seeing the function saying the same thing. Why the stress? Just get rid of the comment if the code already explains itself.

Commented codes

This is quite common. But gone are the days where you'd need a code you didn't need before and start crying about it because you deleted it rather than simply commenting it out.

With tools like git, you can keep track of every code change you made in your project. So if you don't need a code now, delete it. When you need it, go to the git history of the project and get it.

But the problem with this is when you don't commit every change you make to your code. So you should endeavor to commit every change made to your code, I'm starting to do this too. It's been really helpful for me.

Another common bad comment

How to get rid of bad comments

Try not to get me wrong here, the only reason you should get rid of the "whats" or "hows" comment in your code is that your code should already explain what it does and how it does it.

For example;

// expires in 10 days
const e = 60 * 60 * 24 * 10;

The comment there shouldn't be there. But believe it or not, it's quite helpful there. Because if you remove it, a reader would have no idea what the variable e is for.

So it's one thing to get rid of all the unnecessary comments in your code, it's another thing to refactor your code to not need those comments in the first place:

const expiresIn = 60 * 60 * 24 * 10;

So as a good practice, when you're refactoring; first refactor your code to not need the comment before getting rid of the comment.

Now refactoring your code to not need a comment can be challenging at first, but with time you'd get used to having tons of ideas for refactoring. But there are some good practices you can use to start out;

for example;

// get all users and sort them by their names alphabetically
const getUsers = async (username, password) => {
  const res = await fetch('http://localhost:5000/users');

  const users = await res.json();

  users.sort((a, b) => {
    if (a.name > b.name) {
      return 1;
    } else if (a.name < b.name) {
      return -1;
    }

    return 0;
  });
};

So if we want to refactor this to not use the comment, we may end up with a function name as getUsersAndSortThem or sth similar. This is your function doing two things, which isn't the best thing for a function. Because when it comes to writing clean codes, as much as possible your function should only perform one task.

So you should break the function into two, where you'd have a getUsers and sortUsers function separately.

Here is another example of breaking things up to be more readable

const sortUsers = () => {
  // in comparison, if name of first param is greater than name of second param return 1, if opposite return -1, else return 0
  users.sort((a, b) => (a.name > b.name ? 1 : b.name > a.name ? -1 : 0));
};

This developer knows that reading the users.sort line would take time to fully understand what's going on there (because it's not really readable), so he/she decided to help with an overwhelming comment. A simpler fix would've been to break the ternary operators to if statements to become more readable.

In most cases, it is often best to not use more than one ternary operator, because it'd be hardly readable.

All these are what make refactoring codes interesting. But if you don't know how to write clean readable code, removing comments (that usually solve your problem of writing bad code by explaining what's going on) becomes an even bigger problem.

So read books, or articles on how to write clean codes, and learn from superiors. I recommend reading the book - Clean code by Robert Ceil Martin.

Conclusion

Comments are an important part of your code, they indicate if you've not done so well in your code as well as indicate if you've done well. If you've done well, trust me you'd hardly have use for comments, and if you haven't you would have comments on almost every part of your code, trying to make up for the bad code you've written.

But picking up this new habit of writing clean code doesn't happen overnight. Get into your past projects, and refactor as many as possible. Check out some open-source projects and do what you can there. And soon enough you'd get the hang of it. I'm still getting the hang of it myself.

Alright, that's it for this. Thanks for reading. Please if you enjoyed this article hit the like button and leave a comment for me. You can also follow up with more articles like this by following me here and on Twitter @elijahtrillionz.

And yeah, you can buy me a coffee to support my writing as well. A dollar can go a long way in cheering me up. I appreciate.

You Don't Need To Learn TailwindCSS To Use It

Elijah Trillionz — Wed, 12 Oct 2022 10:29:56 +0000

A few months back, I wrote an article on when to learn React, now in this article, I'm going to do something similar on TailwindCSS/Tailwind only that it's "using" rather than "learning" because you don't need to learn Tailwind.

I decided to write this article like a week ago because of how easy I discovered using Tailwind was for me, even though I didn't learn anything about it. I was only contributing to an open-source project for Hacktoberfest.

The project uses Tailwind, and though I liked using vanilla CSS, I just had to go with the project. And believe me when I tell you, it was as easy as "a walk in the park", unless walking in the park is not easy for you. Hmmm 🤔

Tailwind is a very useful framework for CSS developers, but some developers I have seen tend to have the wrong idea of the framework. Tailwind is not a framework for learning CSS, and neither does it improve your knowledge or understanding of CSS all by itself.

Hey, don't be quick now to jump to the comment section to say "I disagree with you, Tailwind helped me understand CSS better". Allow me to explain further first, ok. Let's all learn something new together.

And also, as I mentioned in a similar article for React, this isn't an article that discourages you from using Tailwind or other CSS frameworks, rather it's an article that hopes to explain what Tailwind is, when to use it, and how to use it. So sit back, relax, and enjoy this walk in the park.

What is Tailwind

Tailwind is a utility-first CSS framework that makes using CSS better. So rather than using semantic classes along with a stylesheet file, you simply use single-purpose classes.

Now what this means is this, a traditional HTML file for a simple webpage could be

<style>
  .desc {
    padding: 15px;
    border: 2px solid red;
  }
  .subtitle {
    color: gray;
  }
</style>
<p class="desc">This is the description of the page</p>
<h1>Hello World</h1>
<p class="subtitle">This is a subtitle</p>

So the styles of the desc class are only applied to the p element, right? But with Tailwind, it gets better

<p class="p-4 border-2 border-solid border-red-900">
  This is the description of the page
</p>
<h1>Hello World</h1>
<p class="text-gray-900">This is a subtitle</p>

All the styles we applied on the first example - padding, border, and color - have been applied on the second example without you directly using CSS.

So you can apply flex to an element just by specifying a class that is a style declaration in a global style file provided by Tailwind. The same thing goes for transition (for animations), border-radius, and so much more.

Every style you could ever need has been provided as a class for you to just plug into your HTML file. This alone can make working with CSS 10 times easier for you.

And another cool thing about Tailwind is that unlike JavaScript frameworks (like React), Tailwind is not limited to some projects only, or rather not "most suitable" for some projects. Using Tailwind spans from using it on a simple personal project to a scaling web application.

How to use Tailwind

As this subtitle suggests, you don't learn Tailwind, you just use it. A lot of developers may not want to agree with me, but it's true.

Think about it: there is nothing to learn in Tailwind other than how to set it up for your project.

If you should find yourself learning Tailwind, then you are not really learning Tailwind rather you're learning CSS. I'll explain how this is possible in a moment.

But before any Tailwind, try as much as possible to learn the basics of CSS well. Because the thing is, here is a tool that makes using another tool easier for you, but if you don't understand or know how the primary tool works, you'll struggle.

For example, a product designer who understands product designing and stuff will never struggle using any other design tool than what he/she is used to. It may take time for him/her to fully adapt to the new workstation, but it comes eventually.

The way I use Tailwind is what I'd recommend for every beginner I meet because funnily enough there is hardly a CSS developer who understands how to use CSS that will struggle with using Tailwind.

Here is how it works for me, say I need to create an element with spaces between the content(s) and the container of the element, I would simply go ahead to Tailwind docs to get the possible classes for padding. Because what I need is padding right? Not margin!

Now how do I know exactly what I need to get the job done? I have understood the basics of vanilla CSS.

The same thing goes for creating a hover effect on a button, I just head on to Tailwind's docs to see the available classes for hovering, or better still how to apply hover effects with Tailwind.

So in summary, since I know what I want to do in CSS, then I seek to know how to apply what I need with Tailwind. With time I will not need to go to the Tailwind docs to see how to apply padding or any other styles in CSS, because by then I'd have gotten used to the ones I use most frequently.

That's why I don't recommend trying to learn/memorize Tailwind classes - py, px, rounded, and others. It's a total waste of time.

These classes will only stick to you if you've built tons of projects with them, you don't have to memorize them.

Besides, there is a cool VSCode extension that autocompletes these class names without you going to the docs.

So if you're a beginner in CSS, and you want to jump into Tailwind, I'd recommend you practice what you know in CSS first, build like two to three simple projects with CSS, then build projects using Tailwind.

You need to be able to know what you want to style, and then at least have an idea of how you would style the element using vanilla CSS, and then styling it with TailwindCSS would be easier.

Conclusion

Does Tailwind improve your CSS knowledge?

In my opinion, Tailwind doesn't improve your knowledge or understanding of CSS, only you do that. Here is how:

When you apply a style to an element with Tailwind, most of the interactions you do with that element's style are in CSS, you'll see how it was written in CSS by Tailwind and you could even make some changes in the browser, and as such you're improving yourself in CSS.

But all these are through Tailwind, so you can decide to give the credit to Tailwind. But let me know what you think about Tailwind in the comment section. Share your experience, because this has been mine.

Alright thanks for reading, if you like this article follow me and hit the like button for more, you can hit me up on Twitter @elijahtrillionz. You can also support me by buying this young man a coffee that's if you think I deserve one 😃

Ultimate Beginners' Guide to JavaScript Recursion

Elijah Trillionz — Fri, 09 Sep 2022 09:04:50 +0000

Recursion in JavaScript is no different from recursion in other languages. It is a popular term used to describe a pattern/algorithm of a function that calls itself directly or indirectly. It describes a function that performs the same action with different criteria/properties up to a specified limit.

Recursion can be a bit tricky and sometimes beginners struggle with it. But it's ok if you're struggling with it, this article will help you understand the certain principles of recursion (how it works). But this article alone will not stop you from struggling with it, practicing with examples will help you get the hang of it.

A simple example to get started would be to get the sum of a range of two numbers

function sumOfRange(start, end, sum = 0) {
  if (start > end) {
    return sum;
  }

  let current = start; // for readability
  sum += current;
  return sumOfRange(current + 1, end, sum);
}

sumOfRange(10, 20);

The function above is recursive because it calls itself. So the aim of the function is, to sum up, all the numbers that go from 10 (inclusive) to 20 (inclusive). That means 10+11+12+13+14...

Initially, the function is called outside with the start and end parameters. Then in the function, we checked to see if the start param is greater than the end, if not we simply performed simple math and called the sumOfRange function again but with the new value(s).

From this recursive function, we can deduce two key factors of recursion

A base condition
A changing value

A recursive function should always have a base condition. For every recursion, there should be a limit/endpoint, and so we use base conditions to check - each time the function is called - if that limit has been reached.

This is done to avoid infinite looping, without the base condition the function is just going to keep calling itself. Clearly, you wouldn't want that in your app.

Coming up with a base condition is very simple, think of it like a while loop approach, for example, in our example above we could say "as long as the number I started with is still less than the target number then proceed otherwise stop".

So what this means is that for every time the function is called again, either we

increment the start param to become greater than the end param or
decrement the end param to become lesser than the start param.

One of the above needs to happen for the base condition to have effect eventually. In our example, the start param was incremented by 1 for every time the function is called. This is because we simply want the sum of all numbers within two numbers (with the first being the lesser one).

You could say

function sumOfRange(end, start, sum = 0) {
  if (start > end) {
    return sum;
  }

  let current = end; // for readability
  sum += current;
  return sumOfRange(current - 1, start, sum);
}

sumOfRange(20, 10);

In this case, we are simply decrementing the end param to meet up with the start param for the base condition to execute eventually. Think of it as a transaction between a buyer and seller, they both have to reach a point of agreement during negotiations for the goods to be purchased by the buyer.

If they don't reach an agreement, recursion is saying if you don't provide a way for them to reach an agreement or forget about buying/selling then they are just going to keep negotiating till the end of the world.

My point is there needs to be a changing value that the base condition(s) can continually check to wrap up everything. Here is a simple example that explains that

const possibleWords = ['same', 'fame', 'name', 'tame'];
function createWord(possibleLetters) {
  const word = produceFourRandomLetters(possibleLetters);

  if (possibleWords.includes(word)) {
    return word;
  }

  return createWord(possibleLetters);
}

function produceFourRandomLetters(possibleLetters, lettersProduced = '') {
  if (lettersProduced.length >= 4) {
    return lettersProduced;
  }

  const letter =
    possibleLetters[Math.floor(Math.random() * possibleLetters.length)];
  return produceFourRandomLetters(
    possibleLetters,
    lettersProduced.concat(letter)
  );
}

console.log(createWord('ameftsn'));

"Elijah, I thought you said it was gonna be a simple example? 😃". Well, it is, don't let the length overwhelm you, it is basic and simple.

What we intend to do is produce a word from a list of possible words. So we have a list of possible words, and we used the letters in it to reproduce one of those words. This is clearly not the most efficient way of doing it, but I think it will help you understand recursions a little better.

My aim with this example is to really explain base conditions and changing values better. So let's forget about all the other stuff in both functions and just pay attention to the base conditions and changing values only. Because when creating a recursive function, the questions that should always think are

what/where is my base condition?
based on my base condition which value is changing? Because it's not just about having a value that changes every time the function is called but does the base condition involve this value.

It is similar to a for loop. In a for loop, there is always a condition and a changing value, just as in every other JS traditional loop. We will talk about the difference between recursions and traditional loops in a while, but in the meantime let's talk more about the example above.

Firstly, both functions are recursive. And the base conditions in both functions are obvious enough, but let's talk about the createWord function first.

function createWord(possibleLetters) {
  const word = produceFourRandomLetters(possibleLetters);

  if (possibleWords.includes(word)) {
    return word;
  }

  return createWord(possibleLetters);
}

The createWord function calls a function that returns a word of 4 letters. The base condition here is to check if the word returned is a member of the possibleWords, if it is then we simply jump out of the function by returning the word. If it isn't then we call the function again, with the same params.

Now the question is, is there a changing value? Yes, there is! The changing value, in this case, is the word variable from the function (produceFourRandomLetters) that randomly generates a word of 4 letters within the range of the possible letters given (possibleLetters).

So technically, we are relying on the produceFourRandomLetters to produce different values each time it is called to meet an expected end (which is to return one of the possible words).

Now let's look at the last function to make sure it would always produce different values.

function produceFourRandomLetters(possibleLetters, lettersProduced = '') {
  if (lettersProduced.length >= 4) {
    return lettersProduced;
  }

  const letter =
    possibleLetters[Math.floor(Math.random() * possibleLetters.length)];
  return produceFourRandomLetters(
    possibleLetters,
    lettersProduced.concat(letter)
  );
}

Producing different values is the primary aim of this function, rather than producing an actual understandable word. It is the createWord function that checks if each of the different values provided by this function is an actual word in the list of possible words.

As mentioned before, the produceFourRandomLetters is a recursive function, and the question of "what/where is the base condition", and "where/what is the changing value" comes to mind.

For the base condition, we are checking to see if the length of the lettersProduced is equivalent to 4. If this is the base condition then it means the changing value has to involve the lettersProduced right? Yeah. In this case, we are appending a random letter to the lettersProduced.

The lettersProduced starts with an empty string, then keeps adding a random letter to the string until it gets to 4 and then we exit the function. So for the first function call, the lettersProduced param passed to the function is '', but for the second time maybe 'a' is passed in, and then maybe 'at' follows, and so on.

Now the algorithm of this example is not done in a way that values already checked for won't repeat themselves, but it is impossible to keep repeating itself to cause an infinite loop. That is why there will always be an indefinite number of attempts/trials before we finally get a word from the list of possible words.

Sometimes it could produce just 40 words (a combination of 4 letters) before it gets a real word, or more than 1000 words, it is never definite. Here is a little twist to the example to check the number of times it takes to get to a real word

const possibleWords = ['same', 'fame', 'name', 'tame'];
function createWord(possibleLetters, trial = 0) {
  const word = produceFourRandomLetters(possibleLetters);
  console.log(word);

  if (possibleWords.includes(word)) {
    console.log(trial);
    return word;
  }

  return createWord(possibleLetters, trial + 1);
}

function produceFourRandomLetters(possibleLetters, lettersProduced = '') {
  if (lettersProduced.length >= 4) {
    return lettersProduced;
  }

  const letter =
    possibleLetters[Math.floor(Math.random() * possibleLetters.length)];
  return produceFourRandomLetters(
    possibleLetters,
    lettersProduced.concat(letter)
  );
}

console.log(createWord('ameftsn'));

Personally, when it comes to recursion there is a way I like writing recursive functions. If you've noticed, there is one common thing among the examples, and that is, there is always a param that is not needed outside the function. For example, we had

function sumOfRange(start, end, sum = 0) {
  if (start > end) {
    return sum;
  }

  let current = start; // for readability
  sum += current;
  return sumOfRange(current + 1, end, sum);
}

sumOfRange(10, 20);

We clearly do not need the sum param outside the sumOfRange function. So I always like refactoring to this

function sumOfRange(start, end) {
  function iterate(current, sum) {
    if (current > end) {
      return sum;
    }

    sum += current;
    return iterate(current + 1, sum);
  }

  return iterate(start, 0);
}

console.log(sumOfRange(10, 20));

This isn't just for the sum param, but it also helps to put things in perspective. When you have a very technical issue to solve with recursion, this can come in handy.

Note: The examples we've seen can all be done with a for loop, while, and do while. While this is possible with loops it is also like 3 times faster with loops than with recursion. Yeah, that's right. It is way faster to go through traditional loops than calling functions.

One major reason developers pick recursion over loops is because of the readability. You'd want to write a readable program that works just as its alternatives only slower. This is very useful when dealing with complex coding issues.

One good thing you can do to improve performance in recursion is to make sure the recursive call is the last statement like in the examples we've given. This helps the compiler optimize the recursive function.

Conclusion

Choosing between recursion and loops shouldn't become a problem for you. Most times, I just like writing a simple loop for simple problems, but then when it gets tougher and more complex I just switch to recursions. Easy enough.

It doesn't really matter if the code is about 3 times slower with recursion, that alone will not significantly affect performance as you might think, other than that what really matters is that it's a good readable code.

Alright, that's it for this article. Thanks for reading guys. Please like, share, and leave a comment below to let me know what you think about recursions. If you're on Twitter, give me a follow @elijahtrillionz.

If you like this article and you'd like to encourage/support me to do more, then you can kindly buymeacoffee

Introducing an Ultimate Web/Mobile Dev Roadmap

Elijah Trillionz — Fri, 19 Aug 2022 20:38:00 +0000

Hey everyone! Hope you're doing great! Allow me to interrupt your scrolling or whatever you were doing to introduce to you an ultimate web and mobile development roadmap.

Don't be surprised how short this article is because it isn't the ultimate roadmap, rather it leads to the roadmap. Now, what is this roadmap?

Many a time, I have been asked "How do I become a developer Elijah?", and am sure some of you have been asked as well. How do you answer? Do you repeat what you've told your previous friend or do you direct the friend to a tweet/article?

However the way I do this no matter how concise I may have written an article/tweet on it, I always feel like I don't fully communicate all the [updated] details I want to in a custom way that concerns the user.

Most times, I find myself asking my friend "What do you love doing the most?", "Is it web dev or mobile dev?", all those kinds of questions just to make sure I don't wind up recommending what he/she does not need.

So one time I got asked, I figured I should do something simple for people to use that is also possible to contribute to.

I wanted to write an article that people can contribute to, but articles contain too many words and less interactivity.

So I created devRoadMap.

Yep.

devRoadMap creates a roadmap for a user based on his/her interest. So technically you just keep clicking what interests you until it arrives at a conclusion of the languages you should learn and in what order you should learn them.

It also recommends things you should do before moving to other languages or after studying a language.

It is not an AI, it is just plain JavaScript with a ton of JSON data, and a ton of DOM manipulation :).

As a beginner

If you're just starting out, and you want to know how to become a developer. There is a tool for you to know the languages to learn and how to learn them. What it does is suggests languages for you to get started with based on your interest.

Now it doesn't ask silly questions like "What's your favorite food" just to know what language would be good for you. Instead, it asks questions to see your ambition and what takes you to the part of development that fits your ambition.

So head up to devRoadMap. Click the "Get Started" button and get started.

You should note that it still is very basic, though it has a lot of information you need. I want to work on improving it day to day while maintaining its simplicity.

As a developer

Why should I care Elijah?

As mentioned before, you have probably been asked to help start the dev journey of a friend (not necessarily your friend, but everyone is a friend - you get the point 👌).

You may not have realized it as I have said it ("start the dev journey..."), but it is what it is. When they take your advice, they are definitely going to start their journey that way.

So let's not make them look back and regret why they chose a particular language to start with. They may not fault you, of course, they shouldn't after all they probably didn't state what they were really interested in.

But rather than all that, why not work together and improve this tool? A tool that puts the interest of the user first and sums up what he/she needs to become the developer of his/her dream.

As of now, devRoadMap covers the basic interests of people who want to be a developer, explaining what each part of development is. But from where I see it, it has a long way to go to cover what everyone and anyone would need.

I want it to be a tool I'd recommend for a friend and go to sleep knowing it's going to do the job and that friend is going to get off with learning what he/she is really interested in.

There are situations where the friend would have a hard time choosing because he/she doesn't know what he should be interested in. For example, a friend who simply wants to be a part of the dev branch that makes a lot of money, well this tool doesn't do that yet, but it should if it's going to be for everyone.

So give it a star, contribute to it, recommend it, and see it grow.

It has a very simple domain, devRoadMap.elijahtrillionz.com or devRoadMap.vercel.app

Why is JavaScript Single-Threaded and Non-Blocking

Elijah Trillionz — Fri, 15 Jul 2022 19:37:23 +0000

"JavaScript is a single-threaded and non-blocking language". Chances are you have heard that statement a couple of times and have no idea what it means or you don't fully understand it.

If you have not heard of it before, well now you know. But you might ask "What does that even me", well in this article am going to try to explain what it means in the simplest possible form.

Now, why should you or any JavaScript developer even care about understanding what that statement means? This is because the statement explains how the JavaScript runtime works behind the hood. It explains how JavaScript executes the code we write.

Understanding that statement alone will help you write better code, and also help you know when to write code synchronously or asynchronously.

Alright, let's get into it already. I will explain this by breaking it down into two subheadings:

What is a single-threaded language
How is JavaScript non-blocking

What is a single-threaded language

A single-threaded language is a language that uses only one thread. In other words, it executes one thing at a time. JavaScript is single-threaded, so it executes the current line of code before moving to the next.

Think of it like a basic queue of people waiting to withdraw their money from an ATM, no matter how smart the ATM is, it can only serve one customer at a time, right?

Let's see an example in code

function funcOne() {
  console.log('First function');
}
function funcTwo() {
  console.log('Second function');
}
funcOne();
funcTwo();

From the above example, JavaScript executes the function as called one after the other. A function that isn't invoked will not be executed, but it will be parsed - a way of JavaScript knowing that there is a function there so when called it can easily go back to it.

Now, each function is pushed to the call stack to get executed. The call stack keeps track of the current functions that are being run and what functions are called within the function. When the current function is finished, the call stack pushes it out and continues from where it stopped in the code.

So while the funcOne function and its children are being executed, every other function (funcTwo) will have to wait. This is how single-threaded language works and this kind of behavior may give rise to blocking.

Basically, any code that is slow to execute is blocking. It could be a network request, loading an image, a loop that runs to 1 million, etc. Other interesting situations could be an infinite loop, or an alert message waiting for a response from the user. For example:

alert('Hello World');
console.log('You received a hello world message!');

The console.log function is blocked from executing because of the alert function. When you run it in the browser you will get an alert message Hello World, not until there is a response to the alert message every other function (including buttons) in the browser will be blocked from executing.

Another common example would be an infinite loop.

while (true) {
  console.log('I am true');
}
console.log('I will never be executed');

If you execute the code above in a browser (which you shouldn't) you would notice that the buttons on the website (if there are any) wouldn't seem to be working, selecting a text (if there are any) would have no effect. Technically the website is blocked. And there is no way "I will never be executed" is logging in the console.

So technically we're saying every single-threaded language (including JavaScript) is blocking.

How is JavaScript non-blocking

So far we've learned about how JavaScript executes its codes naturally. We've also seen that as a result of JavaScript being single-threaded in nature, some codes in JavaScript can be blocking. But if you haven't fully grasped what this blocking means, here is a metaphor to give you a light understanding before we go a little deep:

Imagine a cashier in the bank who waits for a customer to correct his/her errors while other customers in the queue wait. So not until the current customer is done with his/her correction(s) the cashier will not attend to any other customers. This is how JavaScript works - it is synchronous in nature.

But you and I know there is a simple solution to this problem, which is:

While the current customer corrects his/her error, he/she can move to the side so other customers that are ready can be attended to. Whenever the initial customer is done, he/she can come back to the cashier to do whatever.

This my friend is how JavaScript is non-blocking that is working asynchronously.

Asynchronous JavaScript

An asynchronous function will not block the execution of other functions in the call stack. For example

console.log('Hey,');

setTimeout(() => {
  console.log('I am John');
}, 1000);

console.log('Bye now');

This will simply log Hey, -> Bye now -> I am John in the console. This is because asynchronous functions (e.g the setTimeout function) will not block the execution of other functions in the call stack.

From the example above, the setTimeout function is meant to delay for 1 second before the function in it is executed, but that won't stop the console.log('Bye now') function from executing, nor will it delay it.

This is because asynchronous functions when pushed to the call stack are pushed out of the call stack to Web APIs to be executed there. Whenever the asynchronous function is ready it is pushed back in an interesting way(we will talk about this in a moment).

So our setTimeout function in the example above is pushed to Web APIs to be executed there. Now it wasn't pushed there because of the delay of 1 second, it was pushed there because it is an asynchronous function so even if we had a delay of 0 seconds the outcome would still be the same i.e

console.log('Hey,');

setTimeout(() => {
  console.log('I am John');
}, 0);

console.log('Bye now');

To log Hey, -> Bye now -> I am John in the console. So what happens after the setTimeout function has been executed in the Web API?

When the setTimeout function is executed, it isn't pushed back to the call stack immediately, rather it is pushed to a callback queue to wait for all other functions in the call stack to be executed before it is pushed back to the call stack.

So, from Call stack -> Web API -> Callback queue -> and back to the Call stack.

This my friend is called the event loop.

This is a little different from how customers who make errors in the bank are attended to. This time the browser (being the manager/cashier at the bank) is saying if you are sidelined to make corrections to your errors or add missing details, you will have to go back to the end of the queue to wait till it gets to your turn again. Not really a good experience for us humans, but the browser loves this algorithm a lot, and we developers benefit from it too.

Pushing asynchronous functions to the web APIs can also be thought of as scheduling for later. So technically, JavaScript being non-blocking doesn't mean it's multi-threading or multi-tasking, rather it means the browser can smartly schedule asynchronous tasks for later, - "later" being when it is ready.

The same thing when making network requests asynchronously, the function is pushed out of the call stack to make the request to whatever API, and when it is ready it is pushed to the callback queue.

Conclusion

So far we've learned what it means when someone says JavaScript is single-threaded and also non-blocking. And hopefully, we've grasped a few things about the event loop. I would recommend you watch the "What the heck is the event loop" YouTube video by Philip Roberts, it will give you more understanding of the event loop and you'd know how to use the Loupe website.

P.S: Sorry about the size of the gif. But trust me you'll get a better view when you play with the Loupe website.

Alright, that's it for today guys. Follow me for more articles like this, and if you find this article useful please share. Also, let me know what you think about the article in the comment section, or you can ping me on Twitter @elijahtrillionz.

How To Build An App With React Context API

Elijah Trillionz — Mon, 30 May 2022 10:26:21 +0000

Overtime, props have proven to be very useful in passing data across components. But as the application grows, it is almost always certain that most components deep in the tree will require data from parent/top in the tree components. As such, using props will make the whole app cumbersome. For example,

<App>
  <Header postsLength={posts.length} /> {/* assuming the header requires the length of the post */}
    <PostsList posts={posts}>
   <PostItem post={post}>

If the PostItem should require any new data from the parent component, you'd have to pass the data as props to every single component in-between. This is the reason for state management in React, and React provides a built-in state management solution - React context to handle passing data through descendant components without having to pass props through every component level.

So this is what we will discuss in this article by creating this Blog. I recommend you code along, so at the end of this article, you'd have created a simple blog with React Context API.

Getting Started

Let's set up all we would need to get the app started, and that would be creating a new React app. So head up to your terminal and run the following command

npx create-react-app devblog

When it is done, you can run npm start to preview the app. We don't need extra dependencies to use React context, so let's get started.

The blog is going to be a very simple one, with only a page to read, add, and delete posts.

Creating components

First off, I want us to create the components we need for this app, so head up to the src directory and create a new directory called components.

1. The header

We will create a simple component for the header of our blog. The header will contain a title and button to create new posts. This button is going to trigger another component which we will attach to the header. So go ahead and create a Header.jsx file and paste the code below

import { useState } from 'react';
import AddPost from './AddPost';

const Header = () => {
  const [openModal, setOpenModal] = useState(false);

  const closeModal = () => {
    setOpenModal(false);
  };

  return (
    <header>
      <h1>DevBlog</h1>
      <button onClick={() => setOpenModal(!openModal)}>Create Post</button>
      {openModal && <AddPost closeModal={closeModal} />}
    </header>
  );
};

export default Header;

Now we will create the AddPost component

2. The form component

The form will contain two input fields i.e the title and the body, and a submit button. On submission, we would validate the input to make sure there are values for the title and body. So create an AddPost.jsx file in the components dir.

import { useState } from 'react';

const AddPost = ({ closeModal }) => {
  const [title, setTitle] = useState('');
  const [body, setBody] = useState('');
  const [error, setError] = useState(false);

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

    if (!title || !body) return setError('All fields are required');

    console.log({ title, body });
    closeModal();
  };

  return (
    <>
      <form onSubmit={validateInputs}>
        <input
          type='text'
          placeholder='Enter title'
          onChange={(e) => setTitle(e.target.value)}
        />
        <br />
        <br />
        <textarea
          placeholder='Enter body'
          onChange={(e) => setBody(e.target.value)}
        ></textarea>
        <br />
        <br />
        <button type='submit'>Submit</button>
        <br />
        {error && <p>{error}</p>}
      </form>
    </>
  );
};

export default AddPost;

For now, we are merely logging the values of title and body in the console, but we would do more with it soon.

3. The posts list component

This component is where we loop through the available posts. Each post will trigger a component (the same component) that will read the title and body of the post. So create a PostList.jsx file and past the following

import PostItem from './PostItem';

const PostList = () => {
  const posts = [{ id: 1, title: 'a title', body: 'a body' }];

  return (
    <ul>
      {posts.map((post) => (
        <PostItem key={post.id} post={post} />
      ))}
    </ul>
  );
};

export default PostList;

The posts array is just a template to preview the UI, we will change it in a bit. But for now, we will create the PostItem component

4. The post item component

The post item component will use the post props passed into it to read the title and body of the post. We would also have a delete and an edit button side by side. As we mentioned before only the delete button will be used in this article, but I believe by the time we are done you will know all you need to work on the edit function and make it possible to edit posts.

So go ahead and create a PostItem.jsx file and paste the code below

const PostItem = ({ post: { title, id, body } }) => {
  return (
    <li>
      <h2>{title}</h2>
      <p>{body}</p>
      <div>
        <i className='fas fa-edit'></i>
        <i className='fas fa-trash'></i>
      </div>
    </li>
  );
};

export default PostItem;

Right now nothing is being done to the delete button. And by the way, the delete and edit button is represented by a FontAwesome icon, to make fontawesome work in your React app, add the link tag below to your index.html file in the public directory

<link
  rel="stylesheet"
  href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.8.1/css/all.min.css"
  integrity="sha512-gMjQeDaELJ0ryCI+FtItusU9MkAifCZcGq789FrzkiM49D8lbDhoaUaIX4ASU187wofMNlgBJ4ckbrXM9sE6Pg=="
  crossorigin="anonymous"
  referrerpolicy="no-referrer"
/>

Since we are already here (index.html), let's quickly update the title of our app to "DevBlog". In the head element there is a title element, change the value from "React App" to "DevBlog". Additionally, you can remove those comments to make it clean, and change the meta description value to "Blog for devs" or something else.

All these components we've created will have no effect until we include them in our App.js file. So paste the following to replace the current code in App.js

import './App.css';
import Header from './components/Header';
import PostList from './components/PostList';

function App() {
  return (
    <div>
      <Header />
      <main>
        <h3>
          New Posts: <span>1 posts</span> {/*hard-coded, will change later*/}
        </h3>
        <PostList />
      </main>
    </div>
  );
}

export default App;

You might be wondering why I had to create a PostList component rather than just looping through the posts in App.js. Well, I can't give a straight answer now but what I can tell you is that the PostList component is going to be useful in learning context api. And we will also have a footer that will not be a component and that would also be useful in learning a few things about context api. So just hold on to that for now, I promise to explain better in a bit.

Before you save and test run, let's update the CSS

Creating styles

This blog is going to have a dark and a light theme, so we would create an additional CSS file but for now, just copy the following styles into App.css

header {
  display: flex;
  justify-content: space-around;
  align-items: center;
  background-color: khaki;
  margin-bottom: 40px;
}

button {
  padding: 15px;
  min-width: 150px;
  border: 2px solid rosybrown;
  border-radius: 4px;
  cursor: pointer;
}

main {
  padding: 0 30px;
  max-width: 800px;
  margin: 0 auto;
}

main h3 span {
  font-weight: 400;
  font-style: italic;
  color: #777;
}

main ul {
  list-style: none;
  margin: 40px 0;
  padding: 0;
}

main li {
  border: 2px solid #ccc;
  padding: 15px;
  border-radius: 6px;
  margin-bottom: 30px;
  transition: border-color 0.2s ease-in-out;
}

main li:hover {
  border-color: #444;
}

main li h2 {
  margin-top: 0;
}

main li div {
  display: flex;
  justify-content: space-between;
  align-items: center;
  margin-right: 20px;
}

main li i {
  cursor: pointer;
}

.fa-trash {
  color: tomato;
}

form {
  position: fixed;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  background-color: #fff;
  border: 2px solid #ccc;
  padding: 30px;
  border-radius: 6px;
}

form input,
form textarea {
  width: 300px;
  padding: 14px 10px;
  border: 1px solid #ccc;
  border-radius: 4px;
}

footer {
  position: fixed;
  bottom: 20px;
  right: 20px;
  background-color: #fff;
  border: 2px solid #444;
  border-radius: 50%;
  height: 35px;
  width: 35px;
  display: flex;
  justify-content: center;
  align-items: center;
  cursor: pointer;
}

Now create an App.dark.css file and add these styles to it

header.dark {
  background-color: #444;
  color: khaki;
}

header.dark form {
  background-color: #444;
}

main.dark li {
  border-color: #444;
  background-color: #444;
  color: khaki;
}

main.dark li:hover {
  border-color: #ccc;
}

footer.dark {
  background-color: #444;
  color: #fff;
}

Go ahead and import the App.dark.css into App.js and save. The dark theme is not going to work just yet because we haven't configured it yet, but we will do that in a bit.

Creating contexts

In the src directory, create a context directory and in it an AppState.js file. We will create our app's context here.
The code examples demonstrated in this section are to explain React context, the actual examples that involve our app will come later on.

How to Create Contexts

React.createContext is a React context API for creating contexts, it is a function that takes a default value as its only argument. This value could represent the initial states of the context as you can access this value wherever you use the context's provider (details coming shortly).

const posts = [];
const AppContext = React.createContext({ posts });

The createContext function returns a context object which provides a Provider and Consumer component. The Provider component is used to wrap components that will use our created context. Any component that needs access to the values passed as default value (initial state) to the createContext, will have to be wrapped with the returned Provider component like this

const App = () => {
  return (
    <AppContext.Provider>
      <Header />
      <Main />
    </AppContext.Provider>
  );
};

The Header and Main components can all access the posts array we set initially while creating the AppContext context. The provider component provides a value prop which overrides the default value in AppContext. When we assign this prop a new value, the Header and Main components will no longer have access to the posts array. But there is a simple approach in which the values provided in the provider component can coexist with the default value of AppContext, and that is with React states(discussed below).

How to Access Context Values

Components that access and use the values of AppContext are called consumers. React provides two methods of accessing context values

1. The Consumer Component

I already mentioned this above as it is a component from the AppContext object just like AppContext.Provider:

const Header = () => {
  return (
    <AppContext.Consumer>
      {(value) => {
        <h2>Posts Length: {value.posts.length} </h2>;
      }}
    </AppContext.Consumer>
  );
};

A request: We have put together everything from where we created the context to now. Kindly do not mind that I am not repeating each step i.e creating the context, providing the context, and consuming the context into one code, but I trust you get it like this.

So inside the consumer component, we created a function that has a value parameter (provided by React), this value is the current AppContext value (the initial state).

Recall we said the current context value could also be provided by the provider component, and as such it will override the default value, so let's see that in action

const posts = [];
const AppContext = React.createContext({ posts });

const App = () => {
  const updatedPosts = [
    { id: 1, title: 'a title', body: 'a body' },
    { id: 2, title: 'a title 2', body: 'a body 2' },
  ]

  return (
    <AppContext.Provider value={{posts: updatedPosts}}>
      <AppContext.Consumer>
        {({posts}) => {
          <p>{posts.length}</p> {/* 2 */}
        }}
      </AppContext.Consumer>
    </AppContext.Provider>
  )
}

Well, congratulations, you now know how to create and access a context, but there is more you need to know. First, let's take a look at the other method (the most used) to access a context value.

2. The useContext hook

It is a React hook that simply accepts a context object and returns the current context value as provided by the context default value or the nearest context provider.

// from
const Header = () => {
  return (
    <AppContext.Consumer>
      {(value) => {
        <h2>Posts Length: {value.posts.length} </h2>;
      }}
    </AppContext.Consumer>
  );
};

// to
const Header = () => {
  const value = useContext(AppContext);
  return <h2>Posts Length: {value.posts.length} </h2>;
};

Note: Any component that uses the provider component cannot use the useContext hook and expect the value provided by the provider component, i.e

const posts = [];
const AppContext = React.createContext({
  posts,
});

const App = () => {
  const updatedPosts = [
    { id: 1, title: 'a title', body: 'a body' },
    { id: 2, title: 'a title 2', body: 'a body 2' },
  ];
  const { posts } = useContext(AppContext);

  return (
    <AppContext.Provider value={{ posts: updatedPosts }}>
      <p>{posts.length}</p> {/* 0 */}
    </AppContext.Provider>
  );
};

This is obviously because the useContext hook does not have access to the values provided by the provider component. If you need access to it, then it has to be at least one level below the provider component.

But that's not to worry because you would hardly have the need to access it immediately as your app will always be componentized (full of components I mean).

You might wonder, why not use the default posts as the updated posts and still get access to it i.e

const posts = [
  { id: 1, title: 'a title', body: 'a body' },
  { id: 2, title: 'a title 2', body: 'a body 2' },
]; // the used to be updatedPosts

Well, this is just hard-coded and it will not always be like this in real application because your values will often change and the most suitable place to handle these changes is inside a component. So in this example, we have just assumed that the updated posts were fetched from a database and have been updated, a more realistic example would be.

const posts = []
const AppContext = React.createContext({ posts });

const AppProvider = ({ children }) => {
  const [updatedPosts, setUpdatedPosts] = React.useState(posts);

  const getPosts = async () => {
    const res = await fetch('some_api.com/posts');
      const jsonRes = await res.json()
      setUpdatedPosts(jsonRes.posts);
  }

  useEffect(() => {
    getPosts() // not a good practice, only trying to make it short. see why below
  }, [])

  return (
    <AppContext.Provider value={{posts: updatedPosts}}>
      {children}
    </AppContext.Provider>
  )
}

const App = () => {
  return (
    <AppProvider>
      <Header />
    </AppProvider>
  )
}

const Header = () => {
  const { posts } = useContext(AppContext)
  return (
    <p>{posts.length}</p> {/* Whatever is returned from the api */}
  )
}

Note: The "not a good practice" warning above is very important, you would naturally use the await keyword as it is an async function, and doing so in a useEffect function would require proper subscribing and unsibscribing.

The returned provider component from our context app is just like any other component in React, and that is the reason we can use React state in AppProvider in the example above. Let's see how to use states more effectively in React context

Using Reducers

React provides a useReducer hook that helps you keep track of multiple states, it is similar to the useState hook and it allows for custom state logic.

Because we will need to perform a series of updates in our context using states (like we did in the example above), it is often convenient to use the useReducer hook to handle all states in it.

The useReducer function takes in two required arguments, the first being the reducer function and the second being the initial states for the hook. So every state you require in your context will (should) be included in the initial states. The function then returns an array containing the current state, and a function to handle the states (just like useState).

const reducer = (state, action) => {
  if (action.type === 'TOGGLE_THEME') {
    return { ...state, isDarkTheme: !state.isDarkTheme };
  }

  return state;
};

const App = () => {
  const [state, dispatch] = useReducer(reducer, {
    isDarkTheme: false,
  });

  const toggleTheme = () => {
    dispatch({
      type: 'TOGGLE_THEME',
    });
  };

  return (
    <div>
      <h2>Current theme: {state.isDarkTheme ? 'dark' : 'light'}</h2>
      <button onClick={toggleTheme}>Toggle theme</button>
    </div>
  );
};

In the reducer function, the action parameter contains the object we passed to the dispatch function. The state parameter contains the current state of the initial state(s) passed into the useReducer function. Don't worry if it's not so clear at first, you can always go to the docs and learn more for yourself.

The reducer function should always return a state to act as the current states of the useReducer hook, it could simply be the unchanged state or updated state, but something has to be returned.

If we use this in our AppContext to handle fetching posts we would have

const reducer = (state, action) => {
  if (action.type === 'GET_POSTS') {
    return { ...state, posts: action.payload };
  }

  return state;
};

const initialStates = { posts: [] }
const AppContext = React.createContext(initialStates);

const AppProvider = ({ children }) => {
  const [state, dispatch] = useReducer(reducer, initialStates)

  const getPosts = async () => {
    const res = await fetch('some_api.com/posts');
    const jsonRes = await res.json()
    dispatch({
      type: 'GET_POSTS',
      payload: jsonRes.posts
    });
  }

  useEffect(() => {
    getPosts() // not a good practice, only trying to make it short. see why below
  }, [])

  return (
    <AppContext.Provider value={{posts: state.posts}}>
      {children}
    </AppContext.Provider>
  )
}

const App = () => {
  return (
    <AppProvider>
      <Header />
    </AppProvider>
  )
}

const Header = () => {
  const { posts } = useContext(AppContext)
  return (
    <p>{posts.length}</p> {/* Whatever is returned from the api */}
  )
}

Using context may not be clear yet, but it gets clearer as you develop with and in it. Now with that said let's see React context in action in our blog.

So paste the code below into AppState.js

import { createContext, useReducer } from 'react';

const appReducer = (state, action) => {
  switch (action.type) {
    case 'DELETE_POST': {
      return {
        ...state,
        posts: state.posts.filter((post) => post.id !== action.payload),
      };
    }
    case 'ADD_POST': {
      return {
        ...state,
        posts: [action.payload, ...state.posts],
      };
    }
    case 'SET_DARK_THEME': {
      return {
        ...state,
        darkTheme: action.payload,
      };
    }
    default: {
      return state;
    }
  }
};

const initialState = {
  posts: [
    {
      id: 1,
      title: 'Post One',
      body: 'This is post one, do to it as you please',
    },
    {
      id: 2,
      title: 'Post Two',
      body: 'This is post two, do to it as you please',
    },
    {
      id: 3,
      title: 'Post Three',
      body: 'This is post three, do to it as you please',
    },
    {
      id: 4,
      title: 'Post Four',
      body: 'This is post four, do to it as you please',
    },
  ],
  darkTheme: false,
};

export const AppContext = createContext(initialState);

export const AppProvider = ({ children }) => {
  const [state, dispatch] = useReducer(appReducer, initialState);

  const deletePost = (id) => {
    dispatch({
      type: 'DELETE_POST',
      payload: id,
    });
  };

  const addPost = (post) => {
    dispatch({
      type: 'ADD_POST',
      payload: post,
    });
  };

  const setDarkTheme = (bool) => {
    dispatch({
      type: 'SET_DARK_THEME',
      payload: bool,
    });
  };

  return (
    <AppContext.Provider
      value={{
        posts: state.posts,
        darkTheme: state.darkTheme,
        deletePost,
        addPost,
        setDarkTheme,
      }}
    >
      {children}
    </AppContext.Provider>
  );
};

The reducer function can always be moved to a different file, I for one always move it to a separate file it makes it cleaner for me.

The functions we create in this component will be useful outside the component so we can pass it as a value in the AppContext.Provider component and any child of the AppProvider component can access and use it. But this component does not have its effect yet till we wrap it around the App.js component, so let's make the updates

import './App.css';
import './App.dark.css';
import Header from './components/Header';
import PostList from './components/PostList';
import { AppContext, AppProvider } from './contexts/AppState';

function App() {
  return (
    <AppProvider>
      <Header />
        <AppContext.Consumer>
        {({ posts, darkTheme, setDarkTheme }) => (
          <>
            <main className={`${darkTheme ? 'dark' : ''}`}>
              <h3>
                New Posts: <span>{posts.length} posts</span>
              </h3>
              <PostList />
            </main>

            <footer
              onClick={() => setDarkTheme(!darkTheme)}
              className={`${darkTheme ? 'dark' : ''}`}
            >
              <i className={`fas fa-${darkTheme ? 'sun' : 'moon'}`}></i>
            </footer>
          </>
        )}
        </AppContext.Consumer>
    </AppProvider>
  );
}

export default App;

While we can do this (i.e using the consumer component), we can also create components for both main and footer. But this is to illustrate to you that there will always be this option - the option of using the consumer component. There will be times when it would be the only option.

Finally, let's update the Header component, all we need is the darkTheme state and add it as a class name i.e

import { useContext, useState } from 'react';
import { AppContext } from '../contexts/AppState';
import AddPost from './AddPost';

const Header = () => {
  const { darkTheme } = useContext(AppContext);
  const [openModal, setOpenModal] = useState(false);

  const closeModal = () => {
    setOpenModal(false);
  };

  return (
    <header className={`${darkTheme ? 'dark' : ''}`}>
      <h1>DevBlog</h1>
      <button onClick={() => setOpenModal(!openModal)}>Create Post</button>
      {openModal && <AddPost closeModal={closeModal} />}
    </header>
  );
};

export default Header;

Reading Posts

The posts we have created in AppContext has no effect yet because we are making use of the hard-coded posts array in components/PostList.jsx. So let's head there and make some changes.

Here, we only need to get the new posts array from AppContext using the useContext hook. So replace

const posts = [{ id: 1, title: 'a title', body: 'a body' }];

with

const { posts } = useContext(AppContext);

You should ensure useContext, and AppContext are imported. Now save and test it out.

Adding Posts

Head up to components/AddPost.jsx and instead of logging into the console, pass in the post object into the addPost function from our app context

import { useContext, useState } from 'react';
import { AppContext } from '../contexts/AppState';

const AddPost = ({ closeModal }) => {
  const { addPost } = useContext(AppContext);
  const [title, setTitle] = useState('');
  const [body, setBody] = useState('');
  const [error, setError] = useState(false);

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

    if (!title || !body) return setError('All fields are required');

    addPost({ title, body });
    closeModal();
  };

  // .....
};

export default AddPost;

Save your app, and try adding a new post, you'd dis.

Deleting Posts

Just like we've done above, we will simply access the deletePost function and pass it to the delete button. Recall the delete button is in components/PostItem.jsx, so add an onClick button like

//..
<i className='fas fa-trash' onClick={() => deletePost(id)}></i>
//..

Recall the deletePost function can be accessed as

const { deletePost } = useContext(AppContext);

With this, I believe you will be able to make the edit button functional, but if you want to go a little further you can add authors as part of the features. And for that, I'd recommend you create another context (UserContext) to handle the authors' section. This context could contain functions like creating an author, logging an author in, updating the author's profile, listing all authors, and many more.

Conclusion

React context has its limits, for a simple blog like this it is the most suitable, but you may struggle to handle a web app that handles tons of changes with React context. But the community has great alternatives if you want to build the next Twitter, Netlify, or something. Some of which are Redux, Recoil, Remix, etc they will be discussed as part of a state management series that I have just started with this article. Remix is not a state management library, but it is a great alternative to it.

So far, we've created a blog that reads, deletes, and adds new posts with React context. This is a big step into React state management so go ahead and create cool apps with it.

You can tag me on Twitter @elijahtrillionz with a link to the blog you created as a result of this tutorial.

Kindly leave a comment below to let me know what you think of the series, please like and share for others to gain, and if you like what I do, you can show your support by buying me a coffee.

Mastering CSS Margin Collapse With Practical Examples

Elijah Trillionz — Wed, 09 Mar 2022 19:19:42 +0000

Margin collapse is an interesting concept in CSS margins that you should know, understand and be conscious of. It is the process where you apply a margin of 10px on top, the bottom of an element, apply another 10px on top, the bottom of the next element, and end up having a 10px space between the two-element instead of 20px.

The space between p elements above is supposed to be 20px because 10+10=20 right? But then it's 10px. Why? How? This is margin collapse and in this article, I want to show you why, how, and help you master it in less than 7 minutes.
A good way to visualize the code examples in this article (like this one above) is to open op your devTools and inspect the elements (i.e p), hover over the element and the margins of the elements will pop up in a light orange color. Let's experiment with the example above:

Open up your web dev tools
Click on the "arrow" icon at the top right of the dev tools or simply type ctrl+shift+c
Click on any of the p elements in the document, try clicking "Hello World"
In the element's dev tools section, hover over the element, and a light orange color will pop up; that is the margin
Hover over the other p element, and the same thing will happen, but you'd notice that it seems like the light orange color of the first element you hovered on is at the same position of the second; this is the effect of margin collapsing.

Use this method to go over the examples that will be used in this article.

First, let's make a quick recap of what margins are and their usefulness. Margin is an important aspect of styling elements in CSS, it allows us to add spaces between elements, or as some might say gives breathing room to the element applied. Apart from the margin, there is also another guy in the box model padding that does the same thing as margin. But they are different and should be applied differently

Margin vs Padding

One key difference is that Margin was designed for creating spaces between sibling elements whereas Padding was designed for creating spaces between a child and parent element. Understanding this changes everything.

It is not that margins cannot be used to create spaces between a child and parent element (you may have probably done that) but you would have unexpected issues when margins start collapsing. Here is one of these issues

Now that we have that setup, let's try to increase the space between the h1 element and the .box element using the margin-top property. Change the value from 0 to 20px and see what happens.

Now it looks like we're pushing down the whole of the .box element, and we still don't see the space between the h1 and .box elements. Try increasing it from 20px to 200px. Still no spaces? How? This is what happens when you use margin for creating spaces between a parent and a child element, they collapse, and then the purpose of margin is actualized between the .empty and .box elements. I will explain later.

One other difference that will also be useful in the course of this article is the order of the box model. In the box model, we have in ascending order

the height and width of the element
the padding
the border
the margin

This is one other thing that makes creating spaces between a child and parent element is more suitable with padding. Borders are the limit of an element, if you want to create a space between a child and parent element, whether you want to apply a border or not (to the parent element now) you should respect the border limit and create spaces between the border limits. And the only guy you can use to create spaces within the border limits is padding, not margin.

Think of it this way, every country in the world has

the residential areas (height and width of element)
the spaces between residential areas and the border of the country (passing)
the border of the country (border)
and the spaces between the border of country A and border of country B (margin) - this can be 0 in some cases like North Korea and South Korea.

So if a leader of country A wants to create more spaces between his/her country's residential areas and country B, the solution is not to increase the margin - because that may lead to a world war rather the solution is to increase the padding. As such country B will have no business with the leader because he/she is respecting its country's border limits.

So try to hold on to the order of the box model, I will come back to it later.

So now that we've gone through what margins are, let's jump right into margin collapse.

Margin Collapse

Margin collapse happens when element A's margin overlaps element B's margin or vice versa based on some conditions or rules. Just two years ago we were all asked to maintain social distancing by maintaining a 6ft gap between you and every other person. Now what this means is that one person should have a 6ft margin around him/her.

If John, for example, meets with Doe for a talk, though they have a 6ft personal space it doesn't mean that they must have a 12ft gap as per the social distancing. Social distancing says at least 6ft, so they can easily overlap their personal space to maintain a 6ft gap. This way I believe they can hear each other well enough.

This is the way margin collapse works, it lets us establish the necessary amount of space between two elements. So now as a CSS developer, our role is to understand when we need our margins to collapse, when we should expect our margins to collapse, and when we shouldn't expect our margins to collapse.

It's not as easy as "Oh cool, all margins collapse, really cool." No, not at all, there are times when margins don't collapse. So we might just expect two margins to collapse and give us 10px, and all of a sudden we get 20px. On the bright side, we can know when margins will and will not collapse.

As such it won't be a matter of trial and error, but we'd be sure if it will collapse or not. There are some conditions/rules that margins rely on before they can collapse. We will quickly go over these conditions as

When Do Margins Collapse

1. When Vertical

Only vertical margins collapse. The left and right margins of the two horizontal elements will not collapse.

You'd notice that the margins between the li elements are 20px each, vertically this would not happen, because it will collapse to give us 10px:

NOTE: You should note that when two margins collapse the bigger margin always wins, from the example above if we make the middle li to have a margin of 20px, we will end up with both the first and last li having a margin of 20px in the bottom and top respectively.

2. When the parent element is in flow layout

Margins of nested elements whose parent is not in flow layout will not collapse. There are multiple layouts on the web, that is flow layout, grid layout, flex layout.

Just like from the example above, the parent element ul is in a flow layout, so the margins of the child elements will collapse. Even if the parent element is body, it will collapse because body is also in flow layout

But this will not be the case if we set the parent element to flex or grid.

So basically from conditions 1 to 2, we've seen that only margins of block elements will collapse.

3. When an element is not absolutely positioned or floating

When an element is absolutely positioned or floating, its margin will not collapse. It will also not collapse if the element is not fixed.

Also when an element is floating, margin collapse is disregarded

4. When siblings are adjacent and not obstructed

So far we've been seeing sibling elements collapse or not collapse based on some predefined style on the parent or child element. But margins of two or more elements can be stopped from collapsing when there obstructing elements like hr or br.

Even the tiniest bit of height for an empty element can obstruct margin collapsing.

So the elements have to be adjacent (touching) for it to collapse.

5. When you do the weird thing

I know you must be curious to find out what this weird thing is, well I already made mention of it earlier. The weird thing is using margin to create spaces between child and parent elements instead of padding. Now it is only weird to me, it can be totally fine with you as long as you know the maneuverings of it.

And yeah, that's what am going to talk about here in this section, how to maneuver your way to using margins for creating spaces between child and parent elements without having the problem we had earlier. That is:

We said if you increase the margin-top of the h1 tag, rather than it creating a visible space between the parent and child element, it creates more space between the .box and .empty element. This is because the child element (h1) which has the margin, collapsed with the parent element' (.box) margin.

Think of it as the child element passing its margin to its parent element. But when it passes its margin to the parent element it doesn't add to the parent element's margin, rather it collapses it. By default, the .box element has a margin of 0 just like every other element, but if we increase it to 5px and increase the child element's margin-top to 10px, the margin between .empty and .box would not be 15px rather it would be 10px - because the bigger margin wins when collapsing occurs right?

It's not confusing, trust me. All we are saying here is that margins of nested elements can collapse with the margin of their parent element.

<style>
  .box {
    margin-top: 15px;
  }
  h1 {
    margin-top: 5px;
  }
</style>
<body>
  <div class="box">
    <h1>I am not empty</h1>
  </div>
</body>

Here is a visual illustration

So no matter the margin you use for the child element, it is just going to collapse it with that of the parent and end up creating more space between the parent element and its sibling (if any). But some things can prevent this from happening

Padding

When we add padding to the parent element we can hinder the margin of the child element from collapsing with that of the parent.

<style>
  .box {
    margin-top: 15px;
    padding-top: 10px;
  }
  h1 {
    margin-top: 15px;
  }
</style>
<body>
  <div class="box">
    <h1>I am not empty</h1>
  </div>
</body>

For the margin to not collapse the parent element should have padding that is in the same direction as the margin to collapse. This means if you change the padding-top to padding-bottom it will not stop the margins from collapsing because the padding is in the opposite direction.

So if you want to specifically hinder only the top of an element's margin from collapsing with its child, you'd have to use the corresponding padding for it. Then, to hinder the all-around margin from not collapsing you just apply padding all-round.

.box {
  margin: 15px;
  padding: 3px;
}
h1 {
  margin: 15px;
}

The size of the padding doesn't really matter it could be as tiny as 1px, it would still stop the margins from collapsing. You might ask "can't we use padding on the child elements too?", I will answer that in the next section.

Border

Borders do the same thing as padding in this regard. Using any size of border on the parent element will prevent collapsing.

When we add another element to act as a sibling to .box, neither the padding nor border of .box will stop the margins from collapsing with the new element

This is because the padding and margin rule only applies to the nested elements of that element. Neither padding nor border can stop the margins of two sibling elements from collapsing simply because they don't have the access to the margins of the element.

Recall that in the box model, we had padding, before border, and finally before margin. The only way padding or border can stop two margins from collapsing is if the padding or border is in between the two margins. And that only occurs between parent and child elements.

Here we have a parent element with a border, the border of this parent element is now above the margin of the child element, while still under the margin of the parent element. So already it's in between the two margins, it won't let them collapse. The illustration below will make it a little clearer.

This is not the case for sibling elements, because the border or padding of any of the elements is not superseding the margins of the other, this is the way it looks in sibling elements.

Gap

One other thing that can cause the margin of a parent element from collapsing with that of its child is when there is a gap between them. This occurs when the height/width of the parent's element is beyond that of its child.

<style>
  .box {
    margin-right: 15px;
    width: 400px;
  }
  h1 {
    margin-right: 15px;
    width: 250px;
  }
</style>
<body>
  <div class="box">
    <h1>I am not empty</h1>
  </div>
</body>

6. Negative margins can collapse too

Alright, now let's talk about negative margins. Two or more negative margins can collapse together. Just like we've seen with positive margins, the biggest negative margin is used over the smallest.

Negative margins can also collapse with positive margins, as such the margins will be added together. From our example above, if the margin-top of other-box is 15px, then we'd have a -15px margin between the two elements.

Conclusion.

It would save you a lot of stress and confusion if you just understand how it works, do some practice on it to make it stick. People who think margin collapse is not a big deal are those who wind up increasing margin size unnecessarily. When you know where you need your margins to collapse you can easily benefit from its benefits, then when you don't need it to collapse you can stop it from collapsing.

Alright, that's it for this article, let me know what you think about margins collapsing in the comment section. Also, remember you can hit me up on Twitter @elijahtrillionz if you need me, and please try to follow. Thanks for reading, see you next time.

Complete Guide On How To Use Styled-components In React

Elijah Trillionz — Thu, 17 Feb 2022 01:47:12 +0000

I have often found styling a React application very confusing and difficult. Initially, I was confused about how to structure my CSS files, thoughts like "should I dedicate a specific CSS file to specific pages? or should I just use one file for the whole app (which is scary, but I've done it :))?" are always roaming through my head when I am creating a new app in React.

Dedicating a CSS file to a specific page or component is ideal, but there are backsides to this. One of which is that a child page/component that has its own style will also inherit the styles of the parent page/component. This will cause a conflict, you will end up using important half the time in your child page/component.

Some can organize this approach properly, but it still is very hard. Then there is Next.js (CSS module) which has done a marvelous job in simplifying this approach for its users. In Next.js, each page/component can have a dedicated style (CSS file). Conflicts do not exist because the styles from any CSS file will only be used if called upon as a class name. But still, this is not my best approach for scaling apps, because of semantic class names.

Then there is Tailwind, this is where some developers have come to rest, but for me it made my JSX look too scary. I made a simple form with it, and I felt like I have made a full website, with lots of overwhelming abbreviated class names that I don't understand. Mind you, I didn't copy and paste. Am not saying Tailwind is bad, I just don't like the way it makes my JSX bucky and rough.

Then I came across styled-components that changed everything. This time I could style everything and anything I want without worrying about conflicts and without using class names in my JSX. That's amazing. Styled-components is basically what the name says: "styled-components". Like "this is a styled component (e.g header)". It's a component that is styled not by using a CSS file, but by using CSS syntax in JavaScript (components to be precise).

Let's now take a quick look at what styled-components is, and how it works which will get us acquainted with the styled-components syntax.

What is styled-components

Styled-components allows you to create components and attach styles to it using ES6 tagged template literals. The styles attached are written in CSS. The code below shows an example of a styled Button component

import styled from 'styled-components';

const Button = styled.button`
  padding: 10px;
  border: 2px solid blue;
  border-radius: 4px;
`;

const Example1 = () => {
  return (
    <main>
      <Button>Click me</Button>
    </main>
  );
};

export default Example1;

From the code above, we can see CSS being used in JavaScript template literals to attach styles to the Button component. The styled object which is imported from styled-components, contains tons of HTML elements as methods that represent what the component is.

For example, the button method above is a function that represents the HTML element "button". This means that the Button component is a button that can be used anywhere in our app just like any other component. Just as we've used it in the Example1 component thereby giving us a styled clickable reusable button component.

The Syntax

const Button = styled.button`
  padding: 10px;
  border: 2px solid red;
  border-radius: 4px;
`;

There is nothing new here, apart from the template literals being attached to a function. If you're not familiar with tagged template literals, this will be new to you and may look confusing too, it was introduced in ES6.

Recall that we mentioned earlier that the keyword button there is a method (object function), and as such what we ought to do is call it and pass some arguments in it right? to be something like

const Button = anObject.method('Some arguments');

Well, that is what we just did, we just called the function and passed in an argument. You say how? Tagged template literals allow you to pass string interpolations as an argument in a function. The result of that argument is an array of the strings passed into the function.

func`ok World` // is equivalent to
func([ok World])

This introduction to styled-components will help you understand this better.

Also worth noting from the syntax above is the purpose of the button method. We've said before that the button method is what tells React to treat the component like a button, and not any other element. Traditionally, it is the same as this

const Button = ({ children }) => {
  return <button>{children}</button>;
};

If we wanted a link rather than a button, then we would say

const LinkButton = styled.a`
  padding: 10px;
  border: 2px solid red;
  border-radius: 4px;
`;

So basically this is the way styled-components works. The code below shows an illustration of the syntax

const ComponentName = styled.element`
  css_property: css_value;
`;

Where:

ComponentName can be any name
element can be any supported JSX element
css_property represents a property name in CSS
css_value represents the value for the property name from 3

Styling Component's Children

So far we've only applied styled-components to a single element containing component. But what if the component is to have child elements that have to be styled as well, does it mean we will have to create a styled component for each element? No, we don't, we can apply styles to child elements like this

import styled from 'styled-components';

const Header = styled.header`
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 10px 15px;
  background: #000;

  h2 {
    font-weight: 400;
    color: violet;
    font-size: 1rem;
  }

  li {
    list-style: none;
    display: inline-block;
    color: #ccc;
  }
`;

const Example2 = () => {
  return (
    <div>
      <Header>
        <h2>Hello World</h2>
        <ul>
          <li>About</li>
        </ul>
      </Header>
      <main>
        <h2>Hello World Paragraph!</h2>
      </main>
    </div>
  );
};

export default Example2;

Preview the example above and you'd notice only the h2 element in header takes the violet color. This is because we've only applied styles to the Header component and its children, not to every matching element. This is possible because styled-components creates a unique class name for each component (styled component) we create. As such the styles of the child elements of the component will be identified with the class name. Inspect the example above in your browser dev tools see the class names generated for the Header component.

Applying Pseudo-classes and Pseudo-elements

It is possible to apply pseudo-classes (e.g :hover) or/and pseudo-elements (e.g ::after) to a styled component. Say we have a button to change the border color when hovered on, we would have

const Button = styled.button`
  padding: 10px;
  border: 2px solid red;
  border-radius: 4px;

  &:hover {
    border-color: blue;
  }
`;

Here we have used the ampersand (&) character to reference the current element of the component. It works like this in a JavaScript object. We can also use this character to style child elements with combinators

const Button = styled.button`
  padding: 10px;
  border: 2px solid red;
  border-radius: 4px;

  &:hover {
    border-color: blue;
  }

  & > span {
    display: block;
    font-size: 1.1rem;
  }
`;

const Example3 = () => {
  return (
    <main>
      <Button>
        <span>An example</span>
      </Button>
    </main>
  );
};

Applying Media queries

Media queries are inescapable for large projects, and so you should be familiar with using them in styled-components. Each component will have to have its own media queries. I honestly like this approach because it just separates concerns and lets me focus on where I have a problem during maintenance or development.

Here is an example of using media queries in styled components

const Header = styled.header`
  padding: 10px;
  margin: 0 auto;

  @media (min-width: 768px) {
    margin: 0;
    display: flex;
    justify-content: space-between;
    align-items: center;

    ul > li {
      display: inline-block;
      margin: 0 4px;
    }
  }
`;

const Example3 = () => {
  return (
    <Header>
      <h2>Ages Blog</h2>
      <ul>
        <li>Home</li>
        <li>About</li>
        <li>Contact</li>
      </ul>
    </Header>
  );
};

In the media queries, you don't have to explicitly specify a selector for the parent element, the styles that comes immediately after (without selectors and braces) the open brace of the media query is applied to the parent element which in our case is header.

Breakpoints can be applied dynamically in our media queries. Let's say you wanna set a different breakpoint when a user clicks a button or when something else is updated, you can pass the breakpoint as a prop to the styled component and access it as you would access any other props in styled-components. For example,

const Header = styled.header`
  padding: 10px;
  margin: 0 auto;

  @media (min-width: ${(props) => (props.active ? '920px' : '768px')}) {
    margin: 0;
    display: flex;
    justify-content: space-between;
    align-items: center;

    ul > li {
      display: inline-block;
    }
  }
`;

Styled components props

Passing props

Earlier we had a LinkButton component that is an a element. To make this a working link we would need an href attribute. Well, we can simply pass an href props to the LinkButton component and have styled-components apply it to our anchor tag as an attribute. We would have

const LinkButton = styled.a`
  padding: 10px;
  border: 2px solid red;
  border-radius: 4px;
`;

const Example5 = () => {
  return (
    <main>
      <LinkButton href='https://example.com'>An example</LinkButton>
    </main>
  );
};

This is the same thing for every other styled component. As long as the props you pass into the component are valid props for that element (the element the component is parsed into), it will work fine. Note that it will not throw an error if you pass an invalid prop, but it will simply have no effect.

For example, passing an href prop to a styled component that is an input element will have no effect. Let's see one more example of passing props

const Input = styled.input`
  padding: 10px 15px;
  border: 2px solid violet;
  border-radius: 2px;
`;

const Example6 = () => {
  return (
    <div>
      <h2>Fill the form</h2>
      <Input
        type='text'
        placeholder='Enter name'
        onChange={() => doSomething()}
        required
      />
      <Input
        type='password'
        placeholder='Enter password'
        maxLength={16}
        minLength={8}
      />
    </div>
  );
};

You would notice the two input fields will be rendered differently, the first being rendered as a text that is required and with an event listener, and the second rendered as a password that its field (what the user types in) by default are not visible in the browser.

Accessing props

Apart from being able to pass props, we can also access props in styled components. It works just the same way it works in regular components. Say we have a unique bot that when activated with a button should have a different background color for that button. First, we would need to pass the active state as a prop to the Button component or whatever component that styles the button element.

const Example7 = () => {
  const [active, setActive] = useState(false);

  return (
    <div>
      {active && <h2>I have been activated</h2>}
      <Button onClick={() => setActive(!active)} active={active}>
        Activate Bot
      </Button>
    </div>
  );
};

Now we have that done, we would need to access it. In regular components, the props are passed as arguments to the component function, so we can access it globally in the component as a parameter. In styled-components, it is a little different, to access props passed into our styled components, we will have to create a function within our components and access the props as a parameter. So we would have

const Button = styled.button`
  padding: 10px;
  background: ${(props) => (props.active ? 'lightblue' : 'orange')};
  border: 2px solid purple;
  border-radius: 4px;
`;

Whenever we create a function within a styled component we have access to the props passed into that component through that function. We could have multiple functions - as many as needed in the component.

const Button = styled.button`
  padding: 10px;
  background: ${(props) => (props.active ? 'lightblue' : 'orange')};
  border: 2px solid ${(props) => props.borderColor};
  border-radius: 4px;
`;

If you're confused about how we were able to create a function within a string or how any of that is a function, then I must welcome you to 2022 where anything is possible with JavaScript :). Alright, jokes aside, the release of ES6 (ECMA2015) brought about template literals (\), a way of writing expressions in strings using the ${} to wrap the expressions.

Also with ES6, we can now create functions without the function keyword, instead, we use arrows (=>), thereby termed arrow functions. With arrow functions, we can write functions in one line without the return keyword or braces ({}) around it. You can learn more about arrow functions in MDN.

Creating and updating props

Interestingly, the props we want in our styled components can be created and updated inside within the component. So let's say you wanna override default props passed into a component or create one in the styled component, you'd need to use the .attrs() method. It takes just one argument of an object that will be merged with the styled component's props

const Button = styled.button.attrs({
  borderColor: 'orange',
})`
  padding: 10px;
  background: ${(props) => (props.active ? 'blue' : 'red')};
  border: 2px solid ${(props) => props.borderColor};
  border-radius: 4px;
`;

We can also attach some dynamic props values based on some conditions

const Button = styled.button.attrs((props) => ({
  borderColor: props.active ? 'orange' : props.borderColor,
}))`
  padding: 10px;
  background: ${(props) => (props.active ? 'blue' : 'red')};
  border: 2px solid ${(props) => props.borderColor};
  border-radius: 4px;
`;

Inheritance

Styled components can inherit styles from other styled components. Inheriting styles give you the flexibility of improving your app styles without recreating what already exists or filling up your styled component with so many props for conditionals. This is what I mean, say we had a Button component for our app, but we wanted a secondary button with a little style change i.e

const Button = styled.button`
  width: ${(props) => (props.secondary ? '130px' : '80px')};
  padding: 10px;
  background: ${(props) => (props.secondary ? 'blue' : 'red')};
  border: 2px solid ${(props) => (props.secondary ? 'red' : 'blue')};
  border-radius: 4px;
`;

Or you could use .attrs. This get's a lot overwhelming when more differences are to be applied to the two buttons, or when the secondary button just happened to have a child element. The best solution at hand is inheritance.

Inheriting the styles from a styled component is as easy as passing the styled component as an argument to styled.

const Button = styled.button`
  display: block;
  margin: 10px;
  width: 80px;
  padding: 10px;
  background: transparent;
  border: 2px solid blue;
  border-radius: 4px;
  text-align: center;
`;

const LinkButton = styled(Button)`
  text-decoration: none;
  background: #ccc;
  color: #000;
`;

const SecondaryButton = styled(Button)`
  width: 130px;
  border-color: red;
  background: paleblue;
`;

These are two use-cases of inheriting our main Button styled component. You should note that the LinkButton component will not be a link element (a). We will need the as props to specify what element we want it to be

const Example8 = () => {
  return (
    <header>
      <ul>
        <li>
          <LinkButton as='a' href='/'>
            Home
          </LinkButton>
        </li>
        <li>
          <LinkButton as='a' href='/about'>
            About
          </LinkButton>
        </li>
      </ul>
      <SecondaryButton>Get Started</SecondaryButton>
    </header>
  );
};

When it comes to inheritance, props are also inherited from the parent styled component. But updates made to child styled components (i.e styled components that are inheriting a styled component) props will override that of the parents.

const Input = styled.input`
  padding: 10px;
  border: 2px solid orange;
`;

const UglyInput = styled(Input)`
  background: #000;
  color: #fff;
`;

const PasswordInput = styled(Input).attrs({
  type: 'password',
})`
  border: 2px solid red;
`;

const Example9 = () => {
  return (
    <form>
      <Input />
      <UglyInput />
      <PasswordInput />
    </form>
  );
};

By default, the text is selected as the input type if not specified. So the type of text will be inherited by all of its inheriting styled component, that's why UglyInput has its type as text. But the case is different for PasswordInput as the prop type has been overridden with password, and now the browser treats it as a password field as it is.

This is just to illustrate prop inheritance, you really would not need to do this in a real-world scenario, instead, this is what you'd have

const Input = styled.input`
  padding: 10px;
  border: 2px solid orange;
`;

const UglyInput = styled(Input)`
  background: #000;
  color: #fff;
`;

const PasswordInput = styled(Input)`
  border: 2px solid red;
`;

const Example10 = () => {
  return (
    <form>
      <Input type='text' />
      <UglyInput type='text' />
      <PasswordInput type='password' />
    </form>
  );
};

I prefer to explicitly set my types as props in the component rather than the previous example. Using .attrs is useful but I wouldn't use it if there is a much more readable approach.

Moving on, one thing you should have noticed about inheritance is that we basically created a component (a styled one) and then applied a new style to it. From the example above Input is a component, and we literally brought all of the styles and props in it into a new component.

Does this mean, I can create a component (not a styled component) and style it? Yeah, that's exactly what it means. How cool this is!

const HeaderComp = ({ className, title }) => {
  return (
    <header className={className}>
      <h2>{title}</h2>
    </header>
  );
};

const StyledHeaderComp = styled(HeaderComp)`
  padding: 10px;
  background: #000;
  color: #fff;
  text-align: center;
`;

const Example11 = () => {
  return <StyledHeaderComp title='A Unique Title' />;
};

You must pass in the className prop in the parent element of the component to be styled because with it styled component can apply the given styles to the component. Apart from custom components, you can also style components that you did not create, maybe components from a module you installed, e.g the Image/Link component from Next.js. But with these components, you don't have to worry about passing the className as it is handled by default.

Animations

Animations in styled-components is a lot similar to what we have in CSS. In styled-components, we have access to a keyframes function that we can assign the value of animating an element to a variable and use this variable in the element's animation property.

In summary,

import styled, { keyframes } from 'styled-components';

const slide = keyframes`
  0% { transform: translateX(0) }
  50% { transform: translateX(100%) }
  100% { transform: translateX(0) }
`;

const MovingButton = styled.button`
  padding: 10px;
  background: #f4f4f4;
  border: 2px solid red;
  border-radius: 4px;
  animation: ${slide} 2s ease-in-out infinite;
`;

const Example12 = () => {
  return <MovingButton>I'm moving</MovingButton>;
};

As easy as that. The only difference with CSS is that the keyframes is a function. One cool advantage of styled-components animations is that they are reusable. You can use the slide animation for some other component or element. In fact, this is an advantage in all of styled-components; being reusable.

Theming

With styled-components you can organize the styles/theme of your entire project. Setting up variables like sizes, colors, font families has been a great help in following a style guide for projects in CSS. The same thing applies in styled-components, only that styled-components makes it a lot better, and usable anywhere in your project.

All of your styled components for a project should not go into one file, as this isn't a good practice, I will show you how I organize mine. If all your styled components were to be in one file, theming like in CSS would simply require you to create an object variable and add the props you need, like colors, sizes, etc. like

const theme = {
  colors: {
    primary: '#333',
    secondary: '#fff',
  },
};

const StyledComp = styled.div`
  background: ${theme};
`;

But if there are going to be multiple files containing your styled components, you may want to be tempted to have a global theme object variable and export it into all your styled component files. This is just tedious and a waste of tools.

Styled-components in its generosity offers a context provider, ThemeProvider so we can wrap around our app and pass in the theme properties we need for our app. This gives us the flexibility of using any of our theme properties in any of our styled components without importing or exporting.

Now, all we need do is import the ThemeProvider from styled-components and wrap it around our app with our theme properties in file App.js.

import { ThemeProvider } from 'styled-components';

const App = () => {
  return (
    <ThemeProvider
      theme={{
        colors: {
          primary: 'orange',
          secondary: 'blue',
          background: '#ccc',
        },
      }}
    >
      {/* our app components */}
    </ThemeProvider>
  );
};

There is a theme prop that comes with ThemeProvider, it lets us pass in the theme properties of our app in it. For this, I am just using colors only, you could have more like font families, sizes, breakpoints (for media queries).

The theme prop is passed as a prop to all of our styled components that are children to the React App component by default. So accessing it will be like accessing any other props

const Button = styled.button`
  padding: 10px;
  border: 2px solid ${(props) => props.theme.colors.primary}
  background: ${(props) => props.theme.colors.secondary}
`;

The theme prop passed into the ThemeProvider is used as a state in the app, and as such, changes to it will cause your app to rerender and update accordingly. An advantage of this rerendering is that we can dynamically set our theme properties and have all the styled components that use it updated.

With this, we can easily create a dark or light theme right in the theme object. This is how the object would be

import { ThemeProvider } from 'styled-components';

const Example13 = () => {
  const [darkTheme, setDarkTheme] = useState(false);

  return (
    <ThemeProvider
      theme={{
        colors: {
          primary: darkTheme ? '#000' : 'purple',
          secondary: darkTheme ? 'skyblue' : '#3caf50',
        },
      }}
    >
      <button onClick={() => setDarkTheme(!darkTheme)}>Toggle Theme</button>
    </ThemeProvider>
  );
};

From the example above, the theme object will only be relevant used by styled components inside the Example13 component. If you want it to be global you can add it in your React App component (the main parent component).

The Global Styles

Oftentimes, we have styles that need to be applied globally to avoid repetition, for example, you could want that all elements should be a border-box, rather than repeating it over and over for each element, we would say in CSS

* {
  box-sizing: border-box;
}

Another example could be removing all underline from a tags, applying different specific font-family on p and h1-h6 tags, or applying a custom scrollbar for your web pages, and many others. To apply these styles in styled-components is simple, we simply create a GlobalStyles styled component and apply it to our app once.

To create the GlobalStyles (you can give it any other name) we would need the createGlobalStyle function from styled-components.

import { createGlobalStyle } from 'styled-components';

const GlobalStyles = createGlobalStyle`
  * {
    box-sizing: border-box;
    margin: 0;
    padding: 0;
    scroll-behavior: smooth;
  }

  body {
    font-size: 0.85rem;
    background: #fff;
    margin: 0;
    letter-spacing: 0.07em;
  }

  ::-webkit-scrollbar {
    width: 6px;
    height: 5px;
  }

  ::-webkit-scrollbar-corner {
    height: 0;
  }

  ::-webkit-scrollbar-track {
    background-color: transparent;
    border-radius: 25px;
  }

  ::-webkit-scrollbar-thumb {
    background-color: lightblue;
    border-radius: 25px;
  }
`;

export default GlobalStyles;

Now we would head up to index.js (the main/root file of react), and use it there

import GlobalStyles from 'wherever-it-is.js'

...
ReactDOM.render(
  <React.StrictMode>
    <GlobalStyles />
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);
...

Organizing your project

What styled-components will not do for you is structure your files. Structuring in styled-components can take different forms, you can decide to keep all styled components in the same file as the component that uses it - just like in React Native. Or you could have all the styled components of a page in a separate file and import them as needed. No matter the case, try not to put all of your styled components in one file.

For me, I like separating my styled components into different files. Each page/component that requires a styled component will have to have its own file of styled components. For example

|___ index.js - a page
|
|___ Index.styled.js - a file that contains all styled components for the page index.js

The way I structure my app with styled-components is inspired by Traversy Media's styled-components crash course. Here is a sample

Project
|
|___ pages
|     |
|     |___ index.js
|     |___ about.js
|
|___ components
|     |
|     |___ Header.js
|     |___ Footer.js
|     |___ styles
|            |
|            |___ Header.styled.js
|            |___ Index.styled.js
|            |___ About.styled.js
|            |___ Footer.styled.js

Conclusion

So these are the basic things you need to get started with styled-components. Here is a blog and source that demonstrates all of what we have learned here today. It's a simple minimal blog.

If you feel all these wouldn't make you use styled-components, then this will. Styled-components applies prefixing to each style declaration that requires prefixing to be compatible with multiple browsers. All you have to do is write it to the current standard and styled-components will make it compatible with multiple browsers by applying prefixes specific to these browsers. So you don't have to worry about moz-, webkit- all of these are taken care of.

The idea of styled-components is to live a life free of "untraceable" class names. I mean it's not a must to use it, but if you think styled-components is a good fit for your project, then you should get started on it. To get started, I recommend you code along with this styled-components crash course by Brad, where you'll build an HTML template.

If you're using VSCode, I have made a gist of snippets for you to add to your javascript.json for styled-component. It contains what you need to generate a new styled component (stc/btc), inherited styled component (ibtc). Kindly ignore or change the commands :).

Thanks for reading. If you have anything to add or correct me about on this please don't hesitate to share in the comments section. Also hit me up on Twitter (@elijahtrillionz), let's connect.

Shouldn't recursion be prevented in React component?

Elijah Trillionz — Thu, 10 Feb 2022 20:38:25 +0000

I had an error recently while working with React/Next.js and styled-components. I was to create a styled component for one of my app's regular components but accidentally gave it the same name.

This lead to an infinite loop in the browser. This is the first time I have experienced such error in React, and my problem was that there was no hint whatsoever as to what is wrong.

ESLint in webstorm wouldn't call it an error, because recursion do exists and it's not an error.

So I was thinking, is there no way React or should I say Next.js could have failed while compiling.

I know recursion can exist and isn't and shouldn't be logged as an error, but then should recursion exist in React?
How does calling a component inside of that component do something useful? I don't know if you guys do anything like that? Please share what you do with it.

My point is, if there is really no point of having a component inside of itself, then why not throw an error if that happens!

How to Become a Web Developer in 2022

Elijah Trillionz — Sun, 09 Jan 2022 16:52:59 +0000

Hello, welcome, and in this article am going to show you how to become a Web Developer in 2022. There are numerous companies out there who are ready to pay a large sum of money to have a web developer in their company. You may say in 2022? I say Yes in 2022!. There are also a good number of companies and businesses that require web developers to help create a website that will represent their businesses online.

Before we talk about how to become a web developer, let's quickly look at who a web developer is. If you are ready to sail with me, then let's dive right in

Who is a Web Developer?

A web developer builds World Wide Web applications. In other words, someone who develops or builds websites or web applications is a web developer. The act or process involved in making these websites or web apps is known as Web Development.

There are three kinds of web developers, Front-End Web Developers, Back-End Web Developers, and Full-Stack Web Developers.

Front-End Web Developers

Front-end web developers are involved in making the visible parts (interface) of a website or web app (client-side). What visitors of the website or web app see and interact with is built and maintained by a front-end web developer.

This includes the beautiful designs, animations, form fields that we see. They can also be called client-side web developers.

Back-End Web Developers

Back-end web developers are involved in building the unseen parts of a website or web app (server-side) i.e the server. These guys are lovers of logic, data, technical construction of websites.

Let's say you fill a form in a web app and then receive a notification that the email is already registered. Now you are thinking, how did this website know my email is registered. Well, a back-end web developer figured it out.

Full-Stack Web Developers

These guys do both the work of a front-end web developer and that of a back-end web developer; they basically do everything.

Okay, now you know the three kinds of web developers, I think it's time you decide which one you love most and that one you love most is what you should do. I will be referring to these three guys again, and by then you should have decided.

How To Become a Web Developer?

To become a web developer, there are certain skills or languages that you need to be familiar with. There are languages we use to communicate with computers as web developers and these are the languages you need to learn. There are a lot of languages but you don't need to learn them all.

Most times, it is at this point a lot of beginners mix essentials with inessentials and tend to miss the right path. By now you should already know what kind of web developer you want to be, and following that path is what matters and that is exactly what we will be doing now.

For each of the three kinds of web development, I will show you the languages/skills required and those that are optional, I will also recommend the one you should learn how and where to learn it for free or with a paid plan depending on your budget.

Skills/Languages To Become a Front-End Web Developer

They include HTML, CSS, JavaScript, TypeScript, Bootstrap, Tailwind, ReactJS, VueJs, etc. Let\'s analyze where each of them belongs and what they do.

Of the above, there are three basic skills to learn that almost the others require you to know before using them. Follow the order below;

1. Markup Languages

You will agree with me that every website or web app has a web page, and every web page contains content (well-structured content). A markup language is what web developers use to structure content on web pages. Simply put, it is what they (web developers) use to display texts, images, buttons, forms, audios, videos to the clients (visitors of the website).

HTML (HyperText Markup Language) is an example of a Markup Language. HTML is the language I recommend you learn as it is most widely used. HTML5 is the latest release of HTML and a lot of companies are making use of HTML5. So you might wanna learn HTML5 as well.

Where do I learn HTML? W3Schools has a very concise tutorial on HTML and HTML5 for free. Check them out. On average, it shouldn't take you more than 3 weeks to learn HTML if you can dedicate at least an hour to studying daily.

2. StyleSheet

As markup languages display texts, buttons, images, etc, stylesheets style these contents and make them look organized and beautiful, very beautiful.

CSS (Cascading Style Sheets) is an example of a StyleSheet and it is what you should learn because it is most widely used and required by companies looking for web developers. CSS3 is the latest release of CSS and lots of websites are making use of its features, it will do you more good if you learn it.

Where do I learn CSS? Again W3Schools has a very concise tutorial on CSS and CSS3 for free. CSS is very easy to learn, it shouldn\'t take you more than a month if you dedicate 1 hour daily to learning it.

3. Scripting Languages

Interactions, behaviors, etc of web pages are made with scripting languages. For Example, when you click a button on a website and then something pops up. A scripting language basically automates task executions.

An example is JavaScript. I will confidently recommend you learn JavaScript. It is widely used in all aspects of development i.e Web Development, Mobile Development, Desktop App Development.

TypeScript is also a great option to learn along with JavaScript.

Where do I learn JavaScript? You can learn JavaScript at W3Schools for free but sincerely that will not be enough. You will need to go wide and as well as have some daily growth activities to get involved with.

A lot of people say JavaScript is hard, honestly, that is as a result of the approach they used. I heard someone say He has been on JavaScript for three years. Learning JavaScript for three years? That must be frustrating.

Don't get me wrong though, learning JavaScript never stops. The same way being a student never stops. But this is about the basics, that's terrible in my opinion. So if you use the wrong approach, you may fall victim to depression, confusion, etc.

Learning JavaScript is tricky but it's not difficult. All you need is to follow the right path and use a good course or tutorial. You may find w3schools difficult to use, so I recommend you use CodeCademy.

CodeCademy gives your projects and exercises to practice with as you learn JavaScript.

Web Frameworks & Libraries

The road-map so far is thus, HTML => CSS => JavaScript. Not HTML => JavaScript => CSS nor JavaScript => CSS => HTML. With the above skills you can build a fully functional static website. Exciting right?

This is the point where you need to build projects with what you've learned. It will help you become better at each of these languages.

You need to follow the order. When you are done with HTML, CSS, and JavaScript; then you may wanna consider some frameworks and/or libraries.

There are numerous web frameworks and libraries for CSS and JavaScript out there but have in mind that their primary job is to make coding easier and faster for you. You can learn web frameworks through their documentations for free. Click on any framework or library mentioned below to access their documentation.

CSS Frameworks

Styling a website can take days, weeks, or even months. But with CSS frameworks the duration becomes lesser and the workload becomes easier. CSS frameworks have already built-in style templates that you just need to tap into your HTML. TailwindCSS is a better and popular option Here is a good list of other CSS frameworks.

JavaScript Frameworks/Libraries

Libraries like ReactJs, or frameworks like VueJs should what I'd say you consider learning. ReactJS is widely used, so you should consider learning.

So far the road-map is HTML => CSS => JavaScript => ReactJS. With the above skills you can build a fully functional dynamic website (web application).

Skills To Become A Back-End Web Developer

The languages popularly used for back-end development includes Python, Rust, PHP, Java, etc.

If you already know JavaScript, you do not need the languages listed above to become a back-end web developer. Simply learn NodeJs.

NodeJS is a JavaScript run-time environment that runs JavaScript on your machine rather than the web browser. With NodeJS you can build servers for your website without learning another language other than JavaScript. NodeJs is by far the easiest to learn, with dedicated 1 hr daily to learning; you will complete it in less than two weeks.

Learning NodeJs is not the end, you need to learn some other NodeJS frameworks like ExpressJs or Fastify(https://www.fastify.io). These frameworks won't take you more than a week to learn the basics.

Also for the back-end, you need to learn a database language/system. You can either learn SQL or NoSQL or both (though not necessary). I recommend learning NoSQL and an example of NoSQL that you should learn is MongoDB.

So to become a back-end web developer this is the roadmap NodeJS => ExpressJS/Fastify => MongoDB/MySQL

Skills To Become A Full-Stack Web Developer

To become a full-stack web developer, you basically need to know everything, and here is everything

HTML => CSS => JavaScript => ReactJS => NodeJS => ExpressJS => MongoDB/MySQL

CodeCademy offers a premium course to learn everything listed above and other goodies to become a full-stack web developer.

A tool for you

Finally, there is a tool I made to go along with this article. It provides a roadmap for you who wants to be a web developer. It shows you what you need to learn, and in what order, and where to learn them. The resources there now, is way more than what you find in this article.
So head there, and see for yourself. It's free to use. and it's called devRoadMap.

You can also contribute to the resources on GitHub. I hope to feature more dev roadmap on this website soon.

Conclusion

Choosing between front-end, back-end or both should be based on what you love doing. If you love designing, content structuring; do well to go for front-end dev.

If you love logic, data analysis then go for back-end dev. If you love both, then full-stack is for you. Becoming the one you love is what makes programming fun for you.

Alright, that's it. Thank you for reading, I will see you in the next article. Don\'t forget to hit me up and follow me on Twitter @elijahtrillionz.

You Don't Need To Learn ReactJS Now

Elijah Trillionz — Fri, 24 Dec 2021 16:07:00 +0000

Now, this isn't another article that tries to stop you from learning and using React and other related libraries and frameworks like VueJS. Rather it is an article that aims to help you understand what React is, when you need to learn it, and what you need to learn it.

So this article will help you learn and use React at the right time. I will also provide useful free courses/crash courses to help you learn React. Let's get started.

What is React
Why is React important
When to learn React
How to learn React
When to use React

What is React?

React is a popular JavaScript library that is used to build user interfaces and single-page applications.

With React, a collection of prewritten code snippets can be used and reused to perform common JavaScript functions.

That is, React allows us to create reusable UI components. These components are what make up our website.

An example of a reusable UI component is the tweet section on Twitter. See what I mean in the image below.

Twitter simply created a component for this section and used it for all tweets in the app. Twitter uses React for its web app.

But you may ask if React is for building single-page then how the hell does Twitter have several pages?

Well, there are maintained supporting packages and libraries that make building complex applications with multiple pages like Twitter with React possible.

While some people still use supporting packages, others have ported to using React frameworks like Next and Remix for building simple and complex applications.

Another framework to learn on top of React you may say. But trust me they are pretty easy to learn. But we won't talk more about them because it is beyond the scope of this article.

Why is React important - What role does it play in web development?

React has played a very vital role in creating interactive web applications in these past few years, and it still is very vital today.

If you are an aspiring front-end developer or full-stack web developer who wants to work for a company, or simply create web apps as a freelancer or a startup, then you need React.

Web applications are different from websites. You don't need React to make a website (static website).

Web apps are dynamic websites that look and feel like desktop or mobile applications. With web apps, you can register an account, make posts, and do things that you'd usually do in an application.

Without React making a dynamic website will not just be tedious for the developer but also difficult to use. Because for each page transition the browser will have to reload. But that isn't so with React.

When do I learn React?

React as you know is a JavaScript library, and as with many other libraries and frameworks, they require a proper understanding of the language itself.

It's no use trying to learn a tool that makes using another tool easier when you have no (or low) clue of how the primary tool works.

React and other JavaScript libraries and frameworks all make use of JavaScript in it (a lot). So it is expedient for you to know vanilla JavaScript to a great extent before learning any JavaScript library/framework.

Understand this, React is not a special thing to learn. It's not like a mini-language that you have to learn to build cool web apps.

Learning React is not a matter of learning a new syntax or something, it's a matter of understanding how React has decided to work with JavaScript. And so you're like "Ok React, this is how you like it, I will play by your rule".

So that means React uses JavaScript's syntax in all ramifications, and a little bit of HTML (JSX). That is why when you know JavaScript enough, you wouldn't find it difficult to move to other libraries and frameworks.

So these libraries and frameworks are not replacing the JavaScript syntax, you're not going to find

if condition:
  // statement(s)
else:
  // statement(s)

replacing JavaScript's if and else in a library. For example in React, we would popularly use

const [state, setState] = useState('initial');

If you have never worked with destructuring arrays in JavaScript, you'd think this is some kind of React's syntax; you may think "here we have the state and setState in an array together and assigned to the useState function, ok this is React". You'd have no clue what this is.

This may sound funny if you are familiar with array destructuring, but some developers are in this situation. And trust me if this is you, it's not a good place to be. But luckily there is a solution - learn enough JavaScript.

So to what extent should you learn JavaScript before learning React?

I think you should learn everything your course/book outlines (I will outline some). Here is a way to learn JavaScript in such a situation - forget about React and other libraries/frameworks.

Don't learn JavaScript because you wanna learn React - don't have such an attitude toward learning. Learn JavaScript because you want to be a web developer who makes cool web apps. Because the truth is React may not always be here.

React may be gone in 5 years or even less. You never can tell. But when you learn enough JavaScript you can easily switch to any JavaScript library/framework you want.

So when you're done with your JavaScript course, that's still not the right time to jump into React. Instead try to master the JavaScript syntax you've learned with exercises, projects, and even websites (lots of them).

To do this, you can google out projects for beginners, Brad Traversy has a great repository of 20 vanilla web JavaScript projects - try building all of them on your own.

When all this is done, I believe you're 100% ready to learn React. Now am not sure which JavaScript course you'll take or may have taken, but to learn React you need to know these topics (explicitly including the basics)

Data Types - string, number, booleans, arrays, objects, undefined, null.
Arithmetic operators and arithmetic operations, logical operators, ternary operators, expressions, variables (const and let), scopes
Conditional statements - if and else, switch and case
Loops - for, for in, for of, while, do/while
Functions - arrow functions, closures, callbacks
Classes and other ES6 features
DOM
JSON
The global object
Asynchronous JavaScript - setTimeout, setInterval

Basically everything. You can use the JavaScript outline provided by W3schools to compare with the course you're using to learn JavaScript. Just to make sure you get every box ticked.

How do I learn React?

Now let's take a look at how you can learn React with the resources that will be provided here. As mentioned before, React is not a special (or hard) thing to learn. This is the way I learn a new framework/library, and I recommend you try it too.

Follow along with a tutorial
Play around with the docs/take a course
Build more projects
Learn in public

Follow along with a tutorial

This is basically coding along with a React tutorial. You can find a React crash course on YouTube for free. You don't have to pay to learn React at all.

I'd recommend a crash course where there is a little bit of explanation on how React works, and then a project. I recommend this React crash course for 2021 by Traversy Media.

The crash course (this step) will help introduce you to React and how it works. It gives you a practical overview of what you'd be working with

Play around with the docs

React has a very good documentation for its library. The documentation gives you more insight into the library and shows you what more you can do with it.

React's documentation is designed to take you from basics to the advanced React step by step. Playing around with the docs simply means studying the docs and trying out some of the examples used.

You can study React's docs like the way you study a course (in college or something). The point is, React's documentation is straight to the point, so you studying it line by line or chapter by chapter is not a waste of time.

Studying the docs shouldn't take more than a week for an average person.

Alternatively, you can take a React course. There are some free React courses out there that can teach you everything you need to know to get started with React in-depth.

Just like the React docs, these courses provide an outline of things you would learn in React, so you go from topic to topic.

These are some of the free React courses:

Build more projects

If you'd notice I said "more projects" rather than "a project". Now, this is because if you follow the first step you'd already built your first project in React, now you just need to build more.

After building more projects, I often recommend checking out some more tutorials on basic projects - you can search for more specific projects and find a tutorial on them.

This will always introduce you to a newer concept and perspective. But try not to end up doing too many tutorials (1 or 2 from different authors is fine), so you don't end up in "tutorial hell".

These steps will help you cover the basics and the more you build projects, and see them from a different perspective, the more you will become efficient in it.

Bonus - Learn in public

Now, this is something I wished I did when I got started with React. It is so important for every developer. Learning in public is like marketing yourself to a dev community. As such you may find companies interested in hiring you. Now it's not as easy or as fast as it sounds.

It would take time and consistency. But when you learn React in public, and post new projects you build you'll definitely get noticed by someone interested in you.

The same thing goes for those who want to freelance.

There are really great communities where you can learn in public, Tech Twitter is one of them. So get active on Twitter. I made a Twitter list of awesome developers you can follow to get started with Tech Twitter.

When do you need to use React

I have already said this before, but I'll just re-iterate.

React is not always needed. You should only use React when you are working on dynamic websites or as some developers may say "complex websites".

You can always use vanilla JavaScript for small projects, and static websites.

For example, if you're to build a business website for a client. The kind of website where you hard-code everything, where visitors come to see about the business like the contact info, and what the business is about. For example a law firm. Such websites don't require React. No matter the pages you're to create, it would be easier for you with vanilla JavaScript.

But if you're trying to build the next Twitter, DEV community, or personal blog (which is always updated) then you'd need the likes of React to easily build them.

Conclusion

React is a cool tool for web development, and as cool as it is, it's very easy to learn. Learning it at the right time puts you at a higher advantage.

To step up your web development career with React you can learn NextJS or Remix easily. You can follow the same steps I mentioned here for learning React to learn one of them. They are a lot easier to learn than React itself.

Thanks for reading. You can leave a comment below to let me know what you think about this article. If you like this article, please like and share. If you want to see more articles like this you can support me by buying me a coffee.

Yeah, and don't forget to hit me up on Twitter @elijahtrillionz. Happy hacking.

Cleaning up Async Functions in React's useEffect Hook (Unsubscribing)

Elijah Trillionz — Tue, 30 Nov 2021 21:11:19 +0000

Functional components in React are most beautiful because of React Hooks. With Hooks, we can change state, perform actions when components are mounted and unmounted, and much more.

While all these are beautiful, there is a little caveat (or maybe not) that is a little bit frustrating when working with useEffect hook.

Before we look at this issue let's do a quick recap on the useEffect hook.

Effect Hook

The useEffect hook allows you to perform actions when components mount and unmount.

useEffect(() => {
  // actions performed when component mounts

  return () => {
    // actions to be performed when component unmounts
  }
}, []);

The callback function of the useEffect function is invoked depending on the second parameter of the useEffect function.

The second parameter is an array of dependencies. You list your dependencies there.

So whenever there is an update on any of the dependencies, the callback function will be called.

useEffect(() => {
  if (loading) {
    setUsername('Stranger');
  }
}, [loading]);

If the array of dependencies is empty like in our first example, React will only invoke the function once and that is when the component mounts.

But you may wonder, "what about when it unmounts, doesn't React call the function too"?.

Uhmmm no. The returned function is a closure and you really do not need to call the parent function (the callback function now) when you have access to the scope of the parent function right in the function you need (the returned function now).

If this isn't clear to you, just take out 7 mins of your time to take a look at an article on JavaScript closures I wrote.

So now we have gone through the basics as a recap, let's take a look at the issue with async functions.

Async functions in React

There is no doubt that you may have once used an async function inside the useEffect hook. If you haven't you are eventually going to do so soon.

But there is a warning from React that appears most times when we unmount and mount a component when we have an async function in the useEffect hook. This is the warning

If you can't see the image, here is the warning

Can't perform a React state update on an unmounted component. 
This is a no-op, but it indicates a memory leak in your application. 
To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

The instruction is pretty clear and straightforward, "cancel all subscriptions and asynchronous tasks in a useEffect cleanup function". Alright, I hear you React! But how do I do this?

It's simple. Very simple. The reason React threw that warning was because I used a setState inside the async function.

That's not a crime. But React will try to update that state even when the component is unmounted, and that's kind of a crime (a leakage crime).

This is the code that led to the warning above

useEffect(() => {
  setTimeout(() => {
    setUsername('hello world');
  }, 4000);
}, []);

How do we fix this? We simply tell React to try to update any state in our async function only when we are mounted.

So we thus have

useEffect(() => {
  let mounted = true;
  setTimeout(() => {
    if (mounted) {
      setUsername('hello world');
    }
  }, 4000);
}, []);

Ok, now we have progressed a little. Right now we are only telling React to perform an update if mounted (you can call it subscribed or whatever) is true.

But the mounted variable will always be true, and thus doesn't prevent the warning or app leakage. So how and when do we make it false?

When the component unmounts we can and should make it false. So we now have

useEffect(() => {
  let mounted = true;
  setTimeout(() => {
    if (mounted) {
      setUsername('hello world');
    }
  }, 4000);

  return () => mounted = false;
}, []);

So when the component unmounts the mounted variable changes to false and thus the setUsername function will not be updated when the component is unmounted.

We can tell when the component mounts and unmounts because of the first code we saw i.e

useEffect(() => {
  // actions performed when component mounts

  return () => {
    // actions to be performed when component unmounts
  }
}, []);

This is how you unsubscribe from async functions, you can do this in different ways like

useEffect(() => {
  let t = setTimeout(() => {
    setUsername('hello world');
  }, 4000);

  return () => clearTimeout(t);
}, []);

Here is an example with an async function with the fetch API.

useEffect(() => {
  let mounted = true;
  (async () => {
    const res = await fetch('example.com');
    if (mounted) {
      // only try to update if we are subscribed (or mounted)
      setUsername(res.username);
    }
  })();

  return () => mounted = false; // cleanup function
}, []);

Update: As suggested by @joeattardi in the comments, we can use the AbortController interface for aborting the Fetch requests rather than just preventing updates when unmounted.

Here is the refactored code of the last example.

useEffect(() => {
  const controller = new AbortController();
  const signal = controller.signal;

  (async () => {
    const res = await fetch('example.com', {
      signal,
    });
    setUsername(res.username));
  })();

  return () => controller.abort();
}, []);

Now React will not try to update the setUsername function because the request has been aborted. Just like the refactored setTimeout example.

Conclusion

When I was still new in React, I used to struggle with this warning a lot. But this turned things around.

If you are wondering, "why does it only happen with async functions or tasks"? Well, that's because of the JavaScript event loop. If you don't know what that means, then check out this YouTube Video by Philip Roberts.

Thanks for reading. I hope to see you next time. Please kindly like and follow me on Twitter @elijahtrillionz to stay connected.