A toggle is a switch that can be set to one of two states: on or off. It’s found in everyday technology such as the switch on your smartphone to enable or disable WiFi and Bluetooth(r) (and many other features). Toggles are used in software applications to provide a simple and flexible way to configure a service.
The simplest toggle implementation is an inline icon and text (as pictured above) but the design possibilities are endless. Depending on the use case, they may be placed inline with other content, within a form or even inside data table rows. They can be configured to be either large or small in size to accommodate different user interfaces. A toggle can also be disabled to hide the option it represents (and pass WCAG contrast guidelines).
Toggles are often used to support dev teams as they write new features. They’re a great way to prevent a feature from being pushed to production until the team has written a full integration test for it. They can be created for a single major code branch or a broad set of decision points which are triggered by a variety of conditions including fitness test results from other features in the codebase, settings in a feature management system and variables provided by config files.
Once a toggle has been flipped and the new functionality is tested to be working correctly, it can be merged back into the master codebase and pushed to production to be rolled out to all users. This allows for a much faster feedback loop in the testing process and can help to mitigate the risk of bugs being introduced when a new feature is first released.
Another great use of toggles is as an in-memory configuration mechanism for a service. If a feature flag is used to disable a service instance then re-configuring the service will require restarting the application and redeploying the artifact. This can be a painful and time consuming experience in shared environments where CI/CD is being used.
Toggle configuration lives side-by-side in source control. Having the toggle off and on state baked into the release means that there’s less need to verify how the new version of a feature performs. It’s important to remember that when a toggle is flipped that the change will affect all affected instances of that service. This is a critical factor to consider when designing an in-memory feature flag solution. For this reason some teams choose to put “expiration dates” on their toggles in order to ensure that they don’t sit around in production for too long. This can be done by adding a task to the team’s backlog each time a toggle is added or introducing a flag with an expiration date that triggers a specific test to fail if the toggle hasn’t been triggered. This can be a very effective way of keeping toggle inventory under control.
