DEV Community: _CODE

Handling exceptions in JavaScript : Key points ⭐️

_CODE — Fri, 24 Sep 2021 12:13:57 +0000

Hello, everybody! 👋🏼

In today's article we'll be talking about exceptions in JavaScript: what they are, different types, declaration and how to handle and deal with them appropriately.

First things first: Main concepts 🧐

Let's first have a look at the main concepts of exception handling to have a clear and concise idea of what they exactly mean in programming.

What is an exception? 🚫

An exception is an anomalous condition that breaks the regular execution of the code.

What does handle an exception mean? 👉🏼

Exception handling is the method by which an exception is caught and managed.

Then, how can we handle exceptions in JavaScript? 🕹

To handle exceptions we'll use the try...catch statement provided by JavaScript.

As easy as that 😊

The try...catch statement 🤠

The try...catch statement is a block that tries to perform one or several actions that can lead to error conditions and defines the instructions to handle such errors appropriately in case they happen to occur.

Let's see the structure for this statement:

try{
/*
 * Action(s) to be performed that can lead
 * to an anomalous condition.
 */
}
catch(e){
/*
 * Error / exception handling.
 */
}
finally{
/*
 * Instruction(s) to be executed after
 * the try...catch statement ends.
 */
}

Things to consider:

Curly braces must be used anytime, even for one line statements within the blocks.
A catch or a finally block must be defined as part of the try...catch statement, but neither of them are mandatory separately.
The previous point results in the following types of try...catch statements:
- try...catch
- try...finally
- try...catch...finally

The throw statement 🎳

The throw statement, as its own name indicates, throws an exception when something wrong occurs within the function or block it is declared.

When a throw statement is found, the execution of the current function stops and the control is shifted to the catch block.

A very simple example:

try{
  throw new Error('Something went wrong!');
}
catch(e){
  console.error(e);
}
/*
 * Output:
 * Error: Something went wrong!
 */

A throw statement is usually called within the try block, but that doesn't mean that can't be called within a catch block (to rethrow an exception once it has been caught) or a finally block (to throw an exception no matter which previous block has been executed).

▫️ Rethrowing an exception in the catch block:

try{
  try{
    throw new Error('🙄');
  }
  catch(e){
    console.error(e);
    throw e;
  }
}
catch(e){
  console.error(e);
}
/*
 * Output:
 * Error: 🙄
 * Error: 🙄
 */

▫️ Throwing an exception in the finally block:

try{
  try{
    throw new Error('Error - try block');
  }
  catch(e){
    console.error(e);
    throw new Error('Error - catch block'); //Note that this exception is never caught
  }
  finally{
    throw new Error('Error - finally block');
  }
}
catch(e){
  console.error(e);
}
/*
 * Output:
 * Error: Error - try block
 * Error: Error - finally block
 */

User-defined exceptions 👨🏻‍💻👩🏻‍💻

A user-defined exception is a custom exception that can contain any valid expression.

The following statements are all correct:

throw 'Error!';
throw 404;
throw false;

Let's see an example where an object is thrown.

Note that object properties become accessible once the exception is caught, through the error itself:

const UserException = {
  name: 'UserException',
  message: 'There was an error 🙃'
}

try{
  throw UserException;
}
catch(e){
  console.error(`${e.name}: ${e.message}`);
}
/*
 * Output:
 * UserException: There was an error 🙃
 */

JavaScript built-in errors can also be used as objects for user-defined exceptions and be thrown accordingly.

Take a look at the following example, where a TypeError error is thrown if the type of the required value is not String.

const TypeException = function(){
  const msg = 'There was an error regarding the data type.';
  this.error = new TypeError(msg);
}

const isString = value => typeof value === 'string';

const city = {};

const setCity = cityName => {
  if(isString(cityName)) city.name = cityName;
  else throw new TypeException();
}

try{
  setCity(28);
  console.log('--- City name has been set correctly.---')
}
catch(e){
  console.error(e.error);
}
finally{
  console.log('--- The execution has finished ---');
}
/*
 * Output: 
 * TypeError: There was an error regarding the data type.
 * --- The execution has finished. ---
 */

Conditional catch blocks 🚀

There may be occasions where the try...catch block throws different types of exceptions.

In order to handle each of them in a proper way, we can use if...else statements within the catch block.

let month;
const setMonth = monthValue => {
  if(typeof monthValue !== 'number') throw new TypeError(monthValue);
  if(monthValue <= 0 || monthValue > 12) throw new RangeError(monthValue);
  month = monthValue;
}

try{
  setMonth(-5);
  console.log(`-- Month ${month} has been set correctly ---`);
}
catch(e){
  const errorInfo = 'Please enter a number [1-12]';
  if(e instanceof TypeError)
    console.error(`Wrong data type: ${e.message}. ${errorInfo}.`);
  if(e instanceof RangeError)
    console.error(`Out of range: ${e.message}. ${errorInfo}.`);
}
/*
 * Output: 
 * Out of range: -5. Please enter a number [1-12].
 */

We could also use a switch statement to handle multiple exceptions, being both examples equivalent:

...
try{
  setMonth(-5);
  console.log(`-- Month ${month} has been set correctly ---`);
}
catch(e){
  const errorInfo = 'Please enter a number [1-12]';
  switch(e.name){
    case 'TypeError':
      console.error(`Wrong data type: ${e.message}. ${errorInfo}.`);
    case 'RangeError':
        console.error(`Out of range: ${e.message}. ${errorInfo}.`);
  }
}
/*
 * Output: 
 * Out of range: -5. Please enter a number [1-12].
 */

Summary: key points 💫

Exceptions are error conditions that break the normal flow of the code execution.
An exception can be any kind of expression: a number, a string, an object...
Exceptions should be thrown and handled appropriately in order to not crash the app and let the user know that something didn't go as expected.
JavaScript built-in errors can be used as throwable objects for user-defined exceptions.
Multiple exceptions can be handled within the same catch block.

⚡️ Related post on Instagram:

And that's all for today! 😇

A big thanks for reading 🤗 and don't hesitate to reach out to me if you have any questions or doubts about today's article.

I hope you found this article useful and I see you all in the next 👋🏼

🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content: info, challenges, quizzes & more 💜

And last but not least... A quick friendly reminder before we go 😊

We all know there are million ways to get things done when it comes to programming and development, and we're here to help and learn, so, if you know another possible way to do what others are sharing (not better, not worse, just different), feel free to share it if you feel like it, but, please, always be kind and respectful with the author and the rest of the community. Thank you and happy coding!

UX 101 📲: Nielsen's 10 Usability Heuristic Principles for User Interface Design (6-10)

_CODE — Thu, 16 Sep 2021 11:24:00 +0000

Hello, everybody! 👋

And welcome to the second lecture of the UX 101 series 🙌

In this series, we will be talking about UX and good practices when it comes to interface design and user interaction.

In this second lesson (together with the first lesson, which you can check out through the table above), we'll be studying Nielsen's 10 Usability Heuristic Principles for User Interface Design.

In today's lecture we'll be covering principles 6-10.

👉🏼 Before delving into the matter, remember that we're also on Instagram, where you can find daily content about web development, all the related slides to every published article and... quizzes and challenges! 💜

Nielsen's Principles (6-10) related post on Instagram 👇🏼

So, with all this said, let's dive in! 🌊

6. Recognition rather than recall 👆🏼

💡 Main idea

Users shouldn't have to memorize lots of information to be able to perform a task within the system. That's why making elements, actions and options visible helps them carry out their goals in an intuitive and approachable way.

💎 Main goals

Reduce the cognitive load and effort on user's side, due to human limited short-term memory.
Make the interface more intuitive so the user doesn't need to struggle when using the system.
Accelerate user's learning process.

🧠 Memory retrieval

Human memory is organized in chunks (as it is computer memory), which are activated when we need to retrieve the information they store.

For these chunks to be activated and ready to work, three factors come into play:

Practice: how often the information stored in a chunk has been retrieved. The more you practice something, the more easily you're going to remember it. When a chunk of memory is the first one in being activated, that means that it's the most accessed and practiced through time.
Recency: how recently a chunk has been practiced. This helps enormously to how clearly you're going to remember the information it contains.
Context: what surrounds the person's focus of attention (stimuli that trigger such retrieval of information, like when you read, hear or see something). The keyword for this factor is association, a very important concept in psychology that is crucial and explains a lot of human mental conditions.

Association

Association mainly works as a connection between concepts and ideas, providing a link between past and present experience.

Regarding memory retrieval, this means that when we perceive a stimulus, we're capable of retrieving information from multiple related chunks.

Association varies a lot from individual to individual because it mainly depends on personal previous experience

👁 Recognition versus recall

The main difference between these concepts is the amount of cues that can help memory retrieval when we perceive something.

A cue can be defined as a piece of information that contains hints that sends our brain to retrieve information related to what we're perceiving at that precise moment.

Recognition is preferred because it involves more cues than recall.

An example

If someone asks you Who wrote El Quijote?, you would likely have to think for at least a few seconds to be able to give an answer. That's recall. The process involves remembering the name of an author.

On the other hand, if they ask you Did Miguel de Cervantes write El Quijote?, you would presumably be able to answer as soon as you're asked. That's recognition. You are capable of easily identify the stated fact and answer rapidly.

