Now then, imagine you are comfortably sitting somewhere, with your coffee or tea in hand, and a desire to learn something new in your mind… I prepared this article for such a moment. Sometimes I sit and think about what is happening in the frontend world, how much our work is changing. Especially since the appearance of this “component” thing, things seem to have sped up quite a bit. But what exactly is this component, why is it so important, let’s have a little chat about it.
A component, in its simplest form, can be thought of as a small, reusable building block within a website or application. Like Lego blocks, you connect them to build a house, right? Components are just like that. A button, a card, a navbar menu, even an entire page can be a component. Isn’t that wonderful? You design it once, then use it anywhere else. It saves time, saves effort.
So, why do we use these components? As I said at the beginning, for reusability. You don’t have to rewrite a code or design element multiple times once you write it once. What does this mean? Less code, fewer errors, faster development process. Imagine you want to change the color of a button. If you’re not using components, you’ll have to find and change hundreds of buttons on your site. But if you use components, you only change that button component’s code, and it updates everywhere! Easy, isn’t it?
In larger projects, this logic becomes even more meaningful. As the project grows, managing it becomes more challenging. Thanks to components, the project’s structure becomes more organized, and it’s clear where to find what. It also makes teamwork easier. You can take a component made by a teammate and use it in your own page. Of course, this component must be well-written, or else it might cause trouble 🙂
I think this component logic has entered into every aspect of our lives. The bricks, walls, and windows used in building a house… they are all almost like components. Or the plates, bowls, and spoons used in the kitchen… they are individual “parts” that come together to form a whole. In the software world, things are no different. We just create these parts through code.
The most popular frontend frameworks (React, Vue, Angular, etc.) are based on this component structure. If you are learning these technologies, understanding the component logic is a must. Sometimes, a component can even contain other components. For example, a login form component might include an input component and a button component. That makes things even more modular.
Another thing is, sometimes you take a component and want to make small modifications. That is where “props” come into play. Props allow us to pass data to a component from outside. For example, you created a user card component. You can pass different user information via props and use the same card design for different users. Isn’t that great? This increases the flexibility of components.
One of the most challenging aspects I face is deciding how small to make components. Sometimes I break down a component into tiny pieces, making it hard to assemble them later. Or, I create a very large component with everything inside. Finding the right balance is crucial. In my experience, a component should have a single responsibility. For example, a button component should only be about the button. It can perform some action when clicked, but it should not connect to a database or fetch data. That’s a different task. Unfortunately, I kind of struggle with this aspect myself 🙂
Let’s move on to a code example. Suppose we want to list blog posts. Initially, we try to do everything in one place. Then, we split it into components. First, assume a simple HTML structure:
<div id='app'> <div class='post-list'> <!-- Each post will go here --> <div class='post-item'> <h3>First Blog Post</h3> <p>This is a brief summary of our first post...</p> <button>Read More</button> </div> <div class='post-item'> <h3>Second Blog Post</h3> <p>Let this be a summary of the second post...</p> <button>Read More</button> </div> </div> </div>As it is, everything is nested inside. Assume we do this with Vue.js. Initially, we try putting everything inside one Vue component, handling data fetching, listing, and individual post’s structure. The code I wrote for proxying is not even that complex 🙂
The initial, somewhat messy version could be like this (this is just a logical example, not a working code):
// WRONG: Handling everything in a single component const App = { data() { return { posts: [ { id: 1, title: 'First Blog Post', excerpt: 'This is a brief summary of our first post...' }, { id: 2, title: 'Second Blog Post', excerpt: 'Let this be a summary of the second post...' } ] } }, template: ` <div class='post-list'> <div v-for='post in posts' :key='post.id' class='post-item'> <h3>{{ post.title }}</h3> <p>{{ post.excerpt }}</p> <button>Read More</button> </div> </div> ` };Look at the difference now. All data and listing are in the `App` component. This may be acceptable for a small project but as it grows, it becomes unmanageable. I experienced this myself early on, so I share it for your benefit.
So, how can we improve this? By splitting into components! First, we can create a separate `PostItem` component for each post. Second, the main `App` component should handle mainly listing these `PostItem`s. Think of it like a recipe; each ingredient has its own place. The correct way would be like this:
// CORRECT: Split into components const PostItem = { props: ['post'], // Receive post data from outside template: ` <div class='post-item'> <h3>{{ post.title }}</h3> <p>{{ post.excerpt }}</p> <button>Read More</button> </div> ` };const App = { components: { PostItem // Use the PostItem component in the app }, data() { return { posts: [ { id: 1, title: ‘First Blog Post’, excerpt: ‘This is a brief summary of our first post…’ }, { id: 2, title: ‘Second Blog Post’, excerpt: ‘Let this be a summary of the second post…’ } ] } }, template: ` <div class=’post-list’> <PostItem v-for=’post in posts’ :key=’post.id’ :post=’post’ /> </div> ` };
// Initialize Vue app const vm = Vue.createApp(App).mount(‘#app’);
See the difference? The `PostItem` component only knows how a single post looks. The main `App` component takes care of listing these `PostItem`s. This makes our code more readable, manageable, and reusable. Of course, this is a simple example. In actual projects, more complex component structures, state management, etc., come into play. For example, recently I used Vuex to manage user data, but I might explain that another time 🙂
Ultimately, components are the backbone of modern frontend development. Using them correctly directly affects the quality and speed of your projects. Yes, there are challenges; if you don’t design components well, managing them can be tough. But overall, component logic has greatly simplified frontend work. I think those days of writing everything in a single file are behind us. Sometimes I wonder what we’d do without using components.
If you’d like to learn more about components, you can do a quick Google search: Component Nedir Frontend. You’ll find plenty of examples and explanations there. Watching short videos on YouTube can also help, search for Vue component tutorial.
In conclusion, understanding and applying the component concept is essential for a frontend developer. It allows for cleaner, more organized, and sustainable projects. Remember, good structure saves your project’s future. Of course, practical experience is the best way to learn, so don’t hesitate to experiment and try. Good luck!