There are two problems with the current implementation of local storage. This is how it works at the moment:
$scope.$storage = $localStorage.$default({
config: urlConfig || clockConfig
});
That is, it takes values from localstorage first, if it is not there, it takes the default fallback, which is either the configuration from the url, or, as last resort, the config file.
updating code base
If clock has updates in its codebase that is incompatible with historic configs, users that have used the clock before already have some stuff in their localstorage. These users never get the new config. Worse, their stored config may break the clock entirely.
development
During development it is often useful to test with different configurations. Clearing localstorage every time takes a long time
Proposal
There are two problems with the current implementation of local storage. This is how it works at the moment:
That is, it takes values from localstorage first, if it is not there, it takes the default fallback, which is either the configuration from the url, or, as last resort, the config file.
updating code base
If clock has updates in its codebase that is incompatible with historic configs, users that have used the clock before already have some stuff in their localstorage. These users never get the new config. Worse, their stored config may break the clock entirely.
development
During development it is often useful to test with different configurations. Clearing localstorage every time takes a long time
Proposal