In our everyday lives we combine both recognition and recall to retrieve information from memory (every second of the day, even though we're not aware of it).

👉🏼 Recall in user interfaces

A very classical example: a login system. When a user wants to access their profile or their personal area. Nothing but the website interface itself can provide a hint to make the user remember their username and password (which hardly ever will provide a real hint).

The user will need to remember their personal credentials, because there aren't real clues in their current context.

👉🏼 Recognition in user interfaces

Another classical example: a navigation system. You're shown a few options, you identify which one you want to access and you perform your task.

🖥 How can we prioritize recognition over recall?

The best we can do to make users recognize our system's interface when interacting with it is to make interface functions discoverable, visible and easily accessible.

An application mainly comprises two components: the interface (buttons, links, navigation menus, forms...) and the content (the information provided by the system).

The main goal to achieve with this principle is to make both of these components easy to remember and reduce cognitive overload on user's side, as stated up above.

🔮 Tips

Make the information discoverable and affordable for the user so they don't have to remember it.
Always offer help based on user's context and try to target their current needs. Never expect the user to read a long tutorial or documentation to learn how to perform a task or to solve a problem. We'll see a more detailed approach to this down below, in the 10th Principle: Help and documentation.
Try to reduce by any means the information the user needs to remember to be able to carry out an action successfully.

🤖 Keywords

Identify
Recognize
Remember
Memory
Association
Experience

7. Flexibility and efficiency of use 🎛

💡 Main idea

Users should be provided with different ways to be able to perform tasks within the system, be their expertise level novice or expert.

Shortcuts are a good example of this: they help expert users achieve their goals faster without being an obstacle for less-experienced users.

These flexible ways can be presented in many forms so the users can pick up their own way out of the choices they're provided with.

💎 Main goals

Make the system flexible enough to be fully adapted to every user's expertise level so they can feel confident by being presented with a variety of options when it comes to performing tasks.
Improve user's reliability on the system.

👩‍💻👨‍💻 Different users. Different needs.

When users interact with an interface for the first time, they will presumably need guidance to help them get to know the system environment in order to get familiar with it and be able to achieve their goals. For example, a good idea would be to provide step-by-step tutorials, since they're likely not going to skip them if they really want to learn how to use the system.

On the other hand, experienced users may expect accelerators to perform the same tasks, like shortcuts and touch gestures, although they can still use the traditional methods.

It's never recommended to provide interaction methods only for a specific population of users, even though you think you already know their level of expertise. Because every user is different and, accordingly, their needs are.

So the point is to create a flexible and efficient system that provides multiple methods to perform the same tasks according to the variety of users who interact with it.

The main goal of providing different ways to do the same thing is to suit the user's working style, so they feel confident to use the system their way. This also improves their reliability on the system, since they feel like someone cares about their needs.

It's recommended to provide a customizable interface when possible, basically to give sort of support users' work habits, even though most users don't bother to customize the system.

Take into mind that if you provide customization, this should be consistent between sessions and not be lost in-between.

🔮 Tips

Provide shortcuts so the experienced users can speed up their task performance.
Don't use obstructive ways that can limit a specific group of users.
Try to customize as much as possible all the content and functionality to adapt them to individual group of users.
Allow customization on user's side so they can select and adapt the system to meet their own needs.

🤖 Keywords

Flexibility
Shortcuts
Adaptation
Expertise
Accelerators

8. Aesthetic and minimalist design ✨

💡 Main idea

Interfaces shouldn't include information that is unimportant to users, since it may take away visibility of relevant content.

This doesn't mean you're obliged to use a flat design. It's more about keeping design focused and targeted to the point.

This principle is closely related to Gestalt Principles. In future lessons of this series, we'll be talking about them and going further into the topic of design of interfaces.

💎 Main goals

Provide a clean, usable interface, focused on users' goals.
Reduce distracting elements that can constitute an obstacle to them.

🔮 Tips

Regarding visuals, always focus on the basics and don't overload the interface.
Don't include elements that are not relevant and can become a distraction to the user.
Focus on users' main goals rather than provide a fancy interface.

🤖 Keywords

Minimalism
Plain
Clean
Focused
Targeted

9. Help users recognize, diagnose and recover from errors ⛔️

💡 Main idea

Errors should be presented as clear messages, always straight to the point and be written in an understandable language, so the user can easily be aware of what's going on. These messages should be focused on the real problem and provide or recommend a possible solution to the issue.

💎 Main goals

Provide quick response when an error appears.
Help users accomplish their tasks.
Provide constructive advice for future interaction.

🛑 How error messages should be presented to the user

Should be explicit and manifest in a clear way that something went wrong.
Should be human-readable, so always avoid using technical vocabulary or jargon words and/or codes.
Should be polite. Never blame the user for errors. Remember that all those mistakes are caused by the designer, never the user, so don't patronize them or make them feel like they did something wrong.
Should be precise and exact. Always try to go to the point and avoid general error messages like Fatal error or Something went wrong, which don't provide extra information and will likely send the user to wonder what they did wrong.
Provide constructive advice on what the real problem is. As a very basic example, picture a login system in which there's a form with two fields: username and password. Say the user has a typo in the username field, so they receive the following message when trying to log in: Incorrect password or username. Try again.
Just be clear and tell the user which the username or the password is throwing the error. In this example there's only two fields, but could be way more.

💬 How to use plain language to communicate with the user

Identify your potential audience to adapt your writing to their needs and expectations. Try to stick to their level of reading, the language they're used to, the concepts they are familiar with and how they expect the information to be presented.
Try not to use slang, idioms, acronyms or complicated terms. Complex language is difficult to understand and may sound pretentious to the user.
Keep sentences and paragraphs short. You can convey the same ideas with less words.
For general audiences, try to write for 6-8th graders. For experts, don't go beyond 10-12th.

🔮 Tips

Make use of traditional error message visuals, like red color, bold typography, alert sounds, etc.
Communicate errors using a language users understand.
Provide valid solutions to fix possible issues as soon as they're identified.

🤖 Keywords

Concise
Precise
Constructive
Plain language
Straight to the point

10. Help and documentation 🗂

💡 Main idea

An optimal system would be that one that doesn't need to provide extra information, but, most times, that's something we can't avoid because users need clues on how to perform tasks so they can reach their goals.

💎 Main goals

Anticipate problems the user may be facing when interacting with the system.
Provide users with relevant extra information to make them feel comfortable, successful and to improve their reliability.
Make users succeed when carrying out tasks and meet their expectations.

🗄 Types of help: proactive and reactive

Proactive help

Proactive help is used to prevent problems and its main goal is to get the user know how the system's interface works. There are two types of notifications that belong to this kind of help:

Push revelations: used to provide help to the user with no regard to the task they're trying to accomplish in that precise moment. They use to appear randomly and out of nowhere containing information that hasn't been asked for.
Pull revelations: used to provide help that is relevant to the task that is being performed by the user. They can appear when the user has initiated a new task or when they're close to face a problem.

It's highly recommended to always choose pull over push revelations when possible.

Take into mind that we will face three types of scenarios when dealing with proactive help provision:

New users using the interface for the first time.
Novice users that are still learning how to use the system.
Expert users that encounter an update of the interface (for example, a new design or new functionalities).

Reactive help

Resources like documentation, videos, tutorials and guides constitute reactive help, which is useful when a user encounters an issue and needs help to address it. The main goal of this kind of help is to answer questions and provide a final solution to fix a problem. FAQ and technical tutorials are a good example of this kind of help.

Always ensure that the resources you're providing the user with are detailed, understandable and useful. It's recommended to provide step-by-step instructions because the user needs to fix something. They don't read documentation just for fun.

Don't stick to only providing one source of information: complement your writing with videos, graphics or any other multimedia resource that you consider that may be useful to help your users.

Structure your information into categories and provide search so users can easily find what they're looking for.

🔮 Tips

Documentation should be visible, easy to find and, mostly, easy to search.
Present the required information in context right at the moment when it's needed.
Provide a list stating the steps that should be followed to accomplish a task or address an issue.

🤖 Keywords

Documentation
Tutorials
Troubleshoot
Searchable
Help in context

And this is all for the second lecture of the UX 101 series!

Stay tuned to know more about UX in future episodes of the series.

A big thanks for reading 🤗 and don't hesitate to reach out to me if you have any questions or doubts about today's lecture.

I hope you found this article useful and I see you all in the next 👋

🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content: info, challenges, quizzes & more 💜

UX 101 📲: Nielsen's 10 Usability Heuristic Principles for User Interface Design (1-5)

_CODE — Sat, 28 Aug 2021 16:59:37 +0000

Hello, everybody! 👋

And welcome to the first lecture of the UX 101 series 🙌

In this series, we will be talking about UX and good practices when it comes to interface design and user interaction.

In the first two lessons (this one and the following one), we'll be studying Nielsen's 10 Usability Heuristic Principles for User Interface Design.

In this first lecture we'll cover the first five principles.

Nielsen's Principles (1-5) related post on Instagram 👇🏼

So, with all this said, let's dive into today's lesson 🌊

What are heuristics?

Heuristics are techniques used to improve the usability of a system based on a previous experience. This improvement consists basically on solving existent problems and identifying the necessities of the said system during the iterative design cycle.

Even though this method is far from being perfect or optimal, it speeds up the process of development and provides a way to start solving issues as soon as they are discovered and identified.

Let's now turn our attention to the first five Nielsen's Principles for User Interface Design:

1. Visibility of system status 🖥

💡 Main idea

The system has to inform the users about the current system status and what is going on at all times, by providing them with appropriate feedback within a reasonable time.

The system status includes:

Where the user is within the navigation tree.
Where the user is within a process derived from a taken action.
If the system is stable and everything is working as it should or something went wrong.

This principle is necessary to make the the user capable of deciding which their next steps will be, based on what's happening at that particular moment (anticipation), since they know beforehand where they are and what the current system status is.

Another advantage of implementing this principle is the reliability we're going to convey to the user. They will end up trusting not only the product or the service we're trying to sell, but also the brand or the individual behind the service (let's say, for example, a blogger).

💎 Main goals

Make the system predictable and let the users know that they have the control, which, consequently, will send them to think that everything's going to proceed in the way they wish and expect.
The less information they get, the easier it will be that they think that they're not in control of the situation.
Make the user feeling comfortable while they go through a series of steps towards a goal.
Create a recurring client (or visitor) and convey trust and reliability looking to the future.

🔮 Tips

Always inform the user on what's going on. Always. No matter what. Communication and transparency are key (like in relationships with people in real world). Let them know the result of their actions and don't leave them wondering if they made a mistake after having taken action over something.
Nothing that affects the users should happen without informing them beforehand. Let alone something that leads to an error condition or a situation from which they don't know how to recover.
If you can avoid this type of situations and they happen at some point, tell the user immediately. Or, at least, as soon as possible. Quick response results in early recovery from errors and providing enough information leads to better decisions.
Build trust through interacting with your users.

At the end of the day, this principle refers more to how well you communicate with your users than the fact of communicate with them itself.

📱 What can we do as UI designers?

A good start would be to implement a series of standard elements that help the user notice the status of the system, like the following:

Breadcrumbs

The user should know where they exactly are within the navigation tree at all times.

Provide feedback of a taken action

For example, by highlighting an element after taking an action on it.

Progress bars

Always let the user know where they are within a multi-step process and show progress bars when appropriate.

Spinners

Implement spinners to let the user know that they have to wait for an action to complete. Don't leave them wondering what's going on.

🤖 Keywords to this principle

Communication
Transparency
Trust
Reliability
Anticipation
Feedback
Information
Decisions
Predictability
Control
Comfort

2. Match between the system and the real world 🖥↔️🌎

💡 Main idea

The system should speak the users' language, this is, they have to be capable of easily understand everything they perceive while interacting with the system.

Human beings find comfort in familiarity, so bear in mind that it's fundamental to use concepts and words that the users already know, have an idea of and find easy to understand. That's what we understand by familiar.

It's true that every person has a different understanding and perception of the world: some things can be very obvious for you, but not that obvious for, let's say, a friend of yours.

So, since this is something unavoidable (but manageable), it's important to take this fact into mind, and, as a result, base every concept of the system in real world conventions. Never assume that your understanding and your particular interpretation of the world match the ones of your final users.

These interpretations are formed based on previous experiences, familiarity with language and objects, beliefs, ideas and values, and are called mental models.

Each user has its own mental model and they carry these interpretations with them from the real world to the digital world, so it's our work to ease this transition by expressing concepts appropriately.

Since it's impossible to know what the vision of the world is for every user, the only thing we can do to create a suitable conceptual model for our system is to use logical statements and concepts that are widely extended within society. This will result in users making use of the system intuitively and comfortably.

💎 Main goals

Match user's expectations as to their interaction with the system.
Let them know that you understand their needs and care about them: to show empathy will make them feel important.
Build trust and set a feeling of familiarity on their side, which will lead to loyal users.

🔮 Tips

Make sure your users understand every piece of information they are interacting with and be aware of the importance that this fact has.
Users should always be able to understand the meaning of everything they run into without having to go look it up in a search engine, so never use jargon or complex words. Better use natural language and present information in a natural and intuitive order. Everything should flow naturally to facilitate the user the task of proceeding when using the system.
Never assume the way of making use of the system by an user and how will they behave while interacting with it.
Do a research on what kind of user will interact with your system to find out what concepts are familiar to them and what type of language you should use, and adapt yours, if necessary.

🤖 Keywords to this principle

Familiarity
Logic
Real world
Perception
Care
Empathy
Experience
Natural

3. User control and freedom 👩‍💻👨‍💻

💡 Main idea

Users make mistakes, so they have to be provided with emergency exits in case they need to escape or recover from wrongly performed actions.

But not only when they proceed in a wrong way: they always have to be allowed to correct mistakes and change their minds, especially when they open up a new page, screen or view (usually through clicking a provided link).

A large amount of users still rely on browser's or device's back buttons instead of using the back links provided by the system, so it's important to pay close attention when leading actions towards new tabs since some users can have trouble trying to go back.

◽️ Types of emergency exits

Back link: a link that allows the user to go back in a page, screen or view.
Cancel link: a link that allows the user to interrupt the process of an ongoing action.
Close link: a link that allows the user to close an open view (e.g., modals).
Undo link: a link that allows the user to reverse a taken action, which should also be ideally accompanied by its corresponding redo link, to let them know they can change their mind anytime even if they make a mistake in the course of performing an action.

💎 Main goals

Ensure that the user feels in control of the situation when interacting with the system.
Give users the freedom to perform actions within the system without leaving them wondering and worried about the actions they are performing.
Make the user feel comfortable enough to explore the system without feeling inhibited, which is a direct consequence of them knowing that they can take actions that can be reversed if they make a mistake.

🔮 Tips

Facilitate the user the task of finding emergency exits on your system, just as it's easy to find their counterparts in public spaces, like a shopping mall.
Using icons that are universally recognizable by the user can help match their mental models (like using a cross to close a view). You can add a text label to point more clearly where the corresponding action will lead them to.
Allow the user to cancel an action at any point of the process. This is specially important when it comes to a purchase, a money transfer or a download that can take some time.
Always support the undo of an action by implementing links, toggles or checkboxes and ensure that they are well placed to be easily discoverable by the user.

🤖 Keywords to this principle

Control
Freedom
Exits
Mistakes
Exploration
Cancel
Go back

4. Consistency and standards ⌚️

💡 Main idea

Users have expectations when interacting with a system, which are based on their previous experiences with another systems.

Jakob's Law states:

"People spend most of their time using products that are not yours, so they expect your product works in the way the others do. Failing to fulfill these expectation may result in user’s cognitive overload and force them to learn something new."

So that's important that our system follows already established conventions when it comes to user interaction and interface design, as we mentioned in Principle 2: Match between the system and the real world.

Some examples of these conventions are:

Underlined text means clickable.
A shopping cart / basket icon represents the section where the items you select to buy are stored and from where you will be able to proceed to a checkout process eventually.
Red means stop / danger and green means go / safe.
A magnifier icon means search.
While accessing a website or an app on portable devices, an icon representing three vertically stacked lines means that there is a hidden navigation menu.

◽️ Internal versus external consistency

Internal consistency regards consistency and standards across a product or a family of products.

When it comes to a single app, this means that consistency should remain throughout the platform: layout, colors, shapes, typography, visual items treatment...

On the other hand, while facing the design of a family of related products, not only the conventions above should be met but also have to keep a coherent relation between them all when it comes to layout, icons and functionality, to mention a few.

External consistency refers to consistency and standards that match the industry and / or web conventions.

As an example, note that all well-known e-Commerce sites follow common standards in order to make the purchase experience consistent and efficient to the customer. Otherwise, it would lead to them leaving the store and looking for another one where they understand the steps they need to take towards their goal (the purchase of an arbitrary number of items) and where they feel comfortable with the process.

◽️ Layers of consistency

1. Visual

Colors, typography, icon design, title decoration, etc should be consistent across the system.
Images should be treated similarly: aspect ratio, borders, size...
Symbols should be consistent with the action they lead to or the information they're providing: use an icon of a plane for flight search, an icon of a car for car rental, an icon of a cat or a dog when specifying if pets are allowed in an accommodation, a cigarette when pointing out if it's allowed to smoke or not, or a shopping cart to store the items that can be eventually purchased, as mentioned earlier above.

2. Page layout

All items related to page layout should remain consistent and coherent across all the pages of the site.
It doesn't matter where you decide to locate buttons and other layout items, but do it consistently: don't place the same button in different places when having different screens among the same process, for example.

3. User-entered data

This is especially important when it comes to dates, phone numbers and locations. Avoid to use an open field for this type of data.
Provide the user with date pickers or auto-formatting so they don't have to think about how to enter the required information and let them know they don't have to insert separators in any case (so you don't have to split the entered information later on).

4. Content

The consistent tone of voice across the site is crucial. Otherwise the user can feel confused, which will result in not meeting their expectations, and consequently, leaving and / or not returning.
Don't mix casual tone with formal tone and always present the information in a way that is readable and understandable by the majority of the users that access your platform.

💎 Main goals

Meet user's expectations, since they come to use your system with a preconceived idea of how it should work (based on their mental model).
Build their confidence towards the system.
Make them focus entirely on the content rather than let them wondering what's the meaning of what they're viewing, reading or listening to.
Make sure that the user doesn't have to learn something new in order to interact with your system (or at least as less as possible).

🔮 Tips

Always pay attention and implement both internal and external consistence, to make sure all the standards and conventions are met.
Follow industry and web conventions to avoid the user have to learn new things or concepts while interacting with your system.

🤖 Keywords to this principle

Consistency
Conventions
Standards
Expectations
Interaction
Confidence
Focus

5. Error prevention ❌ → ✅

💡 Main idea

Users, as human beings, make errors. You, as an user, make errors. Everybody does. That's something natural. But, even it's something unavoidable, it can also be alleviated by designing a good interface for our system, in these terms.

Although alerting the user with an error message is a good practice, it's even better to design a non error-prone system.

◽️ Types of errors

There are two types of errors the users can make: slips (minor errors) and mistakes (conscious errors).

Slips: This type of error is often caused by inattention on user's side, like typos. They are more often made by experienced users, who use the autopilot when interacting with a system: they feel comfortable and rely their confidence on their previous experience with it, while newbies pay more attention to what they're doing since they're learning how to interact with the system.
Mistakes: These are caused by a mismatch between the user's mental model and the design of the system. They take the correct steps towards their goal but these can be inappropriate for the situation. Mistakes are more difficult to prevent than slips.

◽️ How to prevent slips

Always include helpful constraints for user input. For example, regarding a form input field where a range of dates should be entered, always compel the user to select a range where the first date comes before the second date.
Offer suggestions as to search, to avoid typos.
Choose according default values, when needed.
Use forgiving formatting. This means that, for some input fields, every user can have a different idea on how to enter data, for example, a phone number. So, from here, we have two options: getting rid of the info the user has entered and which is not needed (parentheses or hyphens, for example) or autocompleting the phone number with these special characters while the user is typing. This latter improves their reliability on the system, since they know that they're performing the task correctly, so it's more appropriated than the first one.

◽️ How to prevent mistakes

Collect data. While you're still designing the system, you can gather information about what kind of users are going to use it and do a little research, so you can be aware of what you can expect of their actual mental models.
Once you have your system designed, you can run usability testing to know what's wrong with the usage of your system on user's side.
Follow design conventions, as we've mentioned above, in Principle #2: Match between the system and the real world.
Communicate affordances. This means that the user should be able to know when an element of the interface is available and, consequently, that is interactive and that an action can be taken on it.
Preview results. Let the user know that the action they're going to take may result in changes at scope level within the system, so they can double-check if they really want to proceed and inform them on what's going on from there.

◽️ Good practices to prevent both types of errors

Don't make the user have to remember things or keep information about something within the system. Always provide contextual information.
Show a confirmation dialog before they take an action that causes changes, like deleting something.
Always support undo, so the user knows that the changes they would do can be revoked.
Let the user know that they will incur an error if they proceed when they're actually doing something that is not allowed. For example, if the user surpasses the number of allowed characters as to a text.

💎 Main goals

Prevent the majority of mistakes a user can make when interacting with our system, rather than waiting for them to perform an action that leads to an error to inform them.
Make the user comfortable with the system by letting them know that if they make a mistake, they can undo the taken action, so their confidence and reliability on the system grow.
Never make the user feel that they're responsible for errors, because they're not. The designer of the system is (yes, us 😇). So, it's important to use an appropriate language when communicating with the user when an error occurs and improve the design of the system so they make as less of them as possible.
Help the user build a good mental model of your system's interface.

🔮 Tips

Always prevent errors to occur.
Avoid slips by including constraints, good default values and suggestions.
Support undo and let the user know they can recover from their errors.
Warn your users when needed.

🤖 Keywords to this principle

Error
Mistake
Undo
Prevention
Revoke
Confirmation

And this is all for the first lecture of the UX 101 series!

Stay tuned to know more about UX in future episodes of the series.

A big thanks for reading 🤗 and don't hesitate to reach out to me if you have any questions or doubts about today's lecture.

I hope you found this article useful and I see you all in the next 👋

🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content: info, challenges, quizzes & more 💜

Styled Components 101 💅 Lecture 3: SSR with Next.js + Custom Icon Fonts 😍

_CODE — Sun, 08 Aug 2021 14:09:13 +0000

Hello, everybody! 👋
And welcome to the 3rd lecture of the Styled Components 101 series 🙌

In this lecture, we'll be covering:

1️⃣ How we can use Styled Components within a Next.js configuration.

2️⃣ How to use custom icon fonts within our styled components.

If you're new to Styled Components and this lecture is the first one you run into, I suggest taking a look at the previous lectures first, where we covered some basic concepts and examples of Styled Components.

With all this said, let's move on to today's topic 👇

How to get Styled Components to work if we're using Next.js 😺

Let's first see what happens if no configuration for Styled Components has been defined for our Next.js project and we try to use the library.

To start off, we're going to create a StyledButton component (already known to all at this point 😜) and render it within the main component of our app.

StyledButton.js

import styled from "styled-components";

export default styled.button`
    background-color: ${props => props.bg};
    color: ${props => props.color};
    border: none;
    border-radius: 5px;
    padding: 20px;
    font-size: 1.5rem;
`

index.js

import StyledButton from '../components/StyledButton';

const Home = () => {
   return(
      <StyledButton bg="#c64dff" color="#fff">Styled Button in Next.js</StyledButton>
   )
}

If we run our app, this is the resultant button:

Where in the world are our styles? 🤔 Let's find out what's going on in here.

First, if we go to the Console Tab in the browser's dev tools, we see that something is throwing an error:

The error reads:

_Warning: Prop `classname` did not match. Server: "sc-pNWdM kcTaxf" Client: "sc-bdnxRM gSuzZs" at button...
```


It seems like two different classes are being assigned on the server and the client, resulting in an __inconsistency__. 

Let's now have a look at the __Elements__ tab:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/59ux7ot96qsk3n4ntn6n.png)

Our button is there and we can confirm that the class provided by Styled Components has been __assigned correctly__, but the __styles are__ completely __missing__.

##So, what can we do to solve this? 😩

Well, this is neither a bug nor even a big deal. It's just that a __further configuration is required by Next.js__ to get to work Styled Components in our project in order to use it.

So, first, we're going to install the `babel-plugin-styled-components`, which is required for __SSR__ (_Server Side Rendering_).



```bash
npm install babel-plugin-styled-components
```




Now, let's create a `.babelrc` file if we haven't already done so (it's not created by default when creating a Next.js app) and write the following configuration for the newly installed plugin on it:

On the terminal:



```bash
touch .babelrc
```



`.babelrc`



```json
{
   "presets": ["next/babel"],
   "plugins": [["styled-components", {"ssr": true, "preprocess": false}]]
}
```



But we're not done yet, we still need a little bit more of configuration.

Now we need to inject the __server side rendered styles__ in the `<head>` element of our HTML file. For this purpose, we need to override the _Document_ file, which is provided by Next.js.

The _Document_ file is extendable, which means that we can add content to it if needed, and it's mainly used to __add custom content__ to the `<html>` and `<body>` elements of the HTML main file. Note that this file is only rendered on the server.

This _document_ is automatically generated with the creation of the Next.js app, but since we need to extend it, we're going to create another file called `_document.js` to __override the original one__. This new file should be placed within the `/pages` directory and it will look like this 👇

`_document.js`



```jsx
import Document from 'next/document'
import { ServerStyleSheet } from 'styled-components'

export default class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const sheet = new ServerStyleSheet()
    const originalRenderPage = ctx.renderPage

    try {
      ctx.renderPage = () =>
        originalRenderPage({
          enhanceApp: (App) => (props) =>
            sheet.collectStyles(<App {...props} />),
        })

      const initialProps = await Document.getInitialProps(ctx)
      return {
        ...initialProps,
        styles: (
          <>
            {initialProps.styles}
            {sheet.getStyleElement()}
          </>
        ),
      }
    } finally {
      sheet.seal()
    }
  }
}
```



Note that `renderPage` should only be modified when working with _CSS-in-JS_ libraries, like Styled Components, since they need the app to be __wrapped to work on server side__. Otherwise the default configuration should always remain 👍

If we're not planning to use any of these libraries, the following configuration could be a good starting point if we need to add something to the structure of our HTML document, being able to remove all that we don't need to change (note that we're __overriding__), like `getInitialProps` or even the `render` method:



```jsx
import Document, { Html, Head, Main, NextScript } from 'next/document'

class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const initialProps = await Document.getInitialProps(ctx)
    return { ...initialProps }
  }

  render() {
    return (
      <Html>
        <Head />
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    )
  }
}

