Breaking down our use-case

Breaking down a use case using CDD.

In the Key Concepts lesson, we learned about important concepts such as Component-Driven Development and Atomic Design. Let's apply these concepts in our use case.

The use case#

We want to replicate what would happen in your daily job, so let's start from the beginning:

Our task is to implement a section containing a carousel with restaurants on the Home page.

The designer handed to us the full design of the page, which we can access on Figma:

Let's try to break everything down into components.

From the design, we see:

  • A RestaurantsSection that is composed of:

    • Typography

    • Carousel

  • A Carousel that is composed of:

    • a list of RestaurantCard

    • RoundButton

  • A RestaurantCard that is composed of:

    • Image

    • Typography

    • Review that is composed of:

      • Typography

    • Badge that is composed of:

      • Typography

From the analysis, we can see that we have atomic components such as RoundButton, Typography, and Image. Those components are considered atomic because they are so simple they can't be broken down. The rest of the components are compositions, meaning that we need to have the atomic components ready before implementing them.

This exercise is pretty good because it makes us aware of the structure of our components. If you apply the same exercise to the entire Home page, you will see patterns that will help you create components that can be easily reused across the application.

Component category/naming#

Naming and categorizing things is hard. It's important to make sure that you and your team follow a pattern that everyone understands. Have you ever been in a situation where the designers call a component Alert, but you call it Modal, and your colleague calls it Popup? That is frustrating! Make sure to share a common language with the designers so that components are properly named in the design phase, and everyone understands them the same way.

When writing stories, you also get to name them and define a category for them. Let's settle on a way to do it and stick to it in this course. In the MealDrop repository, shared components live under src/components folder, and components that are specific to a page live under pages/<page-name>/<component-name>. Let's follow the same structure when writing stories as well. This makes it easier to understand which components are shared and which components only exist within a certain page.

What's next?#

In the next lesson, we will start coding the components that we just identified.

Start a new discussion. All notification go to the author.