Panther is a full-stack React/Redux/Node web app that uses the Spotify API to make suggestions based on an initial user-specified artist.
It uses a graph consisting of vertices and edges to represent the data. At the center, the user's currently-selected artist, along with the artist's avatar and some audio samples of the artist's top tracks. To the left is a vertex representing the previous artist, and to the right are 3 suggestions. By clicking on the vertices, users can move forwards and backwards through their suggestion tree, (hopefully) discovering a bunch of awesome new music.
This project is a fun side-project, and is not a serious endeavor. I've not tested its browser compatibility and have not had time to fix some issues on mobile :)
The most challenging part of this project was coordinating and animating the sequence of events that happen when a user clicks a related artist:
I also didn't want this flow to be strict. If a user clicks a previous artist node, I shouldn't need to create a whole new workflow for it.
The solution I came up with was to have Redux Saga tackle the API requests and overall app state (like whether the app is "loading" or not). Everything else is a simple function of state.
The Graph component is handed a new state when the selected artist changes. Redux doesn't concern itself at all with this orchestration; it just makes the necessary changes to the Graph state and passes it along.
The component then works in 3 steps:
This flow works in either direction: When clicking previous nodes, it follows the same generic steps to transition from left to right.
There's a problem, though. When going forwards, the animation needs to start before I have all the information.
Specifically, when a related artist is clicked, I need to start moving that node to the center immediately, even though I don't have all the data I need about it yet. I need to know its related artists, and I need to populate its audio samples.
Because of this, in most cases*, the flow outlined above runs twice:
* Note that this only happens in 2 stages when we need info from the API. When moving backwards in time, or when viewing artists we already have cached, it can be done in a single pass.
The graph's primary animation, when transitioning from one vertex to another, was a big challenge. Initially, I had set the vertices as plain
div elements, and used React Flip Move to calculate their change in position. This did not work for the edges, though; They don't simply need to move from one position to another, they need to change shape as the line rotates and translates.
In the final version, the graph is one big SVG, which contains
circles for the vertices and
lines for the edges. The strategy I employed was very similar to that of the FLIP technique, but with the special SVG properties.
The first thing I needed to know was where every vertex will be positioned, using their
y coordinates, calculated from the top left of the screen. I cut the screen into 3 on-screen regions: PAST, PRESENT, and FUTURE (there is also GRAVEYARD and CATACOMBS, but those are both off-screen. They're needed so that edges don't just disappear once their vertex goes off-screen). I decided where exactly the 5 on-screen vertices should be. For example, the PAST vertex should be vertically centered, and horizontally 1/6th of the screen from the left:
| o | _ | _ | ^ ^ ^ ^ ^ ^ ^ 0 1 2 3 4 5 6
window.innerHeight, I figure out the number of pixels from the top left of the screen to its appropriate position, and I do this for all "slots" for the regions. Then, it was simply a matter of figuring out which region and position the vertex is being moved to in the next set of props.
Once I have both the initial position and the final position, I use
requestAnimationFrame to transition the vertex's
The edges work in a similar way. Lines have four coordinates, instead of two: x1/y1 and x2/y2, but these coordinates correspond to the vertex centers, so the calculation is the same.
This project was made so much easier by React/Redux. There are so many fiddly bits, potential timing issues, and edge cases that trying to account for all possible state permutations would have been impossible. Instead, I can make the views simply a representation of state; they just render whatever Redux tells them to without worrying about trying to account for all the changes.