export default MyDocument

```


In any other case, there's no need to extend the original _Document_ and we can forget about it 😜.


Once we've made all of these arrangements, let's re-run our application and see what happens!

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qz2kvlnuks7kxza9exkj.png)

There we go! Our Styled Button is finally rendering properly 👏

And that would be all the configuration needed to work with __Styled Components + Next.js__.

Let's now dive into how we can add a __custom icon font__ to a _styled_ component 👇

#Custom Icon Fonts in Styled Components ❤️

This topic is totally separate from the previous one, __since an extra configuration for fonts is no longer required in Next.js__, but anyway, let's extend our _styled_ button by adding an icon from a custom icon font and let's see what we need to do to make it work.

##First of all... What is an icon font? 🐔

Unlike regular fonts, which contain letters and numbers, an icon font is nothing more than a __collection of symbols and glyphs__ that works as a typeface. Its use is widely extended because they are really easy to style with CSS.

The tool we're going to use to get our icon font is ___Icomoon___, but this example works for every downloaded fonts coming from any font resource.

Let's say we have already downloaded our font files after generating the custom set and we're all set and ready to go. 

##Integrating a custom icon font set into our project 🐸

What we're going to do in this section is to __add an icon__ from our custom icon font as an `::after` pseudo-element, to place it after the text of our button.

So, first, we're going to add a new _prop_ to our styled button call and pass it the content value of an icon of our choice.

Note that every icon has a sort of _id_, which is the value we'll pass in to the _prop_ named ___icon___. This content value is always provided by the tool, so you don't need to assign it yourself.

In this case, the content value for our icon is `\e900`.



```jsx
<StyledButton bg="#c64dff" color="#fff" icon="\e900">Styled Button in Next.js</StyledButton>
```



Then, we'll just add the `::after` pseudo-element to the _StyledButton_ definition:



```js
import styled from "styled-components";

export default styled.button`
    background-color: ${props => props.bg};
    color: ${props => props.color};
    border: none;
    border-radius: 5px;
    padding: 20px;
    font-size: 1.2rem;
    &::after{
        font-family: "icomoon";
        content: "${props => props.icon}";
        padding-left: 8px;
    }   
`
```



##Time to create a global style ⚡️

In the previous lecture, we had a glimpse on __how to create a global style__, as part of the example where we created a light/ dark theme toggler. So don't hesitate to take a look at it for further reference if needed 😀

But in case you missed it or you don't have the time to read one more article, keep reading: everything's explained ahead ✌️

First, we are going to __create our global styles file__, that will be called `IconFont.js`, and which will __host the CSS definition__ to import custom fonts. It's just plain CSS inside a _styled_ component. Nothing new 😎 And it will look like this: 

`IconFont.js`



```jsx
import { createGlobalStyle } from "styled-components";

export default createGlobalStyle`
@font-face {
   font-family: "icomoon";
   src: url("/fonts/icomoon.eot");
   src: url("/fonts/icomoon.eot?#iefix")
   format("embedded-opentype"),
   url("/fonts/icomoon.svg#icomoon") format("svg"),
   url("/fonts/icomoon.woff") format("woff"),
   url("/fonts/icomoon.ttf") format("truetype");
};
`
```


###Things to consider at this point
1. Pay attention to the __routes__ and the __filenames__: the ones you're seeing above work for the configuration that we're going to see in a minute. __You should always use the actual routes of your project and the names you provided to your font files__. Otherwise, it won't work ❌ 
It may sound obvious but sometimes it happens that we make a mistake in writing this definition and we go nuts for the rest of the day trying to figure out what's going on. Believe me, it happens more often that you may think 😝

2. In case you're using a ___theme___, you're supposed to already have a global styles file. In such case, just add the `@font-face` definition to it and you'd be set and done.

Then, __how do I have to structure my project__ to make the previous `@font-face` definition work?

First, and as mentioned before, you need to use the __actual names of your font files__ and define every possible format you have for that font (you will likely have something like _.ttf_, _.otf_, _.svg_, and/or _.woff_, but there are others, too).

And, second, and __key to this configuration__ 👉 You need to create a `fonts` directory inside the `/public` directory. 

This is necessary because __Next.js serves static files under the `/public` folder__, so since fonts are a static resource, they have to be located in there.

>Note that every resource placed in the `/public` directory should be routed using a slash `/` before its name.

###Making our global theme accessible by the app

As a final step to be able to start using our custom icon font, we just need to __import__ the `IconFont` component into our main app component, `_app.js`, like this:

`_app.jsx`



```jsx
import IconFont from '../components/IconFont';
const MyApp = ({ Component, pageProps }) => {
  return (
    <>
      <IconFont />
      <Component {...pageProps} />
    </>)
}

export default MyApp;
```


If everything goes as expected, this will be the __result__ of our _styled_ button, to which we have appended a __heart icon__:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xppa5n45y6u9iu7upda1.png)

Otherwise, __if something went wrong__ along the way, this is what we'll see:

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/36gb38hazu5y4casr6bw.png)

Getting a _square_ instead of the actual icon can mean:
- The icon font has been found but the value for the content you have provided __is not part of the list of values of that font__.
- There's a __problem with the location of the fonts__: the specified font files are not located at the route you have provided.
- Something __wasn't configured properly__.

###Older versions of Next.js
As of Next.js 11, __no extra configuration for Webpack is required__ to _translate_ font file formats. If you're using an older version, it's highly recommended that you __update__ your package version by running the following command:



```bash
npm install next@latest
```



In case you need to use an __outdated version__ for whatever reasons, keep in mind that __a little bit of further configuration__ will be required: you'll need to install the `file-loader` Webpack loader, which will handle font formats appropriately and bundle them up to include them in the final bundle that will be served to the browser, and then, you'll have to add the corresponding configuration in `next.config.js`.

___

And this is all for the third Styled Components 101 lecture! 

Stay tuned to know more about Styled Component in future episodes of the series.

A big thanks for reading  🤗  and don't hesitate to reach out to me if you any questions or doubts about today's lecture.

![Rachel Green from Friends TV Show behind a desk saying "Ask me anything"](https://media.giphy.com/media/XFuQ4InwtXBE4DDPHM/giphy.gif)

I hope you found this article useful and I see you all in the next 👋

🎉 Don't forget to follow @underscorecode on [Instagram](https://instagram.com/underscorecode) and [Twitter](https://twitter.com/underscorecode) for more daily webdev content 🖥🖤

____

####And last but not least... A quick friendly reminder before we go 😊
We all know there are million ways to get things done when it comes to programming and development, and we're here to __help and learn__, so, if you know another possible way to do what others are sharing (__not better, not worse, just different__), feel free to share it if you feel like it, but, please, __always be kind and respectful__ with the author and the rest of the community. Thank you and happy coding!

I made 50+ COLOR PALETTES for you to use in your next projects and designs 🎨

_CODE — Sat, 31 Jul 2021 17:18:27 +0000

Hi, everybody! 👋

Today, I bring you 50+ color palettes to use in your upcoming projects or to just get some inspiration out of them.

I've given every palette a name to make it easier to identify them (I've tried my best, promise 😅).

Let me know if you like this kind of content and if you'd like to see more articles like this in the future (about colors, gradients, fonts, design resources, etc). I'd be glad to hear from you in comments!

And now, let's have a look at those color schemes 👇

Package 1

Sunset in Arizona
Pink Fall Vibes
Desert Adventures
Chic Garden
Neon Lights
Pastel Cake
Acid Tangerine
Frozen Winter
Vibing Summer
Drops of Summer

Package 2

Pink Mandarin
Nomadic Dreams
Circus Acrobat
Coffee By The Sea
Strawberry Nights
Dans La Fôret
Easter Vibes
Salty Waters
Fresh Berries
Skeptical Minds

Package 3

Dry Landscape
Dark Sunset
Antartic Sun
Velvet Fall
Water Park
Origami
Nights In The City
Vintage Vineyards
Fun & Games
Aquamarina

Package 4

Cold Pastels
Sober Twilight
Sandy Cocoa
Tokyo Streets
Tireless Traveler
Candy Dreams
Roses & Wood
Downtown LA
Pumpkin Spice Latte
Honey Hearts

Package 5

Orange Muffin
Self-love
Trip to Paris
Perfect Getaway
Eclipse Solstice
Muddy Feelings
Watermelon Party
Golden Hour
Sun, Sand & Tan
Soft Skies

Bonus

Vibrant Neon
Sweet Surrender
90s Child
Pomegranate Paradise
Brown Eyed Soul

And this is all for today!

I hope you liked the article and see you all in the next 👋

🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content 🖥🖤

Styled Components 101 💅 Lecture 2: Creating a theme + Light/Dark theme toggler example ☀️🌙

_CODE — Sun, 25 Jul 2021 12:49:22 +0000

Hello, everybody! 👋
And welcome to the 2nd lecture of the Styled Components 101 series 🙌

In this lecture, we'll be covering the creation of a custom theme with Styled Components.

If you're new to Styled Components and this lecture is the first one you run into, I suggest taking a look at the previous lecture first, where we covered some basic concepts and examples of Styled Components.

With all this said, let's move on to today's topic 👇

Creating the theme file 🔮

First things first. Before start generating components and other component-related stuff, what we need to do is create the file that will host our app's theme.

This theme file will be just a regular JavaScript file with js extension that will contain an object called theme with properties and values that we'll be using to style our components.

As easy as that 💁‍♂️

Let's have a look at how this file looks like:

theme.js

const theme = {
   colors: {
      plum: "#52314b",
      rose: "#c3537d",
      dryrose: "#dd7f9a",
      primrose: "#e8babf",
      white: "#fff"
   }
}

export default theme;

For now, we'll be working only with colors, but every property/value you can imagine that is used for styling will also be set in this file: values regarding fonts, padding, margin, etc. In short, every value that you'd set up in a CSS file.

Don't forget to export your theme object. Otherwise, there's no way for it to be found by the app 👍

And that's all for the theme file. We're now set to head on to the next step 😼

Making the theme file reachable by the app 🕵️

In order for the theme file to be able to be accessed, we need to provide it to the app. To do this, we'll import the component ThemeProvider from styled-components and will wrap our app with it.

App.js

import { ThemeProvider } from "styled-components";
import theme from "./theme";

const App = () => {
   return(
      <ThemeProvider theme={theme}>
         //your code here  
      </ThemeProvider>
   )
}
export default App;

Now, our theme is recognized by the app and can be accessed and used from anywhere throughout it.

Using the theme inside a styled component 💅

Retrieving theme values from within a styled component is a really easy process, since the theme is implicit to the component props.

Let's see how to style a styled component making use of a couple values from our custom theme:

BasicThemedButton.js

import styled from "styled-components";

export default styled.button`
   background-color: ${props => props.theme.colors.primrose};
   color: ${props => props.theme.colors.white};
   font-size: 1.25rem;
   border: none;
   border-radius: 5px;
   padding: 10px;
