Engineering Blog

Using sessionStorage for SPA feature switching

tl;dr

Release and integrate code often to de-risk front-end SPA development. Hide unfinished features with sessionStorage.

Why?

During development of a new feature it is important to continuously integrate and release early and often so that developers and quality assurance engineers are given a faster feedback loop on bugs and technology blockers. Features may take weeks or months before release; waiting until the end of development to integrate code with a continuously evolving system creates excessive risk toward the end of the project that may jeopardise delivery. Feature switching solves the problem of having unfinished features integrated on the master branch, by providing a mechanism to enable and disable that feature for manual and automated testing.

Feature switching UI features through environment or backend configuration can lead to fairly invasive code changes; creating touchpoints in multiple system layers and build configurations that create regression risk when implemented or removed. Back-to-front feature switching also creates a dependency between backend services and front-end code which might restrict autonomous release-ability of SPAs (single page applications) and back-end services. SPA only feature switches using sessionStorage will restrict code touch-points to the front-end, and will not affect the release cycle of the SPA.

How?

SessionStorage provides methods for getting and setting arbitrary strings which will persist over page reloads but will not persist after the browser window is closed. SessionStorage data will not be shared across multiple browser tabs which differs from the behaviour of localStorage which provides persistence across sessions and tabs. LocalStorage can also be used for feature switching, though the potential to forget that a feature is on for that developer or QA engineer may lead to a false sense of security; e.g. regressions caused by the side-effects of technology choices might not be apparent if the feature is switched on. Having a feature on in one tab and off in another is also useful during manual testing. SessionStorage works in IE8 and above.

Word of warning: Just because the feature is switched off for your users doesn’t mean it is safe from a security, quality or performance point of view, your usual QA process must be adhered to during integration.

The example below uses sessionStorage to get the value of an arbitrary key representing the on/off state of a feature.

if(sessionStorage.getItem("app.featureswitch.searchresults") === "on"){
	router.add("search/:id/results", showSearchResults);
}

To enable this feature the developer, QA engineer or test automation script simply runs the following in the browser’s console.

sessionStorage.setItem("app.featureswitch.searchresults", "on");

Or as a bookmarklet.

Javascript:sessionStorage.setItem("app.featureswitch.searchresults", "on");

This incredibly simple way of switching SPA features on and off for initial development ensures that technology choices are de-risked early, feature bugs are discovered sooner, and merge and integration conflicts are less severe and happen less often.

comments powered by Disqus