Forem: Bunmi Oye

How I Built an Infinite Scroll Photo Gallery with Vue 3 and the Unsplash API

Bunmi Oye — Wed, 06 Aug 2025 10:10:39 +0000

Creating a photo gallery powered by the Unsplash API is a great way to build a media-rich, user-driven frontend experience. This walkthrough covers the core components of a Vue 3 + TypeScript application that integrates with Unsplash’s search endpoint to deliver an infinite-scroll image gallery with search support.

Setting Up the Project: Vite, Vue 3, TypeScript

The project was scaffolded using Vite, Vue 3, and TypeScript to ensure fast dev builds, modern syntax, and type safety. The base structure included a main.ts entry file, a minimal App.vue shell, and clean CSS defaults via a custom style.css.

To streamline development, Volar was installed via the VS Code extension store for Vue-specific TypeScript support.

💡 Tip: If you're using TypeScript with Vue, Volar offers the best IDE experience in VS Code right now.

Building the Photo Fetch Logic

I created a dedicated composable (hook) to fetch photos from Unsplash’s search/photos endpoint using axios. It accepted a query string and page number as parameters.

This modular fetch logic allowed:

Dynamic searching
Infinite scrolling
Reusability across components

import { createApi } from 'unsplash-js';
import { API_KEY, PHOTO_COUNT_PER_PAGE } from '../constants';

export async function fetchPhotos(query: string, page: number = 1) {
  const api = createApi({
    accessKey: API_KEY,
  });

  return await api.search.getPhotos({
    query,
    orientation: 'landscape',
    page,
    perPage: PHOTO_COUNT_PER_PAGE,
  });
}

Using a composable pattern also made it easy to track request states like loading, success, or error, making the UI much easier to manage.

Laying Out the Image Grid

Images from the API were rendered in a grid layout via a dedicated component that accepted the photo data as props. I used CSS Grid to create a responsive, flexible layout that adapts to different screen sizes.

<Gallery
  :photos="photos"
  :status="fetchStatus"
  :is-loading-initial="isLoadingInitial"
  :is-loading-more="isLoadingMore"
/>

Each image included proper alt text (based on Unsplash data) and CSS rules to maintain consistent aspect ratios and spacing.

Making It Searchable

A search input was added at the top of the page, allowing users to dynamically query the Unsplash API.

Here’s how it worked:

When a new term was submitted, the photo list was cleared
The query state updated
A new request was made, starting from page 1

This enabled users to explore terms like “mountains”, “sunsets”, or “cityscapes” in real-time through Unsplash’s library.

Adding Infinite Scroll Without Breaking Everything

To reduce friction and improve the experience, I implemented infinite scroll. As users approached the bottom of the page, the app automatically requested the next page of results and appended them to the current list.

Scroll position was tracked with an event listener, and throttling was applied to prevent spammy API requests.

onMounted(() => {
  const observer = new IntersectionObserver(loadMorePhotos);
  observer.observe(loadMoreRef.value);

  onBeforeUnmount(() => observer.disconnect());
});

This created a smooth, uninterrupted browsing experience, essential for image-heavy interfaces.

⚠️ Note: Be mindful of Unsplash’s API rate limits if you’re implementing this yourself.

What Happens When Things Break

I added visual indicators to show when content was loading and included fallback UI for error states, like when the API request failed or hit its limit.

Whether it was a network hiccup or exceeding Unsplash’s rate limit, the app informed users without breaking flow or crashing the UI.

What I Learned (and You Might, Too)

This project combined Vue 3’s modern frontend tools with Unsplash’s API to deliver a fast, engaging, and responsive image gallery.

Key takeaways:

Modular composables make fetch logic reusable and testable
Infinite scroll feels great but needs careful handling
Semantic HTML and thoughtful styling go a long way in user experience

If you're looking to build something similar, start simple. Then iterate.

What’s Next?

Some upgrades I would explore:

Debounced search input to reduce redundant API requests
Lazy-loading images to improve performance
A photo modal for fullscreen previews and metadata
LocalStorage (or backend) support for saving favorites
Dark mode toggle (because why not?)

Final Thoughts

This project was a fun way to learn and apply Vue 3 in a hands-on setting, while integrating with a real-world API. If you’re exploring Vue or just want to build something visual and interactive, a photo gallery like this is a great place to start.

Working with Vue was a new experience for me, and I talked about that experience here: I Thought React Was Clean, Then I Tried Vue

Tooling I Used

⚡ Vite – for super fast development
🟦 TypeScript – for static typing
🌄 Unsplash API – for fetching beautiful images
🧱 Vue 3 – using the Composition API
🖼️ SCSS – scoped in .vue files for styling

🔗 View the code here

Thanks for reading! I'd love to hear your thoughts and experiences with Vue. What stood out to you the most? Let me know in the comments.

Happy coding. 🚀

I Thought React Was Clean, Then I Tried Vue

Bunmi Oye — Wed, 30 Jul 2025 08:00:00 +0000

Why I Finally Gave Vue a Shot

As a frontend developer who's spent a lot of time with React, learning Vue has always been on my bucket list. I finally got my hands on Vue recently and I want to share my experience, highlighting the differences, similarities, and surprises along the way.

Learning and using Vue was easier than I expected. At one point I genuinely thought, “Man, they have it easy over here.” Vue’s simple yet functional nature is what I hope to share in this post.

How a Job Application Pushed Me into Vue

I applied for a job that required Vue, and given my strength in React, I was confident I could pick it up fast. The company had other plans, though, they required me to complete an assessment using Vue.js. That turned my casual interest into a hands-on crash course.

Me and React: A Brief History

My first hands-on experience with React was in 2020, back when class components were still widely used. It was a bit of a headache to learn, but I leaned into it while appreciating the simpler functional components. I started working with React professionally at an entry level in 2021.

Why Vue, and Why Now?

Back in 2020, the options presented to me were React, Vue, or Angular. Angular seemed like it was falling out of favor (even though it wasn’t really losing Google’s support) while Vue felt a bit more alien than React (surprisingly). I sometimes wonder if starting with Vue would’ve been better, but I’m ultimately glad I picked React first. Learning Vue after React felt easier than I imagine the reverse would’ve been.

Besides needing Vue for the assessment, I’d had it in mind for a while. The job just gave me the excuse I needed.

My First Impressions of Vue

Working with Vue was actually a lot more intuitive (and fun) than I expected. Vue files reminded me of vanilla web projects; HTML, CSS, and JavaScript all in one place.

Vue components come in two flavors: the Options API and the Composition API. The Options API structures things around objects and is more declarative. The Composition API, introduced in Vue 3, is closer to the function-based style I'm used to in React. I tried the Options API briefly, but stuck with the Composition API because it felt more natural.

A typical .vue file contains three sections:

<template>
  <h1 class="greeting"> Hi mom! </h1>
</template>

<script setup lang="ts">
  import { ref } from 'vue';
  const isReact = ref<boolean>(false);
</script>

<style lang="scss" scoped>
  .greeting {
    font-style: italic;
  }
</style>

The <template> tag handles your rendered HTML and other components, kind of like the return() in a React component. You can also render multiple elements without wrapping them in a div, just like React fragments. (Fun fact: Vue also supports JSX.)
The <script setup> block is where you declare state, functions, and imports, similar to what you'd place above the return statement in React.
Styling is scoped by default and written in a <style> block using normal CSS selectors. It also allows using specific styling like SCSS.

Building Something Real with Vue

I built an infinite scroll photo gallery using the Unsplash API. Key features included:

Keyword search via a search bar
Displaying photos in a masonry-style grid
Viewing each photo in a modal
Auto-loading more photos when scrolling near the bottom

I went into more detail in this post, but here’s what stood out compared to React.

Fetching on Page Load

