Configuration

[Fauntleroy]

Objective

Allow configuration of media players via props, specifically the client_id of the SoundCloud player.

---

What I did

• Added the soundcloudConfig, vimeoConfig, and youtubeConfig props.
• Moved some configuration data into defaultProps accordingly.
• Ensured that every player would automatically set its volume on startup.
• Updated the debug page.

---

How to verify

• Pull this branch
• Run npm run start
• Go to http://localhost:3000/
• Write custom configuration JSON and set it, such as:

{
  "youtube": {
    "playerVars": {
      "autoplay": 0
    }
  }
}

• When initialized, the YouTube player should be modified accordingly. Note: This will not work on players that are already initialized.
• Modify the volume
• Switch to another player
• The player should be at the volume you set

---

Screenshots

[Fauntleroy]

One important thing to note is that if you pass in a configuration object via props it will completely replace the default one. If preserving the other defaults while changing one thing is important to you, I can try to merge the configuration objects instead.

[cookpete]

You should use let here I think

[cookpete]

Hi @Fauntleroy. Many thanks for your contribution!

I'm wondering if a prop for a config for each player is polluting the top level props too much, and maybe something like a playerConfig object to hold all of them would be better? Although then I suppose it could get awkward with default props and object merging for each player.

I also wonder if the deep structure is slightly overkill at this point, and whether we should just use youtubePlayerVars, soundcloudClientId and vimeoFrameParams instead.

[cookpete]

Also, I've just pushed 0.1.0 with file support and some other minor bits which you will have to rebase on. Apologies!

[Fauntleroy]

No problem, @cookpete! I'm more than happy to contribute to anything that'll rid me of JWPlayer (and the delicate browserify-shims that come along with it).

Concerning the use of top-level props like soundcloud, vimeo, and youtube, I spent a while thinking about it last weekend and chose this approach for the following reasons:

• Why props? Using props to configure a react component seems like the best way to handle this (as opposed to a static like Player.setConfig(...))
• Why top-level? These are pretty obscure configuration options that I don't expect most users of this component to utilize (aside from maybe the SoundCloud client_id, which you might want to emphasize). Since these props are optional, that means most users won't ever have to pollute their render methods with them.
• Why not one playerConfig object? Using separate props with keys related to each provider, in my opinion, is a cleaner and easier to use abstraction in practice.
• Why deep objects? These objects, while a bit unweildy, leave plenty of room for adding additional configuration options in the future. I'm going to resolve the issues with preserving react-player defaults by using Object.assign (or similar) to merge those defaults properly when the SoundCloud, Vimeo, or YouTube player is initialized.

[Fauntleroy]

I responded to the code review comments, updated the way default playerVars and iframeParams are handled, and fixed the initial volume issue with the new FilePlayer.

[cookpete]

Can we call this DEFAULT_IFRAME_PARAMS?

[cookpete]

Typo: iframParams in commit message for 989d4f1

[cookpete]

Looking good Tim. I've made a few more notes, then we should be more or less good to merge :)

[Fauntleroy]

Variable names changed, commit message amended.

[cookpete]

Nice work. Could you squash the commits up into the different features you added? I think it could just be one for the config stuff, and one for the volume setting fixes. Leaving in fixup commits feels a bit untidy.

[Fauntleroy]

Commits squashed.