The next goal after initial shuffling works should be to enhance the UI to be more SPA-like. This includes the following:
Goals
Add a button to fetch more playlists, or even autoscroll
Click a playlist icon and replace the user info card with more details on the playlist, and buttons to allow operations on it
Home page wakes up to a "Connect to Spotify" button
Search for playlist to edit
Design
I propose using a mixture of htmx and possibly AlpineJS for the bulk of these. We'd start with some new HTML-valued endpoints:
GET /playlists/
GET /user/
GET /playlists/<id>
Routing
Initial request to / should give back htmx that either has the user and playlists preloaded or simply asks for them at the appropriate endpoints on load. Then clicking on a given PlaylistTile can fetch the data, and swap with the UserInfo card. That larger PlaylistCard can then expose buttons and more detailed information. When we focus away from the top detail card, we can restore the user card. We can naively hit the appropriate endpoint again, manage changes using the cache somehow, or keep the data in the DOM and just hide and show content as necessary. One crucial piece of this will be to figure out how to return Astro components from dynamic endpoints.
Search
Users of Playtron are likely to have a lot of playlists. In order for this tool to be useful, there needs to be a way to filter playlists given a string. There are two strategies we can take to implement this.
Implement a parameter on GET /playlists that would allow filtering to happen on the server. To be practical, this would require a user-level data persistence layer that we'll probably need eventually. This would enable the lightest weight front-end, but will also lead to increased chattiness in the application, especially if we filter on every keystroke.
Send all playlists to client and filter with frontend JS. This would require waiting for multiple API calls to get all the users playlists. Filtering can be implemented fairly easily using AlpineJS -- something like this.
For the MVP phase of this project, the latter is best, and won't prevent us from implementing the server logic in the future. We can optimize the amount of playlists we fetch by sending a subset on initial load, and fetching the rest when the user begins using the search bar.
Playlist Navigation
Even if a user doesn't use the search bar, they will want to browse the rest of their playlists. There are again two choices:
Pages
Infinite Scroll
Pages would be very natural to implement given the structure of the Spotify API, but infinite scroll would probably be more slick. Either way, we'd need some parameter on GET /playlists/ to allow pagination. Then htmx could handle placing the new data where it belongs. And either way, search should know if data has already been fetched in order to avoid grabbing it again.
cayala5
commented
9 months ago
Enhance UI
The next goal after initial shuffling works should be to enhance the UI to be more SPA-like. This includes the following:
Goals
Design
I propose using a mixture of htmx and possibly AlpineJS for the bulk of these. We'd start with some new HTML-valued endpoints:
GET /playlists/GET /user/GET /playlists/<id>Routing
Initial request to
/should give back htmx that either has the user and playlists preloaded or simply asks for them at the appropriate endpoints on load. Then clicking on a givenPlaylistTilecan fetch the data, and swap with theUserInfocard. That largerPlaylistCardcan then expose buttons and more detailed information. When we focus away from the top detail card, we can restore the user card. We can naively hit the appropriate endpoint again, manage changes using the cache somehow, or keep the data in the DOM and just hide and show content as necessary. One crucial piece of this will be to figure out how to return Astro components from dynamic endpoints.Search
Users of Playtron are likely to have a lot of playlists. In order for this tool to be useful, there needs to be a way to filter playlists given a string. There are two strategies we can take to implement this.
GET /playliststhat would allow filtering to happen on the server. To be practical, this would require a user-level data persistence layer that we'll probably need eventually. This would enable the lightest weight front-end, but will also lead to increased chattiness in the application, especially if we filter on every keystroke.For the MVP phase of this project, the latter is best, and won't prevent us from implementing the server logic in the future. We can optimize the amount of playlists we fetch by sending a subset on initial load, and fetching the rest when the user begins using the search bar.
Playlist Navigation
Even if a user doesn't use the search bar, they will want to browse the rest of their playlists. There are again two choices:
Pages would be very natural to implement given the structure of the Spotify API, but infinite scroll would probably be more slick. Either way, we'd need some parameter on
GET /playlists/to allow pagination. Then htmx could handle placing the new data where it belongs. And either way, search should know if data has already been fetched in order to avoid grabbing it again.