[GH-ISSUE #313] A way to search for multiple types of content #96

New issue

Closed

opened 2026-02-27 20:23:05 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 20:23:05 +03:00

Owner

Originally created by @PaulOlteanu on GitHub (Apr 27, 2022).
Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/313

Is your feature request related to a problem? Please describe.
Currently the only way to use the search API is to specify the type of content you'd like to search for (e.g. Track, Album, Artist, etc.). I'd like to search for multiple, or all types of content.

Describe the solution you'd like
The search function should take an option of a list of SearchTypes (e.g. Some(&[SearchType::Album, SearchType::Track])).

I'm not sure how the SearchResult would work, perhaps the response could be a Page<SearchResult>, and have SearchResult be an enum with a variant per content type (e.g. SearchResult::Track(FullTrack), SearchResult::Album(SimplifiedAlbum), etc.)

Edit: An even simpler way would to have SearchResult be a struct of options:

pub struct SearchResult {
    playlists: Option<Page<SimplifiedPlaylist>>,
    albums:    Option<Page<SimplifiedAlbum>>,
    artists:   Option<Page<FullArtist>>,
    tracks:    Option<Page<FullTrack>>,
    shows:     Option<Page<SimplifiedShow>>,
    episodes:  Option<Page<SimplifiedEpisode>>,
}

while less ergonomic, this more accurately represents the actual Spotify API response (I also now see that the pagination wouldn't really be feasible the way I first proposed)

Originally created by @PaulOlteanu on GitHub (Apr 27, 2022). Original GitHub issue: https://github.com/ramsayleung/rspotify/issues/313 **Is your feature request related to a problem? Please describe.** Currently the only way to use the search API is to specify the type of content you'd like to search for (e.g. Track, Album, Artist, etc.). I'd like to search for multiple, or all types of content. **Describe the solution you'd like** The search function should take an option of a list of `SearchType`s (e.g. `Some(&[SearchType::Album, SearchType::Track])`). I'm not sure how the `SearchResult` would work, perhaps the response could be a `Page<SearchResult>`, and have `SearchResult` be an enum with a variant per content type (e.g. `SearchResult::Track(FullTrack), SearchResult::Album(SimplifiedAlbum)`, etc.) Edit: An even simpler way would to have `SearchResult` be a struct of options: ```rust pub struct SearchResult { playlists: Option<Page<SimplifiedPlaylist>>, albums: Option<Page<SimplifiedAlbum>>, artists: Option<Page<FullArtist>>, tracks: Option<Page<FullTrack>>, shows: Option<Page<SimplifiedShow>>, episodes: Option<Page<SimplifiedEpisode>>, } ``` while less ergonomic, this more accurately represents the actual Spotify API response (I also now see that the pagination wouldn't really be feasible the way I first proposed)

kerem

2026-02-27 20:23:05 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 20:23:06 +03:00

Author

Owner

@PaulOlteanu commented on GitHub (Apr 28, 2022):

I think the end result for the user is still gonna be the same - having to handle the search results for the different types independently, so I'm not sure there would be much point to this change (other then perhaps reducing the number of API requests made from 1 per content type per search to one per search)

@PaulOlteanu commented on GitHub (Apr 28, 2022): I think the end result for the user is still gonna be the same - having to handle the search results for the different types independently, so I'm not sure there would be much point to this change (other then perhaps reducing the number of API requests made from 1 per content type per search to one per search)

kerem referenced this issue

2026-02-27 20:24:07 +03:00

[PR #178] [CLOSED] Make cache file a optional feature #292