DevelopmentMay 13, 2026

How to Hide Feature A and Show Feature B to Different Users in React

Introduction

Have you ever wondered how companies like Slack, Netlify, Zoom or Facebook (and surely the rest of the FAANG crowd) roll out new features gradually to just some users? 🤔

Mystery solved! They do it with feature flags (FF for short), and we're going to dive right into this concept.

Feature flag services work like this: you define a list of features (for example, dark mode, a login with a horizontal layout, or design 2.0) and assign them to a group of users, specifying the conditions to turn them on or off.

There's a good chance you've already used FF in your projects without knowing it. Have you ever stored booleans in a database indicating whether a specific user should have access to a certain feature? If so, congratulations: you already have experience with feature flags.

Database booleans worked up to a point, but progress doesn't stop, and today there's a much more flexible and developer-friendly way to control which features are available. Let's take a look at feature flag services. They bring these advantages:

A UI where you can define and manage features
User segmentation
A/B testing
Flag analytics
Phased rollouts
SDKs for different languages and frameworks

In this article we'll use Flagsmith, an open source feature flag and remote config service, though you can also check out commercial alternatives like LaunchDarkly. The goal is to learn how to get started with feature flags in React and make rolling out new features to users a smoother process.

With Flagsmith you can manage FF from practically anywhere (frontend, backend or mobile platform). Take a look at this diagram:

Let's walk through what happens step by step.

The user requests the page
Part of your application (FE/BE) calls the Flagsmith service with the user's uuid
Flagsmith matches that uuid against the feature configuration available for that user and returns the information
The application renders the page based on the information received

Nothing out of this world. Let's get to it! Flagsmith GitHub logo / flagsmith Open source feature flag and remote config service. Install it on your own servers or use their hosted version at https://flagsmith.com/

Our goal

We want to build a fairly standard dashboard app (sorry, no to-do list today) with authentication set up. The idea is to show certain components only to users who've opted into the beta.

To build it we'll lean on React, Next.js, Next-Auth, and the great dashboard components from Tailwind UI.

Prerequisites

Create a new app with Next.js, React and Next-Auth, or clone this sample repository

Additional links

Getting started with Next.js

Getting started with NextAuth

Then, create an account on Flagsmith's cloud version.

Setting up the Flagsmith environment

Setup is simple. Once you've signed up, create a new project. In Flagsmith you can define several environments per project, and each one has its own features, users, segments and API key.

Let's create our first feature and call it "pinned_projects". Beta users will be able to pin projects and view them.

The next step is to install the flagsmith-react package


npm i flagsmith-react

To get started, we wrap our _app.js with FlagsmithProvider and pass it the Flagsmith API key, which you can get from their UI's settings page. FlagsmithProvider lets you use the useFlagsmith hook and passes the state down to child components.


import Auth from 'components/auth';
import { Provider as SessionProvider } from 'next-auth/client';
import { FlagsmithProvider } from 'flagsmith-react';
import '../styles/globals.css';
export default function MyApp({ Component, pageProps }) {
  return (
    <FlagsmithProvider environmentId={process.env.NEXT_PUBLIC_FLAGSMITH_API_KEY}>
      <SessionProvider session={pageProps.session}>
        {Component.auth ? (
          <Auth>
            <Component {...pageProps} />
          </Auth>
        ) : (
          <Component {...pageProps} />
        )}
      </SessionProvider>
    </FlagsmithProvider>
  );
}

FlagsmithProvider initializes the Flagsmith JavaScript client under the hood, and you can already start fetching the flags declared in the UI. But it doesn't make much sense if we're not fetching flags specific to each user. For Flagsmith to know which user is requesting the flags, we need to identify them. The perfect spot for that is the Auth component, which is in charge of checking the user's session and redirecting them to the login page if it has expired.


import { useSession, signIn } from 'next-auth/client';
import { useEffect } from 'react';
import { useFlagsmith } from 'flagsmith-react';
export default function Auth({ children }) {
  const { identify, isIdentified, getTrait, setTrait } = useFlagsmith();
  const [session, loading] = useSession();
  const isUser = !!session?.user;
  // Identify user and set email trait if does not exist
  const identifyUser = async (id, email) => {
    await identify(id);
    const hasEmail = !!getTrait('email');
    if (!hasEmail) {
      setTrait('email', email);
    }
  };
  useEffect(() => {
    if (loading) return; // Do nothing while loading
    if (!isUser) signIn(); // If not authenticated, force log in
  }, [isUser, loading]);
  useEffect(() => {
    if (isUser && !isIdentified) {
      // In the example we don't save users in the database so we don't have id that should be used for identification
      // Instead we're going to use email as a trait and id
      identifyUser(session.user.email, session.user.email);
    }
  }, [isIdentified, identify, session, isUser]);
  if (isUser) {
    return children;
  }
  // Session is being fetched, or no user.
  // If no user, useEffect() will redirect.
  return <div />;
}

Here you can see we use getTrait and setTrait. Traits are nothing more than key/value pairs tied to specific identities. You can assign the user any additional information that can later be used for segmentation, such as their plan, whether they've opted into beta features or the newsletter, and so on.

Let's create our first segment and call it beta_opt_in. Go to Segments → Create Segment. Here you can also define an expression based on a trait that adds users meeting the condition to the segment. We can start with something simple: if the email contains [example.com](http://example.com), we'll consider them opted into beta features.

The last step is adding the check to our React component with hasFeature("pinned_projects").


const Home = () => {
  const { hasFeature } = useFlagsmith();
  return (
    <>
      <main className="relative z-0 flex-1 overflow-y-auto focus:outline-none">
        <div className="border-gray-200 border-b px-4 py-4 lg:px-8 sm:flex sm:items-center sm:justify-between sm:px-6">
          <HomeHeader />
        </div>
        {hasFeature('pinned_projects') && (
          <div className="mt-6 px-4 lg:px-8 sm:px-6">
            <PinnedProjects items={pinnedProjects} />
          </div>
        )}
        <ProjectsTable items={projects} />
      </main>
    </>
  );
};

Done!

If you've followed all the steps, you should now have a small test project showing a modern approach to feature flags. Congratulations! 🎉

Feel free to extend it or apply the idea to your current projects.

P.S.: To keep reading

In this article we've only taken a quick look at feature flags and built a simple sample app, but a full FF system can go a lot further. Take a look at:

A/B testing
Feature flag analytics
Phased rollouts