GitHub User Search App

The GitHub user API returns useful profile data, but not every field is guaranteed to contain a value. A user may have no bio, no company, no blog link, no location, or no Twitter username. A common mistake is rendering these values directly without checking for null or empty strings. The UI then shows broken links, empty labels, or text like null, which makes the app feel unfinished.

This project is a good opportunity to practice defensive data mapping. Instead of letting raw API data reach every component, normalize the response once in a service or helper function. The UI should receive a clean profile object where missing values are already converted into display-friendly fallbacks such as “Not available.”

Problematic approach:

          function UserProfile({ user }) {
            return (
              <section>
                <img src={user.avatar_url} />
                <h2>{user.name}</h2>
                <p>{user.bio}</p>
                <a href={user.blog}>{user.blog}</a>
                <p>{user.location}</p>
                <p>@{user.twitter_username}</p>
              </section>
            );
          }

This assumes all fields exist and are meaningful. If bio, blog, or twitter_username is missing, the profile card may look broken.

Better normalized model:

          type GitHubUserApiResponse = {
            login: string;
            avatar_url: string;
            name: string | null;
            bio: string | null;
            company: string | null;
            blog: string | null;
            location: string | null;
            twitter_username: string | null;
            public_repos: number;
            followers: number;
            following: number;
            created_at: string;
            html_url: string;
          };

          type GitHubUserProfile = {
            username: string;
            avatarUrl: string;
            displayName: string;
            bio: string;
            company: string;
            blog: string;
            location: string;
            twitterUsername: string;
            publicRepos: number;
            followers: number;
            following: number;
            joinedAt: string;
            profileUrl: string;
          };

Mapping API data safely:

          function normalizeGitHubUser(user: GitHubUserApiResponse): GitHubUserProfile {
            return {
              username: user.login,
              avatarUrl: user.avatar_url,
              displayName: user.name || user.login,
              bio: user.bio || "This profile has no bio yet.",
              company: user.company || "Not available",
              blog: user.blog || "Not available",
              location: user.location || "Not available",
              twitterUsername: user.twitter_username || "Not available",
              publicRepos: user.public_repos,
              followers: user.followers,
              following: user.following,
              joinedAt: user.created_at,
              profileUrl: user.html_url
            };
          }

Cleaner rendering:

          function UserProfile({ profile }: { profile: GitHubUserProfile }) {
            return (
              <section className="user-card" aria-labelledby="user-name">
                <img
                  src={profile.avatarUrl}
                  alt={`${profile.displayName} GitHub avatar`}
                />

                <h2 id="user-name">{profile.displayName}</h2>
                <p>@{profile.username}</p>
                <p>{profile.bio}</p>
              </section>
            );
          }

Pay attention to: Normalize the GitHub API response before rendering. The UI should not have to guess whether every profile field is available.

A GitHub User Search App has several possible failure states. The username may not exist, the user may submit an empty form, the network may fail, or the API may temporarily reject requests. If all of these cases become “Something went wrong,” the app gives poor feedback and users do not know what to do next.

A good search app should distinguish common cases. A 404 response should show “No user found.” A network failure should suggest retrying. A request-limit response should explain that the app is temporarily limited. Validation should prevent empty searches before the request is sent. These small details make the project look much more professional.

Problematic approach:

          async function searchUser(username: string) {
            try {
              const response = await fetch(`https://api.github.com/users/${username}`);
              const data = await response.json();

              setUser(data);
            } catch {
              setError("Something went wrong.");
            }
          }

This does not check response.ok. A failed response can still be parsed as JSON and may accidentally be passed into the profile UI as if it were a valid user.

Better typed result:

          type SearchResult =
            | { status: "success"; user: GitHubUserProfile }
            | { status: "not-found"; message: string }
            | { status: "rate-limited"; message: string }
            | { status: "network-error"; message: string };

          async function searchGitHubUser(username: string): Promise<SearchResult> {
            try {
              const response = await fetch(
                `https://api.github.com/users/${encodeURIComponent(username)}`
              );

              if (response.status === 404) {
                return {
                  status: "not-found",
                  message: "No GitHub user found with this username."
                };
              }

              if (response.status === 403) {
                return {
                  status: "rate-limited",
                  message: "GitHub API limit reached. Try again later."
                };
              }

              if (!response.ok) {
                return {
                  status: "network-error",
                  message: "GitHub profile could not be loaded."
                };
              }

              const data: GitHubUserApiResponse = await response.json();

              return {
                status: "success",
                user: normalizeGitHubUser(data)
              };
            } catch {
              return {
                status: "network-error",
                message: "Network error. Check your connection and try again."
              };
            }
          }