To load photos on page load, I used Vue’s onMounted() lifecycle hook. It’s basically Vue’s version of React’s useEffect(() => {}, []).

onMounted(() => {
  fetchPhotos();
});

Modals with `<teleport>` vs React Portals

For the modal, I wanted to append it directly under the <body> tag. In React, I’d use ReactDOM.createPortal, but Vue makes this incredibly simple with the <teleport> tag. Honestly, this might be my favorite Vue feature so far.

React Portal

import { createPortal } from "react-dom";

const Modal = () => {
    return createPortal(
        <div>
            <h3>This is a modal!</h3>
        </div>,
        document.body
    );
};

Vue Teleport

<teleport to="body">
    <div>
        <h3>This is a modal!</h3>
    </div>
</teleport>

Modal closed

Modal open

Passing Props to Child Components

To pass the selected photo to the modal, I used props. In Vue, you pass props using the : shorthand for v-bind:

<template>
    <Gallery :photos="photos" />
</template>

Infinite Scroll with Intersection Observer

To implement infinite scrolling, I set up an IntersectionObserver inside the onMounted() hook and cleaned it up using onBeforeUnmount(), just like you would with a cleanup function in React.

onMounted(() => {
  const observer = new IntersectionObserver(loadMorePhotos);
  observer.observe(loadMoreRef.value);

  onBeforeUnmount(() => observer.disconnect());
});

Skeleton loaders when scrolling down

Final Thoughts on Vue vs React

React and Vue share many similarities, but Vue feels cleaner and more elegant in some areas. That said, I haven’t tackled advanced topics in Vue yet; like lazy loading, memoization, or server-side rendering (SSR). I know Vue might not have 1:1 equivalents for everything in React, and that’s okay. I'm excited to explore further and share what I learn.

Tooling I Used

⚡ Vite – for super fast development
🟦 TypeScript – for static typing
🌄 Unsplash API – for fetching beautiful images
🧱 Vue 3 – using the Composition API
🖼️ SCSS – scoped in .vue files for styling

🔗 View the code here

Thanks for reading! I'd love to hear your thoughts and experiences with Vue or React. Have you tried switching between them? What stood out to you the most? Let me know in the comments.

Happy coding. 🚀

(Mis)Understanding React Context

Bunmi Oye — Mon, 14 Apr 2025 05:00:00 +0000

I've been building frontend websites with React for a while now, gaining experience with each passing year, but I recently made an assumption that cost me some hours of my life. I falsely believed that when using React context to manage state, using multiple providers in different sections of the codebase would all refer to the same state. Wild, I know.

A quick dive into React Context

React context is an in-house solution to managing state in React. It shines best when used between parents and deeply nested children, as it prevents props drilling. For example, when you pass a state required by Component C as a prop from Component A through Component B to Component C, Component B receives the state so that it can pass it to Component C without using the state itself.

This is how you would do it without context

import { useState } from 'react';

function ComponentA() {
    const [count, setCount] = useState(0);

    return <ComponentB count={count} />
}

// ComponentB receives state it does not use
function ComponentB({count}) {
    return <ComponentC count={count} />
}

function ComponentC({count}) {
    return <p> Count: {count} </p>
}

This can get messy when you pass the props through many children components.

How to do it with context

// context.jsx
import { createContext, useState } from 'react';
export const CounterContext = createContext(undefined);

export function CounterProvider({children}) {
    const [count, setCount] = useState(0);

    return (
        <CounterContext.Provider value={{count, setCount}} >
            {children}
        </CounterContext.Provider>
    )
}

import { useContext } from 'react';

function ComponentA() {
    return (
        <CounterProvider>
            <ComponentB />
        </CounterProvider>
    )
}

// no longer receives state it does not use
function ComponentB() {
    return <ComponentC />
}

function ComponentC() {
    const { count } = useContext(CounterContext);

    return <p> Count: {count} </p>
}

To extract and use a context value from useContext, the component must be wrapped with the context provider. The implementation in Component A resolves to

