Embracing real-time feature toggling in your React application

Update: We released a flopflip@5.0.0 which brings a SwitchFeature component for multi-variate toggling, a rebranded ToggleFeature, flag selectors for react-redux, noticeable performance improvements and many helpful minor changes.

Update: We released a flopflip@3.0.0 which brings custom adapters such as localstorage, in memory, LaunchDarkly or split. You can also roll your own to integrate with another service or API. Configuration and examples are in our readme.

Thanks to react-landing-page

Toggling features within a code base is a technique to influence the behaviour of software without having to redeploy. It is often used in conjunction with Continuous Delivery enabling alternative branches for different user groups within the interface a web application. These branches should optimally be triggered independently from the main code base.

Advantages of feature toggling

We at commercetools like to have small iterations on features gathering feedback from customers in the process. Without feature toggling we struggled to target specific customers and often had to make assumptions about the scope and shape of features during development before releasing them. Using feature toggles allows us to engage with our customers and shape features with them by targeting only specific stakeholders involved.

Integrating often and early

Often times feature toggling can be used to avoid long-living feature branches. A given feature can be integrated and released multiple times without being visible to the general public. This reduces the risk of having infrequent, big, impactful and hence potentially breaking releases for customers.

Targeting different user groups

The state of a feature toggle can be bound to any context of a given user. Differentiations can be made for different clients, locations, staff, roles, or any type of user grouping. This allows a feature to be validated quicker and safer by controlling the impact of a features availability. For example, we can start making features available to a select group, allowing them to participate in testing and provide feedback, before sharing it with everyone else.

Multivariate toggles and A/B testing

A/B testing (bucket tests or split-run testing) is a controlled experiment with two (or also more) variants, referred to as A and B. The goal of A/B testing is to identify changes which maximise an aimed for outcome. This outcome can be any success metric such as conversion rate or general interaction with a feature. Feature toggles allow for this experimentation within the UI by having multiple variations (not just on or off) represented in a toggle. An example would be two variations of a signup form which are triggered by a multivariate toggle targeting different groups by e.g. location. The scope of the variation can differ from button colours to swapping an entire section of a page.

Feature toggling within React components

Lets leave the theory behind and dive into code and some examples.

We decided to use LaunchDarkly as a service for our feature toggles with minimal effort. It supports multiple projects and environments while empowering us to target users based on information we provide. As the integration within our React application we chose a library called flopflip which offers a set of Higher Order Components (HoCs) and other helpers to maintain the state of all feature toggles.

In our root component we simply configure flopflip by wrapping our app component

This behind the scenes connects to LaunchDarkly, fetches all toggles and instruments any components further down the component tree of our application.

Now we are ready to toggle any component in our application. The easiest way to toggle a feature is to wrap the component within the ToggleFeature component

Here we also specify a component to be rendered in case the feature is disabled. This helps to mitigate layout issues or just generally helps to communicate that a feature will be there in the future for the excluded target group.

Another more advanced component offered by flopflip is the branchOnFeatureToggle HoC. It enhances any components in our application by component composition

This pattern nicely integrates with any other HoC by composing them all together. A real world example would be to compose connecting to our store while adding routing and internationalisation and a feature toggle

When working with the above-mentioned multivariate flags the branchOnFeatureToggle HoC offers to pass an optional variation key which determines which variate of a feature this component represents. The component will then only render when the user is targeted for that specific variation.

Whenever even more fined grained control within a component is needed to trigger custom logic and not just conditionally render, the injectFeatureToggle HoC allows for just injecting the demanded feature toggle’s value onto the props of a given component.

In addition, the injectFeatureToggle HoC also has a sibling component in injectFeatureToggles which allows to make decisions within a component based on multiple feature toggles.

The integration of flopflip with the js-client of LaunchDarkly comes with the power of real-time updates of flag values within the frontend. As a result, merely turning off a feature or changing its targeting will automatically live-update any React components attached to it within a deployed and running application without refreshing the browser.

Lastly, flopflip offers a non-Redux integration in flopflip/react-broadcast with the same API and components. Switching between both is nothing more than changing imports from flopflip/react-redux to flopflip/react-broadcast .

General advice and lessons learned

We like to share some tips and tricks we learned in the process of dipping our toes in feature toggling parts of our frontend.

Feature toggles should be short lived and be removed from the code base as soon as possible. Maintaining a code base with a lot long lived feature toggles makes predictability of the software harder. After all, problems or even bugs within the program can be a result of different combinations of flags.

Creating an engineering process around feature toggles and their lifecycle can help to manage their usefulness and avoid dead code within the application. This includes keeping tasks to remove feature flags, a dashboard to view all available flags and the habit of testing the UI with different plausible combinations of available flags.

As feature flags are often integrated through another independent system, either self-written or a service, it is inevitable to provide fallback behaviour in case of that system not being available. This can be achieved by a sane default for every flag. This ensures that certain elements of the interface do not accidentally show up or that a basic view is always present even with the flag service or provider being down. This is quite easy to achieve using flopflip by just passing another prop called defaultFlags when configuring the library. Furthermore, the initialisation of an adapter can be deferred by controlling the so called deferAdapterConfiguration prop on ConfigureFlopflip which defaults to false triggering the immediate initialisation respectively.

Finally, using feature toggles should not be used as an excuse to develop big features behind them. Trading a long living branch for a long living feature toggle will likely not provide as much customer value as possible. Toggled features should still be split into small and independent parts, some of which might not need toggling and can provide customer value alone. Generally, small bits can be iterated more easily upon with little assumptions being made beforehand. Customer feedback can then drive further improvements and the cost of failure remains low until the feature has been collaboratively developed and the toggle is removed. This feedback focussed culture needs to be established and cultivated among all parties involved and time for iteration needs to be reserved and communicated.

Summary and conclusion

Feature toggling is a powerful technique not only for backend applications to for instance control server load and feature rollout. It allows features within a frontend being integrated often and early already during development. It reduces risk of big releases and embraces customer feedback. However, as anything it is not a silver bullet and requires discipline and lightweight processes across all parts of the organisation. Knowing when and how to apply feature toggles is crucial. We definitely recommend to consider adopting feature toggling in your team, especially with powerful tools like LaunchDarkly together with flopflip.