Closed oyeanuj closed 5 years ago
At a glance it looks like it just renders an image that loads the player properly on click. There's no reason you can't do this right now by just rendering a thumbnail that gets replaced with ReactPlayer after clicking.
Some possible problems with including it as a feature of the library:
style
attributes that may cause CSP problems.@CookPete All valid points. Some follow-up thoughts:
At a glance it looks like it just renders an image that loads the player properly on click. There's no reason you can't do this right now by just rendering a thumbnail that gets replaced with ReactPlayer after clicking.
Totally, I figured it would be repeating logic for a lot of users. To fetch the thumbnail image, etc.
On breaking autoplay: Both the above links this and this seems to not have that problem on Chrome.
On styling: I was thinking it would be an opt-in prop, and then you we could supply an example for styling it, similar to how you do today for responsive videos.
Yes, that would be a nice tracking goal that maybe community can help with as well once we have a standard implementation/example :)
I think what I was realizing was that the benefits on page load and speed might be significant to recommend as a best practice for a popular library like this - standardizing an efficient soliution (even if it is opt-in).
Thoughts?
@CookPete Just following up if you had any more thoughts based on the above comment?
Sorry @oyeanuj, all good points:
On breaking autoplay: Both the above links this and this seems to not have that problem on Chrome.
They do for me. Is it possible that these sites are over the new "media engagement" threshold on your Chrome, that allows autoplay?
https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#mei
On styling: I was thinking it would be an opt-in prop, and then you we could supply an example for styling it, similar to how you do today for responsive videos.
Yeah fair point. We could have an import 'react-player/light.css'
or something, with some basic CSS for a centred play button.
Yes, that would be a nice tracking goal that maybe community can help with as well once we have a standard implementation/example :)
I guess as long as it is documented somewhere which players support thumbnail previews, then that's good enough.
I think it's a good idea and wouldn't be too intrusive to implement. Happy to leave this issue open and look into it.
@CookPete I was doing a little bit of research for something else and realized that Youtube and Vimeo both support thumbnail previews. Did you get a chance to look more into it as per your above comment?
@CookPete Any updates on this one? Did you get a chance to look into it more?
@oyeanuj light
prop added in 1.8.0
. Let me know if everything works ok for you.
@CookPete Thanks you! Just got a chance to implement it - it mostly worked great except for a couple of little things:
The request to NoEmbed is made it via http
which is blocked by default on https site. Is there a reason to prefer http
over https
when making the noEmbed
call?
On clicking, can we default to playing to prevent repeat clicking on the play button?
@CookPete Just wondering if you had any thoughts on the above issue? (1) is particularly a blocker on using this feature.
Hey @oyeanuj, the https
problem should be sorted in 1.9.1
.
As for defaulting to playing, that's just a case of passing in playing={true}
to the light player.
I've added a light mode toggle to the demo app so you can play around a bit more now.
Great, thank you for the quick fix!
Hi @CookPete, back again!
One of the issues that I've been facing on my site is that even having a single Youtube embed on a page can really slow down the site. On researching further, it seems like Google+ and others use a slightly different technique for not loading Youtube videos by default, and instead only on click using the methods described below:
Thoughts on whether this library should support that?