Youtubeexplode: Add overload to SearchVideosAsync

[Kriste00]

It would be great to have the option to specify the number of videos instead of pages when using SearchVideosAsync.

[Tyrrrz]

I guess we can replace pages entirely with something like desiredVideoCount.

Scenario 1 -- playlist has fewer videos than desiredVideoCount or equal amount:

Returns all videos in playlist.

Scenario 2 -- playlist has more videos than desiredVideoCount:

Scrap pages until the result contains enough videos to satisfy desiredVideoCount and also parse all videos from the last downloaded page. This way the user can trim the resulted videos if they need to and the last page doesn't partially go to waste.

Would this be too counter-intuitive, considering resulting video count almost never will be the same as desiredVideoCount? Maybe the name should be different?

[Giggitybyte]

Figure I'd put my two cents in here.

I don't think you'd need to remove pages in favor of desiredVideoCount.
For scenario 2, I say just leave out the remaining videos on the last page and return only the amount the user requested. Scenario 1 shouldn't need to change.
If the user wants more control and wants to trim and filter the results themselves, then they can just use pages. desiredVideoCount would be more of a convenience for the user.

[Tyrrrz]

The problem with keeping both is that both of the parameters are ints (pages and video count) so there will be a method signature conflict, and I don't really want to introduce a method, e.g. SearchVideosByCountAsync.
Also, I think the existing solution, with pages, doesn't offer "more control". I think the issue @Kriste00 was having was that he didn't know how many videos he'd end up with, considering 2 pages can contain anywhere from 2 to 400 videos, depending on how many of them are blocked, deleted or unavailable (but still show up in the list).

[shaked6540]

How about adding an enum with a default value?
For example

enum ResultType 
{
    Page,
    Video
}

SearchVideosAsync(int count, ResultType resultType = ResultType.Page) {..}

That way you don't make breaking changes and users are able to get results based video count and not only page count

[SlowLogicBoy]

changing method signature is a breaking change (doesn't matter if it's with or without default value).
However adding an overload is not a breaking change.

[shaked6540]

Then add that method as an overload?

public async Task<IReadOnlyList<Video>> SearchVideosAsync(string query) { .. }
public async Task<IReadOnlyList<Video>> SearchVideosAsync(string query, int maxPages) { .. }
public async Task<IReadOnlyList<Video>> SearchVideosAsync(string query, int maxResults, ResultType resultType) { .. }

[Tyrrrz]

I've decided I want to wait with this until we have IAsyncEnumerable, which can probably help in solving this.

[beqabeqa473]

hi.

any thoughts for this specific issue?

i think, we can let thirdparty devs to make page loop in their own apps rather than in youtubeexplode itself.
because, if i am searching 100 pages, for example, it is too slw to finish search and give search results.
i didn't find a way to assynchronously search and return as soon as possible.

thanks.

[Tyrrrz]

I agree

[Tyrrrz]

I think a good design to solve this would be to return PaginatedResponse<T> from SearchVideosAsync(...). PaginatedResponse would then have a method GetNextAsync() to get the next page or null if there is none.
If someone wants to make a PR, I'm open.

[AlenToma]

Just a reminder, why dont you Add instead a pagination. eg PageNumberand Pagesize

public async Task<IReadOnlyList<Video>> SearchVideosByFilterAsync(string query, int maxPages = 1, int pageSize = 20, SearchFilterType searchType = SearchFilterType.Default)

[Tyrrrz]

Because unfortunately we can't guarantee page size, with videos being removed or blocked or whatnot

[spoikbr]

I don't know if this is pertinent to this issue, but wouldn't be better if we could specify the page?

Something like SearchVideosByPageAsync(string query, int page)
and some method returning the number of pages for that specific query

Thanks anyway, great lib @Tyrrrz