hibroseph / spotsync Goto Github PK

Currently the queue is generated from the party hosts top tracks. I want to generate the queue from all current party attendees top recommended songs. You will need to follow some of the Spotify API documentation such as the recommendation endpoint can only accept 5 seed tracks.

There will need to be logic to determine which 5 seed tracks are used if there are more than 5 people or which 5 seed tracks to use from which people.

There currently is no logging. We need to add exception logging. I believe I would like to write the exceptions to a file to be retrieved later since we do not have a database. This will probably require a logging framework that can thread safely add exceptions to a file

The output from webpack is HUGE (over 1.5 MB). We need to do what we have to to fix that.

User should be able to query for songs, artists, albums, genres etc and see search results.

When you log in to SpotSync, the app receives an access token that is good for an hour. After an hour, we need to get another authentication token with a refresh token.

We need to allow this so

1. It can be saved in their Spotify and there is more of a parallel
2. We can start using this data to roll our own predictive analysis for songs they would like

Discussion

• Should we save songs in our database or just use Spotifys. We can access songs favorited/ in playlists from their API https://developer.spotify.com/documentation/web-api/reference/library/

wrench.js has been depreciated. I don't explicitly use wrench.js but I believe it is used on the file-loader for webpack. The webpack site says file-loader is deprecated in v5. Let's remove file-loader for modules and see if that fixes the build

It would be ideal that we could add new features without making it available to everyone that uses our software. Ideally this would be database driven so we could change it on the fly without restarting the app.

Discussion:

• If this is stored in the database, how should it be stored? Column per feature? A complex datatype such as JSON (we are using POSTGRES which JSON is a supported datatype)?
• Should the user be able to enable all beta features or enable specific features?

Notes

• This could be a framework used for showing new features

If you go to a party that is real but you are not joined in with a url (https://spotibro.com/party?partyCode=SQXJC6) It will never show the queue or history but will show that you can leave the party when you are not joined.

Ideally this page would show current playing song, queue, and history. You could even sync music for the current song but still have an option to join. Probably joining this party would remove you from other parties

Currently running the app in Docker only work if you run it from Visual Studio if you already have the dependency containers running (such as postgres). We should be able to start all the necessary service containers with a single command

Right now the footer is very simple. It just has the app name with who created it. It would look much more professional if it followed the same idea that most web sites do.

This probably means having multiple columns with related links on those columns

Links we could include

• Github url (maybe as a Github icon)
• Link to my profile
• Privacy Policy
• Feature Request
• Report an issue

This should be created in a way that adding more footer values are easy to add

It would be nice if back and forward buttons could be used to go through different component states. I am not sure what that would look like since it wasn't thought of like that from the start

If you are joined in a party and you use the url to go to another party (spotibro.com/party?partyCode=NotYourCurrentPartyCodeButARealOne), it will load the party you ARE joined in but show the party code that you searched. This is not ideal.

You should be able to go to other parties if you know the code and the information between the two parties will not conflict

I can't sign back in after signing out.

Currently different code paths are hit for host and listeners. We are able to test the host with your Spotify account but usually need another account to test the listener perspective. We need to engineer a way to test both.

The future style has been determined for Spotibro. We need to redo the login page to make this the same

This project needs basic documentation of architecture, getting set up and running, etc.

Chat with me if you'd like to do this and I can explain what needs to be explained

The party page shows a blank song list. This needs to either be conditionally rendered on the party page or passed to another page . I think I would rather a lot of the functionality that is currently in the party page be moved to other pages.

There are some essential parts of our application that we need to have unit tested. This is to have the end goal of enabling continuous integration. We need to have enough confidence in our tests that we can release automatically

Parts to get code coverage first:

• Playlists can be created
• Events are emitted (such as when the next song comes)
• You can join a party
• You can leave a party (also include while being in a weird state, being in 2 or more parties at once)
• Make sure when you logout, you leave all parties

We have a few views that return paged data. This happens most often on the track list but it would be nice to have this be generic so we could add the functionality anywhere that has paging.

Things to think about:

• What is different between all the different ways to page?
• What is the same

Move the things that are the same to the generic functionality and pass in the differences as parameters

This will integrate Spotify into the browser so we do not have to connect to their other instance of Spotify

Create a page that is visible for the release log.

This will require some dicussion, should it be a static page or be populated from the database

Right now the text in the disconnected Spotify Popup is not the clearest.

We could clear it up by:

1. Rewriting it with clearer language
2. Have feedback when the press sync (either give it more things to try or tell it that it failed, maybe a loading icon while it is trying)

If you access the page with mobile, the menu will not appear despite the menu being there

We can cache the users playlists as well as users top songs to reduce API calls

If a user does not have a current device found, we need to do something (either logic to find an active device or relay information to user)

Logic needs to exist so that shuffle is turned off for all those that join a party

Currently trying to write code to unit test the parsing logic of the SpotifyHttpClient. This relies on the JSON that Spotify returns to me. I was thinking that I could easily test the parsing logic but mocking the HttpClient.SendAsync method to return the JSON of a specific API endpoint and comparing the parsed output to what I expect to make sure it is parsing correctly.

I am not sure if I am going about this the right way. The code resides SpotSync.Tests > UnitTests > SpotifyHttpClientTests

When I run npm run build I get the following error.
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]
Here is the full console log.

Anywhere in the code we need to rename SpotSync to Spotibro.

This should be changed and only prompt you for connecting your Spotify when you have a playlist and it is trying to play a song

I am pretty confident that nothing that needs to be secure is shown on Azure Devops but I would love a second pair of eyes on Azure Devops. Go to the builds and releases and make sure no one can do/see anything confidential. (SSH keys, passwords, usernames)

https://dev.azure.com/Kipley/Spotibro

If a user leaves a party or wants to log out, we need to make sure the app doesn't modify their Spotify app anymore. This needs to be fault tolerant and robust.

If an error occurs, we need to make sure the operation of leaving a party happens no matter what

We are able to get the users profile image, we should display that in the nav bar to add some personalization to our app.

If there is an unhandled error, it would be great if we displayed a page with that verbage. It would be great if the user could easily add more information and tie it to an exception so it can be solved faster

An idea but we might be able to hash a unique part of the exception and keep track of what exceptions are most common.

Pretty self explanatory

We need to create a UI that will allow us to use our complex queries to add songs to the queue

We only need to output the bundle javascript file and not all TS files.

you can specify to have explicit songs in your party or not.

If there are no explicit songs allowed and a person tries to add one, it will warn them before adding it

Currently when the app is run and has successfully received a cookie, the app will consider the browser logged in even though the user doesn't exist in the cache since the app was restarted and the cache is in memory.

We probably should make sure all cookies are reset on every restart of the app

We need to be able to run the app on a specific port when debugging so we can simplify the getting started process. This means we explicitly state what port to use so we do not need to modify the Redirect Url.

Currently if a request fails to Spotify (such as play this song), it will not retry that request.

We should bake in a retry API request logic. We might roll our own or look at existing solutions (such as Polly)