function ComponentA() {
    return (
        <CounterProvider>
            <ComponentB>
                <ComponentC>
                    <p> Count: 0 </p>
                </ComponentC>
            </ComponentB>
        </CounterProvider>
    )
}

You may be wondering why Component B, which still does not use the count state, needs to be wrapped with the provider? You would be correct. You should wrap the component (or preferably the children) at the topmost level that uses the state. In our case, we can wrap only Component C with the provider

function ComponentA() {
    return (
        <ComponentB>
            <CounterProvider>
                <ComponentC>
                    <p> Count: 0 </p>
                </ComponentC>
            </CounterProvider>
        </ComponentB>
    )
}

A common bad practice is to wrap <App /> (or its children), which is typically the topmost component, with the provider so that any child that needs the state has easy access. The problem with this is that whenever the state changes, the entire app re-renders.
Imagine you have a landing page with a countdown timer below the navbar managed by context state. With every passing second, the entire page re-renders, including the hero, the footer, and all other possibly complex sections.
The only time it's permissible to wrap <App /> is when you have two components that need the state, and you're certain that <App /> is the only common ancestor. If you get to that point, though, consider other state management libraries. However, React context is fine for small-scale state management, like theming.

The Provider divide

Remember when I said this?

The only time it's permissible to wrap <App /> is when you have two components that need the state, and you're certain that <App /> is the only common ancestor.

I sometimes wondered why I can't wrap each component separately with the provider; that way, I don't have to wrap the entire <App /> with it, and both components access the state easily.
In fact, I didn't just wonder, I did this implementation once and forgot that I did, and boy, did things go wrong.

Cue the debug session. I would update the state, but would not see the expected re-render on one of the child components. I checked the state values to ensure that it's being updated, and it is, but one child component isn't receiving these changes. Frustrating.

After a while, I finally noticed that I had the two components wrapped with separate providers, instead of wrapping a common ancestor component. The odd thing is that at that moment, I felt it was normal. It made sense. But my frustration led me to do a deep dive into the React context docs, and like a flash of lightning, I realised my mistake.

React Context Provider manages the state and allows all nested children access to the state. However, when you wrap a section with the provider and another section with the same provider, you get two different instances of the context. It's the same way we are able to reuse a component multiple times in React. Every time the component is used, a different instance is made.

Going back to my implementation, the two different components were referencing two different instances of the same context, and by extension, two different states, so they could not react to the same state change. The simple solution was to take out the providers wrapping each component and wrap the common ancestor with one provider. What a day that was.

Conclusion

Interestingly, what seemed like common sense to me at the time was more of a rookie mistake, but it was a real learning experience.
React Context is useful for light state management, and proper usage means you identify all the components that use the context state, and then wrap their common ancestor with the provider. That way, they all have access to the same instance of that state.

Thank you for your time. Let me know your thoughts on this, as well as your experience with React context. Enjoy coding.

Forem: Bunmi Oye

How I Built an Infinite Scroll Photo Gallery with Vue 3 and the Unsplash API

Setting Up the Project: Vite, Vue 3, TypeScript

Building the Photo Fetch Logic

Laying Out the Image Grid

Making It Searchable

Adding Infinite Scroll Without Breaking Everything

What Happens When Things Break

What I Learned (and You Might, Too)

What’s Next?

Final Thoughts

Tooling I Used

I Thought React Was Clean, Then I Tried Vue

Why I Finally Gave Vue a Shot

How a Job Application Pushed Me into Vue

Me and React: A Brief History

Why Vue, and Why Now?

My First Impressions of Vue

Building Something Real with Vue

Fetching on Page Load

Modals with <teleport> vs React Portals

React Portal

Vue Teleport

Passing Props to Child Components

Infinite Scroll with Intersection Observer

Final Thoughts on Vue vs React

Tooling I Used

(Mis)Understanding React Context

A quick dive into React Context

The Provider divide

Conclusion

Modals with `<teleport>` vs React Portals