Have you ever been curious to see what your Spotify data looks like? How a round-up of your listening habits gets compiled every year? Or even wanted to see metadata of your favorite tracks? Luckily, Spotify makes a ton of interesting data like this accessible via the Spotify API. For example, there is data available for every users’ [top tracks and artists](https://developer.spotify.com/documentation/web-api/reference/#endpoint-get-users-top-artists-and-tracks) of all time and [audio features](https://developer.spotify.com/documentation/web-api/reference/#endpoint-get-several-audio-features) like danceability and tempo for every single track.

## Why this course

If you're interested in accessing personalized Spotify data like we mentioned above, Spotify requires your app to be authorized. And to get authorization, you'll need to implement something called OAuth. This course will walk you through every step of the OAuth flow in a concise, easy to follow way. Unlike YouTube tutorials that only cover a few concepts and leave you with half-baked GitHub repositories, we'll cover everything from explaining what REST APIs are to implementing Spotify's OAuth flow to fetching data from the Spotify API in React hooks. Split into seven modules, each lesson includes clear, detailed explanations and complete code examples. By the end of the course, you'll have an app deployed to the internet that you can share with your friends and add to your portfolio.

## What we’ll build

**On the front end**, we’ll build out a professional, responsive user interface with [React](https://reactjs.org/), React Hooks, and the popular CSS-in-JS library, [Styled Components](https://styled-components.com/). We’ll pull in data from the Spotify API using modern ES6 [async/await](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async_await) methods and display that data in an engaging way.

**On the back end**, we’ll learn the basics of [REST APIs](https://en.wikipedia.org/wiki/Representational_state_transfer), [HTTP requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods), and [OAuth](https://oauth.net/). We'll lift the veil on how to [authorize an app with Spotify](https://developer.spotify.com/documentation/general/guides/authorization-guide/), and then build a Node server with the [Express framework](https://expressjs.com/) to handle our authentication requests. Finally, we’ll deploy our app to the internet using [Heroku](https://www.heroku.com/).

![Top Artists](https://d2uusema5elisf.cloudfront.net/courses/build-a-spotify-connected-app/module_00/lesson_00.00/public/assets/screenshot-1.png)

![Top Tracks](https://d2uusema5elisf.cloudfront.net/courses/build-a-spotify-connected-app/module_00/lesson_00.00/public/assets/screenshot-2.png)

![Playlist tracks sorted by tempo](https://d2uusema5elisf.cloudfront.net/courses/build-a-spotify-connected-app/module_00/lesson_00.00/public/assets/screenshot-3.png)

Learn how to build a full stack web app to visualize personalized Spotify data with the help of Node.js, React, Styled Components, and the Spotify Web API.

Build a Spotify Connected App

---
title: Using Local Storage to Persist Login State
description: Learn how to use local storage to let users log in and log out
privateVideoUrl: https://fullstack.wistia.com/medias/5ghhguzzcu
isPublicLesson: true
code: https://gitlab.com/fullstackio/books/newline-course-apps/brittany-chiang-build-a-spotify-connected-app-app/-/tree/main/code/module_05/lesson_05.01/protected/src?ref_type=heads
---

In the last module, we successfully passed Spotify auth tokens from our Node server to our React app with URL query parameters. In this lesson, we'll set up a way for our React app to remember those tokens when they are no longer in the URL.

## Separation of concerns

First, we'll move our query param logic from `App.js` to a separate file to keep all Spotify-related logic in one place. It's good practice in projects like this to separate concerns — we don't want our `App.js` file to store any query param-related logic — all it needs to know about is whether there's a valid token or not.

Let's create a `spotify.js` file in the `src` directory of our React app, and move the logic we had in the `useEffect()` hook to a function in the new file.

```js
const getAccessToken = () => {
  const queryString = window.location.search;
  const urlParams = new URLSearchParams(queryString);
  const accessToken = urlParams.get('access_token');
  return accessToken;
};

export const accessToken = getAccessToken();
```

Then, we can refactor our `App.js` file to import the access token from `spotify.js` and use the `useState` hook to keep track of the token. We'll then use the `token` state variable to conditionally render the login button, or a logged-in state, with a ternary.

```js { actualFilename=./protected/src/client/01/App.js endChar=556 endLine=28 startChar=0 startLine=1 statedFilename=client/src/App.js url=https&#x3A;//gitlab.com/fullstackio/books/build-a-spotify-connected-app/module_05/lesson_05.01/protected/src/client/01/App.js }
import { useState, useEffect } from 'react';
import { accessToken, logout } from '../spotify';
import './App.css';

function App() {
  const [token, setToken] = useState(null);

  useEffect(() => {
    setToken(accessToken);
  }, []);

  return (
    <div className="App">
      <header className="App-header">
        {!token ? (
          <a className="App-link" href="http://localhost:8888/login">
            Log in to Spotify
          </a>
        ) : (
          <h1>Logged in!</h1>
        )}
      </header>
    </div>
  );
}

export default App;
```

Now, although we're able to let users log in to Spotify and grab the access token from the URL, we still have a problem. Our React app is only aware of the Spotify access token when it's stored as a query parameter on the URL — meaning if we visit <http://localhost:3000> again, we'll see the login button, not the logged-in state. We don't want our users to have to go through the login flow every time they visit our app, so how do we fix this problem?

## Local storage gameplan

We can store our tokens in [local storage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage), a mechanism of the [Web Storage API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API) which lets us store **key/value pairs** in the browser.

Local storage is very similar to session storage, but there's a key difference between the two. Session storage only stores data for the duration of the page session, while local storage stores data even after the browser is closed. In simpler terms, local storage will let us store data in the browser for a particular domain and persist it, even when the user closes the tab or navigates away from our app.

Here's our gameplan for using local storage in our app:

-   When a user first visits our app, we'll prompt them to log in to Spotify, then store the access token and refresh token from the resulting URL query params in local storage.
-   Since we know that Spotify's access token will eventually expire after 3600 seconds (1 hour), we'll pre-emptively store a timestamp in local storage to keep track of when the tokens currently in use were stored.
-   Then, the next time we need to use the access token to make a request to the Spotify API, we'll first check if there is a timestamp and access token stored in local storage. If there is, we'll check if the token is still valid by determining if the amount of time that has elapsed between the timestamp being set and now is greater than 1 hour.

    -   If the access token is still valid, we'll simply use that for our API request.
    -   If the access token has expired, we'll use the refresh token we stored in local storage to request a new access token from Spotify behind the scenes using our Express app's `/refresh_token` endpoint. When we receive the new token, we'll store it in local storage along with an updated timestamp.

In a nutshell, our app will store four items in local storage:

1.  Spotify access token
2.  Spotify refresh token
3.  Spotify access token expire time (3600 seconds)
4.  Timestamp of when the access token currently in use was fetched and stored

Whenever our app needs to send a request to the Spotify API with an access token, we'll use the access token we stored in local storage. In the case the token has expired, we'll refresh it in the background using our refresh token from local storage.

## Using dev tools

**Tip:** When working with local storage, browser dev tools are super helpful. In Chrome, you can find all items currently stored in local storage for `http://localhost:3000` under the Chrome Dev Tools' `Application` tab. From here, you can update or delete items as you wish.

![Chrome dev tools for local storage](https://d2uusema5elisf.cloudfront.net/courses/build-a-spotify-connected-app/module_05/lesson_05.01/public/assets/localstorage-devtools.png)

## Update the `/callback` route handler

First, let's update the `/callback` route handler in our Express app to also include the `expires_in` value in the query params of the redirect URL so we work with it in our React app.

```js { actualFilename=./protected/src/index.js endLine=80 startLine=67 statedFilename=index.js url=https&#x3A;//gitlab.com/fullstackio/books/build-a-spotify-connected-app/module_05/lesson_05.01/protected/src/index.js#L67 }
      if (response.status === 200) {
        const { access_token, refresh_token, expires_in } = response.data;

        const queryParams = querystring.stringify({
          access_token,
          refresh_token,
          expires_in,
        });

        res.redirect(`http://localhost:3000/?${queryParams}`);

      } else {
        res.redirect(`/?${querystring.stringify({ error: 'invalid_token' })}`);
      }
```

## Update the way we retrieve the Spotify access token

Next, we're going to update our `getAccessToken()` function in the `spotify.js` file. We'll start by declaring some constants at the top of the `spotify.js` file.

Learn how to use local storage to let users log in and log out