DEV Community: Ayra Austine Baet

My First React Project (Part 3): Reusable Components, Framer Motion Animation, and Key Lessons Learned

Ayra Austine Baet — Sat, 06 Jun 2026 03:19:54 +0000

This is the third and final part of my first React project for the Frontend Mentor's Digital Bank Landing Page Challenge. I'm excited to say that I finally finished it.

Live Demo: https://bank-landing-page-react-gmtz.vercel.app/
Github Repo: https://github.com/ayra-baet/bank-landing-page-react

Learning Component Reusability Beyond Small Elements

At first, I thought this final part would mostly involve finishing the Articles and Footer. But while building, I realized something more important:

React's reusability isn't limited to small UI elements like buttons or cards; entire sections can be reusable too.

Earlier in this project, I reused a single Button component across the header, hero, and footer. This time, I noticed that the Features and Articles sections shared almost the same structure:

both had an h2 heading
both used a grid layout
both wrapped child components

The only real difference was that the Features section included a description paragraph.

That immediately felt like a perfect use case for a reusable component with conditional rendering.

So I created a reusable Section component:

function Section({ backgroundColor, title, description, children }) {
    return(
        <section 
            className={backgroundColor}
            aria-labelledby={`${title}-heading`}
        >
            <div className="container section__container">
                <div className="section__header">
                    <h2 id={`${title}-heading`}>{title}</h2>
                    {description && <p>{description}</p>}
                </div>

                <div className="section__grid">
                    {children}
                </div>
            </div>
        </section>
    );
}

Then I reused it inside my LandingPage component:

function LandingPage() {
    return(
        <>
            {/* other LandingPage JSX */}

                <section id="features">
                    <Section
                        backgroundColor="section--gray-100"
                        title="Why choose Digitalbank?"
                        description="We leverage Open Banking to turn your bank account into your financial hub. Control your finances like never before."
                >
                        <Features />
                    </Section>
                </section>

                <section id="articles">
                    <Section
                        backgroundColor="section--gray-50"
                        title="Latest Articles"
                    >
                        <Articles />
                    </Section>
                </section>

            {/* other LandingPage JSX */}
        </>
    );
}

This made the code feel much cleaner and more scalable. If I ever add another section with the same structure, I can simply reuse the component instead of rewriting markup from scratch.

That was one of the biggest "React mindset" moments during the project.

Adding Animations with CSS + React Hooks

For the Hero Section, I wanted a fade-in + slide-up animation when the mockup image loads.

In plain HTML/CSS, I'd rely on CSS animations triggered by page load. But in React, I used the useState hook with the onLoad event:

function HeroSection() {
    const [imageLoaded, setImageLoaded] = useState(false);

    return(
        <section 
            className={`hero ${imageLoaded ? "loaded" : ""}`}
            aria-labelledby="hero-title"
        >
            {/* other hero JSX */}
            <img 
                src={mockup}
                alt="Mockup of a banking app on mobile phones"
                className="hero__mockup"
                onLoad={() => setImageLoaded(true)} 
            />

            {/* other hero JSX */}
        </section>
    );
}

Here's how it works:

imageLoaded starts as false
Once the image finishes loading, setImageLoaded(true) runs
React adds the loaded class
The CSS animation then triggers

This ensures the animation plays only after the image is fully ready, creating a smoother experience.

Staggered Animations with Framer Motion

The last animation I added was a staggered reveal for the article cards.

Instead of writing complex JavaScript with the Intersection Observer API, I used Framer Motion, which is declarative and integrates beautifully with React.

I defined variants for the parent container and child cards:

// Section component
    const containerVariants = {
        hidden: {},
        visible: {
            transition: shouldReduceMotion
            ? {}
            : {
                staggerChildren: 0.12
            }
        }
    };

// Articles component
    const cardVariants = {
        hidden: {
            opacity: shouldReduceMotion ? 1 : 0,
            y: shouldReduceMotion ? 0: 30
        },
        visible: {
            opacity: 1,
            y: 0,
            transition: shouldReduceMotion
            ? { duration: 0 }
            : {
                duration: 0.5,
                ease: "easeOut"
            }
        }
    };

