Why Using Cookies in React.js
By Benoit Tremblay - Published 2018/10/22
While spending a lot of my time playing with cookies, I’ve learned quite a lot and would like to share my insight with you on when and why you should use them and why you should not.
Your cookies are sent with all your requests
SSR is a very popular approach in React.js where you render statically on the page how your Web app will look like at the page load. That way, your user can see the application a lot quicker until the real app is loaded. However, if your user is already logged in or have custom settings, your server needs to know about everything. This is where cookies are becoming very handy. By using a library like universal-cookie-express and react-cookie, you can automatically load the user cookies within your code and when doing the rendering on the server-side, you could get and save cookies on the server the same way you would do on the client.
Authentification / Session ID
Saving authentication tokens or session ID within a cookie is a good idea because you most likely need them everywhere. Having them sent with every request is handy because it becomes one less thing to think about. If you also want to include them within your AJAX requests, make sure to use the
credentials: 'include or same-origin' if you are using fetch or
withCredentials: true if you are using XMLHttpRequest. Otherwise, your cookies might not be included with the request if you are using fetch or XMLHttpRequest and your API is on a different domain.
Limiting the scope of your data
This is by far the less understood part of cookies and their default behaviour. By default, the scope of your cookie is the current path. If you are saving a cookie at https://example.com/cat, you will be able to access it if you are at that exact page or sub-page (example https://example.com/cat/pacman). However, you will not be able to access it on the home page or any other page not starting by /cat. If you are a beginner and don’t know about that, it might be frustrating to see your cookies appear and disappear. However, the solution is easy. If you wish to make your cookies available everywhere, just set
path: '/' when saving your cookies. However, you also have the option to make them available only on a sub-set of your pages. If your Website is not a Single Page Application, you can limit the scope of your cookies to the minimum you need them.
You can also share your cookies between sub-domain by using
domain: ‘.domain.com' (with a leading dot). You can also limit your cookies to a specific sub-domain by making it explicit. If your cookies have an authentication token, it is also a good idea to limit them to only HTTPS by setting the
secure: true flag.
Have an expiration date by the browser
Finally, the last benefit of using cookies is the explicit expiration date. You can tell the browser for how long your cookie should live and when it should expire. That you, you can make sure the user has to re-login or doesn’t use an expired authentication token. The same behaviour could be replicated by saving a date in your local storage, but it is nice to have something to enforce it.
Using the local storage
If you don’t care about any of that, you might as well use the local storage. It is supported by every browsers. Instead of having a limit of 4K per cookie, your local storage has an overall limit of 5MB.