What are Components in the front-end and why do we need them?

Let's first address the following problem: It's not super clear what a Component is. Well, many experienced developers will think of the same thing, but that is not true for those who are new to the Front-End world or haven't really though much about architecture of their codebase.

One of the reasons is that the front-end field as a whole is big, there are many developers and leaders that name things differently and might not always agree to what is what. Different things are refered with different names.

For example, what is the difference between Component and Element? Or something else — when you hear Component, do you think about React? Or Vue? Or an HTML tag or tags?

Let's define what is a Component

A component can be thought of as a group of one or more HTML Elements. Elements are the regular HTML elements you can think of — <span>, <div>, <section> and so on.

It's good to start simple, so we will look into a <button> component. This is your regular HTML Element, no React, no nothing. It will render a simple button on the page. Or would it?

The element will render this small pill shaped box under the text.

As you can see, it doesn't look good at all. To make it more useful, we can provide it with text to output inside by wrappin that string with the tag. If we want, we can also give it an attribute like disabled which will fade it out. All of this would result in:

This is all very simple and intuitive. What we really did was to pass values to a function. That function in return outputted a result which was the button you see above. That in of itself is what a Component does! So, from that, we can easily say that any HTML Element is also a Component.

Great, but that's not all, otherwise we wouldn't use two names for the same thing, right? A Component can also be created by combining more HTML Elements into one. Here is an example of a Card component:

<div class="card">
  <h1 class="card-title"></h1>
  <p class="card-description"></p>
</div>

It has three HTML Elements, but it's one Component — Card. Do you see any React code there? No, because a Component is a concept that can be applied to many things. In the front-end world, this is mostly what you see above. Now, let's see the same component in the context of React:

export default function Card() {
  return (
    <div class="card">
      <h1 class="card-title"></h1>
      <p class="card-description"></p>
    </div>
  );
}

What it does is to provide you with the ability to output that markup by just calling <Card /> And in the spirit of HTML Elements, you can also provide arguments that can modify the output, just like with the button example above. In the world of React, such arguments are called props and are passed to the function via the props object. No need to go into details here, even if you haven't worked with React it's completely fine.

So, to sum it up: A component is a group of HTML elements (or just one). That's about it. For libraries like React we can add more settings like passing props and running functions inside, but it is still a Component.

Why do we need components?

This question is important to understand how to use them. In order to use a tool, you first need to know what the job is, right?

The Front-End developer's job (aside from styling) is to provide the markup structure of an application or a website. Throughout my years of development, I've noticed that the markup is the most overlooked bit. Many developers ignore it and jump straight to styling and functionality. But, turns out that this creates a major problem. The markup if your app is it's skeleton. You can't really build properly without having a good structure that can be reused, modified, extended and so on.

One of the core skills of a programmer is the ability to break down one large problem into many smaller problems and tackle them separately.

But, the trick is to be able to stich them together to solve that big problem. Your large application is your big problem. Break it down into smaller ones, by separating pieces of it into components. All these components then must work together. And the structure of combining them and reusing them is this important skill we need to develop.

To think in Components in the context of HTML is like to think in Functions in the context of a program. You don't want it all dumped into one place, right?

Breaking down the application into components helps with:

• Create a map of the application - it's easier to navigate and understand your building blocks from just reading class names.
• Scoping - you can style HTML Elements without the worry of breaking others. You don't really need CSS in JS to achieve that.
• Reusability - You can define your components once and then call them, by passing arguments to fill in the data. This works great with libraries like React, but it's also completely achievable with more standard PHP projects or HTML Templating languages.

And together with everything above you open up the door to your teammates.

This is just the start

If you found out the above as helpful, then please continue reading the other posts of the series as I will be getting into practical examples and guides that will help you structure your code. If you already knew everything there, I still believe that in my following articles you will find good tips or at least a different point of view, which will help you structure your codebase and reduce the time you spend on debugging, adding new code or maintaining the codebase.

Read next: The Component Types in Front-End Development