Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR will add the following feature:
Load the next set of videos in queue.
By queue I mean when the video is being played, the queue for next videos to be played.
This can happen with several interactions:
The first problem is a bit easier, we fetch the next set of videos when the last video starts to play or ends.
The second problem has two solutions:
Infinite Scroll
Pros: Smoother UX, Feels modern.
Cons: Addictive, "Unethical" (We don't have anything to gain by watchtime increase but users waste more time searching/waiting for a good video to show up), a little harder to implement and manage.
Loading Button
Pros: Ethical, saves time, easier to implement and debug.
Cons: Feels older.
Apart from the UX there are a few other difficulties as well:
The Video component and Queue in Store don't have a FeedType.
This is required because while loading the next set of videos we want the FeedType from which to load the video.
The Lists and Queue in the reducers serve the same purpose.
The current approach is to load the data from API into the lists and then fill the Queue whenever the user starts a Video.
Due to this there is duplicate data present in queue. As the state of the queue visible in the component is different from that stored in the redux store, the state of the redux store is useless. The Queue is just another step in between the Store's lists and the local state queue in the component.
This affects the problem in hand because when we need to fetch new videos to add to the list, we have to:
Instead of this, we can store a current playing list type variable and simply update the local queue of the component with the list of that type. Fetching new videos to add to the queue will be simplified: The new videos get added to the list, the local queue is updated with the list.
In the spirit of simplifying, I have added the type of the current list in the queue. With some modification we can remove the posts variable and then it would resemble my suggestion above. Afaik, there are no specific usecases that require us to have a separate queue in the redux store. As this requires some thought and discussion, I have described the change here before implementing it.
Please review the idea, I will start on the feature as soon as we land on a consensus.
This PR will fix #50