Then applied them:

// Section component
    <motion.div
        variants={containerVariants}
        initial={shouldReduceMotion ? false : "hidden"}
        whileInView={shouldReduceMotion ? undefined : "visible"}
        viewport={{ once: true, amount: 0.2 }}
        className="section__grid"
    >
        {children}
    </motion.div>

// Articles component
    <motion.article
        variants={cardVariants}
        className="article__card" 
        key={article.id}
    >
        {/* article content */}
    </motion.article>

The result is a smooth, staggered animation in which each card slides upward one after another.

What I liked most was how simple Framer Motion made everything. The whileInView prop automatically handles scroll-triggered animations without needing to manually wire up observers.

Key Lessons Learned

1. Component Architecture

Breaking the UI into reusable pieces made the project much easier to manage.

Each component owns its own markup and logic, while the LandingPage component simply arranges sections together.

That separation made the codebase feel more organized and scalable.

2. React Hooks

Hooks became essential throughout this project.

I used:

useState for menu toggles and image load tracking
useEffect for disabling page scroll when the mobile menu is open

Before this project, hooks felt abstract while reading documentation. Building something real made them finally "click" for me.

3. Props and State Management

Passing props down and lifting state up are core React patterns that I practiced repeatedly here.

The more I used them, the more I understood how React components communicate and stay flexible.

4. CSS Was Harder Than React

Ironically, CSS ended up being the hardest part of the project.

I spent far more time dealing with:

layouts
spacing
positioning
responsiveness
overflow issues

than writing actual React logic.

Using functions like clamp() across breakpoints helped improve my responsive design skills a lot.

5. Accessibility Matters

I also tried to make the project more accessible by:

adding aria-labelledby
respecting prefers-reduced-motion
using Framer Motion's useReducedMotion hook

This reminded me that accessibility shouldn't be treated as an afterthought.

Final Thoughts

This project tested both my CSS fundamentals and React basics.

Even though it wasn't the most React-heavy application, it gave me hands-on experience with:

component architecture
hooks
reusable layouts
Framer Motion
accessibility considerations

More importantly, it taught me persistence.

I got stuck multiple times. I rewrote code, researched solutions, broke layouts, and made mistakes, but I kept going until everything finally came together.

And honestly, that might be the biggest lesson from this entire project.

I now feel much more confident building future React applications, and I can already see how much more structured my approach has become compared to when I started.

On to the next project!

My First React Project(Part 2): Struggling with a Responsive Hero Section (CSS Lessons Learned)

Ayra Austine Baet — Tue, 07 Apr 2026 06:25:43 +0000

In Part 1, I talked about building the header for the Frontend Mentor's Digital Bank Landing Page Challenge. At that point, I felt like I had momentum.

Then I met the Hero section... and yeah, it didn't go as smoothly as I expected.

This post is about that struggle, what went wrong, what I learned, and how I pushed through it. I'll also share a quick win with the Feature section that reminded me why I enjoy React.

Hero Section (a.k.a. where things got real)

At first, I thought:

"This is just a two-column layout. I've done this before. Easy"

It was not easy.

The JSX part? Totally fine. If you understand functional components in React, structuring this is pretty straightforward.

The real battle was CSS, specifically:

positioning
layering
responsiveness
making everything behave across screen sizes

I rewrote this section more times than I'd like to admit.

What Made It So Difficult?

The design doesn't look that complex, but under the hood:

There's an SVG background and a mockup image of four phones that need to be scaled and positioned correctly
The phones overlap the background
The layout changes depending on screen size
Elements behave differently across breakpoints

I ran into issues where:

Elements overlapped in unintended ways
Images were misaligned
Layouts looked fine on mobile but broke on desktop (and vice versa)
Overflow caused unwanted horizontal scrolling

What I Learned (The Hard Way)

1. Stop Hiding Image Elements in CSS

My first instinct was to use ::before pseudo-elements for decorative images.

It worked... until it didn't

I realized I needed full control over resizing, positioning, and layering across breakpoints. So, I made everything explicit in the markup:

.hero
 .hero__container
  .hero__visual
   .hero__bg-wrapper
    .hero__bg (SVG background)
   .hero__mockup (phone mockup)
  .hero__content (text + button)

This made responsiveness much easier to manage.

2. Relative + Absolute Positioning = Power (and Pain)

This combo became the foundation of the layout:

.hero {
    position: relative; /* establishes positioning context */
    /* other hero styles */
}

@media (min-width: 1024px) {
    .hero__mockup {
        position: absolute;
        right: clamp(-120px, -8vw, -80px); /* positioning tweak */
        bottom: clamp(-110px, -8vw, -80px); /* positioning tweak */
        /* other hero__mockup styles */
    }
}

Using position: absolute gave me precise control over layering and positioning. From there, I used the right and bottom properties to push the mockup slightly outside the hero section, though it involved a lot of trial and error.

3. clamp() Saved My Sanity

Fixed pixel values broke everything across screen sizes.

Switching to clamp() changed how I approached responsiveness:

.hero__mockup {
    /* positioning from earlier */
    width: clamp(280px, 75vw, 420px); /* responsive sizing */
    margin-top: clamp(-140px, 18vw, -110px); /* responsive sizing */
    /* other hero__mockup styles */
}

@media (min-width: 768px) {
    .hero__mockup {
        width: clamp(360px, 55vw, 520px); /* responsive sizing */
        margin-top: -clamp(150px, 20vw, 180px); /* responsive sizing */
    }
}

@media (min-width: 1024px) {
    .hero__mockup {
        /* positioning from earlier */
        right: clamp(-120px, -8vw, -80px); /* responsive offset */
        bottom: clamp(-110px, -8vw, -80px); /* responsive offset */
        width: clamp(540px, 45vw, 700px); /* responsive sizing */
    }
}

Instead of chasing pixel-perfect values, I started thinking in terms of fluid scaling.

4. Use Grid (Only When It Makes Sense)

I didn't force CSS Grid everywhere.

I used it only where it helped.