`

Our custom theme is implicitly passed-in as a prop and it's easily accessed because the component is also wrapped by the provider:

App.js

import { ThemeProvider } from "styled-components";
import theme from "./theme";
import BasicThemedButton from "./components/BasicThemedButton";

const App = () => {
   return(
      <ThemeProvider theme={theme}>
         <BasicThemedButton>I am a basic themed button! 🤗</BasicThemedButton>  
      </ThemeProvider>
   )
}
export default App;

Using the theme inside a custom React component ⚛️

To use our theme inside a custom React component, we need to write a little bit more code, but not a big deal at all.

ThemedButton.js ≡ React component

import React, { useContext } from "react";
import StyledButton from "./StyledButton";
import { ThemeContext } from "styled-components";

const ThemedButton = () => {
   const theme = useContext(ThemeContext);
   return(
      <StyledButton bgColor={theme.colors.plum} color={theme.colors.white}>I am a themed button 😜</StyledButton>
   )
}

export default ThemedButton;

StyledButton.js ≡ Styled component

import styled from "styled-components";

export default styled.button`
   background-color: ${props => props.bgColor};
   color: ${props => props.color};
   padding: 10px;
   border: none;
   border-radius: 5px;
   font-size: 1.25rem;
`

This time, the values from the theme are passed to the styled component via props, which have been previously retrieved in the React component by making use of the useContext hook and the ThemeContext component from styled-components.

Note that we'll be calling our React component as we regularly do:

App.js

import { ThemeProvider } from "styled-components";
import theme from "./theme";
import ThemedButton from "./components/ThemedButton";

const App = () => {
   return(
      <ThemeProvider theme={theme}>
         <ThemedButton/>
      </ThemeProvider>
   )
}
export default App;

The theme prop 🤖

The theme prop is used to pass in an inline object that contains the specification for the theme to a styled component.

App.js

import { ThemeProvider } from "styled-components";
import StyledButton from "./components/StyledButton";
import theme from "./theme";

const App = () => {
   return(
      <ThemeProvider theme={theme}>
         <StyledButton theme={{bg: theme.colors.primrose, color: theme.colors.white}}>I am a button with a theme prop! 😎</StyledButton>
      </ThemeProvider>
   )
}
export default App;

StyledButton.js

import styled from "styled-components";

export default styled.button`
   background-color: ${props => props.theme.bg};
   color: ${props => props.theme.color};
   padding: 10px;
   border: none;
   border-radius: 5px;
`

This method can be useful if we don't have many properties, but, when we have a robust application with several properties and values for styling, this method becomes difficult to maintain and tricky to deal with ❌

Using JavaScript objects to write our styles rather than CSS 🤹‍♀️

Did you know that is also possible to write custom styles using JS instead of CSS in Styled Components? And it's easier than you may think.

Let's have a look at the following snippet:

JSStyledButton.js

import styled from "styled-components";

export default styled.button(props => ({
   backgroundColor: props.bgColor,
   fontSize: "1.5rem",
   color: props.color
}));

App.js

import { ThemeProvider } from "styled-components";
import theme from "./theme";
import JSStyledButton from "./components/JSStyledButton";

const App = () => {
   return(
      <ThemeProvider theme={theme}>
         <JSStyledButton bgColor={theme.colors.plum} color={theme.colors.white}>I am a JS Styled Button 🤠</JSStyledButton> 
      </ThemeProvider>
   )
}
export default App;

Notice that property names are written in camelcase notation, as we're using a JavaScript object, but it's also accepted to write them within double quotes, like this:

import styled from "styled-components";

export default styled.button(props => ({
   "background-color": props.bgColor,
   "font-size": "1.5rem",
   color: props.color
}));

Also note that the used method to specify the styles is similar to the one we use when extending styles from a supercomponent (Lecture 1 - Inheriting styles from another component section):

...
export default styled.button(...);
...

And now... 👑 The jewel in the crown: Let's create a Light/Dark theme toggler with Styled Components

Theory is cool but, but let's get our hands dirty and let's create something interesting using themes 👏

Excuse me, but... what exactly is a theme toggler? 🤔

We can say that a theme toggler is a system that allows to switch between a light and a dark theme with just one click by using a button or an emoji. Cool, right?

In this tutorial, we'll implement a styled button that will perform this task really fast and efficiently.

And now, let's get it started 👉

The components and files 🎬

These are the components and files that will make up our app:

Button.js: the button that will switch between themes.

GlobalStyles.js: a component that will inject global styles into the app.

ThemeToggler.js: the component that will receive the theme as a prop, which, in turn, will be passed in to the Button component.

useDarkTheme.js: a custom hook that will contain the business logic.

App.js: the main app. It will wrap everything up with the theme provider and will include the global styles.

themes.js: the file that will host our themes (we already know how to do this at this point 😺).

Let's first create our themes file 📝

themes.js

export const lightTheme = {
    background: '#fff',
    color: '#1d1f28',
    buttonBg: '#c5718d'
}

export const darkTheme = {
    background: '#1d1f28',
    color: '#fafafa',
    buttonBg: '#515d90'
}

Not a lot to remark here: we have defined both themes with their respective style properties. Don't forget to export them both 👍

Now let's go with the switch button 🔵

Button.js

import styled from "styled-components";

export default styled.button`
   font-family: "Monaco", monospace;
   cursor: pointer;
   border: none;
   background-color: ${({ theme }) => theme.buttonBg};
   color: #fff;
   padding: 10px;
   border-radius: 5px;
   font-size: 1.5rem;
`

A regular styled button. You can style it as you like best.

Note that the value for background-color will be set depending on the selected theme. The rest is up to you 😇

Time for global styles 😼

GlobalStyles.js

import { createGlobalStyle } from "styled-components";

export const GlobalStyles = createGlobalStyle`
   body {
     font-family: "Monaco", monospace;
     background: ${({ theme }) => theme.background};
     color: ${({ theme }) => theme.color};
     transition: all 0.50s linear; 
  }
`

GlobalStyles defines the global styles for our app. They will be injected into our app by in App.js.

Note that for this purpose, we'll import the createGlobalStyle helper from styled-components, which will create a new styled component that will handle global styles.

Regarding the properties, background and text colors will be retrieved from the theme. We'll also add a transition property to make the switch effect smoother.

Creating the theme toggler 💁

ThemeToggler.js

import React from 'react';
import Button from "./Button";

const ThemeToggler = (props) => {
   const { themeToggler } = props;
   return (
      <Button onClick={themeToggler}>Switch Theme ☀️ 🌙</Button>
   );
};

export default ThemeToggler;

ThemeToggler renders the Button component and provides it with the style properties that correspond to the passed-in theme.

useDarkTheme.js

import { useState } from 'react';

const THEMES = {
   LIGHT: "light",
   DARK: "dark"
}

const useDarkTheme = () => {
    const [theme, setTheme] = useState(THEMES.LIGHT);
    const themeToggler = () => {
        theme === THEMES.LIGHT ? setTheme(THEMES.DARK) : setTheme(THEMES.LIGHT);
    };
    return [theme, themeToggler];
};

export default useDarkTheme;

useDarkTheme is a custom hook that contains the logic for our toggler. We're using a hook to abstract our app as much as possible.

The switching procedure is as easy as follows: if the passed-in theme is light, the dark theme will be set up, and vice versa.

Building the main app 😈

App.js

import React from "react";
import { ThemeProvider } from "styled-components";
import { GlobalStyles } from "./components/GlobalStyles";
import { lightTheme, darkTheme } from "./themes";
import ThemeToggler from "./components/ThemeToggler";
import useDarkTheme from "./hooks/useDarkTheme";

const App = () => {
   const [theme, themeToggler] = 
   useDarkTheme();
   const selectedTheme = theme === 'light' ? lightTheme : darkTheme;

   return (
      <ThemeProvider theme={selectedTheme}>
         <>
            <GlobalStyles />
            <ThemeToggler themeToggler={themeToggler} />
            <p>Trying out light and dark themes! 😍</p>
         </>
      </ThemeProvider>
   )
}
export default App;

First, we're calling the useDarkTheme hook, that will handle the switch logic.

Then, we also need to have a function selectedTheme, that decides which theme is going to be used.

And now, what's only left is to wrap up ThemeToggler with ThemeProvider and include GlobalStyles.

The result ☀️ ➡️ 🌙

And this is all for the second Styled Components 101 lecture!

Stay tuned to know more about Styled Component in future episodes of the series.

A big thanks for reading 🤗 and don't hesitate to reach out to me if you any questions or doubts about today's lecture.

I hope you found this article useful and I see you all in the next 👋

👉 You can also check out the related slides for this article on Instagram 👈

🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content 🖥🖤

And last but not least... A quick friendly reminder before we go 😊

Styled Components 101 💅 Lecture 1: Introduction + Setup in a React Environment ⚛️

_CODE — Wed, 14 Jul 2021 13:36:15 +0000

Hello, everybody! 👋
And welcome to the first lecture of the Styled Components 101 series.

In this series, we will be thoroughly covering different topics related with Styled Components.

Still don't know what Styled Components are? It seems like you're in luck because we start with the first lesson right now! 👇

What are Styled Components? 💅

Styled Components is a modern tool used to generate components out of the most basic HTML elements, which also allows you to write your custom CSS styles for them in JavaScript by making use of the tagged template literals feature.

Styled Components gets rid of the mapping between components and styles, so, when declaring your CSS, what you're actually doing is creating a regular React component that has its own styles attached.

Installation 🖥

If you use npm:

npm install styled-components

If you use yarn:

yarn add styled-components

Getting Styled Components ready to work with React ⚛️

This is the best part: no extra configuration is needed to start using Styled Components with React. In next lectures, we'll see how to configure Styled Components to get it to work with frameworks like Next.js and how to integrate them with SSR (Server Side Rendering). But, for now, everything's ready on React side. Keep tuned to this series of Styled Components if you want to learn further 😺

Creating our first styled component 🐣

There are a couple ways to define a styled component. Personally, my favorite is to keep the component independent, defined in its own file, as we regularly do with React components. But, although conceptually speaking, this is the best way of keeping an app properly modularized and making a good use of abstraction, the approach of declaring a styled component within another component is widely extended as well. Not my favorite, but also valid.

Our first styled component will be a Button. Let's see how we can define it using the Styled Components syntax:

StyledButton.js

import styled from "styled-components";

export default styled.button`
   background-color: #7b4cd8;
   color: #fff;
   padding: 10px;
   border: none;
   border-radius: 5px;
   font-size: 1.25rem;
`

As you can see in the example above, we're using plain CSS syntax inside of backticks to make our styles understandable to JavaScript.

And then, we just have to import our component wherever we want it to be rendered:

import StyledButton from "./components/StyledButton";

const MyApp = () => {
   ...
   return(
      <StyledButton>I am a styled button! 😼</StyledButton>
   )
   ...
}

export default MyApp;

Our first styled button will look like this:

Styling our component through props 💁‍♂️

In the previous example, all the styles have been predefined by us and every rendered StyledButton will have the exact same appearance.

But, can we render the same type of component multiple times to create different components and apply different styles to them? The answer is yes and what we're going to do to get this behavior is passing props with custom values to our styled button.

Let's say we want to have three buttons with different background and text colors, but with the same padding, border radius and font size.

Then, we're going to do something like this:

StyledButtonWithProps.js

import styled from "styled-components";

export default styled.button`
   background-color: ${props => props.bg};
   color: ${props => props.color};
   padding: 10px;
   border: none;
   border-radius: 5px;
   font-size: 1.25rem;
`

Let's now call our three buttons:

import StyledButtonWithProps from "./components/StyledButtonWithProps";

const MyApp = () => {
   ...
   return(
      <StyledButtonWithProps bg="#ffc3c3" color="#b6201e">Button 🍓</StyledButtonWithProps>
      <StyledButtonWithProps bg="#ffdaca" color="#d85d16">Button 🍑</StyledButtonWithProps>
      <StyledButtonWithProps bg="#fff4c7" color="#bb9922">Button 🍋</StyledButtonWithProps>
   )
   ...
}

export default MyApp;

And this is the result:

Styling our component conditionally 💁

Let's now have a look at how we can style our button component by adding some conditions.

This time, let's say we want to have a different background color for our button depending on its type value, which will be passed in to the component through the prop buttonType.

Then we should do the following:

StyledButton.js

import styled from "styled-components";

export default styled.button`
   ${props => props.buttonType && props.buttonType==="primary" ?
   `background-color: #7b4cd8; color: #fff; font-size: 1.25rem;` :
   `background-color: #ff31ca; color: #ffe6f9; font-size: 0.95rem;`};
   padding: 10px;
   border: none;
   border-radius: 5px;
`

If the prop buttonType exists and has a value of primary, then the component will get the first set of style properties. Otherwise, the second.

Note that the style properties defined outside the condition block, remain the same for all components.

Let's now call our buttons:

import StyledButton from "./components/StyledButton";

const MyApp = () => {
   ...
   return(
      <StyledButton buttonType="primary">I am a Primary Button! 👆</StyledButton>
      <StyledButton>I am a different kind of button! 👇</StyledButton>
   )
   ...
}

export default MyApp;

And there we are:

Inheriting styles from another component 👨‍👧‍👦

Even though the aforementioned method of passing style properties by using component props works well in every scenario, if our app starts to grow, we can find the process of creating components tedious and repetitive.

And now's when constructors come to rescue: we can have a supercomponent (like a superclass, making reference to inheritance in OOP 🤓), whose styles can be inherited by other components.

This means that every children component that inherits from the supercomponent will have the supercomponent styles in addition to its own custom styles.

Let's see how we can connect them:

SuperButton.js

import styled from "styled-components";

export default styled.button`
   color: #fff;
   width: 200px;
   height: 50px;
   border: none;
   border-radius: 5px;
   font-size: 1.25rem;
`

ChildrenButton.js

import styled from "styled-components";
import SuperButton from "./SuperButton";

export default styled(SuperButton)`
   background-color: ${props => props.bg};
`

Let's now call them all:

import ChildrenButton from "./components/ChildrenButton";

const MyApp = () => {
   ...
   return(
      <ChildrenButton bg="deeppink">Hello! 👋 </ChildrenButton>
      <ChildrenButton bg="hotpink">Hello! 👋 </ChildrenButton>
      <ChildrenButton bg="coral">Hello! 👋 </ChildrenButton>
   )
   ...
}

export default MyApp;

And this is the result:

Can I use CSS preprocessors like SASS or LESS to write my styles instead of plain CSS?

Not really. But you can still make use of their most common features.

Styled Components is based on the paradigm CSS-in-JS, so, technically, we need to use plain CSS to define them. However, we can kinda emulate the behavior of a preprocessor: Styled Components allows us to define variables and nest selectors, for example.

The following snippet would be far correct in Styled Components:

StyledDiv.js

import styled from "styled-components";

export default styled.div`
   p{
      font-family: 'Arial', sans-serif;
      font-size: 1.5rem;
      color: deeppink;
      &.primary{
         font-weight: bold;
      }
   }
