m-roll / hj Goto Github PK

Using GH actions, we should set up a way to build a docker image whenever we contribute to the master branch. This build will be pushed to the DockerHub repository. We will still need to manually deploy by pulling the repo on the host machine and running it.

#10

this will allow us to do faster lookups to see if a user pool contains a certain user. this way there won't be duplicates in a room.

On left hand side of UI, indicate if the user is logged in currently. If not, show a button that says "log in".

Service workers could be a good way to speed up load times dramatically, and pre-populate the queue if someone leaves the page. This would also help with back-end load as it could defer some of the work to off-peak hours.

This should be investigated if it's worth implementing anywhere. Performance is lacking on mobile but it would be great if it could be used there seamlessly.

If we attempt to play a song and the user does not have an active device, remove them from the pool of users for a given room.

Instead of throwing an error, just kick the user from the group that they are already in. If I were using the app, this is what I would expect.

Party, stream

Reading an empty state from the queue (i.e. on the page load for a freshly loaded room) causes the socket to crash. Should be a pretty easy fix.

Steps to reproduce:

1. Create a new room from the front end
2. This error will appear in the elixir console

While the connection is largely stateless, we cannot leak any users Spotify credentials. The scopes include playback, so if the credentials are leaked a bad actor could potentially control a victim's account.

SpotifyEx embeds the authentication information into the web page connection cookies. If we do something like retrieve an cross-origin image and send the cookies along with the request, the information could be captured by the other source.

There should also likely be a CSRF token embedded in the page. However, this isn't a huge issue since we restrict the usable callback URIs from the Spotify side.

We should show the playback status bar regardless of logged in status. However, if the user isn't logged in, cross out the headphones button. If they are logged in, allow them to change the device they are listening to by clicking the headphones button. If logged in, maybe put a green dot below it to encourage interaction.

Need to figure out why playback doesn't work with DeSpotify

When trying to listen on a mobile device, the browser gets stuck after trying to initialize the web playback SDK for Spotify. If this initialization fails, we should just hide the "click to activate" shadow box (That's there since we can't autoplay audio without user interaction. This forces that interaction) since the audio will play through some other device.

Me and Christian are in control of this codebase so we should switch to this and add on the beta functionality.

We should also check that the socket isn't terminated when the browser page goes inactive and loses connection. i.e. if someone locks their phone, what happens?

Any input with font size < 16px will force the screen to zoom.

If there are no active devices, the song sync fails. Instead, we should either

1. Restore the most recently used device (implicit - easier for user interaction)
2. Force the user to select the device they want to use, as if they were logged out (explicit, the users would have more trust over the program)

I am leaning towards option 2

Sometimes, clicking or tapping on the search results breaks the list. It flashes and then the buttons do nothing when clicked after this happens.

This could just be a modal that says they won't be able to listen but do everything else

We are generating the queue table using document.createElement which is annoying. We can use a JSX template instead to easily generate new rows to add to the table. Remember to import the React polyfill, use the other JSX file in the project as an example (the search modal results JSX file)

The Jukebox controller (controller/jukebox.js) should only be used as a way to "wire up" the application. The rest of the files are broken up into components pretty well, but the jukebox controller specifically has a fuzzy boundary of what it is controlling. We should pull out anything in this file that shouldn't be there and "invert the control" of this structure.

this is required for third party spotify apps

We need a way to store which device we want to play the audio on. This can be considered a part of the user state and should be stored in the user pool for each room.

This would be a really cool feature to add. In the "add song" window, before the search is done, populate the list with songs that are currently popular on the service.

Make the favicon flat and circular to fit with the rest of the design.

If someone leaves the page while the queue is empty, and is listening to their own music outside of the queue, playback will pause when the website is left. We should only pause if the music is synced with the queue.

There's a few little jumps when the screen gets smaller

Instead of making it a bubble, maybe make it just greed text with a big "plus" next to it.

We need an interface to show the user which devices are available to play their music through. The user should be able to set the device they are listening through through this interface.

This device will automatically be set to the one created via the Spotify Web Playback SDK, if it's available. Otherwise, just use the device the user previously set.

Use the unload javascript listener to determine when to unregister users from a group. At the moment, we rely on terminate/2 websocket callback in the backend to detect when a user leaves a page which is unreliable.

Might be worth consulting somebody at spotify about this. Upon playing a new track (on sync), I got this error. Oddly enough, after a couple retries the song play actually went through. Might be worth implementing a retryer utility process that will retry the request some number of times. Could possibly be an open source library as well!

Re-focusing the window on mobile (when playing in background) makes the status of the client out-of-sync. Maybe just poll the backend on focus to make sure everything is up to date

Keeping the room code in the URL slug clutters the users history with potentially expired room code URLs, and increases the odds that someone joins a room that has happens to reuse a name.

Instead, invite links should be generated by including query parameters that include some kind of encoded key that includes the room code in it. The key will be an encrypted token that is unique to that instance of the room code and is kept to the server. This way, we can validate invite links and only allow the user to connect if the invite link is valid for that session.

Types would help a lot for keeping the front-end maintainable. This would help us define behaviors for providers -- these are the objects that are expected to have certain members on them so callbacks can be coordinated between the view and the state of the application.

This will help us catch errors at compile time rather than when some bogus interaction occurs. Multiple inheritance will be especially useful since some objects fill the role of multiple different providers.

If we keep all of the history, we would give the user the option to add the song to their library after it's been played.

Also, highlighting the currently playing song could make it easy to identify the current song when looking at the queue.

People should be able to see the progress of a track if they are in a room, even if they aren't logged in.