abandon yt js api

[ThaUnknown]

youtube's JS API for the most part isn't needed, because I think the autoplay bug can be fixed by appending &playlist={id}, however I don't have a Mac to verify this, instead the JS API can be "spoofed":

  let frame: HTMLIFrameElement
  function ytCall (action: string, arg: string | null = null) {
    frame.contentWindow?.postMessage('{"event":"command", "func":"' + action + '", "args":' + arg + '}', '*')
  }
  let timeout: ReturnType<typeof setInterval>
  frame.onload = () {
    timeout = setInterval(() => {
      frame.contentWindow?.postMessage('{"event":"listening","id":1,"channel":"widget"}', '*')
    }, 100)
    frame.contentWindow?.postMessage('{"event":"listening","id":1,"channel":"widget"}', '*')
  }
  function ytMessage (e: MessageEvent) {
    if (e.origin !== 'https://www.youtube-nocookie.com') return
    clearInterval(timeout)
    const json = JSON.parse(e.data as string) as { event: string, info: {videoData: {isPlayable: boolean}, playerState?: number} }
    if (json.event === 'onReady') ytCall('playVideo')

    if (json.event === 'initialDelivery' && !json.info.videoData.isPlayable) {
      throw new Error('video not playable')
    }

    if (json.event === 'infoDelivery' && json.info.playerState === 1) {
      // video playable
    }
  }
  window.onmessage = ytMessage

this saves loading their 200kb or so API

[paulirish]

&playlist={id} sounds quite clever, for sure.

Will have to try that out.

Really appreciate you filing!

[ThaUnknown]

the id for playlist is ofc the video id

[Garbee]

I think the question before deciding to abandon (past ensuring this works as expected for the use cases) is, do we not want to expose the API? It is quite powerful for developers to control the player. Is there a way for them to attach the JS API on top of the embed if we remove it?

Currently we don't expose it against the video, sure. But it has come up that some do want that made public.

If we want to try and "trim everything down", then maybe loading the YT API and exposing the instance against the video is something we could let developers opt-in to.

[ThaUnknown]

I think the main goal of this lib is to make as light of an yt embed as possible, the js api isn't always included anyways, only on some specific browsers, so it's not like it's a compatibility change

[ThaUnknown]

and again, all this stuff can be exposed via this api spoof I showed