`

And by calling it like this...

import StyledDiv from "./components/StyledDiv";

const MyApp = () => {
   ...
   return(
      <StyledDiv>
         <p className="primary">Hello from a Styled Div!</p>
      </StyledDiv>
   )
   ...
}

export default MyApp;

...this is what we get:

This behavior is doable because Styled Components uses a preprocessor, called stylis, under the hood, so it supports scss-like syntax, which is really cool for nesting and using pseudo-elements and pseudo-classes out of the box.

So, that means I can also add a nested pseudo-element to my styled component, right? 🤔

Absolutely yes.

This time, we're going to define a <p> element to append some content to it. Let's take a step further and let's add that content based on a condition.

StyledP.js

import styled from "styled-components";

export default styled.p`
   {$props => props.before ? `
   color: #7b4cd8;
   &::before {
      content: "${props.before}";
   }` : 
   `color: #ff31ca;`
   }
`

import StyledP from "./components/StyledP";

const MyApp = () => {
   ...
   return(
      <StyledP before="_">CODE</StyledP>
      <StyledP>I don't have a ::before 😢</StyledP>
   )
   ...
}

export default MyApp;

Et voilà:

If a prop called before is found, its value will be appended in front of the <p> element and the component will receive the specified text color. Otherwise, since the condition would never be satisfied, the only style property the component would get would be the color.

And this is all for this first Styled Components 101 lecture!

In next episodes, we'll keep delving into all the amazing features of Styled Components and how we can integrate them into our projects.

I hope you found this article useful and I see you all in the next 👋

🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content 🖥🖤

And last but not least... A quick friendly reminder before we go 😊

JavaScript Bundlers: An in-depth comparative 👍👎 Is Webpack still the best bundler in 2021? 📦

_CODE — Fri, 09 Jul 2021 15:15:54 +0000

Hello, everybody! 🚀

For the last few days, I've been doing some research on the currently available JavaScript bundlers to try to draw my own conclusions about them and figure out which one would be more appropriate for my projects. And, of course, to find out if it's all about popularity and we developers are overrating some of them and underrating the others 😇

Since the only bundler I've been working with for the last few years is Webpack, I decided to take a look at npm trends to find out which the most popular JS bundlers are in 2021 and give them a try.

And this is what I got:

So today, we'll be making a comparison between the 5 most popular bundlers according to npm trends: Webpack, Rollup, Browserify, ESbuild and Parcel.

In this comparative, we will create a really basic scenario for each of them with a couple of the most used resources/tools these days, and we'll be talking about their pros and cons and comparing them all based on a few parameters.

First things first. What is a bundler? 🤔

A bundler is a tool that puts together all your JavaScript code and its dependencies and throws a new JavaScript output file with everything merged, ready for the web, commonly known as the bundle file.

These bundlers can work with other types of files as well apart from JavaScript, but they need a little help to perform their bundles. We'll talk about this more in depth in each of the examples below.

None of them require a config file, what perfectly works for the most basic bundle. This means you have a .js file converted into another .js file with minimal setup. But, once you start having more and more kinds of files that need to be transpiled and, consequently, configured, it's time to add a config file because, otherwise, you'll find yourself immersed in chaos 😰

The scenario 🖥

To try out these bundlers, we don't need a specific complex structure for our project, so let's propose a really basic scenario: an HTML file, with some styles (we'll slightly complicate it by using a preprocessor like SASS) and ready to use ES6, which means we will include Babel even though we're not using React, Vue or any library/framework that rely on it in this comparative. But let's get it setup anyway.



/dist
   bundle.js
   [styles.css]
/src
   index.js
/styles
   styles.scss
index.html
package.json
[*.config.js]

/dist will be the folder created after the bundle process and will contain all the bundled files. The bundled file for the styles is optional because we can choose either to inject the styles directly in the HTML or generate a new transpiled file containing the styles.

/src is the folder containing the entry point from which the bundler will start the bundle process.

/styles is the folder containing the original styles file, before the bundle.

index.html is the file containing what we'll see in the browser.

package.json is the file where all the dependencies, scripts and some configurations are stored.

*.config.js is the file where all the config for the bundler is defined. This file is optional for every bundler in this list, but highly recommended. * will be replaced accordingly by the name of the bundler.

Having said all this, let's see what each of these 5 bundlers can offer us.

1. Webpack

Loved by many, hated by some, known to all. And still the most popular bundler in 2021. With more than 15 million weekly downloads (at the time of writing this post), there's no doubt that Webpack is still the bundler par excellence in 2021. But, is it the easiest to use, configure and understand how it works?

Let's have a look at how we should configure it to have it ready to work.

Approach used by Webpack

A build script
A config file
Loaders used to transform files
Plugins for more complex stuff

package.json



...
"scripts": {
   "build": "rm -rf dist && webpack --mode development"
}
...

Really really easy. There's no need to do anything else for a basic configuration. Actually, if you don't want to use a different name for your configuration file, you don't even need to specify a configuration in the build script. If you want to use a different one, you should add --config your_config_file.js to the command.

Note that we'll be adding the command rm -rf dist to every build of every bundler. What this does is removing the dist folder every time a new build script is executed.

webpack.config.js



module.exports = {
   entry: "./src/index.js",
   output: {
      filename: "bundle.js",
      path: path.resolve("dist")
   },
   module: {
      rules: [
         {
            test: /\.(js|jsx)$/,
            exclude: "/node-modules/",
            use: "babel-loader"

         },
         {
            test: /\.html$/,
            use: "html-loader"
         },
         {
            test: /\.(scss|sass)$/,
            use: ["style-loader", "css-loader", "sass-loader"]
         }
      ]
   }

}

Maybe a little bit more tricky and difficult to understand at first than the other bundlers, but really easy once you get the sense of how everything works together.

What is happening in this config file? 🙃

Well, first, we need an entry point for our bundler to start merging everything. That is specified in the entry attribute and the file will be our file index.js in the folder src.

Same for the output file, we'll tell Webpack our file will be called bundle.js and it should be stored in the folder dist.

And now, what's only left is to handle the files that are not JavaScript (ES5). Webpack takes care of these files using loaders. To transform these files, we just need to indicate the file format and which loader(s) will deal with them.

So that's what we need: a few loaders to take care of our styles, our HTML and our JS (ES6 - remember that we're getting it ready for formats like .jsx): style-loader, css-loader and sass-loader for the styles, html-loader for the HTML files and babel-loader for ES6.

Notice that we're also transforming the HTML file (this loader will be useful if we want to add resources that are loaded directly in the HTML file, such as images). This loader is really useful in bigger projects, but not necessary in this case (due to its simple structure), we'll skip this step for the rest of the bundlers.

And this is it. Everything will be bundled once we run the build command.

About the bundle

Since we're using style-loader to bundle the styles, instead of a plugin to minify CSS and generate a new file (MiniCSSExtractPlugin), the styles are injected into the HTML file inside a <script> tag, so the only output file is bundle.js, which needs to be added to index.html.

What do I think about Webpack? 👇

I have to admit that first time I had to face Webpack I thought the configuration would be impossible. It was my first time using a bundler and I was barely able to understand the overall concept. Let alone all the loaders and more complex related stuff because it was a bigger project.

But after a few from-scratch configurations on my part, I have to say that now I find it more intuitive and easier to set up if I compare it to what it felt like to get to know the rest of them.

Let's take a look at the others and you'll understand why!

2. Rollup

Let's now turn our attention to Rollup. As well as the rest of the loaders, this has been my first time trying it out, so I'll also provide my first impressions about it 🤓

Approach used by Rollup

A build command.
An optional config file.
Plugins used to transform files

package.json

Basic bundle with no config file:



...
"scripts": {
   "build": "rm -rf dist && rollup src/index.js --file dist/bundle.js"
}
...

Using a config file:



...
"scripts": {
   "build": "rm -rf dist && rollup -c"
}
...

A really easy command for building, as well, so nothing else to point out here.

Let's now check the config file, that is optional but recommended.

rollup.config.js



import babel from "@rollup/plugin-babel";
import scss from "rollup-plugin-scss";

export default {
   input: "./src/index.js",
   output: {
      file: "./dist/bundle.js",
      format: "cjs",
   },
   plugins: [
      babel({ exclude: "node_modules/**" }),
      scss({ output: "styles.css" }),
   ]
}

What Webpack defines as loaders, here in Rollup are called just plugins. This time we just need a couple of them: the one for transpiling ES6 into ES5 (Babel) and the one for SCSS: @rollup/plugin-babel and rollup-plugin-scss.

These plugins have also their own optional configuration. In this case, for Babel, we're excluding the folder node_modules and for SCSS we're giving the output file a different name. Otherwise, it will remain output.css.

For configurations with plain CSS, there's a plugin called rollup-plugin-css-only that works in the exact same way as the plugin we're using for SCSS.

Note that we need to specify the entry and the output points exactly as we did before with Webpack.

And that would be it.

About the bundle

The Rollup bundle comprises two files: bundle.js and styles.css. It's necessary to import the original styles files in the entry point index.js for the bundler to be able to find the file (there's no other place where we can reference it).

Also both bundles need to be added to the HTML index file.

My first impressions about Rollup 👇

To be honest, I wasn't expecting much of these other easier slash light-weight bundlers since Webpack has always worked for me, and I have to say that Rollup has surprised me in a good way.

I find it pretty similar with Webpack (config file with almost the same structure, plugins work in the same way as loaders to translate no-js files, the easy build command...), which means familiarity, usage recall and, consequently, ease of use.

The only drawback I've been able to find so far is the large number of dependencies it relies on, and consequently, the huge size of the project (3x a project bundled with Webpack). We'll be focusing on this more in depth at the end of the post 🔜

3. Browserify

Let's now talk about Browserify.

Approach used by Browserify

No config file
Transforms used to transform files
Everything you need to configure -> package.json

The method used by Browserify has nothing to do with the traditional approach of a build command and a config file. With this bundler, every possible configuration is allocated in package.json and the build command can get a little bit tedious if we don't have the concepts clear.

It also needs plugins (or transforms, as they are also called) to transform everything into something readable by the browser.

Let's have a glance at how we can configure it:

package.json



...
"scripts": {
   "build": "rm -rf dist && browserify -o dist/bundle.js src/index.js"
}
...

A very basic use of this bundler could be something like the code snippet above. We only have defined the input and output files (no configuration for styles or anything more complex).

Note the length of the build command having only declared the input source and the output.

Let me show you how it would look like if we add the suitable plugin for handling plain CSS.



...
"scripts": {
   "build": "rm -rf dist && browserify -t [browserify-css --output dist/styles.css] -o dist/bundle.js src/index.js"
}
...

Then, if we wanted to add some configuration to the plugin, we would do something like the following down below in the same file:



...
"browserify": {
   "browserify-css": {
      "autoInject": true,
      "minify": true,
      "rootDir": "."
   }
}
...

It starts getting not that maintainable.

And now, let's complicate it a little bit more by adding plugins for SCSS and Babel. We need a couple of plugins called Babelify and scssify.

Something to take into account

I've been trying out this bundler with the last released version of Node (v16.4.2) and the command line throws multiple errors when trying to install any dependencies that rely on node-sass (scssify and sassify, more specifically). A very negative point.

We could do this in two different ways:

By saturating the build script with more content 😅
By adding a transform property

Via the build script

For specifying several transforms in the build script using Browserify, we should add as many as -t [ transform options ] as needed, like this:



...
"scripts": {
   "build": "rm -rf dist && browserify -t [ scssify --output dist/styles.css ] -t [ babelify --presets [ @babel/preset-env ] ] -o dist/bundle.js src/index.js"
}
...

If you're using this method, pay close attention to the white spaces inside the arrays. They matter ✌️

I find this method tedious and difficult to understand, and above all, difficult to maintain. And we're only using two plugins. All said.

Via the transform property



...
"browserify": {
    "transform": [
      [ "babelify", {
            "presets": [
               "@babel/preset-env"
            ]
        }
      ],
      [ "scssify", { "autoInject": true } ]
    ]
  }
...

By using this method, the build script will look like it was originally, when it just performed the simple bundle of the input js file:



...
"scripts": {
   "build": "rm -rf dist && browserify -o dist/bundle.js src/index.js"
}
...

Much better 😊

About the bundle

The Browserify bundle consists of the bundle.js file and, only if we set an output file for the styles in the plugin that takes care of them, we'll get a styles.css file. Otherwise, the styles will be injected at the bottom of the <head> element in the HTML file inside a <script> element.

Take a look at this two different config examples for browserify-css:



...
[ "browserify-css", {
      "autoInject": false,
      "minify": true,
      "rootDir": ".",
      "output": "dist/styles.css"
   }
]
...

This config above will create a separate .css file.



...
[ "browserify-css", {
      "autoInject": true,
      "minify": true,
      "rootDir": "."
   }
]
...

And this other config will inject the code into a <script> tag in the head of index.html.

My first impressions about Browserify 👇

My less favorite so far. I don't find it as intuitive as the other two, and the approach it uses is totally different from what we are regularly used to. Also, I think the configuration is more tedious if at first you don't know how and where to handle the required plugins.

Also, blank spaces matter, and if you don't know that beforehand, you can perfectly spend 2 hours trying to figure out what's wrong with your code 👎

4. ESBuild

Time to talk about ESBuild.

Approach used by ESBuild

A build command (encourages the use of the terminal)
An optional config file
Plugins used to transform files

With ESBuild you can use either the command line or a config file as well as the others, even for more complex configurations. It's totally up to you, but specifying a config file is always recommended for maintainability, scalability, readability and productivity reasons.

We're going to create a config file called esbuild.config.js and we'll execute it from the build script by running the command node.

But first, let's have a look at the simplest way to start bundling our files with ESBuild (no config file is required this time):

package.json



...
"scripts": {
   "build": "rm -rf dist && esbuild --bundle src/index.js --outfile=dist/bundle.js"
}
...

As usual, we declare the entry point and the output file. And that's it. But what happens when we need to keep bundling more different kind of files?

Let's then take a look at the following example:



...
"scripts": {
   "build": "rm -rf dist && esbuild --bundle src/index.js --outfile=dist/bundle.js && esbuild --bundle styles/styles.css --outfile=dist/bundle.css"
}
...

We are now bundling the styles as well, and adding a little more information to the build script (mess alert again!) by defining two different bundlers. We could (and definitely will) have more filetypes that would need to get bundled and this could become a total mess.

So, let's put aside this approach and let's create a config file.

esbuild.config.js



import esbuild from 'esbuild';
import { sassPlugin } from "esbuild-sass-plugin";
import babel from 'esbuild-plugin-babel';

esbuild.build({
   entryPoints: ['src/index.js'],
   bundle: true,
   outfile: 'dist/bundle.js',
   plugins: [sassPlugin(), babel()],
}).catch(() => process.exit(1));

And here comes what I found (let me say) weird and what took me some time to figure out.

Maybe because I was expecting to run this config file in the same way as Webpack and Rollup do (they run their config file by default if it exists and has the default name), I had some trouble trying to tell ESBuild to take it as an input for configuration.

Finally, I realized that it should be called via the node command to just run the script 😬



"scripts": {
   "build": "rm -rf dist && node esbuild.config.js"
}

And that was all.

Something I want to mention here is that, the fact that there aren't so many plugins from where to pick and also most of them are way outdated, doesn't make me particularly happy. And, if you allow me some advice, try to pick plugins which use either CommonJS (which inserts modules through require) or ES Modules (which does the same using import), because if you mix them up... the only things you'll get will be errors and mess everywhere! 😖

Just make sure you change the type attribute in package.json if you're using ES Modules (import) to load your plugins into the config file:



...
"type": "module"
...

Practically all plugins have been created by the community (if not all). For this example, I've chosen esbuild-sass-plugin for SASS/SCSS and esbuild-plugin-babel for Babel. Both of them work with import, so no extra problems.

A great point to mention: ESBuild is really fast compared with the others. At least in this scenario.

My first impressions about ESBuild 👇

Mixed emotions. At first, I thought it would be very easy to configure (it is if you only intend to perform a regular bundle) but then I started to struggle a bit with the config file, not because of the syntax but because of the multiple errors thrown on the terminal regarding Node.

5. Parcel

Let's now have a look at the last bundler in this list: the famous Parcel. Hi to the huge community of Parcel fans out there 👋

Approach used by Parcel

The Parcel approach is mainly based on a zero configuration environment 😱 I was reluctant to believe it at first (that's the main reason why I wanted to try it out so bad), but, yes, it's possible to bundle a project like the one we're testing in this post by writing the bare minimum configuration, in a few minutes and without racking your brains 🙌

Zero configuration? Are you sure? 😪

By zero they mean very little and precise. Let me show you the configuration I used for this basic project:

package.json



...
"scripts": {
   "build": "rm -rf dist && rm -rf  && parcel build src/index.js --no-scope-hoist --no-source-maps"
}
...

The procedure is pretty much the same: we need to indicate where the entry point for our app is located. And I also added the flags --no-scope-hoist to avoid odd behaviors regarding require when running js scripts and --no-source-maps to avoid the creation of sourcemaps. Otherwise, Parcel will create one for every bundle file by default.

Now, if we want to change the location and the name of the output bundle file, we need to change the value of the main property attribute in package.json, like this:



...
"main": "dist/bundle.js"
...

Otherwise, the bundle will be generated at root level and will be called with the name that is stored in main, in most cases index.js (if we didn't change it when running npm init).

Now, let's (zero)configure the styles and Babel

Since we're using SCSS, we need to use SASS as a preprocessor. So, what was my surprise when I read that SASS is already included with Parcel installation. But not only SASS, also LESS, Stylus, and... Babel! 😧

So the only step to take here is to create a couple of config files for SASS and Babel.

Our SASS config file will be named .sassrc and will contain the following code inside:



{
  "includePaths": ["node_modules"]
}

And when we run the build command, Parcel will automatically install the plugin @parcel/transformer-sass as a dependency and will create a bundle.css file in the same specified directory for the bundle, and that's all the configuration. Pretty cool, right?

Now don't forget to link this file to your HTML 🤗 And remember that your .scss file should has been previously imported on your entry point file in order for the bundler to know what file it has to transform.

On Babel side, we need to create a .babelrcconfig file to specify the needed presets (let's say we want to get it ready for using React in the future):



{
   "presets": ["@babel/preset-env", "@babel/preset-react"]
}

Parcel will automatically call @parcel/transformer-babel and will do the job for us.

Don't forget to previously install @babel/preset-env, @babel/preset-react and all the dependencies needed by React.

And that's... it. We're all set and ready to rock 😁

My first impressions about Parcel 👇

The first thing I want to point out is that Parcel wasn't that easy for me at the beginning since I had a really (really) hard time trying to get it ready to work, and it seemed like it wouldn't stop throwing errors regarding the OS and creating more trouble out of outdated versions of some dependencies 😥 So, to be honest, Parcel wasn't going to be in this list because I didn't want to talk about it if I couldn't try it out myself.

But, magically ✨ (and due to my tireless perseverance 😅), I finally could make it and set everything up to get it ready 🙌

And after that, it was really easy compared to the rest of the bundlers. So let's draw a veil over the setbacks and let's give it a chance.

Parcel is also pretty fast, because it uses cache.

But... something I don't like at all is the several security vulnerabilities that appear after installing it (around 12, some of them high risk) 😖 That doesn't speak well of you, Parcel. Not to mention the huge size of the project. The heaviest in this comparative.

The comparison 📈

Here you have the highlights of this comparative summed up in a table:

What is my final verdict? 😼

Well, I think some of these other bundlers apart from Webpack can be cool to use for small or side projects, but in reality, I personally think that Webpack is still the best option for robust projects (we just have to look at the huge number of downloads per week compared to the rest).

Also, I find it the easiest to manage since once you get the sense of how it deals with configuration, it's easier to keep adding values to that configuration. But it's not something that obvious. You have to take your time playing with it to get a very basic idea at first.

Moreover, you have the majority of resources you need (loaders, plugins...) available from the creators, so you make sure you're using a real source of truth. And they are updated really frequently, so you can use it without worry with newer versions of Node and other packages.

So, yes, I will keep choosing Webpack as my first option over the others.

My second choice would be Rollup for sure, and I truly think I will definitely use it in some of my side projects since I found it intuitive to configure and it seems like it works properly on robust projects as well.

And about their plugins, most of them are also available from the creators, so, again, a real source of truth and many more advantages.

I also think Parcel is a very interesting option and I'd like to try it with larger projects and check if it really doesn't need further configuration. Definitely a great find.

And a big plus to the fact that plugins like Babel, SASS, LESS and some more are built-in and ready to use out of the box.

What about Browserify and ESBuild?

These two have been the ones with which I have struggled more, especially Browserify. The fact that it doesn't require a config file and everything should be declared in package.json kinda forces you to change the way you think of how bundlers are traditionally configured. Not to mention you end up saturating the file with way a lot tricky configurations, which makes it difficult to read and maintain.

Also, when it comes to plugins, most of them are not developed and maintained by the creators (especially the most common) and are really outdated (many of them haven't been updated in the last 4 years) and this fact leads to problems with newer Node/other packages versions and compatibility in general.

And on ESBuild side, I didn't especially like it either. The first impression was good but then, since the config file caused me some trouble, it mainly ended up in confusion about how to manage configuration with and without this file. So I found it quite ambiguous and took me a bit to realize how to set up both scenarios in different ways.

About their plugins, same as Browserify, practically all of them has been created by the community, not the author, so you have to use them at your own risk. But as a plus point, they are often updated and maintained.

Now it's your turn! 🔥

What do you think of this comparative? Do you agree? Which one is your preferred bundler? Do you know some other bundler that is not on the list? Would you like to suggest different bundlers for future comparative posts? Comment below!

Disclaimer 👇

Remember this is just a post showing my impressions about something I tried for the first time. I have decided to share the process with you and my opinion about what I experienced. The opinions expressed in this post don't mean that some bundlers are better over others. My advice is to try them all out and draw your own conclusions, like I did. And based on that, use the ones you like best and fit your needs.

🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content 🖥🖤

And last but not least... A quick friendly reminder before we go 😊

Let's create an iOS Calculator Clone in React [+ detailed explanations]

_CODE — Sat, 03 Jul 2021 15:36:25 +0000

Hello everybody! 🚀

Today we will be creating an iOS calculator clone using React.

This tutorial comprises 3 parts: the components structure, the calculator's interface and the functionality.

Let's dive into it and start by creating the components and their structures.

1. The components

Since we're using a component-based approach, we're going to try to modularize our app as much as we can, so with that vision in mind, we'll split it up into 4 components, namely, the following:

· Calculator.js

This will be the main component. The one who will hold all the logic and functionality, and will interact with the rest of the component through props.

· Display.js

The screen of the calculator. It will receive a value that will be displayed on screen.

· Keypad.js

The keypad of the calculator. It will be divided into a few sections, depending on the functionality of every specific set of buttons.

· Button.js

A reusable component for every button in the calculator.

Now that we've learned about the components we're going to work with, let's turn our attention to the structure of each of them.

1.1. Calculator.js

The parent component, which will be in charge of all the functionality and the one managing the state of the whole calculator app.



import React, { useEffect, useState } from "react";
import Display from "./Display";
import Keypad from "./Keypad";

const Calculator = () => {
  ...
  return (
    <div id="calculator-view" className={"flex column jc-center ai-center"}>
      <div id="viewport" className={"flex column jc-sp-between ai-center"}>
        <Display value={screenValue} />
        <Keypad actionToPerform={handleActionToPerform} allClear={isScreenClear} />
      </div>
    </div >
  )
}

This main component is going to call a couple of different custom components: Display and Keypad, so they need to be imported up above.

Note that the ellipsis (...) in this code snippet means that we'll be injecting some state and functionality for the component soon later.

For now, let's just focus on the structure of the components themselves.

1.2. Display.js

A very simple component that just receives a value and shows it on screen, as mentioned earlier above.



import React from "react";

const Display = (props) => {
   const { value } = props;
   return (
      <div id="display" className="flex">
         <input type="text" tabIndex="-1" value={value} />
      </div>
   )
}

export default Display;

1.3. Keypad.js

Keypad is a component whose function is to serve as a gateway between the calculator and the buttons.



import React from "react";
import Button from "./Button";
const Keypad = (props) => {
   const { actionToPerform, allClear } = props;
   ...
   const handleClickButton = (value, keyType) => {
      actionToPerform(value, keyType);
   }
   return(
      <div id="keypad" className="flex row jc-sp-around">
         <div className="grid">
            {functionKeys.map(
                    functionKey =>
                        <Button key={functionKey.label} label={functionKey.label} value={functionKey.value}
                            buttonStyle="fx-key" onClick={handleClickButton} type="fx" />
             )}
            {numericKeys.map(
                    numericKey =>
                        <Button key={numericKey} label={numericKey} value={numericKey}
                            buttonStyle="numeric-key" onClick={handleClickButton} type="numeric" />
             )}
            {lastRowKeys.map(
                    lastRowKey =>
                        <Button key={lastRowKey.label} label={lastRowKey.label} value={lastRowKey.value}
                            buttonStyle={lastRowKey.buttonStyle} onClick={handleClickButton} type={lastRowKey.type} />
             )} 
         </div>
         <div className="flex column jc-sp-btw">
            {operatorKeys.map(
                    operatorKey =>
                        <Button key={operatorKey.label} label={operatorKey.label} value={operatorKey.value}
                            buttonStyle="op-key" onClick={handleClickButton} type="operator" />
             )}
         </div>
      </div>      
   )
}

export default Keypad;

This component contains a bunch of buttons (don't forget to import the Button component 🙂), which when pressed, send back some information about their functionality and type. The keypad, in turn, will send this data to the Calculator component.

Since it's a good practice to abstract your data as much as you can (always in a moderate way), we'll be using arrays to define every set of buttons instead of defining a button component every time we need to create one. This is useful for many reasons.

One of them, among others: Let's say that you wish to change the name of the Button component to Key. If you're calling the component 10 times, you'd have to change the name of the component 10 times. However, if you map through an array that creates a Button component in every iteration, you'd just have to make the change once.

Let's have a look at how these arrays are defined and structured:



const numericKeys = [7, 8, 9, 4, 5, 6, 1, 2, 3];

const operatorKeys = [
   { label: "÷", value: "/" },
   { label: "×", value: "x" },
   { label: "-", value: "-" },
   { label: "+", value: "+" },
   { label: "=", value: "=" }
];

const functionKeys = [
   { label: allClear ? "AC" : "C", value: allClear ? "AC" : "C" },
   { label: "±", value: "+/-" },
   { label: "%", value: "%" }
];

const lastRowKeys = [
   { label: "0", value: "0", type: "numeric", buttonStyle: "numeric-key special" },
   { label: "·", value: ".", type: "fx", buttonStyle: "numeric-key" }
];

For numeric keys, we just have an array of integers, ordered by the order of occurrence of each of them.

For operator and function keys, we have an array of objects, each of them containing a label and a value.

For last row keys (they receive this name because they appear at the bottom but have different functionalities as to organize them based on that), we have as well an array of objects, each of them comprising a label, a value, a type and a buttonStyle.

1.4. Button.js

A reusable component to define buttons.



import React from "react";

const Button = (props) => {
    const { value, type, buttonStyle, label, onClick } = props;

    const handleButtonClick = () => {
        onClick(value, type);
    }
    return (
        <button name={value} className={buttonStyle} onClick={handleButtonClick}>
            {label}
        </button>
    );
};

export default Button;

This component just renders a regular HTML button element.

2. The interface

In this tutorial, we're cloning an existent app, so our replica should be the most faithful possible to the original interface.

For styling the interface, we'll be using SCSS. But of course you can use whichever styling language / tool / resource of your choice: CSS, SASS, LESS, PostCSS, Styled Components...

Here's the code:



//color variables
$white: #fff;
$black: #000;
$dark-gray: #333;
$medium-gray: #444;
$gray: #a5a5a5;
$light-gray: #c4c4c4;
$orange: #ff9d20;
$light-orange: #ffb657;

* {
    font-family: "Source Sans Pro", sans-serif;
    font-weight: 200;
    color: $white;
}

.flex {
    display: flex;
}

.row {
    flex-flow: row nowrap;
}

.column {
    flex-flow: column wrap;
}

.flex-end {
    justify-content: flex-end;
}

.jc-sp-btw {
    justify-content: space-between;
}

.jc-sp-around {
    justify-content: space-around;
}

.jc-center {
    justify-content: center;
}

.ai-center {
    align-items: center;
}

.grid {
    display: grid;
    grid-template-columns: repeat(3, auto);
    gap: 9px; 
}

#calculator-view {
   width: 385px;
   height: 775px;
   background-color: $black;
   border-radius: 70px;
   border: 10px solid $dark-gray;
   #viewport {
      width: 90%;
      height: 70%;
      #display {
         width: 100%;
         input {
            border: none;
            outline: none;
            font-size: 6rem;
            background-color: $black;
            width: 100%;
            text-align: right;
            padding-right: 20px;
         }
      }
      #keypad {
         width: 97%;
         button {
            border: none;
            border-radius: 50px;
            width: 75px;
            height: 75px;
            font-size: 2rem;
            cursor: pointer;
            &.fx-key {
               background-color: $gray;
               color: $black;
               &:hover {
                  background-color: $light-gray;
               }
            }
            &.numeric-key {
               background-color: $dark-gray;
               &:hover {
                  background-color: $medium-gray;
               }
            }
            &.op-key {
               background-color: $orange;
               font-size: 3rem;
               &:hover {
                  background-color: $light-orange;
               }
            }
            &.special {
               width: 100%;
               grid-column-start: 1;
               grid-column-end: span 2;
               text-align: left;
               padding-left: 25px;
            }
         }
      }
   }
}

There's not really much to explain here. We're just simulating the interface of the iOS calculator and this snippet of code would be it! 😇

3. The functionality

Let's start by defining the overall state for the calculator (specified and managed in the calculator component).



const Calculator = () => {
   const [accValue, setAccValue] = useState(null);
   const [screenValue, setScreenValue] = useState("0");
   const [currentOperator, setCurrentOperator] = useState(null);
   const [expectsOperand, setExpectsOperand] = useState(false);
   ...
}

export default Calculator;

What's the main idea in here?

Well, we need to divide our component state into four chunks (the minimum required for our calculator to behave as a calculator):

accValue: the accumulated value in the calculator. It starts off as null because there's no accumulated value initially.
screenValue: the value that is going to be shown on screen. Initially, its value is "0". Note that we're defining it as a string, not a number. We'll talk about this later.
currentOperator: the ongoing operator. As well as accValue, it starts off as null for the same reason.
expectsOperand: a boolean that lets the calculator know if a new operand should be entered after pressing a button or if, on the contrary, a result, which is final itself, has been already calculated.
It will become true when an operator key is pressed, and false otherwise (only operations wait for a second operand. Neither numbers nor functions that apply to a single operand). It starts off as false, since the initial state itself is stable.

Let's now take a look at the different types of functionality that our calculator will implement and their associated keys/buttons.

But first, let me show you the handler that will be called every time a key (Button component) is pressed. It receives the value of the key and the key type (function, numeric or operator) as parameters. The handler itself will call a different function depending on the value of keyType:



const handleActionToPerform = (value, keyType) => {
   switch (keyType) {
      case "fx": handleClickFunctionKey(value); break;
      case "numeric": handleClickNumericKey(value); break;
      case "operator": handleClickOperator(value); break;
   }
}

3.1. Function keys

The function keys are those who implement a function over a single operand or functions related to the screen.

This is what happens when we click on a function button:



const handleClickFunctionKey = value => {
   switch (value) {
      case "AC": allClear(); break;
      case "C": clearScreen(); break;
      case "+/-": reverseSign(); break;
      case "%": percentage(); break;
      case ".": addDecimalPoint(); break;
   };
 }

We have implemented a switch statement that decides which function is executed next based on the passed in value.

The few different function keys in our calculator implement the following actions:

3.1.1. All clear and clear screen functions: AC/C

The allClear function (AC) clears everything and resets every value to their initial state.



const allClear = () => {
   setAccValue(null);
   setScreenValue("0");
   setCurrentOperator(null);
   setExpectsOperand(false);
}

The clearScreen function (C) clears the value of the current screen, but the rest of the state remains the same.



const clearScreen = () => {
   setScreenValue("0");
}

These two functions are available through the same button, so we need to have a boolean variable who manages the current state of the screen (clear or not) at all times, to be able to know which one of them should be shown as the label of the button. That's the reason why this variable is passed to the Keypad component as a prop.



const isScreenClear = screenValue === "0";

3.1.2. Reverse sign function: +/-

The reverseSign function, as its name indicates, reverses the sign of the screen value.



const reverseSign = () => {
   setScreenValue(String(-parseFloat(screenValue)));
}

String? parseFloat?

Well, it's time to mention how the data is displayed and stored in the calculator. Let's bear in mind the following fact:

What we see on screen is a value stored as a string and the values with which we operate are stored as float numbers.

You may be wondering why we don't use floats directly on the screen. The answer is because we could never see something like 0. using a float. That's only possible by using a string.

As easy as that :)

So, in this particular case, we are parsing the screen value (currently a string) into a float value, then we reverse its sign, and then we reconvert it to string to show it on screen.

3.1.3. Percentage function: %

The percentage function divides the screen value by 100.



const percentage = () => {
   setScreenValue(String(parseFloat(screenValue)/100));
};

We're applying the same method to set the new screen value (retrieve the current screen value, parse it to float, operate with it and reconvert it to string).

3.1.4. Decimal point function: .

The addDecimalPoint function adds a dot to visually transform the current screen number into a float-like number (we're actually operating with floats, but remember that the screen value is a string and if we were using a float value directly, we could never see something like 0. or 3.).



const addDecimalPoint = () => {
   if (expectsOperand) {
      setScreenValue("0.");
   }
   else {
      if (!screenValue.includes("."))
         setScreenValue(screenValue + ".");
   }
   setExpectsOperand(false);
}

Let's stop for a minute to understand the idea of this function.

When adding a dot (to let the user know that they can add decimals to the number shown on screen), we need to be a little bit more cautious than with the rest of operations.

Let's propose these scenarios:

If the calculator is waiting for an operand, that is, the next step is adding a second operand (let's say we want the second operand to be 0.5), and we directly press on the decimal point key (without pressing a numeric key before), a 0 should be appended in front of that dot. The calculator must not in any case show an operand starting by a dot (.5, for example).

But if the calculator isn't waiting for anything else, that is, the current state is stable (the screen value is a full operand and makes sense by itself, although we still have the possibility of adding more digits), a dot will be concatenated to the screen value if and only if there's no other dot in it. Otherwise, the screen number will remain the same. A number can't have two decimal parts 😰

3.1.5. Delete last digit function: <-

In this calculator prototype, a button for removing the last digit is not provided, so we're going to emulate such behavior by using the backspace key of the keyboard.

Note that this is the only one functionality that we're going to implement to be used through the keyboard, not number, operator or function keys. For those, we'll be using the keypad buttons, not the keyboard.

This case works quite differently and we need to add an event listener for such purpose. An event listener is an object that listens for an event to happen and triggers a function every time it occurs.

Let's see the code before going on any further:



useEffect(() => {
   document.addEventListener('keydown', handleKeyDown);
   return () => document.removeEventListener('keydown',handleKeyDown);
   }, [screenValue]);

The event for which the listener waits is a keyboard key being pressed. To specify that behavior, we're passing in the keydown event type.

When this event occurs, the function handleKeyDown will be called and its code will be executed.

Note that we're specifying this event listener within the useEffect hook, which, in addition, is being called conditionally.

Ok, but... Why? Well, because we need this function to be triggered every time the screen value changes. That's it 🙂

Oh, and don't forget to remove the event listener to avoid odd behaviors in your code.

Let's now take a look at handler for the event:



const handleKeyDown = e => {
   if (e.key === 'Backspace') {
      e.preventDefault();
      clearLastDigit();
   }
}

Note that the handler itself calls another function, which is the one executed to delete the last entered digit:



const clearLastDigit = () => {
   if (screenValue !== "0")
      if (screenValue.length > 1)
         setScreenValue("0");
      else {
         setScreenValue(screenValue.substring(0, screenValue.length - 1));
      }
   }

This function, as mentioned right up above, deletes the last entered digit of the screen value if its length is greater than 1. Otherwise, the screen value becomes zero (the screen value must never be empty).

To carry out this deletion, we'll be calling the substring method from 0 to the current screen value length minus 1.

3.2. Numeric keys

The numeric keys are those keys containing numbers to operate with.

Every time a numeric key is clicked, the following function is called:



const handleClickNumericKey = value => {
   if (expectsOperand) {
      setScreenValue(String(value));
      setExpectsOperand(false);
   }
   else
      setScreenValue(screenValue === "0" ? String(value) : screenValue + value);
}

As done before, let's distinguish between these two scenarios:

If the calculator is waiting for an operand (this means that there's an ongoing operation), the value we're introducing will become the current screen value and we'll tell the calculator that it doesn't need to wait for another operand.

If the calculator isn't waiting for a new operand (this means there is an ongoing operand which we can keep adding digits to), it just appends the new digit to the current screen value if this one is not zero. Otherwise, the screen value will be overwritten.

And, in which cases can the screen value be zero? Well, when the calculator is at initial state, or after cleaning the screen or the stored values, for example.

3.3. Operator keys

The operator keys are those that represent arithmetic operations.

This is what happens when we click on an arbitrary operator:



const handleClickOperator = operator => {
   const inputValue = parseFloat(screenValue);
   if (accValue === null) {
      setAccValue(inputValue);
   }
   else {
      if (currentOperator) {
         const resultValue = operate(currentOperator, accValue, inputValue);
      setAccValue(resultValue);
      setScreenValue(String(resultValue));
      }
   }
   setExpectsOperand(true);
   setCurrentOperator(operator);
}

How this function works?

First things first. We need to store the current screen value parsed to float in a constant so we can operate with it.

Then, we'll check if we already have an accumulated value or not.

If there's no accumulated value (we just entered the first operand), we'll set the state for it to this new input value.

Bear in mind that the accumulated value is only stored when an operator is pressed, not when a numeric key is pressed.

Else, if we already have and accumulated value and there's also an operation going on (we just entered the second operand), then we can operate. After the proper operation is done, we'll assign the result value to the accumulated value and the screen value (previously parsed to string in this case).

In any case, we need to store the new operator clicked for later and also tell the calculator to wait for another operand.

There you have the operate function:



const operate = (operator, accValue, inputValue) => {
   switch (operator) {
      case "+": return accValue + inputValue;
      case "-": return accValue - inputValue;
      case "x": return accValue * inputValue;
      case "/": return accValue / inputValue;
      case "=": return inputValue;
   }
}

This function receives the stored operator, the accumulated value and the last screen value as parameters and, based on the operator value, a different operation, which includes the other two values, is performed .

Really easy, right?

And that's pretty much it! I hope you found this tutorial useful and don't hesitate to pose any doubts or questions you could have related to the tutorial and/or examples above.

🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content 🖥🖤

And last but not least... A quick friendly reminder before we go 😊

CSS Selectors: The Full Reference Guide 🚀

_CODE — Wed, 23 Jun 2021 13:35:26 +0000

Hello, everybody! 🚀

Today we'll be covering CSS selectors in depth.

What is a selector in CSS?
Types of selectors
- Universal selector
- Type selector
- Class selector
- ID selector
- Attribute selector
Grouping selectors
- Group selector
Combining selectors
- Descendant combinator
- Child combinator
- General sibling combinator
- Adjacent sibling combinator
Pseudo-classes
Pseudo-elements

What is a selector in CSS?

A CSS selector is a pattern used to choose the HTML elements that we want to style.

Speaking more technically, CSS selectors are able to select those HTML elements to which a style ruleset will be applied.

Types of selectors

1. Universal selector

Syntax: * { style properties }

This selector is represented by an asterisk (*) and matches all the elements in the HTML document.

<ul>
  <li>Computer Science Eng.</li>
  <li>Mathematics</li>
  <li>Physics</li>
</ul>

* {
  border: 1px solid coral;
}

This will apply a 1px solid coral border to all elements in the document.

Output:

The border property shows very well the behavior of this selector. As you can observe in the image above, every element is now surrounded by a border, including the <body> element and the <html> element.

The universal selector is also used to avoid confusion and make your code easier to read.

Let's take a look at the following examples:

div :first-child {
  background-color: maroon;
}

div:first-child {
  background-color: maroon;
}

These two code snippets look both pretty much the same, right?

Well, we only need to notice the blank space between the type selector and the pseudo-class to realize that they're not exactly the same: the first one selects the first child of every <div> element and the second one selects the <div> elements that are first children themselves of another element.

Don't panic yet, we'll be talking more in detail about pseudo-classes and how selectors work later on 🙂

For now, just keep in mind that in this example there are two different element selectors working together to apply a styling rule. Everything will make sense later. Promise.

In any case, to distinguish one from the other and being able to see the blank space more clearly, we can make use of the universal selector, as shown below:

div *:first-child{
  background-color: maroon;
}

Speaking in terms of functionality, adding an asterisk symbol does nothing, but it's useful to quickly identify the elements that are going to be targeted and to keep your code neat and tidy.

2. Type selector

Syntax: elemType { style properties }

This selector matches all elements that belong to the specified type.

<p>A paragraph</p>
<p>Another paragraph</p>
<p>One more paragraph</p>

p {
  font-size: 1.5rem;
  color: deeppink;
}

This will apply a font size of 1.5rem and a deep pink color to all <p> elements. Easy and direct.

Output:

3. Class selector

Syntax: .classname { style properties }

This selector is represented by a period (.) and matches all elements that contain the specified class.

<div>
  <p class="deeppink">This is a deep pink paragraph</p>
  <p class="hotpink">This is a hot pink paragraph</p>
  <p class="pink">This is a regular pink paragraph</p>
  <p class="deeppink-bg">This is a paragraph with a deep pink background</p>
  <p class="hotpink-bg">This is a paragraph with a hot pink background</p>
  <p class="pink-bg">This is a paragraph with a regular pink background</p>
</div>

.deeppink {
  color: deeppink;
}
.hotpink {
  color: hotpink;
}
.pink {
  color: pink;
}
.deeppink-bg {
  background-color: deeppink;
}
.hotpink-bg {
  background-color: hotpink;
}
.pink-bg {
  background-color: pink;
}

/* Group selector - Stay until the end to understand its
 behavior 😉 */
.deeppink-bg, .hotpink-bg, .pink-bg {
  color: white;
}

This will apply a different pink color variant to every <p> element depending on the class they contain, styling either their text or their background.

Output:

Another way to specify a class selector is by appending the type of the element that contains the classname in front of the regular class selector.

Take a look at this example of a regular list:

<ul>
  <li class="list-item">...</li>
  <li class="list-item">...</li>
  <li class="list-item">...</li>
</ul>

We could style every list item like this:

.list-item{
  padding: 5px;
}

Or like this:

li.list-item{
  padding: 5px;
}

Note that in this specific case it wouldn't be necessary to use this method because all the elements that contain the list-item class are <li> elements, so appending the element type wouldn't make any difference .

But let's have a look at this other example below:

<section>
 <h1 class="big">List of animals</h1>
 <ul>
   <li><p class="big">Cat</p></li>
   <li><p class="big">Dog</p></li>
   <li><p class="big">Monkey</p></li>
   <li><p class="big">Dolphin</p></li>
   <li><p class="big">Frog</p></li>
 </ul>
</section>

In this example, we have different types of elements referencing the same class, so, in order to apply different styling rules to each of them, we need to specify the type of the elements that contain that class. Otherwise, the elements won't be targeted properly and, consequently, the styles we're trying to apply won't be displayed as expected.

So we should do something like the following to apply different rules depending on if the element is a heading or a paragraph:

h1.big {
  font-size: 3rem;
  color: coral;
}

p.big {
  font-size: 2rem;
  color: orange;
}

Output:

4. ID selector

Syntax: #idname { style properties }

This selector is represented by a hash symbol (#) and matches the unique element that contains the specified id.

<div>
  <table id="users-table">
    <th>Users</th>
    <tr>
      <td>John Doe</td>
    </tr>
    <tr>
      <td>Jane Doe</td>
    </tr>
  </table>
  <table id="staff-table">
    <th>Staff</th>
    <tr>
      <td>Hannah Legend</td>
    </tr>
    <tr>
      <td>Daniel Oaks</td>
    </tr>
  </table>
</div>

/* Type selector */
table {
  padding: 20px;
}
/* ID selectors */
#users-table {
  background-color: black;
  color: white;
}
#staff-table {
  border: 1px solid black;
}

This will apply a black background color and a white text color to the table that matches the id users-table, and a 1px solid black border to the table that matches the id staff-table. Both of them receive a padding of 20px based on their type.

Output:

Important: Even though HTML allows you to assign the same id value to several elements, you shouldn't ever do it.

If you need to apply the same style to a bunch of different elements, always use the class attribute. You'll keep your code clean and will get rid of a possible confusion.

5. Attribute selector

The attribute selector is more complex than the rest of the selectors and has several syntaxes that can be applied to our HTML elements based on which condition should be satisfied by them.

In other words, it matches all the HTML elements which contain a specified attribute and whose value for that attribute satisfies a given condition.

Attribute selector syntaxes

Syntax 1

[attr] { style properties }

Matches elements with the specified attribute.

<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/blog">Blog</a></li>
    <li><a href="/contact">Contact</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>

/* Type selector */
nav {
  background-color: darkslategray;
  padding: 10px;
}

/* Attribute selector */
a[href] {
  color: white;
  text-decoration: none;
}

This will apply a white color to every <a> element that contains the href attribute, regardless of its value, and removes the underline.

We're also styling the <nav> element with a background color and some padding by making use of the type selector.

Output:

Syntax 2

[attr=value] { style properties }

Matches elements whose value for attr is exactly value.

<form>
  <label for="username">Username</label>
  <input id="username" type="text" placeholder="Username" />
  <label for="password">Password</label>
  <input id="password" type="password" placeholder="Password" />
</form>

input[type="text"] {
  color: chocolate;
}

This will apply a chocolate text color to every <input> element that has the type attribute with an exact value of text.

Output:

We could as well use this syntax to emulate the ID selector (remember the example in section 4):

[id="users-table"] {
  background-color: black;
  color: white;
}

[id="staff-table"] {
  border: 1px solid black;
}

Explanation: By using this attribute selector syntax, we are targeting elements that contain an id attribute whose value is exactly users-table or staff-table. We're using this one syntax because an element can only have one idname, so the value needs to be exact (=).

Syntax 3

[attr~=value] { style properties }

Matches elements whose value for attr is a list of words separated by blanks and one of them is exactly value.

<p lang="en-gb en-us en-ca en-au en-nz">Welcome!</p>
<p lang="fr-fr fr-ca fr-be">Bienvenue!</p>

p[lang~="en-us"] {
  color: navy;
}
p[lang~="fr-fr"] {
  color: red;
}

This will apply a navy color to every <p> element whose value for lang is a list that contains the exact string en-us. Same for all <p> elements whose value for lang contains fr-fr, applying a red color in this case.

Output:

As well as the previous syntax, through which we could emulate the ID selector behavior, we can also use this one attribute syntax to emulate the behavior of the class selector:

[class~="list-item"]{
  padding: 5px;
}

Explanation: By using this attribute selector syntax, we are targeting elements that have a class attribute whose value is a list that contains the string list-item.

We're using this specific syntax because an element can contain several classes and we're aiming at just one of them (~=). But even though the element had just one class, the value for the class attribute always acts like a list of values.

Syntax 4

[attr|=value] { style properties }

Matches elements whose value for attr is exactly value or starts with value followed by a hyphen.

<p lang="en-us">Hello</p>
<p lang="en-gb">Hello</p>

p[lang|="en"] {
  background-color: cornflowerblue;
  color: antiquewhite;
}

This will apply a cornflower blue background color and an antique white text color to every <p> element that has a lang attribute whose value is exactly en or starts with en-.

Output:

Syntax 5

[attr^=value] { style properties }

Matches elements whose value for attr starts with value.

<a href="#list1">Go to list 1</a>
<a href="#list2">Go to list 2</a>
<section>
  <h1>Lists</h1>
  <div id="list1">
    <h1>List 1</h1>
    <ul>
      <li>Milk</li>
      <li>Butter</li>
      <li>Eggs</li>
      <li>Sugar</li>
    </ul>
  </div>
  <div id="list2">
    <h1>List 2</h1>
    <ul>
      <li>Oranges</li>
      <li>Lemons</li>
      <li>Strawberries</li>
      <li>Apples</li>
    </ul>
  </div>
</section>

a[href^="#"] {
  color: crimson;
  font-size: 2rem;
}

This will apply a crimson color and a font size of 2rem to every <a> element that has a href attribute whose value starts with #.
Output:

Syntax 6

[attr$=value] { style properties }

Matches elements whose value for attr ends with value.

<a href="css-selectors-guide.pdf">CSS Selectors Guide</a>

a[href$=".pdf"] {
  color: slateblue;
}

This will apply a slate blue color to every <a> element that has a href attribute whose value ends with .pdf.
Output:

Syntax 7

[attr*=value] { style properties }

Matches elements whose value for attr contains at least one occurrence of value.

<div class="small-box">
  <p>This is a small box</p>
</div>
<div class="big-box">
  <p>This is a big box</p>
</div>

div[class*="box"] {
  background-color: burlywood;
}

This will apply a burlywood background color to every <div> element that contains a class attribute whose value has at least one occurrence of the string box.

Output:

Grouping selectors

Grouping selectors in CSS is basically used to put together those elements of different type or with different id/classes that we want to apply the same style properties to.

Additionally, by using this technique, we'll get rid of redundancy and our code will be clean, concise and organized.

Group selector

Syntax: elem1, ..., elemN { style properties }

This selector is represented by a comma (,) and matches all the elements stated in the list and applies the same ruleset to all of them.

<h1>Computer Science Engineering</h1>
<h2>List of courses</h2>
<ul>
  <li>Algebra</li>
  <li>Calculus</li>
  <li>Physics</li>
  <li>Discrete Mathematics</li>
  <li>Introduction to Programming</li>
</ul>

h1, h2, li {
  color: darkred;
}

This will apply a dark red color to every <h1>, <h2> and <li> element.

Output:

Combining selectors

CSS selectors can also be combined. By combining selectors, then we can define CSS combinators.

CSS combinators are used to establish a relationship between different selectors and are very useful to make your element selection more targeted.

1. Descendant combinator

Syntax: elem1 elem2 { style properties }

This combinator is represented by a single space ( ) and matches all elem2 that are descendants of elem1.

Consider the following navigation:

<nav>
  <ul>
    <li><a>Home</a></li>
    <li>
      <a>People</a>
      <ul>
        <li><a>Students</a></li>
        <li>
          <a>Faculty members</a>
          <ul>
            <a>Discrete Mathematics</a>
            <a>Programming</a>
            <a>Physics</a>
            <a>Algorithms</a>
          </ul>
        </li>
        <li><a>Staff members</a></li>
      </ul>
    </li>
    <li><a>About</a></li>
    <li><a>Contact</a></li>
  </ul>
</nav>

nav a {
  border: 1px solid crimson;
  color: darkslateblue;
  font-size: 1.5rem;
  font-weight: bold;
}

This will apply a 1px solid crimson border, a dark slate blue color, a font size of 1.5rem and a bold font weight to every <a> element that is descendant of a <nav> element, regardless of how nested they are.

Output:

2. Child combinator

Syntax: elem1 > elem2 { style properties }

This combinator is represented by a prompt (>) and matches all elem2 that are direct children of elem1.

<div class="box">
  <p>This is a direct child of .box</p>
  <div>
    <p>This is not a direct child of .box</p>
  </div>
  <p>This is another direct child of .box</p>
</div>

.box > p {
  color: darkgoldenrod;
}

This will apply a dark golden color to every <p> element that is a direct child of any element that has the class box, so, in this HTML example, the first and last <p> elements will be selected, but not the one in the middle.

Output:

3. General sibling combinator

Syntax: elem1 ~ elem2 { style properties }

This combinator is represented by a tilde (~) and matches all elem2 that are siblings to elem1 and come after it.

<img src="blue-mug.jpeg" alt="a regular blue coffee mug" />
<p>Blue mug</p>
<p>Price: $15</p>

img ~ p {
  color: darkblue;
}

This will apply a dark blue color to every <p> element which is a sibling of any <img> element and comes after it. In this example, both <p> elements will be selected.

Output:

4. Adjacent sibling combinator

Syntax: elem1 + elem2 { style properties }

This combinator is represented by a plus symbol (+) and matches all elem2 that are siblings to elem1 and appear immediately after it.

<img src="blue-mug.jpeg" alt="a regular blue coffee mug" />
<p>Blue mug</p>
<p>Price: $15</p>

img + p {
  color: darkblue;
}

In this case, only the first <p> element will be selected, since the second one doesn't appear immediately after the <img> element.

Output:

Pseudo-classes

A CSS pseudo-class is a keyword that is added to a selector and defines a special state of the selected elements.

Syntax: elem:pseudo-class { style properties }

This selector is represented by a colon (:).

<h1>Shopping list</h1>
<ul>
  <li>Milk</li>
  <li>Butter</li>
  <li>Eggs</li>
  <li>Sugar</li>
</ul>

li:hover {
  background-color: black;
  color: white;
}

In this example, we're applying a black background color and a white text color to every <li> element when the cursor hovers over it.

Take a look at what happens when we hover over the Butter element:

Output:

Some of the most common CSS pseudo-classes are:

:active, :hover, :focus, :disabled, :checked, :first-child, :nth-child, :first-of-type.

Pseudo-elements

A CSS pseudo-element is a keyword that is added to a selector to style a specific part of the selected elements.

Syntax: elem:pseudo-element { style properties }

This selector is represented by a double colon (::).

<p>CODE</p>

p::before{
  content: "_";
}

In this example, we're appending an underscore symbol in front of every <p> element.

Output:

Some of the most common CSS pseudo-elements are:

::after (can also be written as :after), ::before (can also be written as :before), ::marker, ::placeholder, ::first-letter.

And that's pretty much it 🙂

I hope this reference guide has been helpful for you.

You can also check out the following related posts about CSS selectors on @underscorecode Instagram account:

🎉 Don't forget to follow @underscorecode on Instagram and Twitter for more daily webdev content 🖥🖤

What's new in Next.js 11?

_CODE — Fri, 18 Jun 2021 12:35:29 +0000

On June 15, the Next.js Conf 2021 was held and brought with it the introduction of Next.js 11.

This new version of the framework brings associated some new features that we'll be discussing in this article.

Worth to mention that the team put a lot of emphasis on the balance DX-UX (developer experience-end user experience) and also the great performance results they're achieving with every new version of Next.js.

After this brief intro, let's dive into the new features of Next.js 11:

Conformance

Conformance is a new system added to Next.js 11 that provides developers with guidance and standards to implement best optimization practices when coding.

This is really useful to avoid having to memorize every single rule for optimal loading performance of your code.

Also, Next.js 11 now supports ESLint for framework-related issues, contributing to a better developer experience.

Usage

npx next lint

Script optimization

For script optimization purposes, in this new version of Next.js, a new type of component has been released: the script component, which allows developers to prioritize the loading of third party scripts.

Sometimes, we developers struggle deciding where to place our scripts in order for them to be loaded and executed properly.

With this new script component, we can set the priority of scripts through the prop strategy, to which we can pass three different values for three different kinds of strategies:

beforeInteractive: For scripts that need to be retrieved and executed before the page is interactive.
afterInteractive: For scripts that can be retrieved and executed after the page is interactive.
lazyOnload: For scripts that can wait to load at idle time.

Usage

import Script from "next/script";
...
<Script src="auth.js" strategy="beforeInteractive" />

Image improvements

With Next.js 10, a new component for image optimization was introduced, since images traditionally take up a lot of space on web apps and this often results in poor performance.

The component has now a couple of new functionalities for even a better image optimization.

Using import to add images

This method automatically calculates and assigns width and height values to static images that are part of our project repository. This helps reduce the cumulative layout shift, a measure that sums all layout shifts on a webpage, that is, those changes in visible elements that aren't caused by user interaction.

Usage

import landscape from "../public/images/landscape.png";
...
<Image src={landscape} alt="Beautiful landscape of mountains" />

Placeholder

When a user visits a webpage for the very first time, large images can take a while to load (especially when using a slow internet connection). This can result in a temporary blank space until the image appears.

To avoid this behavior, a new placeholder prop for the image component has been introduced in this new version of Next.js. We can use this prop to ease the transition, which will show a blurry version of the image until this is fully loaded.

Image source: nextjs.org

Usage

<Image src={landscape} placeholder="blur" alt="Beautiful landscape of mountains"  />

Webpack 5

As of version 10.2, Webpack 5 became the default bundler for Next.js applications, but in order to use it, it was necessary to add a flag in next.config.js to specify the version of Webpack we were going to work with.

With Next.js 11, you don't need any extra configuration to set Webpack 5 as your application bundler. It is automatically ready to use right out of the box.

Next Live

Definitely one of the most important features of Next.js 11. Next Live basically means team collaboration in real time. It allows collaborators to share, comment and edit code within the browser itself from anywhere in the world, by just sharing a URL, without a previous build step, which makes the process fast and efficient.

Another point in favor is that it also provides offline access to let the team work on the project when they don't have internet connection.

Images source: nextjs.org

CRA Migration

With this new feature, every Create React App application is now Next.js compatible by just running the tool @next/codemod. By doing this, a /pages directory is automatically created within the project and CSS imports are relocated to their proper location.

This feature is still experimental and it wasn't mentioned in the conference, but it appears on the Next.js related docs.

Improved performance

The performance of the framework was also highly emphasized: the startup time has been improved by up to 24% and processing time for changes has been cut off by up to 40% as of Next.js 10.

Besides, Next.js 11 also includes a new implementation of Webpack's Babel loader to keep reducing the startup time.

To take advantage of all these new features, we just have to keep Next.js updated, by running the following command:

npm i next@latest react@latest react-dom@latest

And that's all for today 🙂

I hope this article has been helpful for you and I'll see you all in the next.

🎉 Don't forget to follow me on Instagram and Twitter for more related content.

60+ VSCode themes you definitely need to try (dark + light)

_CODE — Tue, 15 Jun 2021 13:42:15 +0000

Hello, everybody!

I don't know about you, but I'm personally a huge fan of changing my VSCode theme every once in a while, mainly for productivity reasons.

So today I bring a list of more than 60 themes for you to try and test.

Check them out and tell me about your favorites in comments below 🙂

1. 2077

Atlantic Night

2. Atlantic Night

3. Atlantic Night Abyss

August

4. August - Ariake Dark

5. August - City Lights Darker

6. August - Dark

7. August - Dawbridge

8. August - In Bed By 7pm

9. August - In Bed By 7pm Darker

10. August - Night Owl

11. August - Nord (Darker)

12. Aurora X

Ayu

13. Ayu - Mirage

14. Ayu - Light

Base16

15. Base 16 - Dark Ashes

16. Base 16 - Dark Mocha

17. Base 16 - Dark Ocean

18. Base 16 - Dark Twilight

19. Base 16 - Unikitty

20. Base 16 - Light Mocha

21. Base 16 - Light Pop

22. Base 16 - Light Tomorrow

23. Bear Theme

Bearded theme

24. Bearded Theme - Arc Blueberry

25. Bearded Theme - Surprising Blueberry

26. Bearded Theme - Monokai Light

27. City lights

28. Cobalt Next - Dark

29. Cobalt 2

30. Code Blue

Dobri Next

31. Dobri Next - C05 - Electron

32. Dobri Next - C09 - Eve

33. Dracula

34. Dracula At Night

35. Electron

36. Halcyon

Horizon

37. Horizon

38. Horizon - Bright

39. LaserWave

Material

40. Material Theme - Ocean

41. Material Theme - Lighter

Mayukai

42. Mayukai - Mirage

43. Mayukai - Mono

44. Mayukai - Sunset

45. Min Theme - Dark

Night Owl

46. Night Owl

47. Night Owl - Light

48. Noctis - Hibernus

49. Overnight - Slumber

50. Panda Syntax

51. Radical

Rosé Pine

52. Rosé Pine

53. Rosé Pine - Dawn

Rouge

54. Rouge

55. Rouge 2

56. Sea Green Theme

57. SynthWave '84

Tinacious Design

58. Tinacious Design

59. Tinacious Design - Light

60. Tokyo Night

61. Vue Theme

🎉 Don't forget to follow me on Instagram and Twitter for more related content.