State-aware rendering:

          if (searchState.status === "not-found") {
            return <p role="alert">{searchState.message}</p>;
          }

          if (searchState.status === "rate-limited") {
            return <p role="alert">{searchState.message}</p>;
          }

          if (searchState.status === "network-error") {
            return <p role="alert">{searchState.message}</p>;
          }

          if (searchState.status === "success") {
            return <UserProfile profile={searchState.user} />;
          }

Pay attention to: Error states should be specific. Users should know whether the username does not exist, the request failed, or the API is temporarily unavailable.

Search apps often behave incorrectly when users submit several searches quickly. For example, the user searches for octocat, then immediately searches for another username. If the first request finishes after the second one, the UI may display the old profile even though the latest search was different. This is a race condition.

This problem is easy to miss during manual testing because network timing changes from request to request. A reliable implementation should either cancel the previous request or ignore outdated responses. This keeps the displayed profile connected to the most recent username submitted by the user.

Problematic approach:

          async function handleSearch(username: string) {
            setLoading(true);

            const result = await searchGitHubUser(username);

            setSearchState(result);
            setLoading(false);
          }

This does not know whether the response belongs to the latest search or an older request.

Better approach with request ID:

          const latestRequestId = useRef(0);

          async function handleSearch(username: string) {
            const trimmedUsername = username.trim();

            if (!trimmedUsername) {
              setSearchState({
                status: "validation-error",
                message: "Enter a GitHub username."
              });

              return;
            }

            const requestId = latestRequestId.current + 1;
            latestRequestId.current = requestId;

            setSearchState({ status: "loading" });

            const result = await searchGitHubUser(trimmedUsername);

            if (requestId !== latestRequestId.current) {
              return;
            }

            setSearchState(result);
          }

Alternative with AbortController:

          const abortControllerRef = useRef<AbortController | null>(null);

          async function searchWithAbort(username: string) {
            abortControllerRef.current?.abort();

            const controller = new AbortController();
            abortControllerRef.current = controller;

            const response = await fetch(
              `https://api.github.com/users/${encodeURIComponent(username)}`,
              {
                signal: controller.signal
              }
            );

            return response.json();
          }

Pay attention to: Search results should always match the latest submitted username. Handle fast repeated searches, slow networks, and outdated responses.

A search bar should behave like a real form. Users should be able to type a username and press Enter. The input should have a label, even if the design hides it visually. The submit button should have clear text, and validation errors should be announced accessibly. A common mistake is using a plain div with an input and a click handler, which works only for mouse users and misses standard form behavior.

This project is small enough that accessibility details are very visible. A polished GitHub User Search App should not only fetch data correctly; it should also be easy to use with keyboard navigation, screen readers, and mobile keyboards.

Problematic approach:

          <div className="search">
            <input
              value={username}
              onChange={(event) => setUsername(event.target.value)}
              placeholder="Search GitHub username..."
            />

            <button onClick={() => handleSearch(username)}>
              Search
            </button>
          </div>

This may work visually, but it does not use native form submission. Pressing Enter may not behave consistently, and the input has no real label.

Better form structure:

          function SearchForm({ onSearch, errorMessage }) {
            const [username, setUsername] = useState("");

            function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
              event.preventDefault();

              onSearch(username);
            }

            return (
              <form className="search-form" onSubmit={handleSubmit}>
                <label className="sr-only" htmlFor="github-username">
                  GitHub username
                </label>

                <input
                  id="github-username"
                  type="search"
                  value={username}
                  onChange={(event) => setUsername(event.target.value)}
                  placeholder="Search GitHub username..."
                  autoComplete="off"
                  aria-describedby={errorMessage ? "search-error" : undefined}
                />

                <button type="submit">Search</button>

                {errorMessage && (
                  <p id="search-error" role="alert">
                    {errorMessage}
                  </p>
                )}
              </form>
            );
          }

