Using Feature Toggle in a React application (part 1)

Published in

EcoVadis Engineering

5 min readSep 15, 2020

Feature Toggles have become a staple of product development. The use of Feature Toggles has made it easier for Product Managers and Operations Specialists to fine-tune when a specific feature should be made available to a specific end-user, while leaving the development teams the freedom to integrate and deploy code in the way most suited to their development cycles. In this article, we will examine how this methodology can be applied in a React application.

The ideas covered in this article have been used to implement an NPM package called featuretoggle-react which is available here: https://github.com/EcovadisCode/featuretoggle-react

Note: This article will cover only the practical aspects of the implementation of Feature Toggles in a React application. If you want to know more about the rationale behind Feature Toggling, check out this article: https://martinfowler.com/articles/feature-toggles.html

Some initial considerations

Let’s define some initial requirements to ensure flexibility and ease of use:

1. Ability to easily substitute a feature toggle provider

An enterprise-wide Feature Toggle solution, more likely than not, will rely on an external service provider. This infrastructure is needed to facilitate access for all stakeholders with an easy-to-use interface, to enable the creation of user target groups, to make canary deployments possible and to provide various other features which have become enterprise standards. Some such providers are Optimizely¹ and Bullet Train², to name just two among many.

As the providers can change as naturally as contracts are signed and cancelled, no tight coupling should exist between the specific Feature Toggle provider and the library used in the frontend application. No changes should be required in the application code. Just a simple change in the configuration.

2. Clarity of intent in the application code

The API needs to be terse, clear and declarative. There should be no mistake about what the developer’s intention was. The building blocks should be intuitive and easy to assemble. It should be possible to figure out which components will be displayed when each Feature Toggle is enabled, just by scanning the JSX code.

3. Ease of removal

An essential part of the Feature Toggle life-cycle is the ability to remove a FT once it is no longer needed. This process should be as painless as possible. Developers should enjoy a high degree of confidence when removing an FT and not have to parse complex logic structures. All that should be required is to remove a few JSX tags.

4. Ability to display alternative versions for on/off or A/B states

Importantly, the Feature Toggle solution should support not only displaying components conditionally, but also displaying fallback components when the FT is off. This could be useful when A/B testing alternative variants of components and displaying them to different user groups.

5. Ease of testing

Lastly, toggled views should be easily testable using standard libraries, such as Jest and Enzyme. It should be possible to assert the existence of particular variants of components depending on the state of the toggle. All this without the need to setup complex mocks of the data layer.

Some NPM libraries which allow the expression of Feature Toggles in JSX code do exist and it is certainly worth checking them out: feature-toggle-jsx³ and react-feature-toggles⁴. However, in this article we will try to create our own FT implementation, which would satisfy the requirements described above.

Looking for the perfect format

Let’s draft our possible format. Are we going to use render props or child components with injected properties? How are we going to determine which state is “ON” and which state is “OFF”. How are we going to pass it to the child component?

This could be one way:

The FeatureToggle component could be wired in such a way that the function would only be fired when the FT is on. But what about the “OFF” state? Maybe something like this?

That looks messy and verbose already! It’s not possible to easily scan the code to determine which component is rendered when the FT is ON or OFF. How about this?

Here, at least the intention is clear, but it’s still pretty awful and verbose. Let’s try passing components via props, as implemented in react-feature-toggles:

While this is clear and legible, passing components as props is not as elegant as passing them as children. It makes editing more cumbersome when removing the toggle (you would need to convert the prop into an element). You could, however, assert against such toggled components in your test suites, even if using a shallow rendering via Enzyme. But let’s try something else:

Much better! Now, we have clarity of intent and the ability to shallow render in a Jest/Enzyme test suite. When removing the toggle, all that needs to be done is to remove the JSX tags and leave the desired component. No extra markup or function code to remove or transform!

The implementation

Now, let’s see how this API can be implemented. We will need to implement the FeatureToggle component and the On and Off components. Let’s work on <FeatureToggle> first. We will leave out the data layer for now and just assume we already have the data in the props. We will clone the children elements and inject them with the featureToggleEnabled property which represents the toggle state.

The child <On> and <Off> components can be simply implemented like this:

The children of <On> and <Off> will render only if the Feature Toggle state is set to ON or OFF respectively.

Testing our Feature Toggle

Now let’s see how the Feature Toggle could be tested using standard Jest/Enzyme libraries.

Let’s try to assert that <ComponentWhenOn> exists when the FT is ON and that <ComponentWhenOff> exists when the FT is OFF. Here is the code that we are going to try to test:

The test code would look as follows. Simple and straightforward: