Since our initial launch of the Livepeer Player and in-browser Broadcast libraries, the Livepeer Studio team has been collecting feedback and iterating on developer experience, performance, and customizability. Today weโ€™re ringing in February with the launch of the Livepeer Kit - a ground-up rewrite of our React library.
๐Ÿ—บ ๐ˆ๐ฆ๐ฉ๐ฅ๐ž๐ฆ๐ž๐ง๐ญ๐š๐ญ๐ข๐จ๐ง ๐†๐ฎ๐ข๐๐ž๐ฌ ๐š๐ง๐ ๐‘๐ž๐Ÿ๐ž๐ซ๐ž๐ง๐œ๐ž:
๐ŸŽ ๐Œ๐š๐ฃ๐จ๐ซ ๐‚๐ก๐š๐ง๐ ๐ž๐ฌ
๐…๐ž๐ž๐๐›๐š๐œ๐ค: The Player and Broadcast components are not very composable
๐’๐ก๐ข๐ฉ๐ฉ๐ž๐: Weโ€™ve decomposed the previous livepeer-react monolith into libraries of primitives, so that you have full control over your usersโ€™ experience. You can use Player primitives to build a media playback experience, and Broadcast primitives to build an in-browser broadcasting experience.
๐…๐ž๐ž๐๐›๐š๐œ๐ค: livepeer-react encapsulates a lot of application logic (fetching data from the backend, auto-upload, etc), leading to confusing integration pathways
๐’๐ก๐ข๐ฉ๐ฉ๐ž๐: Weโ€™ve decoupled data fetching from the Player and Broadcast with a shared helper library and improved the interaction between the Player and Livepeer SDKs, to provide a more flexible and cohesive experience. The only web requests are for pure playback or broadcasting (WHEP/WHIP and metrics reporting) - there are no more API requests to Livepeer Studio from any components. This means that you do not need to configure a LivepeerProvider with an API key. Keep those keys on the backend.
๐…๐ž๐ž๐๐›๐š๐œ๐ค: The styling is difficult and hard to rework (and not compatible with Server Components)
๐’๐ก๐ข๐ฉ๐ฉ๐ž๐: The components are now completely unstyled, and the docs will provide examples of how to style them similarly to how they were in the previous releases. You can copy-pasta and then tweak from there.
๐Ÿ’ก ๐Ž๐ญ๐ก๐ž๐ซ ๐ˆ๐ฆ๐ฉ๐ซ๐จ๐ฏ๐ž๐ฆ๐ž๐ง๐ญ๐ฌ
๐‚๐จ๐ฆ๐ฉ๐จ๐ฌ๐š๐›๐ฅ๐ž ๐œ๐จ๐ฆ๐ฉ๐จ๐ง๐ž๐ง๐ญ๐ฌ - all components are extremely narrow in their scope, and support the asChild pattern popularized by Radix UI. When asChild is set to true, we will not render a default DOM element, instead cloning the part's child and passing it the props and behavior required to make it functional.
๐€๐ฎ๐ญ๐จ๐ฆ๐š๐ญ๐ข๐œ ๐ฉ๐จ๐ฌ๐ญ๐ž๐ซ ๐ข๐ฆ๐š๐ ๐ž๐ฌ - if you pass in the playback info response directly into getSrc, it will automatically parse the thumbnail image and pass it into the poster for the video.
๐‘๐ž๐ฌ๐ฎ๐ฆ๐ž ๐ฉ๐ซ๐จ๐ ๐ซ๐ž๐ฌ๐ฌ ๐จ๐ง ๐Ÿ๐š๐ฅ๐ฅ๐›๐š๐œ๐ค - when an error happens during playback for any reason, we resume playback where it left off.
๐๐ซ๐ข๐ง๐  ๐ฒ๐จ๐ฎ๐ซ ๐จ๐ฐ๐ง ๐œ๐จ๐ฆ๐ฉ๐จ๐ง๐ž๐ง๐ญ๐ฌ - useMediaContext is now much easier to use - since the <Player.Root /> is now just a simple React Context provider, you can build out your own components inside of it which consume the video controller.