Useful visually hidden class:

          .sr-only {
            position: absolute;
            width: 1px;
            height: 1px;
            padding: 0;
            margin: -1px;
            overflow: hidden;
            clip: rect(0, 0, 0, 0);
            white-space: nowrap;
            border: 0;
          }

Pay attention to: Use a real form. Support Enter key submission, labels, validation messages, and accessible error feedback.

Many GitHub User Search App designs include light and dark themes. A common mistake is adding a button that toggles a CSS class but forgetting to persist the selected theme. The user switches to dark mode, reloads the page, and the app returns to light mode. Another mistake is ignoring the system preference completely, even though many users expect apps to respect their device theme by default.

A cleaner theme system should check saved user preference first. If there is no saved preference, it can fall back to the system color scheme. After the user changes the theme manually, save that choice in localStorage. The UI should also expose the current theme state in the toggle button label.

Problematic approach:

          const [darkMode, setDarkMode] = useState(false);

          function toggleTheme() {
            setDarkMode(!darkMode);
          }

          return (
            <button onClick={toggleTheme}>
              Theme
            </button>
          );

This does not persist the theme and does not explain what the button will do.

Better theme initialization:

          type ThemeMode = "light" | "dark";

          function getInitialTheme(): ThemeMode {
            const savedTheme = localStorage.getItem("theme");

            if (savedTheme === "light" || savedTheme === "dark") {
              return savedTheme;
            }

            const prefersDark = window.matchMedia(
              "(prefers-color-scheme: dark)"
            ).matches;

            return prefersDark ? "dark" : "light";
          }

          const [theme, setTheme] = useState<ThemeMode>(getInitialTheme);

Persisting and applying theme:

          useEffect(() => {
            document.documentElement.dataset.theme = theme;
            localStorage.setItem("theme", theme);
          }, [theme]);

          function toggleTheme() {
            setTheme((currentTheme) => {
              return currentTheme === "dark" ? "light" : "dark";
            });
          }

Accessible toggle:

          <button
            type="button"
            onClick={toggleTheme}
            aria-label={
              theme === "dark"
                ? "Switch to light theme"
                : "Switch to dark theme"
            }
          >
            {theme === "dark" ? "Light" : "Dark"}
          </button>

Pay attention to: Theme switching should be persistent and understandable. Respect saved preference first, system preference second, and make the toggle label clear.

GitHub profiles include fields such as website, company, location, and Twitter username. These fields are user-generated, which means they can be empty, unusual, or not formatted the way your UI expects. The blog field is especially tricky because some users enter a full URL, while others enter a domain without protocol. If you put that value directly into an anchor, the link may behave incorrectly.

A good implementation should format external links before rendering them. If the value is missing, show a disabled or muted “Not available” state. If the value exists but does not include http:// or https://, add https:// for the actual link while keeping the display text clean.

Problematic approach:

          <a href={user.blog} target="_blank">
            {user.blog}
          </a>

If user.blog is empty, this creates a broken link. If it is example.com, the browser may treat it as a relative path instead of an external URL.

Better link formatter:

          function formatExternalUrl(value: string): string | null {
            const trimmedValue = value.trim();

            if (!trimmedValue || trimmedValue === "Not available") {
              return null;
            }

            if (
              trimmedValue.startsWith("https://") ||
              trimmedValue.startsWith("http://")
            ) {
              return trimmedValue;
            }

            return `https://${trimmedValue}`;
          }

Safe profile link component:

          function ProfileLink({
            label,
            value
          }: {
            label: string;
            value: string;
          }) {
            const href = formatExternalUrl(value);

            if (!href) {
              return (
                <p className="profile-link profile-link--disabled">
                  {label}: Not available
                </p>
              );
            }

            return (
              <p className="profile-link">
                {label}:{" "}
                <a href={href} target="_blank" rel="noreferrer">
                  {value.replace(/^https?:\/\//, "")}
                </a>
              </p>
            );
          }

Pay attention to: User profile data is not always ready for display. Format links, handle missing values, and never create empty clickable elements.