A toggle is a switch that lets you enable or disable features. It’s an extremely simple user-interface element that is heavily used in modern interfaces but, when used incorrectly, can do more harm than good. It’s important to use toggles sparingly and carefully and to make sure they provide a clear and consistent message to users. It’s also crucial to design them with a high level of accessibility in mind.
Unlike other types of feature flags that can live side by side with the codebase in source control, toggle configuration tends to be more dynamic. Adding and changing the state of a toggle typically requires deploying a new release to introduce the change (or at least restarting a process that is relying on that toggle to work). Savvy teams try to minimize this impact by only having to deploy a new version in order to re-configure a toggle when they have determined it’s no longer required. This helps them keep their backlog of toggle removals manageable while still being able to rapidly respond to product feedback.
Another challenge with a more dynamic toggle system is determining which configurations to test. It’s best practice to only test the toggle configuration that is expected to go live in production, but for safety reasons many teams also perform some tests with all of the toggles they intend to release flipped On. This allows them to verify that the new release doesn’t break existing or legacy functionality in the event that they need to revert the toggle to Off at some point in the future.
