Building Reusable Components in React

The Philosophy: Component-Based Architecture

At its heart, React is all about building user interfaces by composing small, independent, and reusable pieces of code called components. Instead of thinking about a web page as one giant HTML file, we think of it as a tree of components.

For our movie app, we can immediately identify several potential components:

• A search bar.
• A list of movies.
• An individual movie card.
• A section for favorite movies.
• A heading for each section.

By building these as separate components, we can develop, test, and reuse them independently.

How to Organize Your Components: Folder Structure

Once you start creating components, the next question is: where do you put the files? A clean folder structure is vital for project sanity. While there's no single "correct" way, there are common patterns that scale with project size.

To get a great overview of these patterns, let's watch a video from Web Dev Simplified, which covers three common approaches.

Summary of Folder Structures

Here’s a quick recap of the structures discussed in the video:

1. Simple Structure:

   • All components live in a single src/components folder.
   • Pros: Easy for very small projects.
   • Cons: Becomes a mess quickly as the project grows.

2. Intermediate Structure (Our Approach):

   • This is the sweet spot for many applications, including our movie app.
   • src/pages: Contains components that represent an entire page or view (e.g., HomePage, ProfilePage). These components are responsible for the page's layout and composing other components.
   • src/components: Contains smaller, reusable components that are shared across different pages (e.g., Button, Modal, SearchBox). This folder can be further subdivided (e.g., src/components/ui, src/components/form).
   • Co-location: Logic specific to one page (like custom hooks or smaller components) can live inside that page's folder (e.g., src/pages/Home/ToDoList.js).

3. Advanced (Feature-Based) Structure:

   • Code is organized by feature, not by file type. A src/features/authentication folder would contain all components, hooks, and logic related to authentication.
   • Pros: Highly scalable and maintainable for large, enterprise-level applications.
   • Cons: Overkill for smaller projects.

Practical Application: Structuring Our Movie App

Now, let's apply the intermediate structure to our movie app. We'll break down the UI and create our first set of reusable components. We will follow a tutorial that builds the exact project we are working on.

First, we need a component to display the list of movies.

As the article shows, the basic flow is:

1. The main App.js component holds the application's state (an array of movies).
2. It renders the <MovieList /> component.
3. It passes the movie data down to MovieList as a prop: <MovieList movies={movies} />.
4. The MovieList component receives props.movies and uses the .map() method to render a list of movie posters.

Creating More Reusable Components

Our app needs more than just a list. It needs a heading and a search box. We could put them directly in App.js, but creating separate components is better for reusability and separation of concerns.

Why is MovieListHeading a good candidate for a reusable component? Because we will soon have two movie lists: one for search results and one for favorites. We can reuse the same heading component for both, simply by passing a different heading prop.

Advanced Reusability: Passing Components as Props

Here's a powerful pattern that truly unlocks component reusability. Instead of having a component decide what to render internally, you can pass another component to it as a prop.

In our movie app, when you hover over a movie in the main list, you want to see an "Add to Favorites" button. But when you hover over a movie in the favorites list, you'll want to see a "Remove from Favorites" button.

The MovieList component shouldn't have to know about adding or removing favorites. Its only job is to display a list of movies and show an overlay on hover. We can make it completely generic by passing the overlay content (the button component) as a prop.

This pattern is incredibly powerful. The MovieList component is now a generic "list renderer" that can be used in many different contexts just by passing it different data and different action components.

Putting It All Together: Reusing MovieList

Now for the payoff. We can reuse our MovieList component to display the favorites list. We just render it a second time, passing it the favorites array from our state and a RemoveFavorites component as the prop.

Conclusion

In this lesson, you've learned the fundamental principles of structuring a React application. This is a critical software engineering skill that moves you beyond just writing code to designing scalable and maintainable systems.

Key Takeaways:

• Component-Based Architecture: Break down complex UIs into small, independent, and reusable components.
• Folder Structure: Organize your project logically. For our project, we're using an intermediate structure with pages for top-level views and components for shared, reusable UI elements.
• Data Flow: The parent component (App.js) holds the state and passes it down to child components via props.
• Component Reusability: Maximize reusability by creating generic components (MovieList) and passing in data and even other components as props. This is a powerful form of composition.

You now have the skeleton of our movie app in place! In the next lesson, we will bring it to life. We'll focus on the SearchBox component, implement the controlled component pattern you learned previously, and make our first API call to fetch movie data dynamically based on user input.