A toggle is a switch that can be set to either one position or another, like a button on a computer that toggles between two functions. It can also refer to the act of switching between two positions, for example toggling between screens while video chatting with friends. Toggles can be used to implement a wide variety of user-interface changes including settings, preferences and features. It is important to use toggles sparingly and only where they are needed to provide a valuable user experience. When using toggles it is essential to ensure that they are properly labeled, use standard visual design and that the toggles deliver a clear result when activated.
The term toggle originally referred to an ornamental rod-shaped button for inserting into a large buttonhole, loop or frog on clothing. It also refers to the action of shifting back and forth between two positions, for example toggling between a video chat with a friend on a laptop and one on a smartphone. The word has also been used to describe a feature of software that allows a user to switch between two settings or modes, such as the Caps Lock and Num Lock keys on a keyboard or the menu options in many applications.
Savvy teams treat their Feature Toggle inventory as something that comes with a carrying cost and seek to keep this low as possible. As such, they are proactive about removing toggles that are no longer needed. Some teams even put “expiration dates” on their toggles which will fail a test or otherwise break the application if they remain in place after that date has passed.
For these reasons and more, savvy teams typically choose to manage their toggle configuration via a centralized store rather than in the source code. This approach allows for a more dynamic and consistent re-configuration of toggle configuration, especially at scale, whereas modifying toggles via source code comments becomes a challenge as your application grows in size.
There is less need to verify how the release will perform with both a toggle Off and On since that state is baked into the release and won’t change (for less dynamic flags at least). This type of approach can be used to roll out Canary releases or Champagne Brunch releases where a given set of users is exposed to one codepath while everyone else sees the other. Using this type of centralized store also makes it easier to track and re-create previous release configurations should this become necessary. This type of toggle configuration management is a key feature of tools such as the Toggle Router and VSTS Release Manager.
