cft

Feature Management in ReactJS

Feature management is the way to control which application features are available to your users based on certain scenarios. Let's look at how to implement it on your React applications.


user

Kenneth Angelo Reyes

2 years ago | 3 min read

In this post, I'll show you how to implement feature management on your React applications. Feature management is the way to control which features are available based on certain scenarios.

Why Do Feature Management?

Here are some scenarios where controlling feature availability is necessary:

  1. The feature should only be turned on after a marketing event. With feature flags, the feature can already be sitting in production and an administrator can just simply enable it via configuration once the event is done.
  2. The feature should only be available to users on a specific plan.

All of these scenarios share the same concept. In this post, we'll focus on the 2nd one. Let's go!

The Requirements

Let's say we're building a blog application that offers the ff. features:

  • Updating Title and Content
  • Publishing to multiple blog platforms
  • Scheduling the publish time

Now, let's say the app offers 3 plans to users: Basic, Pro, and, Ultimate.

With these plans, the team has decided to have a plan comparison table that looks like this:

We now have all the requirements defined. Let's start building!

The Starting Point

For your reference, the initial state of the project can be found here.

For simplicity, we only have the New Blog page in this version.

The page contains the following:

  • A Role Switcher to simulate changing of the plans
  • All the features are still available to the user

Here's how it looks like at this point:

The Role Switcher

Here's a look at the RoleSwitcher component:

The component receives 3 properties which are passed by the App component.

The App component then refers to the availablePlans exposed by Config.js

The RoleSwitcher displays all the available plans and allows the user to set the activePlan. The activePlan variable will then be passed to the Editor component later on.

The Feature-Based Approach

Now, let's update the other features to only be shown on the appropriate plan.

In this approach, we let the plans identify the features that are going to be available in them.

Therefore, we need to make changes to the Config file:

In the above change, each plan inside the availablePlans array now has a list of features that are available in them.

Then, let's update the RoleSwitcher to support this new format:

The initialization section of the App component also needs to be updated:

And now, for the star of this post, let's talk about the FeatureBlock component!

The Feature Block Component

The FeatureBlock component is a wrapper component and receives the following:

  • The activePlan property to determine the selected plan
  • The featureName property to which will be matched against the features list of the activePlan property. If a match is found, the FeatureBlock's children will be rendered.
  • The component's children which are conditionally rendered based on the above 2 properties

For simplicity, we'll only use the FeatureBlock component to wrap the publisher and scheduled inputs in the Editor component. This is because the title and content fields are available to all plans anyway.

The Editor component will now have this structure:

After all these changes, the RoleSwitcher will now toggle the visibility of the publisher and schedule inputs.

As you can see, everything is functioning as expected. But, there's a problem with the Config file.

It's too centralized! Once the app grows, the Config file has the potential to be bloated. Let's solve this in the next section.

By the way, here's the code at this point.

The Plan-Based Approach

To solve the problem with the Config file, we should follow a plan-based approach.

In this approach, we're inverting the dependency. Instead of letting the plan define the features available, we let the features specify which plans they should be available on. This is a more modular and cleaner approach.

The Editor component will now have this structure:

The FeatureBlock will also be updated to support this change:

Now that the Config will not be responsible for storing the plan-to-feature mappings anymore, it can already be simplified to:

Here's the code at this point.

In Summary

We've successfully implemented Feature Management in React!

What I've provided is simply a skeletal reference. You can expand it further to support more advanced requirements.

In my case, I was thinking to implement user-specific feature availability. In this scenario, specific features can only be available to users who pass certain conditions.

For example, what if only want to make the scheduled publishing feature available to users from a certain location? We'll explore this in my next article which I'll upload in the next few days!

Glad that you've reached the end of this post. Let me know what you think of this approach by sending in your comments.

I hoped you learned something new from me today!


Hey, you! Follow me on Twitter!

Cover Photo by Javier Allegue Barros on Unsplash

Upvote


user
Created by

Kenneth Angelo Reyes

I build apps then I write about the experience. All tweets are my own personal thoughts and opinions.


people
Post

Upvote

Downvote

Comment

Bookmark

Share


Related Articles