⚠ Notice: May require action

Dynamic updates to previous daily-js versions will end

Today, if you're using daily-js in call object mode, you may have noticed that certain bug fixes and updates are applied automatically to your client code, regardless of the version of daily-js you're using. Sometimes, these dynamic updates can introduce slight changes to the behavior of the API.

We’ve received feedback from developers who are looking for more stability and want more control over when these fixes and updates end up in their client implementations.

So, starting in an upcoming version of daily-js, bug fixes and updates will no longer be automatically applied to previous versions of daily-js, reducing unexpected changes for users of our library.

Going forward, if you’re using a numbered version of daily-js in call object mode, you will need to periodically update to the latest version in order to receive any of the latest fixes or improvements*.

If you're using daily-js to embed Daily Prebuilt, there's no change; you'll continue to get the latest embedded Daily Prebuilt experience (though you might choose to regularly update daily-js to take advantage of its latest API improvements*).

*Note: Daily commits to supporting previous daily-js versions released up to 6 months ago, so you'll want to at least update to stay within that support window.

Features

• 🗣️ Experimental: User Data API

  This preview of a new API is meant to allow customers to set and share custom participant state, like whether a participant in a call has raised their hand. The data is tied to a single participant, settable at join time, dynamically updatable, and retrievable remotely as data on each participant.

  The data can be any JSON-serializable JavaScript object less than 4096 characters in length. It can be set via the new userData Frame property, or as a parameter to the new method setUserData, and it can be read as a key on participant, e.g. participants()['local'].userData.

  Note: this data is not intended for frequent, rapid updates. For example, it would not be ideal for storing real-time location of moving users within a spatial call application. Local state will be set immediately, and remote state will eventually reflect the last call made.

  Full documentation for this feature will be released in the future as it matures.

• 🚀 Allow setting an idle timeout for streaming

  When a user switches to another tab, some browsers throttle the CPU and cause their stream to pause. Idle timeout logic on our worker will stop livestreams or recordings automatically in this scenario, so we now allow users to override this behaviour and let streams run on for a configurable time before timing out as idle.

  Control this behaviour by setting the new key minIdleTimeOut to a number of seconds in the DailyStreamingOptions object supplied to either the startRecording or startLivestreaming daily-js methods. For example:

  startRecording({
    width: 1920,
    height: 1080,
    fps: 30,
    minIdleTimeOut: 5 * 60, // five minutes, the current default
  });

Bugfixes

• 🐛 Allow joined_at to be undefined, and prevent it from being set before it has a reasonable value. (Fixes Github issue #191).

Other Improvements

• 💻 Update streaming/recording APIs to allow specifying an instanceId. This lays the groundwork for some day enabling multiple active recordings and/or livestream instances per call.
• 📷 Add new selected-devices-updated event which will fire when setOutputDeviceAsync is called, to allow applications to respond to output device changes.