ionwyn / percify-dashboard Goto Github PK

While the development branch is already set-up for testing in interactive environment with yarn test, we still don't have any test cases.

Test Driven Development is not really my thing, anyway.

• At the moment, Redux states are a mess. We need to have consistency in our redux states.

At the moment, Actions return the userdata, which is then given to a component as props so components can do stuff with it.

This method is unreliable and therefore we need to use sessionStorage ? sessionStorage : localStorage to make user information accessible across components.

If a Spotify user account has no avatar, logging in will cause the site to crash.

This is because the site tries to take a profile picture from the returned JSON that the API calls. The API returns JSON without the key for user's image. Component tries to render the image, bug the image is undefined

At the moment, once a user signs in, a layout for that user is hardcoded in the user actions. We need to add a method to get the layout via dispatching an action.

When an unauthenticated user tries to access a URL endpoint, the site will crash. This is because the endpoint tries to get information about the user from the session or local storage, giving undefined when components try to access them.

At the moment, (mostly because I'm lazy), user access token expiry is not handled. This causes the site to loses user's data.

This is easily handled since, during login, our authentication method gives us initial access token and a refresh token. Refresh tokens can be used to generate a new access token. We can either

• Update the access token when accessing data returns fail
• Keep track of access token expiration, updating when the timer expires.

The current 'homepage' which displays a user's top tracks, artists, genres, and vibes don't look so good for User Experience.

Needs polishing

file associated: Home.js

When the user logs in, Toolbar takes a user's name for display. The API returns null for the user name's key. This can happen because:

• Upon signing up with Spotify, the user did not specify a name.
• The user did not sign up using Spotify.

I'm not sure which one it is, there may be other ways that the API returns null for a user's name.'

An idea is, when user's name is null, we simply display userID

The repo has a bunch of personal information that were committed. This has to be removed.

Snyk has detected Security Vulnerabilities. Some have workarounds.

If you visit the playback multiple times, the same song will play again, therefore doubling the playback.

To consider:
When components render, they may fire actions that trigger the playback. We need to know then there's a playback and prevent the player component from firing the actions that triggers playback

At the moment, for persistent login, I've implemented a global variable in commit 5919f4b on index.js for persistent login (meaning all components are aware of the existence or absence of a logged in user).

I wonder if this is a good practice. It seems suspicious. Is this an anti-pattern to Redux?

While this was an easy implementation, I suspect that it'd be better to use Intersect/FuseAuthorization or pass it through Provider.