Replace cookies with localStorage

[xPaw]

Fixes #69. We don't need to store any of the data on cookies, localstorage is better suited for this.

[astorije]

It's rather a non-minor change, I'm very much in favor of having 2 reviews for this (not that I am against this, quite the opposite, but 2 reviews rather than 1 seem safe and sensible to me here :-) ). Removing the second review needed for now.

[AlMcKinlay]

At a first pass, this looks good. I'll take a more detailed look later, and run it to make sure it works. Looks good so far though, and nothing to comment as of yet.

[AlMcKinlay]

👍 Looks good, seems to work fine.

[astorije]

This is really great indeed, 👏 @xPaw!

One thing that might be more relevant in the future than this PR, but still worth noting: by releasing this, everyone currently with specific settings will see their settings reset to default.
Avoiding that or not is a trade-off: having code that defaults to reading from the cookie that or not. Drawback is of course that this code will be less and less relevant over time...
Considering that this fork is pretty new, our current userbase is small and the amount of settings is too, so I think we can simply ignore that for now and simply add a notice on the change log / release information. However, this is something we should keep in mind next time we have a similar change on bigger legacy.

What do you think?

[xPaw]

Yeah, as our fork is rather new, I wouldn't want to introduce backwards compatibility like this just yet.

[AlMcKinlay]

Yeah, I agree with that. I think it's a little annoying in the short term, but not enough as it's really not hard to reset your settings once as there aren't that many settings.

I wouldn't want to invalidate the settings again, but this once at the beginning of our fork sounds fine to me :-)

[astorije]

Agreed with both of you. I'm thinking we might have to do that later on though: when introducing packages, we might want to namespace settings to avoid packages playing around with settings from other packages. But a fight for another day I guess :-)

👍 and merging.

[AlMcKinlay]

I'm thinking we might have to do that later on though: when introducing packages, we might want to namespace settings to avoid packages playing around with settings from other packages.

Possibly, yeah. We can take that as it comes along :-)