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
API Direction Discussion #14
Comments
Ok, so I've thought a bit more about this and came up with this: <Media
source={{uri: 'http://example.com/example.mp4'}}
autoplay={false}
onLoadStart={() => console.log('media started loading');}
onProgress={() => console.log('media loaded more chunks');}
onLoad={() => console.log('media fully loaded');}
onEnded={() => console.log('media playback complete');}
onSeek={() => console.log('media seek performed');}
onUpdateTime={() => console.log('media currenttime changed');}#
style={style.media}
poster="pathtocoverimage"
videoResizeMode="cover"
/> Props
Optional/alternative props
When working with a playlist having the option to decide between JS API
Optional convenience apis
|
@johanneslumpe - I think this api would be fantastic. One thing that we might want to do instead of a poster (perhaps I'm getting ahead of myself here) is supply React component that is responsible for displaying some information about it, that way you could pass in an The main thing I'm not entirely sure about yet is how to deal with playlists - should it be the responsibility of the component to do this? If we reuse an AVPlayer instance, it would be trivial to wrap a media component to create a playlist, and would simplify the core api for this. If we support playlists, our number of props/methods will get about twice as big - we need to support skipping tracks, going back, callbacks for item specific things (onReachLastItem, onNewItemStart maybe, along those lines). I'm very tempted to defer support for multiple tracks until we have everything else nailed down. What do you think? |
I totally agree about having the ability to pass a component as value for |
So what's our next step? Do you want to merge the seeking code first? And we can work from there? |
@johanneslumpe - I'm away until tomorrow evening for a weekend trip 😄 if you add the seeking code into the example app and it works as you expect, I'm okay with merging it in and then we can discuss next steps tomorrow evening or on Monday! Thanks for pushing me forward with this 👍 |
@brentvatne 23 days have passed by, we need to make this happen ;) |
Agreed @johanneslumpe, I think we can get back into this now, let's try to get this out this week |
whoo, https://github.com/brentvatne/react-native-video/tree/new-api a basic start. Totally untested though - wip ;) |
@johanneslumpe - it just occurred to me, what behaviour would we expect if we are manually setting Should we somehow enforce that only one of the two APIs is used? |
There won't be a paused prop anymore. My proposed list of props is this:
Controlling the video should be done purely through the api. |
Ah ok, I saw that in the code still so I was confused 👍 |
Currently we control the whole video using props. I think it might be useful to only control basic things like
source
,autoplay
etc via props. For everything else we should start creating a proper api, which can then be triggered like this inside a component:I propose that we implement the following as api:
play
pause
togglePlay
(?)setRate
setVolume
setMuted
/toggleMuted
setRepeat
setResizeMode
seek
(already implemented in the feature/seeking branch)Thoughts on this?
The text was updated successfully, but these errors were encountered: