-
-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: feature complete contents parser #44
Conversation
This is useful for getting results other than videos, like playlists and channels.
Awesome! This looks very promising, thanks for contributing. |
Just to confirm: This library uses snake_case for fields and camelCase for methods? |
lib/core/Actions.js
Outdated
@@ -283,7 +283,7 @@ async function search(session, client, args = {}) { | |||
switch (client) { | |||
case 'YOUTUBE': | |||
if (args.query) { | |||
data.params = Proto.encodeSearchFilter(args.options.period, args.options.duration, args.options.order); | |||
data.params = args.options.hasOwnProperty('params') ? args.options.params : Proto.encodeSearchFilter(args.options.period, args.options.duration, args.options.order); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this won't be necessary, I've been working on the protobuf definitions for more search filters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I could tell the channels and playlists are only returned if you do not send any params, but maybe I'm missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that's correct.
But I assume that happens because the “type” search filter is missing in the protobuf definition, so YouTube is basically defaulting to “Video” when it should be “All”.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that's right. |
Added common renderers used when searching artists
These are needed for channel tabs: Videos, Playlists, Community, Channels Additionally, do not merely return text as string, since they may include links which may be navigated to
Channels should be viewable when not logged in, also added 'navigation' type for use in NagivationEndpoint in the future.
The HomeFeed class remains compatible with the existing API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This adds typescript
as a development dependency
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is related to issue #21 which also suggested it not be written by hand!
Nice! That will make things much easier to maintain. |
lib/core/Channel.js
Outdated
|
||
/** | ||
* @note home_page only returns videos! | ||
* XXX: should some other API be made available to expose the content of the channel |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think advanced users should just use the Simplify API (which I will still document) to get the other types of content on the home page
Maybe the home_page
should also expose the channel trailer, but that might break the existing API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the
home_page
should also expose the channel trailer, but that might break the existing API.
The old channel parser was implemented quite recently, so you shouldn't worry about backward compatibility here.
I've just removed Simplify completely 🎉 |
Perfect! Also, could you move all data access classes from |
Sure. Some of those classes are very general though (Feed, TabbedFeed, FilterableFeed) and are meant to abstract away from the underlying results structure. |
Also added MenuServiceItemDownload
No problem, since those are for core functionality then it should be fine. |
To what degree must I try to maintain backward compatibility with v1? The new getTrending response is completely different from v1 |
Doesn't really matter at this point — we've already changed so many things that it wouldn't make sense to try and keep backward compatibility here and there, but not everywhere. |
I think this PR is about ready to merge then I can continue work on this repo. |
Yup, merging now. |
Feature complete contents parser
Description
Add parsers for all known renderers and provide complete typescript definitions for all of them.
This allows the library to parse all of the contents instead discarding a lot of the valuable information.
Type of change
I will attempt maintain backward compatibility with the existing APIs
TODO:
Checklist: