A toggle (pronounced tog-l
Toggles are commonly used in user interfaces, for example in the options menus found in many applications. Toggles allow us to change settings and preferences in an easy way, without having to revert back to the default setting. They are also the preferred control type for changing system functionality on mobile devices, where they take up less screen space than radio buttons.
The word toggle has a long history, dating all the way back to the 18th century. The original meaning of the word was a pin passed transversely through an eye or loop in a rope or chain as a means to temporarily bind it to another. The more modern definition of the term is a quick, temporary switching of states or functions, such as toggling between the camera views of a video chat.
Feature Toggles can be a powerful tool for making data-driven optimizations to things like the purchase flow of an ecommerce system or Call to Action wording on a button. For this reason they are often used in experiments and in more dynamic environments where it is necessary to be able to re-configure the toggle at runtime.
One of the most common use cases for toggles is in multivariate testing or A/B testing. For this purpose a toggle is configured to consistently send a given user down one of several codepaths at runtime, depending on which cohort they are in. This allows us to measure the impact of specific changes on our users and then to make a data-driven decision on whether or not to keep that particular feature enabled in production.
There are a few ways we can configure our toggles at runtime, from simple approaches which offer little to no flexibility through to more sophisticated methods which allow for dynamic in-memory re-configuration of individual service instances. The most common method for configuring toggles is by hardcoding them into the source code, using a preprocessor’s #ifdef feature where available. This offers a high level of flexibility but it isn’t suitable for all use cases and can be a real pain to deal with in shared test environments, where it may have to be deployed multiple times to exercise the different paths.
We can also use external services to manage our toggles at runtime, as these will often allow for in-memory re-configuration. However, these services can be expensive and a painful to deploy in shared test environments, where they may have to be manually re-deployed every time we want to swap the toggle between different settings. For this reason, it is generally preferable to have our toggle configuration live side by-side in our source code so that we can quickly and easily make changes at any time.
