Recap – storing state in a browser for users

I’ve been working on some static sites recently, and I needed to show some content to someone, but allow it to be dismissed easily, and then stay dismissed. This is much a note to future me as anyone else, but hopefully it’ll be helpful to some other soul on the net.

Doing this with frameworks like django or rails

When I’m working with a full dynamic site, how you do this is usually hidden from you using a handy data structure in the language that your framework is written in.

For example, in django you often have a handy session object available, which works like a dictionary you can get and set data on. Let’s say you have a blog, and you want to set some state on the user, to mark that they’ve commented on on a post you’ve written.

In some view code handling a get request, you might set a value on the session like so:

request.session['has_commented'] = True

Then, later on you could check for this by calling get on the session object:

if request.session.get('has_commented', False):
        return HttpResponse("You've already commented.")

Python also has a native cookie library that does a similar job, of storing state on a client browser, and sparing you the gory details.

This is very handy, but when when you’re working with a static site, you don’t have the server there to wrap all of it in some tasty syntactic sugar.

If like me, you’ve had it abstracted away from you most of the time, it might be useful to know your options.

Your options if you need to do it yourself

If you want to keep data on the client

Right now, if you want to store state just on the client you have two popular options: local storage, and session storage. In both cases you use javascript to write values, with an api that looks a bit like so:

// Save data to sessionStorage
sessionStorage.setItem('key', 'value');

// Get saved data from sessionStorage
var data = sessionStorage.getItem('key');

The main difference between localstorage and session storage is that session storage is automatically expired at the when you close a tab. By comparison, local storage persists, so you can visit a page, set some data, close it, and assuming you haven’t set a super short expiry date, access it again the following day  from the same browser.

You can’t access this from a server though it never leaves the browser.

If you want to be able to access the data on the server

If you do want data to persist for more than one session, and you want to be able to read this information on the server side (like the example the django example above), then cookies are a better fit. They work at the HTTP level, so they’re really sent as extra headers when you send HTTP requests to a server somewhere. Mozilla’s docs are fantastic if you want to learn more about what’s really happening under the hood.

You might want to have a similar API to the session and local storage APIs, to keep them easy to remember, so you can use javasscript to set data on a user’s client browser like so:

// set a value as cookie
docCookies.setItem(name, value)

// get saved value from the cookies
docCookies.getItem(name)

If you want this, then you want to look at the nice cookies.js library, that wraps it up in some nice synatactic sugar, and save you remember esoteric invokations, just to set some basic data on a client.

Just remember, you can’t set much data with cookies compared local storage or session storage.

Obviously if you’re sending data back and forth between a browser and server, there are privacy implications and in the EU, you should to inform users how you’re using cookies, to get consent before you start tracking your users. Again the MDN docs are a good concise starting point, if you need a reminder.