@media (min-width: 1024px) {
    .hero__container {
        display: grid;
        grid-template-columns: 1fr 1.5fr;
        grid-template-areas: "content visual";
        /* other hero__container styles */
}

A mobile-first + progressive enhancement approach worked much better.

5. Overflow Will Break Your Layout (If You Let It)

The mockup image needed to overflow, but the background shouldn't.

Here's what worked:

html, body {
    overflow-x: hidden;
}

.hero__bg-wrapper {
    overflow: hidden;
    /* other hero__bg-wrapper styles */
}

Feature Section (Finally, A Win)

After the Hero section, the Feature section felt like a breath of fresh air.

Each feature shared the same structure:

icon
title
text

So instead of repeating markup, I used an array:

const features = [
    {
        id: 1,
        icon: onlineIcon,
        title: "Online Banking",
        text: "Our modern web and mobile applications allow you to keep track of your finances wherever you are in the world."
    },

    {
        id: 2,
        icon: budgetingIcon,
        title: "Simple Budgeting",
        text: "See exactly where your money goes each month. Receive notifications when you’re close to hitting your limits."
    },

    {
        id: 3,
        icon: onboardingIcon,
        title: "Fast Onboarding",
        text: "We don’t do branches. Open your account in minutes online and start taking control of your finances right away." 
    },

    {
        id: 4,
        icon: apiIcon,
        title: "Open API",
        text: "Manage your savings, investments, pension, and much more from one account. Tracking your money has never been easier."
    }
]

Then mapped over it:

{features.map((feature) => (
    <div className="feature__item" key={feature.id}>
        <img className="feature__item-icon" src={feature.icon} alt="" />
            <h3>{feature.title}</h3>
            <p>{feature.text}</p>
    </div>
))}

This reminded me why I enjoy React:

separating data from UI
building reusable patterns
using map() effectively

What This Project Taught Me

The Hero section isn't always the hardest part, CSS can be the real challenge
Positioning and scaling are just as important as component structure
React shines when handling repeated UI patterns

If you're also learning React and struggling with CSS, you're not alone. This part definitely tested me.

Feel free to check out the project on my Github repo: https://github.com/ayra-baet/bank-landing-page-react

What's Next?

In Part 3, I'll finish the landing page and hopefully break fewer things along the way.

My First React Project (Without Tutorials)

Ayra Austine Baet — Fri, 20 Feb 2026 23:52:22 +0000

Hi, I'm Ayra👋
I'm an aspiring front-end developer, and instead of watching another React tutorial... I decided to build something on my own.

After practicing HTML, CSS, and JavaScript, I wanted to challenge myself:

Can I build a React project without following step-by-step guidance?

So I chose Frontend Mentor's Digital Bank Landing Page Challenge and rebuilt it using React, even though the challenge was originally meant for plain HTML, CSS and JavaScript.

Here's what I learned.

Why I chose React

React is component-based, which means you can break your UI into small, reusable pieces instead of writing everything in one large file.

Instead of traditional HTML tags, React uses JSX, which lets you write HTML-like syntax directly inside JavaScript.

Even more interesting:

React uses virtual DOM
It applies a diffing algorithm
It updates only what has changed

That means no manual DOM manipulation. No querySelector. No addEventListener for every interaction.

Just state → UI

Building the Header Component

I started with the Header component.

Instead of hardcoding navigation links, I stored them in an array and rendered them dynamically using map():

const links = ["Home", "About", "Contact", "Blog", "Careers"];

<ul className="nav__links" aria-label="navigation links">
  {links.map(link => (
    <li key={link}>
      <a href="#">{link}</a>
    </li>
  ))}
</ul>

Why this matters

No duplication
Easier to maintain
Scalable if links change
Cleaner code structure

It felt like a small decision, but it made the component much more flexible.

Implementing the Mobile Menu (State!)

This was the part that truly made me understand React.

In vanilla JavaScript, I would normally:

Select the button
Add an event listener
Toggle a class manually

In React, we manage UI changes using state.

Here's how I handled the toggle:

import { useState } from "react";

function Header() {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <button
      className={`toggle ${isOpen ? "toggle--open" : ""}`}
      aria-label="menu toggle"
      aria-expanded={isOpen}
      onClick={() => setIsOpen(!isOpen)}
    >
      <span></span>
      <span></span>
      <span></span>
    </button>
  );
}

Now, instead of "manually changing the DOM," I just update the state.

React handles the rest.

That mental shift of thinking declaratively instead of imperatively was huge for me.

Component Architecture and Props

I didn't want my Header component to become too large.

So I split things into:

MobileMenu
Backdrop

Both depend on the same isOpen state, so I passed it down as props:

<MobileMenu links={links} isOpen={isOpen} />
<Backdrop isOpen={isOpen} onClose={() => setIsOpen(false)} />

You can check out the full MobileMenu and Backdrop components in my GitHub repo: https://github.com/ayra-baet/bank-landing-page-react

This made everything:

Cleaner
More reusable
Easier to reason about

It also forced me to think about:

Where should the state live
How components communicate
How to avoid unnecessary duplication

This is something you don't really experience when building static HTML pages.

What This Project Taught Me

Even though I only rebuilt the header section, I learned a lot:

1. Component Architecture Matters

Should everything live in one file?
Or should it be broken into smaller pieces?

2. State Placement Is Important

If multiple components need the same state, it should probably live higher up.

3. Reusability > Repetition

Arrays + props + dynamic rendering = scalable UI

4. React Is About Thinking Differently

It's not just "JavaScript with different syntax."
It's a shift in mindset.

The Biggest Realization

React felt confusing when I just watched tutorials.
But when I built something on my own, struggled a bit, and solved real UI problems... it finally clicked!

What's Next?

In my next post, I'll share how I built the rest of the landing page...