A toggle is a switch that allows users to quickly change the state of an application. Typically, toggles control either settings or views within an app, and they can be configured to be on or off at any given time. When using toggles, it’s important to consider both the way they are deployed and their intended purpose. This article will explore best practices for managing toggles and offer guidance on how to make them effective for a variety of use cases.
General Definition
A toggle can be a simple on/off button, like the one that turns your Caps Lock on or off on your keyboard. Toggle switches also exist in computer hardware as a means to enable or disable a feature, such as Wi-Fi or Bluetooth.
Toggles in software allow developers to hide features before they are ready for public release. This allows dev teams to complete code sprints while keeping the features they’re working on inactive until they are finished and can be merged back into trunk. This approach helps support more agile development processes that may otherwise require a long QA and testing cycle before the new feature can be rolled out to production.
When creating and deploying feature toggles it’s important to keep the scope of each toggle as small as possible. It can be tempting to create large swaths of functionality that are controlled by a series of toggles, but this approach can be confusing for the team and a nightmare to debug weeks or months down the line when changes are made to other parts of the product.
Best Practice: Name Toggles
The first step in making a toggle work is to give it an identifiable name. This gives some useful context to someone who stumbles upon the toggle in an error message or code review. It also helps ensure that the appropriate person is aware of the impact of a toggle’s current state.
Finally, it’s important to have a process for managing the lifecycle of toggles. As with any other feature in the codebase, toggles should be pruned as soon as they are no longer needed. This can be as simple as adding a task to the team’s backlog or as complex as building a process into your toggle management tool.
A final note: When managing toggles it’s important to choose an approach that enables dynamic in-memory configuration. If a toggle must be hardcoded in the codebase or exposed via a static endpoint then you will need to manually re-deploy an artifact into your test environment every time the toggle’s configuration changes. This can significantly slow down the speed of your test cycle and hurts the all-important feedback loop of CI/CD. Fortunately there are a number of options for managing toggle configuration ranging from the very basic, but less dynamic approaches like commenting on the code to more sophisticated and more dynamic alternatives such as a Preprocessor’s #ifdef feature or a JavaScript conditional statement.
