DEV Community: Jess Mitchell

Build a video call app with Svelte in an afternoon

Jess Mitchell — Thu, 06 Jan 2022 13:34:49 +0000

Daily's JavaScript library, daily-js, is compatible with any frontend framework, which means choosing your stack is really up to you. Today we'll be looking at one of our favourite frameworks at Daily...

Svelte! 🎉

In today’s tutorial, we’ll rebuild our Daily Prebuilt demo, already built in React and Vue, but this time with Svelte! ✨

Specifically, we’ll cover how to:

Embed Daily Prebuilt in a Svelte app
Handle updating your components based on whether you’ve joined a Daily call or not
Manage your Daily Prebuilt call with a custom control panel

If you want to test the completed version of the demo first, check out the deployed version.

What exactly is Svelte?

Svelte is an open-source frontend component framework that can be used as an alternative to other frontend frameworks, like React or Vue.

It differs from other frameworks based on how it updates your app’s UI. Instead of using a virtual DOM to handle app changes (like React uses), Svelte is instead a compiler that converts app components to JavaScript and inserts any UI changes directly into the DOM itself.

Or, as the Svelte docs put it:

“Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.”

Who is this tutorial for?

Since this is a Svelte tutorial, the following content will be most helpful for anyone already familiar with Svelte. In case you’re not, we’ll do our best to explain what is unique to Svelte.

Thankfully, Svelte also has amazing documentation and interactive tutorials to learn the basics, and we highly recommend giving those a read!

Getting started

To get started locally, clone the Daily Prebuilt Svelte demo app and run the following commands in your terminal:

npm i
npm run dev

You will also need to create a Daily account and a new Daily room for testing the demo.

Note: The demo README includes additional instructions for creating new Daily rooms locally via the app.

Once you have the app running locally, navigate to http://localhost:5000 in your browser of choice, and you should see the home page.

`App.svelte`: Determining which view to show

Our app is going to have two possible views:

Our home page, which includes a form to join a call
The call UI, which includes the Daily Prebuilt embed and our custom call controls

We know we'll need some logic to determine which view should show. To determine this, let’s take a look at our parent App component. App will handle deciding whether the Home or Call component is rendered.

// App.svelte
<script>
 import Call from "./screens/Call.svelte";
 import Header from "./components/Header.svelte";
 import Home from "./screens/Home.svelte";

 let currentScreen = "home"; //  || 'call'
 let url;
 let userName;

 const handleJoinCall = ({ detail }) => {
   currentScreen = "call";
   // set component vars with form submission values
   url = detail.url;
   userName = detail.name;

   // save in local storage
   localStorage.setItem("svelte-prebuilt-url", url);
   localStorage.setItem("svelte-prebuilt-name", userName);
 };

 const handleLeaveCall = () => {
   currentScreen = "home";
 };
</script>

<svelte:head>
 <script crossorigin src="https://unpkg.com/@daily-co/daily-js"></script>
</svelte:head>

<div class="wrapper">
 <Header />
 {#if currentScreen === "home"}
   <Home on:submit={handleJoinCall} />
 {:else}
   <Call {userName} {url} on:left={handleLeaveCall} />
 {/if}
</div>

Let’s step through this:

In the script tag, we start by importing the components we’ll be using (Call, Home, and Header)
Then, we declare variables that will be used in this component but are assigned later on.
Next, we define handleJoinCall, which we'll describe in more detail below. In short, it sets our currentScreen variable to call.
We then define handleLeaveCall, which simply resets currentScreen to home.
Lastly, we import our daily-js script tag to make the daily-js library available to the rest of the app.

Now let’s specifically look at the markdown in App to see how we render our components:

// App.svelte
<div class="wrapper">
 <Header />
 {#if currentScreen === "home"}
   <Home on:submit={handleJoinCall} />
 {:else}
   <Call {userName} {url} on:left={handleLeaveCall} />
 {/if}
</div>

In Svelte, you can conditionally render components based on your JavaScript values using an if statement.

We know we always want to render our Header, but we only want to render the Call component if the user is trying to join a call, i.e. the currentScreen equals call.

This is where we can use Svelte’s if syntax:

{#if currentScreen === "home"} to render the Home screen
{:else} we can show the Call component.

And don’t forget to close your if block with {/if}

Listening for custom events

Another handy feature of Svelte is being able to dispatch custom events that can be forwarded to other components.

Since the Home component has a form to join calls, we want to call handleJoinCall (defined in App) when the form’s submit event is dispatched.

Similarly, when you’re in a call and go to leave the call, we want to listen for the custom left event we'll define in Call.

We handle both situations by adding a custom listener on each component, like so:
<Call on:left={handleLeaveCall} />

Notice how it says on:left? This will listen for any left events dispatched. To listen to other custom events you've defined, you can just update the event name, such as on:fancy-event-name.

One other thing to note is being able to pass variables to child components. In Svelte, we can pass the userName and url values as props to the Call component like so:
<Call {userName} {url} />

Note: Since the prop name and variable being passed use the same name, we can use the shorthand notation. That is to say, {url} is shorthand for url={url}.

These properties can then be made available in Call like so:

// Call.svelte
export let url;
export let userName;

Honey, I’m `Home.svelte`

By default, App will render the Home component first.

Our Home component contains the main content for our app’s home screen. The code for it is a bit longer than App so we’ll look at the most important sections.

// Home.svelte
<script>
 import { createEventDispatcher, onMount } from "svelte";
 import api from "../api";

 const dispatch = createEventDispatcher();
 ...

At the top of our component, we import Svelte’s createEventDispatcher method and assign it to the variable dispatch. This method is what we’ll use for dispatching our custom events discussed above.

Now let’s jump to our HTML and focus on the form.

// Home.svelte
<div class="home-screen">
 <h2>Daily Prebuilt Svelte demo</h2>
 <p>Start demo with a new unique room or paste in your own room URL</p>
…
 <form on:submit={goToCall}>
   <label for="name">Name</label>
   <input id="name" type="text" required bind:value={name} />
   <label for="url">Daily URL</label>
   <input
     id="url"
     type="text"
     required
     bind:value={url}
     placeholder="https://your-domain.daily.co/room-name"
   />
   <input type="submit" value="Join call" />
 </form>
</div>

Here, we have a native HTML <form> element with the submit handler using goToCall:

<form on:submit={goToCall}>

Note: This is not a custom event since forms have a native submit event.

The form has two inputs for a username and Daily room URL. To make each of these input values available in our component’s JavaScript, we can bind each value to a variable declared at the top of the component.

For example, the username input value will be bound to the variable name, which is declared at the top of the file:

// Home.svelte
<script>
   let name;
</script>

...
<form on:submit={goToCall}>
    ...
    <input id="name" type="text" required bind:value={name} />
    ...
</form>

This means when the form’s submit event occurs and the goToCall method is called, we can use the input values via our bound variables (e.g name).

This also makes the input values available to forward to the App component via the dispatch method we defined before like so:

// Home.svelte
const goToCall = (e) => {
   e.preventDefault();

   dispatch("submit", {
     name,
     url,
   });
 };

In goToCall, we first prevent the form from refreshing the page with e.preventDefault().

Then we use our dispatch method to forward the submit event to our App component. Both name and url (our variables bound to the inputs) are passed as options to make those values available to App, as well.

If you recall from App, the Home component has an event listener on it for submit, which calls the handleJoinCall method.

<Home on:submit={handleJoinCall} />

When our dispatched submit event registers in App, it will call handleJoinCall.

// App.svelte
 const handleJoinCall = ({ detail }) => {
   currentScreen = "call";
   // set component vars with form submission values
   url = detail.url;
   userName = detail.name;

   // save in local storage
   localStorage.setItem("svelte-prebuilt-url", url);
   localStorage.setItem("svelte-prebuilt-name", userName);

   error = null;
 };

In handleJoinCall we update currentScreen to equal call. This will cause the Call component to show instead of Home. We then set our url and userName variables to the values passed from the form and save them in local storage, as well.

Now that all the Home form's information is shared with App — who also shares it with Call — we can move on to setting up our call UI.

Call on line 1, please

So far we’ve set up our App component and our Home screen. Now let’s build our Daily call in Call.svelte.

Let’s start with the Call component's HTML markdown this time.

// Call.svelte
<div
 class={meetingState === "joined-meeting"
   ? "call-screen"
   : "call-screen prejoin"}
>
 <div id="container" />
 <Controls
   {url}
   {meetingState}
   {stats}
   on:toggle-camera={toggleCamera}
   on:toggle-mic={toggleMic}
   on:toggle-screen-share={toggleScreenShare}
   on:fullscreen={goFullscreen}
   on:toggle-local-video={toggleLocalVideo}
   on:toggle-remote-video={toggleRemoteVideo}
 />
</div>

We have a container div with two children:

Another div, which is where we’ll embed Daily Prebuilt
Our Controls component, which receives the room url, meetingState, and call stats as props. It also has a list of custom event listeners added for each of the control’s buttons.

Let’s focus on the Daily call to start.

Embedding Daily Prebuilt in your Svelte app

Svelte has a handy onMount lifecycle method that gets called when the component is first rendered.

// Call.svelte

import { onMount } from "svelte";

onMount(() => {
   // assume if the Call component is showing, we should join
   initializeDaily();
 });

We know the Call component mounts when the form is submitted, so we want to initialize the call as soon as Call renders. We can do this by calling initializeDaily on mount.

// Call.svelte

 const initializeDaily = async () => {
   …
   // select container element to embed Daily iframe in
   const container = document.getElementById("container");
   // create Daily iframe
   callFrame = window.DailyIframe.createFrame(container, {
     iframeStyle: IFRAME_OPTIONS,
     showLeaveButton: true,
     url,
     userName,
   });

   callFrame.on("joining-meeting", updateMeetingState);
   callFrame.on("joined-meeting", updateMeetingState);
   callFrame.on("left-meeting", handleLeftMeeting);
   callFrame.on("error", updateMeetingState);

   // set up interval for retrieving current network stats
   interval = setInterval(() => getNetworkStats(), 5000);

   // let the local user join the call, which will cause
   // the call to be displayed in our app UI
   await callFrame.join();
 };

Stepping through this initializeDaily function:

We first select our div element that will be the Daily Prebuilt iframe’s container:

const container = document.getElementById("container");

Next we create our Daily Prebuilt iframe with the createFrame method via daily-js, and pass the container div and some call options to it.

window.DailyIframe.createFrame(container, options)

Recall: window.DailyIframe exists because we imported the daily-js script in App.

Next, we add some Daily event listeners so we can update our UI if the local user joins a call, leaves, or there’s a critical error. We’ll explain this a bit more below.

e.g. callFrame.on("joined-meeting", updateMeetingState);

Then we set up an interval to get the call’s network stats every 5 seconds so we can display it in our Control panel. (We won’t go into more detail about this, but ask us if you need help!)

interval = setInterval(() => getNetworkStats(), 5000);

And, finally, we use Daily’s join method to actually join the call. 🎉

await callFrame.join();

Adding our custom control panel

As Bruce Springsteen once said, “Honey, I want the heart, I want the soul, I want control right now,” so let’s do just that and add a little more control to our app.

daily-js provides instance methods to programmatically do anything you can already do via Daily Prebuilt's UI. This gives a bit more flexibility to how you want to set up your own app’s UI.

For example, if you want to add a big “Mute” button to your UI, you can! Let’s take a look at how.

Adding a Mute button to toggle local audio

As mentioned, our Call component has a bunch of custom event listeners added to Controls. This means all the actual Daily logic can stay contained in our Call component. The Controls component is basically just UI to dispatch the custom events.

// Call.svelte

<Controls
   …
   on:toggle-mic={toggleMic}

In Controls, we have a button to mute the local user:

// Controls.svelte

<button on:click={handleToggleMicClick}>
    <span>
        Toggle mic
        <img src="/images/mic.svg" alt="Microphone" />
    </span>
</button>

On click, this button calls handleToggleMicClick. That method will then dispatch our toggle-mic custom event:

const handleToggleMicClick = () => dispatch("toggle-mic");

Looping back to Call, the toggle-mic custom event that is forwarded calls toggleMic (on:toggle-mic={toggleMic}), a method defined in Call.

The toggleMic method is what contains our daily-js interaction.

// Call.svelte 

const toggleMic = () => {
   if (!callFrame) {
     logError(noCallFrameError);
     return;
   }
   const localVideo = callFrame.localAudio();
   callFrame.setLocalAudio(!localVideo);
 };

If there is no Daily callFrame – defined in initializeDaily – we do nothing. This shouldn’t ever happen but, you know, bugs. 🐛

Next, we get our current local audio state (muted or unmuted) via the localAudio Daily method:

const localVideo = callFrame.localAudio();

Whatever the current value is, we want to make it the opposite. To do this, we can use the setLocalAudio instance method and set our local audio to the inverse boolean value.

callFrame.setLocalAudio(!localVideo);

Once that’s called, your unmuted audio will mute, or vice versa! 💪

We won’t cover all the buttons in the control panel since they all follow a similar pattern, but if you need help, please let us know! 🤗

Appetite for (call) destruction

To understand how the Daily event listeners work a bit more, let’s use the left-meeting event as an example.

In Call, we added an event listener for left-meeting, which calls a callback method (handleLeftMeeting) when triggered:

// Call.svelte

callFrame.on("left-meeting", handleLeftMeeting); // in initializeDaily()

 const handleLeftMeeting = (e) => {
   updateMeetingState(e);
   if (interval) clearInterval(interval);
   dispatch("left");
 };

The callback, handleLeftMeeting, gets called when the local user clicks the Leave button via Daily Prebuilt’s UI. It then dispatches a custom event (left) that App is listening for.

It does a couple other clean up tasks as well, but we won't worry about that for now. Essentially, it resets our app’s state.

If you recall, App has a listener on the Call component for a custom left event:
<Call {userName} {url} on:left={handleLeaveCall} />

handleLeaveCall gets called, which resets our currentScreen value to home:

const handleLeaveCall = () => currentScreen = "home";

Once currentScreen gets reset to home, App will render the Home component instead of Call.

We’ve come full circle back home! 🍩

Cleaning up after the party

Now that we have reset our state to get back to the home screen, we still have a little leftover clean up to do.

If you recall, we added some Daily event listeners to our callFrame.

As a final step, we can turn off those event listeners and destroy our Daily callFrame. It will be recreated when the next call is joined so we don't need it hanging around after leaving this call.

// Call.svelte
import { onDestroy } from "svelte";

onDestroy(() => {
    if (callFrame) {
      // remove event listeners
      callFrame.off("joining-meeting", updateMeetingState);
      callFrame.off("joined-meeting", updateMeetingState);
      callFrame.off("left-meeting", handleLeftMeeting);
      callFrame.off("error", handleError);

      // destroy Daily callframe after call ends
      callFrame.destroy();
    }
  });

Svelte provides an onDestroy lifecycle method that will be triggered when the Call component is destroyed.

In onDestroy, we can turn off our Daily event listeners and destroy the callFrame with Daily's destroy method.

Wrapping up

We hope this tutorial helps you get started with building your own Daily video apps in Svelte. To learn more about Daily Prebuilt, check out our other Daily Prebuilt blog posts.

If you’d like to build something more custom, keep an eye out on Twitter for our next Svelte tutorial! 👀

Build a real-time video chat app with React Native

Jess Mitchell — Mon, 29 Nov 2021 19:21:35 +0000

Daily’s React Native library allows developers to build mobile apps compatible with both Android and iOS with one codebase. It also means your web developers, who have likely crossed paths with React at some point, can write code that will get compiled into native mobile code with a smaller learning curve, since React and React Native are fairly similar.

Recently on the Daily blog, we discussed how to build your own audio call app in React Native. That tutorial specifically looked at Daily’s Party Line demo app, which was built to handle the use case where every call is always audio-only.

Today's agenda

In today’s tutorial, we’ll take a look at Daily’s React Native Playground demo app, which uses more of a traditional video call format; call participants have the option to turn on and off both audio and video.

More specifically, we’ll cover:

How to build a multi-participant video call in React Native with react-native-daily-js
How to give call participants control of their devices in the video call to toggle their local microphone and camera

Who is this tutorial for?

If you are interested in building a mobile app with video calls and have some React Native (or even React) knowledge, this tutorial is for you. React Native projects can be a little more finicky to run locally than web apps because of the platform-specific setup requirements, so having some comfort with React Native is a big plus.

We won’t cover every section of the Playground demo app code base in this tutorial since a lot of the functionality is similar to daily-js (web) apps, which we promise already have a bunch of existing tutorials.📚

A note on today’s stack and React Hooks

Since this app is written in React Native, we’ll be looking at React Native code examples and React hooks from the demo codebase. We recommend familiarizing yourself with React Hooks before reading on to get the most out of this tutorial.

We’ve also used TypeScript in this demo app. TypeScript isn’t specifically discussed below, but having some familiarity with it will help you review the code examples.

Getting started

For anyone new to React Native app development, we’ll quickly cover some basics.

Typically, you’ll want to test on both Android and iOS mobile or tablet devices to ensure your app is working in both operating systems. To test on iOS devices, you’ll need to download XCode, which is only available to download on Mac computers. (You’ll also want to pour yourself a coffee or two while it downloads and hope you’re not on deadline. ☕)

Note: This means you will need a Mac to access XCode for iOS development.

Android, however, can be tested with Android Studio, which is available on a range of operating systems.

In terms of running the Daily Playground demo app locally, thorough instructions for both Android and iOS development are included in the repo’s README.

Note: You’ll need to use real devices instead of a device emulator when you’re testing the video/audio features. In terms of which OS to start with, if you don’t have a personal preference, it’s typically faster to get this app running on an Android device.

App features and functionality

As mentioned, we won’t cover every part of this codebase. To start, let’s discuss the overall structure and functionality of the app so you know how to navigate it.

The App component is the top-level parent component. It renders either the home screen or the in-call view.

Let’s quickly review how the home screen works.

When you first land on the home screen, there’s an empty room URL text input, a “Create demo room” button, and a disabled “Join call” button.

If you know which Daily room you want to join, you can enter the room URL in the text input and press “Join call”, which will be enabled once the input has a value.

If you do not have a room URL, we’ve set up an endpoint that will create a new room for you using Daily’s REST API. This endpoint is called when the “Create room” button is pressed, which calls the method createRoom, defined in App:

// App.tsx
<Button
    type="secondary"
    onPress={createRoom}
    label={
       appState === AppState.Creating
          ? 'Creating room...'
          : 'Create demo room'
    }
/>

// App.tsx
 const createRoom = () => {
   setRoomCreateError(false);
   setAppState(AppState.Creating);
   api
     .createRoom()
     .then((room) => {
       setRoomUrlFieldValue(room.url);
       setAppState(AppState.Idle);
     })
     .catch(() => {
       setRoomCreateError(true);
       setRoomUrlFieldValue(undefined);
       setAppState(AppState.Idle);
     });
 };

Here, we update our appState state value to be in a temporary “creating” state, call api.createRoom(), and, if it’s successful, set our roomUrlFieldValue value and appState. (Both appState and roomUrlFieldValue are component state values initialized in App.)

Note: Take a look at api.ts to see the api.createRoom() method.

Whether you use your own Daily room URL or one created in the app, when you press the “Join call” button, it will take the roomUrlFieldValue, set the roomUrl state value with it, and kick off creating the Daily call object.

Here we have the “Join call” button:

// App.tsx
// “Join call” button will call startCall on press
<StartButton
   onPress={startCall}
   disabled={startButtonDisabled}
   starting={appState === AppState.Joining}
/>

Next, we call startCall:

// App.tsx
/**
  * Join the room provided by the user or the
  * temporary room created by createRoom
 */
 const startCall = () => {
   setRoomUrl(roomUrlFieldValue);
 };

And lastly, a useEffect hook is triggered by the roomURL value getting updated, which creates our Daily call object (the brain of this operation!)

// App.tsx
/**
  * Create the callObject as soon as we have a roomUrl.
  * This will trigger the call starting.
  */
 useEffect(() => {
   if (!roomUrl) {
     return;
   }
   const newCallObject = Daily.createCallObject();
   setCallObject(newCallObject);
 }, [roomUrl]);

The following line is where the call object is actually created:
const newCallObject = Daily.createCallObject();

Then, by setting that value in our component’s state, the call object instance can be referred to later:

setCallObject(newCallObject);

After the call object has been created, we can then actually join our room (finally! Considering we pressed the “Join call” button 😉)

// App.tsx
 useEffect(() => {
   if (!callObject || !roomUrl) {
     return;
   }
   callObject.join({ url: roomUrl }).catch((_) => {
     // Doing nothing here since we handle fatal join errors in another way,
     // via our listener attached to the 'error' event
   });
   setAppState(AppState.Joining);
 }, [callObject, roomUrl]);

Here, in another useEffect hook in App, when the callObject and roomUrl state values are truthy, which they now are, we can actually join our call by passing the roomUrl to our call object instance.

This step is also where our app view will change from the home screen to the in-call view. This happens because of this line in the effect above: setAppState(AppState.Joining);

// App.tsx
 const showCallPanel = [
   AppState.Joining,
   AppState.Joined,
   AppState.Error,
 ].includes(appState);

When showCallPanel — shown above — is truthy, our in-call view will render instead of the home screen:

// App.tsx
<View style={styles.container}>
    {showCallPanel ? (
         <View style={[
             styles.callContainerBase,
                orientation === Orientation.Landscape
                    ? styles.callContainerLandscape
                    : null,
         ]}>
             <CallPanel roomUrl={roomUrl || ''} />
             <Tray
                onClickLeaveCall={leaveCall}
                disabled={!enableCallButtons}
             />
        </View>
    ) : (
    … //home screen
    )
...

We’ll leave it at that for the home screen and focus on the CallPanel component — our in-call view — for the rest of this tutorial. If you have any questions about this section, please reach out! We’re happy to help. 🙌

Displaying video tiles in your Daily React Native app

Let’s start by familiarizing ourselves with what our in-call app UI is supposed to look like:

We have the local participant’s camera feed at the top left corner, the room URL and a button to copy it to your clipboard in the middle of the screen, and our tray at the bottom. If anyone is screen sharing, they’ll also be included as a small thumbnail at the top.

Note: Screen sharing can’t be initiated in this app but call participants can join the room from any platform, including a web app using daily-js, where screen sharing is permitted.

The tray (i.e. the Tray component) has buttons to toggle the local participant’s audio, video, and to leave the call.

When more participants join, their videos are shown in the middle of the screen, replacing the room URL information.

Iterating over our participant list

Now that we know what we’re talking about, let’s jump right to where we’re actually creating our participant videos with react-native-daily-js.

In CallPanel.tsx, we render an array called largeTiles, which represents the remote participants.

// CallPanel.tsx
<ScrollView
     alwaysBounceVertical={false}
     alwaysBounceHorizontal={false}
     horizontal={orientation === Orientation.Landscape}
 >
     <View
        style={[
            styles.largeTilesContainerInnerBase,
                orientation === Orientation.Portrait
                 ? styles.largeTilesContainerInnerPortrait
                 : styles.largeTilesContainerInnerLandscape,
         ]}
      >
         {largeTiles} // <- our remote participants
      </View>
 </ScrollView>

Note: We’ve put this in a ScrollView but you may prefer a FlatList component if you know you will be having larger calls. (A FlatList will only render the visible tiles, which should help with performance. It’s less of a concern in 1-on-1 video calls.)

Our largeTiles (remote participants) and thumbnailTiles (the local participant or screen sharer) are determined by the same memoized function. The tiles in largeTiles can be either full size or half size depending on the number of participants.

// CallPanel.tsx
 /**
  * Get lists of large tiles and thumbnail tiles to render.
  */
 const [largeTiles, thumbnailTiles] = useMemo(() => {
   let larges: JSX.Element[] = [];
   let thumbnails: JSX.Element[] = [];
   Object.entries(callState.callItems).forEach(([id, callItem]) => {
     let tileType: TileType;
     if (isScreenShare(id)) {
       tileType = TileType.Full;
     } else if (isLocal(id) || containsScreenShare(callState.callItems)) {
       tileType = TileType.Thumbnail;
     } else if (participantCount(callState.callItems) <= 3) {
       tileType = TileType.Full;
     } else {
       tileType = TileType.Half;
     }
     const tile = (
       <Tile
         key={id}
         videoTrackState={callItem.videoTrackState}
         audioTrackState={callItem.audioTrackState}
         mirror={usingFrontCamera && isLocal(id)}
         type={tileType}
         disableAudioIndicators={isScreenShare(id)}
         onPress={
           isLocal(id)
             ? flipCamera
             : () => {
                 sendHello(id);
               }
         }
       />
     );
     if (tileType === TileType.Thumbnail) {
       thumbnails.push(tile);
     } else {
       larges.push(tile);
     }
   });
   return [larges, thumbnails];
 }, [callState.callItems, flipCamera, sendHello, usingFrontCamera]);

Let’s step through this function:

We declare two arrays that we’ll be updating in this function: larges and thumbnails
We get an array of our call participants (Object.entries(callState.callItems)) and do the following for each (or forEach, if you will):
- _Note: The tileType can be TileType.Full, TileType.Half, or TileType.Thumbnail. The latter is the local participant, and the first two options are for remote participants (our largeTiles).
- If the “participant” is actually a screen share, we make it a full size tile
- If the participant is local or currently sharing their screen, we make them a thumbnail
- If the call has 3 or less participants total, remote participants will have full size tiles; otherwise, they’ll have half size tiles.
- We then render a Tile component for each participant and update our larges and thumbnails arrays

Okay, we’ve come pretty far but we still need to render our actual video and audio for the participants, so bear with us!

Rendering participant media

The most important part of the Tile component is the mediaComponent, a memoized instance of the DailyMediaView component imported from react-native-daily-js:

// Tile.tsx
import {
   DailyMediaView,
} from '@daily-co/react-native-daily-js';
... 
const mediaComponent = useMemo(() => {
   return (
     <DailyMediaView
       videoTrack={videoTrack}
       audioTrack={audioTrack}
       mirror={props.mirror}
       zOrder={props.type === TileType.Thumbnail ? 1 : 0}
       style={styles.media}
       objectFit="cover"
     />
   );
 }, [videoTrack, audioTrack, props.mirror, props.type]);

The videoTrack and audioTrack are props passed to Tile from CallPanel but are actually set in callState.ts:

// callState.ts
function getCallItems(participants: { [id: string]: DailyParticipant }) {
 // Ensure we *always* have a local participant
 let callItems = { ...initialCallState.callItems }; 
 for (const [id, participant] of Object.entries(participants)) {
   callItems[id] = {
     videoTrackState: participant.tracks.video,
     audioTrackState: participant.tracks.audio,
   };
   if (shouldIncludeScreenCallItem(participant)) {
     callItems[id + '-screen'] = {
       videoTrackState: participant.tracks.screenVideo,
       audioTrackState: participant.tracks.screenAudio,
     };
   }
 }
 return callItems;
}

We’re jumping around here a bit but the important thing to understand is that our Daily callObject provides our participant information (see: callObject.participants()) and our participant information contains their media (video/audio) tracks. We can then pass those tracks to the DailyMediaView component to actually play those tracks in the app.

Jumping back to the Tile component, we get the videoTrack and audioTrack values from the videoTrackState and audioTrackState props.

// Tile.tsx
 const videoTrack = useMemo(() => {
   return props.videoTrackState
      && props.videoTrackState.state === 'playable'
     ? props.videoTrackState.track!
     : null;
 }, [props.videoTrackState]);

 const audioTrack = useMemo(() => {
   return props.audioTrackState && props.audioTrackState.state === 'playable'
     ? props.audioTrackState.track!
     : null;
 }, [props.audioTrackState]);

This means we use the tracks from the individual participant information if they’re available, and otherwise set that corresponding props to null. Both are valid types for the DailyMediaView videoTrack and audioTrack props.

Tile also has an overlay with the audio and camera muted icons when they apply (i.e. when there’s no track to play), but we won’t review that code here. Again, let us know if you have any questions. 🙏

Controlling your local devices in-call

As a final note, let’s see how our Tray component interacts with the Daily call object. As a reminder, it’s rendered in App.tsx at the same time the CallPanel component is rendered.

As mentioned, the tray lets up control our local camera and microphone, as well as leave the current call to return to the home screen.

To toggle our local camera, we can call setLocalAudio on the call object instance.

// Tray.tsx
 const toggleCamera = useCallback(() => {
   callObject?.setLocalVideo(isCameraMuted);
 }, [callObject, isCameraMuted]);

Similarly, we can toggle our microphone on or off with setLocalAudio.

// Tray.tsx
 const toggleMic = useCallback(() => {
   callObject?.setLocalAudio(isMicMuted);
 }, [callObject, isMicMuted]);

Lastly, pressing the “Leave” button will call the leaveCall function call, a prop passed from App.

// App.tsx
/**
  * Leave the current call.
  * If we're in the error state (AppState.Error),
  * we've already "left", so just
  * clean up our state.
  */
 const leaveCall = useCallback(() => {
   if (!callObject) {
     return;
   }
   if (appState === AppState.Error) {
     callObject.destroy().then(() => {
       setRoomUrl(undefined);
       setRoomUrlFieldValue(undefined);
       setCallObject(null);
       setAppState(AppState.Idle);
     });
   } else {
     setAppState(AppState.Leaving);
     callObject.leave();
   }
 }, [callObject, appState]);

Here, we’re destroying our call object instance and resetting the state in App to get back to our initial values.

Resources

We hope this helps you navigate building your own video call apps with Daily’s React Native library. We covered the most important aspects of our Playground app but we’re always happy to answer any questions you may have! 😁

If you’re looking to learn more about building with Daily’s React Native library, check out our beloved docs or read our previous tutorial on building a Clubhouse clone app. 📱

Build a mobile audio chat app in an afternoon with React Native

Jess Mitchell — Wed, 24 Nov 2021 15:35:01 +0000

At Daily, one of our primary focuses has been supporting audio-only apps with our APIs. Lately, we’ve been hearing more and more discussions about how to help app users avoid Zoom fatigue — the feeling of being burnt out from sitting in video calls all day long.

Audio-only apps are a great solution to this issue as they typically require less cognitive resources to participate in. They are also a great option for larger calls or calls on mobile devices as they tend to have lower CPU requirements. (So you and your devices need to think less. 😉)

To help our customers support their audio-only use cases, we launched an audio starter kit (a.k.a. Party Line) earlier this year, which includes demo apps in React (web), iOS, Android, and React Native.

In today's tutorial, we’ll be doing a deeper dive into how the React Native version of Party Line works.

By the end of this tutorial, you’ll know how to build a Clubhouse-esque Daily audio app using our react-native-daily-js library and Daily’s customizable call object.

Who is this tutorial for?

To get the most out of this tutorial, some basic React Native knowledge is useful. If you’ve never used React Native before but are familiar with React and React hooks, you should be able to follow along.

Note: React and React Native code is fairly similar but does have some differences, so we’ll do our best to explain those differences as they come up!

Getting set up locally

To run the Party Line app locally, follow the instructions located in the Github repo’s README. Instructions for both iOS and Android are included, depending which OS you prefer to primarily test React Native apps.

Feature set and backlog

Let’s start by describing which audio call features will (and won’t) be included.

Party Line will include two views:

A home screen with a form to join or create an audio call
An in-call view once a call has been joined

Let's review some of the basic functionality:

From the home screen, the local user can fill out their name in the form and either specify a room code or leave the code blank. If they leave the code blank, Party Line will automatically create a new room and join it when the form is submitted.
Each room created in Party Line will expire after 10 minutes. The expiry is set when the room is created via the Daily REST API and something we’ve included to avoid long-living demo rooms. This can be adjusted in the room settings to match your use case, however.
Once the room is joined, the room code can be shared with anyone. Rooms created from one app are compatible with any of our other Party Line apps (iOS, Android, React/web, or React Native).

We’ll allow for three different types of participants: moderator, speaker, listener.

Participant types are handled as follows:

The room creator is the moderator
Moderators are indicated in the UI by a star next to their initials
Moderators can promote listeners to speakers, speakers to listeners, and anyone to a moderator
Listeners can raise (or lower) their hands to indicate they would like to speak
Speakers and moderators can mute/unmute themselves, but only mute others
When a moderator leaves the call and there are no other moderators present, the call ends for everyone

In terms of constraints, we will not:

Use any external account management or authentication
Have a database, though we recommend handling the participant types with a database for production-level apps (❗)
Have a backend aside from serverless functions, which call the Daily REST API
Offer a list of rooms to join; the participant will need to know the code for the room they want to join. This would be a great feature to add, though 😉

We’ll cover how most of this works below or share links to existing resources for anything we don’t have time to go over.

Component structure

Before we dive into the code, let’s plan the structure we’re going to use for our components.

Here, we have our App component as the top-level parent component. It will render the Header component with the app title and information. It will also conditionally render either the InCall component, which handles the Daily audio call, or the PreJoinRoom, which has a form to join a Daily audio call, depending on our app state.

Our InCall component has the most complexity because it handles our Daily call.

InCall contains the following components:

One Counter component, which displays how much time is left in the call
A CopyLinkBox to copy and share the room code
A Tray to control your local microphone, raise your hand, or leave the call
A Participant component for each participant. It renders:
- Participant UI, with each participant represented by a box with their initials and a “show more” menu button that renders the Menu component in certain conditions. (More on that below)
- The DailyMenuView component, which provides the participant’s audio for the call. Note: In a React project, you would just render an <audio> element.

CallProvider.jsx: The brain of this operation 🧠

To keep our logic organized and in (mostly) one place, we are using the React Context API, which helps us store global app state. Our App component wraps its contents in the CallProvider component (our context), which means all of our app’s contents can access the data set in our call context.

// App.jsx
function App() {
   return (
       <CallProvider>
          <AppContent />
       </CallProvider>
   );
}

Note: The Context API can be used by any React app (not just React Native). In fact, we did just that in the web version of this app!

Now, let’s spend some time understanding what’s happening in CallProvider. (We can’t cover every detail here, so let us know if you have questions.)

There are several actions (i.e. methods) we define in CallProvider:

Creating a new Daily room (createRoom) with the Daily REST API. We’re using a Netlify serverless function for this but you can use the Daily REST API endpoints however works best for your app.
Creating a Daily meeting token (createToken) for meeting moderators with the Daily REST API. (Same as above regarding using serverless functions.)
Joining a Daily room (joinRoom)
Leaving a room the local participant is currently attending (leaveCall)
Muting/unmuting (handleMute, handleUnmute)
Raising/lowering your hand (raiseHand, lowerHand)
Changing/getting a participant’s account type (e.g. upgrading a listener to a speaker)
Adding Daily event listeners
Initializing app state that will be shared with other components

Starting with our app state, let’s look at which values we’ll initialize and export to be used throughout our app.

// CallProvider.jsx
export const CallProvider = ({children}) => {
 const [view, setView] = useState(PREJOIN); // pre-join | in-call
 const [callFrame, setCallFrame] = useState(null);
 const [participants, setParticipants] = useState([]);
 const [room, setRoom] = useState(null);
 const [error, setError] = useState(null);
 const [roomExp, setRoomExp] = useState(null);
 const [activeSpeakerId, setActiveSpeakerId] = useState(null);
 const [updateParticipants, setUpdateParticipants] = useState(null);
 …
return (
   <CallContext.Provider
     value={{
       getAccountType,
       changeAccountType,
       handleMute,
       handleUnmute,
       displayName,
       joinRoom,
       leaveCall,
       endCall,
       removeFromCall,
       raiseHand,
       lowerHand,
       activeSpeakerId,
       error,
       participants,
       room,
       roomExp,
       view,
     }}>
     {children}
   </CallContext.Provider>
 );
};

How updating a participant type works using `sendAppMessage`

In this demo, we manage participant types (moderator, speaker, or listener) by appending a string to the end of each participant’s username, which is not shown in the UI (e.g. ${username}_MOD for moderators).

❗Note: For production-level apps, we recommend building a backend for participant type management. This current solution is meant to keep the code client-side for demo purposes.

That said, let’s look at how participant type management works.

Whenever a moderator updates another participant’s account type, that update will be communicated to other participants with the Daily method sendAppMessage.

All participants will receive that app message via the app-message event listener, which is added in CallProvider:
callFrame.on('app-message', handleAppMessage);

This will use the callback method handleAppMessage, which will update the appended string on the username to the new account type (e.g._LISTENER to _SPEAKER).

// CallProvider.jsx
 const handleAppMessage = async (evt) => {
     console.log('[APP MESSAGE]', evt);
     try {
       switch (evt.data.msg) {
         case MSG_MAKE_MODERATOR:
           console.log('[LEAVING]');
           await callFrame.leave();
           console.log('[REJOINING AS MOD]');

           let userName = evt?.data?.userName;
           // Remove the raised hand emoji
           if (userName?.includes('✋')) {
             const split = userName.split('✋ ');
             userName = split.length === 2 ? split[1] : split[0];
           }
           joinRoom({
             moderator: true,
             userName,
             name: room?.name,
           });
           break;
         case MSG_MAKE_SPEAKER:
           updateUsername(SPEAKER);
           break;
         case MSG_MAKE_LISTENER:
           updateUsername(LISTENER);
           break;
         case FORCE_EJECT:
           //seeya
           leaveCall();
           break;
       }
     } catch (e) {
       console.error(e);
     }
   };

Making someone a moderator is slightly more complicated because they need to rejoin the call with a Daily token, which will give them the owner privileges they need to be able to mute other participants. To do this, we kick them out of the call quietly (callFrame.leave()) and then immediately rejoin them as a moderator with an owner token.

Note: To make a participant a meeting owner with a meeting token, the is_owner token property must be true. See our token configuration docs for more information.

As we go through specific components below, we’ll loop back to some of the other specific methods outlined in CallProvider as they’re used.

PreJoinRoom form

The PreJoinRoom component is a form with three inputs (first name, last name, join code), and a button to submit the form. Only the first name is a required field; the last name is optional and if no join code is provided, we take that to mean the user wants to create a new room to join.

Let’s focus on what happens when you submit the form:

// PreJoinRoom.jsx
const PreJoinRoom = ({handleLinkPress}) => {
 const {joinRoom, error} = useCallState();
 const [firstName, setFirstName] = useState('');
 const [lastName, setLastName] = useState('');
 const [roomName, setRoomName] = useState('');
 const [submitting, setSubmitting] = useState(false);
 const [required, setRequired] = useState(false);

 const submitForm = useCallback(
   (e) => {
     e.preventDefault();
     if (!firstName?.trim()) {
       setRequired(true);
       return;
     }
     if (submitting) return;
     setSubmitting(true);
     setRequired(false);

     let userName =
       firstName?.trim() + (lastName?.trim() || '');

     let name = '';
     if (roomName?.trim()?.length) {
       name = roomName;
       /**
        * We track the account type by appending it to the username.
        * This is a quick solution for a demo; not a production-worthy solution!
        */
       userName = `${userName}_${LISTENER}`;
     } else {
       userName = `${userName}_${MOD}`;
     }
     joinRoom({userName, name});
   },
   [firstName, lastName, roomName, joinRoom],
 );

In submitForm, we first make sure the first name is filled out. If not, we update our required state value, which blocks the form from being submitted.

Next, we get the local user’s username by joining the first and optional last name values:

let userName = firstName?.trim() + (lastName?.trim() ?  ${lastName?.trim()} : '');

If there’s a room code (roomName) provided in the form, we assign that to our name variable and update the username to have _LISTENER appended to it.

If there is no room code, we don’t set a room name and append _MOD to the username. As mentioned, the person creating the room is the moderator by default so we track that in the name.

if (roomName?.trim()?.length) {
    name = roomName;

    userName = `${userName}_${LISTENER}`;
} else {
    userName = `${userName}_${MOD}`;
}

Once we have our userName and optional room name, we can then call joinRoom, a method from CallProvider.

const joinRoom = async ({userName, name, moderator}) => {
   if (callFrame) {
     callFrame.leave();
   }

   let roomInfo = {name};
   /**
    * The first person to join will need to create the room first
    */
   if (!name && !moderator) {
     roomInfo = await createRoom();
   }
   setRoom(roomInfo);

   /**
    * When a moderator makes someone else a moderator,
    * they first leave and then rejoin with a token.
    * In that case, we create a token for the new mod here.
    */
   let newToken;
   if (moderator) {
     // create a token for new moderators
     newToken = await createToken(room?.name);
   }
   const call = Daily.createCallObject({videoSource: false});

   const options = {
     // This can be changed to your Daily domain
     url: `https://devrel.daily.co/${roomInfo?.name}`,
     userName,
   };
   if (roomInfo?.token) {
     options.token = roomInfo?.token;
   }
   if (newToken?.token) {
     options.token = newToken.token;
   }

   await call
     .join(options)
     .then(() => {
       setError(false);
       setCallFrame(call);
       call.setLocalAudio(false); 
       setView(INCALL);
     })
     .catch((err) => {
       if (err) {
         setError(err);
       }
     });
 };

joinRoom has the following steps:

It leaves the current room if you’re somehow already in one. (This is mostly defensive programming for those terrible, horrible, no good, very bad code bug days.)
It creates a new room with our createRoom method mentioned above if a room name isn’t provided
It creates a token if the participant joining is a moderator. This can happen if they are the first person to join or if they’re rejoining as a moderator after being upgraded
Next, we create our local Daily call object instance: const call = Daily.createCallObject({videoSource: false}); (We’ll go into more detail about the videoSource property below.)
We also set our call options that we’ll need before joining the call (room URL being joined, username, and optional token for moderators

const options = {
  url: `https://devrel.daily.co/${roomInfo?.name}`,
  userName,
};

Finally, we join the call and update our local state accordingly, including updating our view value to incall

await call
    .join(options)
    .then(() => {
       setError(false);
       setCallFrame(call);
       /**
        * Now mute, so everyone joining is muted by default.
        */
       call.setLocalAudio(false);
       setView(INCALL);
    })

Once this is complete, we’ll be brought to our InCall component because of this condition in App.js:

{view === INCALL && <InCall handleLinkPress={handleLinkPress} />}

The in-call experience: Moderators and the rest of us

Now that we know how to get into a call, let’s focus on how we actually use the react-native-daily-js library to get our audio working.

The InCall component renders a Participant component for each participant in the call, and displays them in the UI based on who can speak. Moderators and speakers are shown at the top and listeners are at the bottom.

Let’s look at how we render the Speakers section, which includes moderators and speakers, i.e. anyone who can unmute themselves.

// InCall.jsx
 const mods = useMemo(() => participants?.filter((p) => p?.owner), [
   participants,
   getAccountType,
 ]);

 const speakers = useMemo(
   (p) =>
     participants?.filter((p) => {
        return getAccountType(p?.user_name) === SPEAKER;
   }),
   [participants, getAccountType],
 );

The individual participant UI includes details like their name, initials, a star emoji if they’re a moderator, and a “more” menu with some actions depending on their participant type.

The most important aspect of the Participant component is not visible in the UI, though: the DailyMediaView component!

// Participant.jsx
import {DailyMediaView} from '@daily-co/react-native-daily-js';

const Participant = ({participant, local, modCount, zIndex}) => {
...

{audioTrack && (
    <DailyMediaView
        id={`audio-${participant.user_id}`}
        videoTrack={null}
        audioTrack={audioTrack}
    />
)}
...

This is a component imported from react-native-daily-js and accepts audio and/or video tracks from your participants list, also provided by Daily's call object (recall: callObject.participants()). Since this is an audio-only app, we set videoTrack to null, and audioTrack to each participant’s audio track:

// Participant.jsx
const audioTrack = useMemo(
   () =>
     participant?.tracks?.audio?.state === 'playable'
       ? participant?.tracks?.audio?.track
       : null,
   [participant?.tracks?.audio?.state],
 );

Once the audio track is set, you will be able to hear the participant. 👂

Sir, this is an Arby’s: Letting moderators mute speakers

Now that we have the audio playing, let’s take a quick look at how we mute participants.

As mentioned, only participants who joined with an owner meeting token are permitted to mute others. (And, by the way, we don’t recommend ever letting participants unmute other participants. It’s a bit invasive! 😬)

To do this, we can take advantage of Daily’s updateParticipant method:

CallProvider.jsx
const handleMute = useCallback(
   (p) => {
     if (!callFrame) return;
     console.log('[MUTING]');

     if (p?.user_id === 'local') {
       callFrame.setLocalAudio(false);
     } else {
       callFrame.updateParticipant(p?.session_id, {
         setAudio: false,
       });
     }
     setUpdateParticipants(`unmute-${p?.user_id}-${Date.now()}`);
   },
   [callFrame],
 );

Here in CallProvider, we have one handleMute method for participants to mute themselves or others. If they’re muting themselves, they call setLocalAudio(false). If they’re muting someone else, they call updateParticipant with the to-be-muted participant’s session_id and a properties object with setAudio equal to false.

You, you, you, oughta know

One important aspect of audio-only apps to be aware of is device permissions. Since Daily’s React Native library is compatible with audio and video apps, it will ask for microphone and camera permissions, unless we intervene.

If you don’t address this issue, your app users will see both of these device permission requests, which may be a bit of a red flag 🚩 for them. (Why would you need camera permissions for an audio app? 🤔)

To help your apps seem less — well — creepy, you can simply set videoSource to false when you create the local call object instance.

const call = Daily.createCallObject({videoSource: false});

Adding this one detail means your users are only asked for microphone permissions. 💫

Resources

We hope this overview of the Party Line app helps you better understand how it works under the hood. We couldn’t cover every detail, so check out these existing tutorials/resources that cover related topics:

Our overview of the Party Line project
Creating audio-only calls with daily-js
A tutorial on creating owner meeting tokens in React
Our Playground app repo in case you’re interested in seeing a React Native video call example
Building a video or audio-only call embedded in a webpage via a Chrome extension

In our next React Native tutorial, we’ll focus on building a video call app, so stay tuned for that!

As always, if you have any questions, let us know!

Build a custom video chat app with Daily and Vue.js

Jess Mitchell — Thu, 28 Oct 2021 17:36:50 +0000

At Daily, we’ve specifically built our video and audio APIs to be frontend framework-agnostic. This is to make sure developers can implement real-time video calls — a big feature in itself — with whichever JavaScript framework they prefer (or no framework at all).

We’ve spent a lot of time discussing React demos and sample code in our blog posts, but React is not your only option for a framework. Vue.js, for example, is another great option that you can use with daily-js.

Recently on the blog, we looked at how to embed Daily Prebuilt in a Vue app. Daily Prebuilt is our plug-and-play option for video calls, which makes it the fastest and most convenient way to add video to your app.

In some cases, however, you may need more control over the video call designs, or you might even be building something more custom like an audio-only call app. In cases like these, using Daily’s custom call object option gives you total control over the video and audio experience, including the video call design and functionality.

In today’s tutorial, we’ll look at building a custom video call app in Vue using Daily’s call object.

Planning our app’s features

In terms of functionality, video call participants will be able to:

Join the call with video and audio
Control their own video and microphones while in the call (e.g. to mute themselves)
Share their screen on any browser that supports screen sharing. We’ll only let one person share at a time to keep things simple for now
Set their username for the call before joining
Leave the call whenever they want
Be notified when device permissions are blocked by the browser, with instructions on how to permit device access
Communicate via text chat in a custom chat box. (The details for this will be covered in a follow-up post.)

As is required for any app, we also need to manage our feature scope. In this case, we won’t worry about managing large calls in terms of performance optimization or the UI layout. Those are big topics in themselves, as demonstrated by this whole series on them!

Getting set up with Daily

To use this demo, you will need a Daily room to join.

To get your own Daily room URL, you’ll need to create a Daily account.

Once you have an account and are logged into the Daily Dashboard, you can create a new Daily room and copy its URL.

Note: You can also create Daily rooms via the REST API.

Setting up your local dev environment

As always, we’ve already built this app for you, so — if you like spoilers — feel free to clone and use the demo app via Github. To run it locally, enter the following commands in your terminal window:

yarn
yarn start

Open the app at whichever port it’s running, which is likely http://localhost:8080/.

More spoilers: Looking at our component structure

It’s often helpful to know the structure of what we’re going to be building before diving in.

The App component is our entry point for our Vue app. It will always render the AppHeader component and conditionally render either Call or Home, depending on whether the user has joined a call.

Call is where daily-js will be imported, and where all the call’s logic will be defined. It is also the parent component for the rest of the components in the app.

Let’s briefly define what each of these components does:

Loading: This component contains an svg with a loading animation. It shows when the user is joining a call, (i.e. in a loading state).
VideoTile: This component is rendered for each participant in the call. It will either render a <video> element or a NoVideoTile component depending on whether the participant has their video on. An tag is rendered for each participant. For local participants, Controls is also a child component of the VideoTile. That means everyone gets device controls for their own tile.
WaitingCard: If you are alone in a call, this component is rendered to let you know you are waiting for others to join.
ScreenshareTile: When a screen share is started, this component is added for the screen share track.
PermissionsErrorMsg: If camera or microphone permissions are blocked locally, this card is rendered instead of the call view so you know to update your browser permissions.
Chat: This is where our chat messages will be sent and displayed.

Now let’s see how these actually work.

Taking advantage of Vue’s data object

One thing you might notice looking at the code for this demo is that there’s no state management library or dedicated backend; instead, we rely on Vue’s data object to keep any information handy that needs to be referenced throughout the code base.

As you review each component in the rest of this tutorial, be sure to look at each component’s data method to see which values are being stored.

Okay, get to the code already

Now that we know what we’re building, we can actually start coding it.

The `App` component: Determining our in-call state

The main conditional we have in App is whether to show our home screen or the call UI.

The home screen is the default view when you visit the demo site. It renders a form to join a specific Daily room. The call UI is everything you see once you submit the form on the home screen to join a Daily room.

In App’s template, we represent this conditional by checking the value of appState, a value on our data object.

<template>
 <app-header />

 <call
   v-else-if="appState === 'incall'"
   :leaveCall="leaveCall"
   :name="name"
   :roomUrl="roomUrl"
 />
 <home v-else :joinCall="joinCall" />
</template>

If appState equals incall, we show our Call component; otherwise, we render our Home component.

Looking at the data object and methods in App, the appState is initially set to idle on render. When you join a call through the home screen’s form, appState gets set to incall. Any time the call is left or refreshed, appState gets reset to idle, bringing the local user back to the home screen.

data() {
   return {
     appState: "idle",
     name: "Guest",
     roomUrl: null,
   };
 },
 methods: {
   joinCall(name, url) {
     this.name = name;
     this.roomUrl = url;
     this.appState = "incall";
   },
   leaveCall() {
     this.appState = "idle";
   },
 },

joinCall gets called in Home and passes the two input values (name and url) as function parameters. These are then set in App’s data object and will get passed as props to Call to be used later by daily-js.

That is really all that happens in App and Home, so let’s jump right to Call to understand how our video call functionality works.

Video call the radio star: Letting participants join with video and audio

When using Daily’s call object like we are in this demo, we need to manually add any elements we want present in our UI. (This is in contrast to Daily Prebuilt, where it’s all done for you.)

That means we’ll need to handle the following in our Call component:

Creating <video> and <audio> elements for any call participants who might have video or audio on. (In this demo, that’s everyone who joins.)
- If someone turns off their video, we’ll show a placeholder to avoid shifting the layout when video isn’t available.

Creating a <video> element specifically for screen shares.
Adding a control panel for the local participant to toggle their camera and microphone, share their screen, or leave the call.
We’ll also add some basic styling for group call layout management, though we’ll prioritize one-on-one calls to keep our CSS styles simpler to start.

The first step in the Call component is to initialize the call instance with daily-js and to join the call, so let’s look at what happens when the Call component is mounted in the mounted() lifecycle method.

data() {
   return {
     callObject: null,
     participants: null,
     count: 0,
     messages: [],
     error: false,
     loading: false,
     showPermissionsError: false,
     screen: null,
   };
 },
 mounted() {
   const option = { url: this.roomUrl };

   // Create instance of Daily call object
   const co = daily.createCallObject(option);
   // Assign in data obj for future reference
   this.callObject = co;

   // Join the call with the name set in the Home.vue form
   co.join({ userName: this.name });

   // Add call and participant event handler
   // Visit https://docs.daily.co/reference/daily-js/events for more event info
   co.on("joining-meeting", this.handleJoiningMeeting)
     .on("joined-meeting", this.updateParticpants)
     .on("participant-joined", this.updateParticpants)
     .on("participant-updated", this.updateParticpants)
     .on("participant-left", this.updateParticpants)
     .on("error", this.handleError)
     // camera-error = device permissions issue
     .on("camera-error", this.handleDeviceError)
     // app-message handles receiving remote chat messages
     .on("app-message", this.updateMessages);
 },

Our three major tasks in the mounted method is to:

Initialize a new Daily call object using the Daily URL provided in the home screen form
const option = { url: this.roomUrl };
const co = daily.createCallObject(option);
Join the Daily call using the username also provided in the home screen form
co.join({ userName: this.name });
Add our Daily event listeners to know when to update our call UI.
co.on("joining-meeting", this.handleJoiningMeeting)
...

Daily events and their callbacks

Before moving on, let’s look at each of the callbacks attached to the Daily events mentioned above to understand how they impact our app’s state.

The `joining-meeting` event

joining-meeting gets called when the local participant is still joining the call. This is like a loading state before being officially in the call.

co.on("joining-meeting", this.handleJoiningMeeting)

handleJoiningMeeting() {
   this.loading = true;
},

In the handleJoiningMeeting callback, we set loading in our data object to true so we know when to show our loading spinner in the UI.

The `joined-meeting`, `participant-joined`, `participant-updated`, `participant-left` events

In this demo, we keep an array of the current participants in our data object to iterate through in our UI. That means we need to update our participant list whenever the participants have an event that will affect our list.

co.on("joined-meeting", this.updateParticpants)
  .on("participant-joined", this.updateParticpants)
  .on("participant-updated", this.updateParticpants)
  .on("participant-left", this.updateParticpants)

All four of these events are handled by the same callback, updateParticipants(e).

Note: In apps with large meetings, you will likely need to set up separate methods for these events to avoid any unnecessary re-renders.

updateParticpants(e) {
    if (!this.callObject) return;

    const p = this.callObject.participants();
    this.count = Object.values(p).length;
    this.participants = Object.values(p);

    const screen = this.participants.filter((p) => p.screenVideoTrack);

    if (screen?.length && !this.screen) {
        this.screen = screen[0];
    } else if (!screen?.length && this.screen) {
        this.screen = null;
    }
    this.loading = false;
},

Here, we get all the participants from the Daily call object with the participants() method and convert it from an object to an array. We also assign that array to our participants key in the data object for future reference.

If any participants have a screenVideoTrack, it means they are screen sharing. We then set the screen share in our data object to be accessed in our HTML.

Lastly, we make sure we’re not in a loading state, which is technically only necessary the first time this method gets called.

The `error` event

This is only called if the video call gets stuck in an unrecoverable state. In an ideal world, it would never get called, but like all good programmers, we cover every possibility. 😇

co.on("error", this.handleError)

handleError(e) {
    this.error = e?.errorMsg;
    this.loading = false;
},

Here we set our error data object key to the error message provided by daily-js and make sure we’re not in a loading state.

The `camera-error` event

For daily-js to access call participants’ devices (like their camera and microphone), it requires that call participants give it explicit browser permissions. Without these permissions (either at the start of a call or mid-call), the camera-error event will get triggered.

co.on("camera-error", this.handleDeviceError)

handleDeviceError() {
    this.showPermissionsError = true;
},

When a camera-error (i.e. device error) happens, we update the data object so that showPermissionError is true. This will let us know when to tell our local participant to update their permission settings.

The `app-message` event

co.on("app-message", this.updateMessages);

app-message gets called when a participant sends a message in the call via the sendAppMessage() Daily instance method.

updateMessages(e) {
    this.messages.push(e?.data);
},

We’ll discuss how chat works in more detail in a follow-up post, but for now it’s important to know every chat message sent by a call participant is saved to the messages array in the data object. That array can then be iterated over to display our full chat history in the chat box.

How our stored data impacts our rendered `Call` UI

Each of these values we set in the data object are used to conditionally render different views in our call UI.

To start, let’s look our Call’s template:

<template>
 <main>
   <!-- loading is true when the call is in the "joining-meeting" meeting state -->
   <template v-if="loading">
     <div class="loading-spinner"><loading /></div>
   </template>

   <template v-else>
     <div class="wrapper">
       <template v-if="error">
         <p class="error-text">{{ error }}</p>
         <!-- refreshing will leave the call and reset the app state -->
         <button class="error-button " @click="leaveAndCleanUp">
           Refresh
         </button>
       </template>

       <template v-if="showPermissionsError">
         <permissions-error-msg :reset="leaveAndCleanUp" />
       </template>

       <template v-else>
         <div
           :class="screen ? 'tile-container' : 'tile-container full-height'"
         >
           <template v-if="screen">
             <screenshare-tile :participant="screen" />
           </template>

           <div class="participants-container" v-if="participants">
             <template v-for="p in participants" :key="p.session_id">
               <video-tile
                 :participant="p"
                 :handleVideoClick="handleVideoClick"
                 :handleAudioClick="handleAudioClick"
                 :handleScreenshareClick="handleScreenshareClick"
                 :leaveCall="leaveAndCleanUp"
                 :disableScreenShare="screen && !screen?.local"
               />
             </template>

             <template v-if="count === 1">
               <waiting-card :url="roomUrl" />
             </template>
           </div>
         </div>
       </template>

       <chat :sendMessage="sendMessage" :messages="messages" />
     </div>
   </template>
 </main>
</template>

There are quite a few conditions here, so let’s break it down a bit.

When loading is true, we show a loading spinner, whereas when loading is false, we show the call UI.

<template v-if="loading">
     <div class="loading-spinner"><loading /></div>
</template>

Next, once we’ve officially joined the call, we conditionally show an error message and refresh button when error is truthy. This is so the local participant can refresh the page if something goes wrong. 😬

<template v-if="error">
    <p class="error-text">{{ error }}</p>
    <!-- refreshing will leave the call and reset the app state -->
    <button class="error-button " @click="leaveAndCleanUp">
        Refresh
    </button>
</template><template v-if="error">
<p class="error-text">{{ error }}</p>
<!-- refreshing will leave the call and reset the app state -->
    <button class="error-button " @click="leaveAndCleanUp">
        Refresh
    </button>
</template>

Next, we want to show a message in our UI if the device permissions are blocked. In some cases, you may not want to prevent your users from seeing the video call just because their permissions are blocked, but we do because we consider device permissions a requirement to use this app.

<template v-if="showPermissionsError">
     <permissions-error-msg :reset="leaveAndCleanUp" />
</template>

Iterating over our participants array

The next block of elements in our template is where we render actual video tiles:

 <template v-else>
  <div
    :class="screen ? 'tile-container' : 'tile-container full-height'"
  >
    <template v-if="screen">
      <screenshare-tile :participant="screen" />
    </template>

    <div class="participants-container" v-if="participants">
      <template v-for="p in participants" :key="p.session_id">
        <video-tile
          :participant="p"
          :handleVideoClick="handleVideoClick"
          :handleAudioClick="handleAudioClick"
          :handleScreenshareClick="handleScreenshareClick"
          :leaveCall="leaveAndCleanUp"
          :disableScreenShare="screen && !screen?.local"
        />
      </template>

      <template v-if="count === 1">
        <waiting-card :url="roomUrl" />
      </template>
    </div>
  </div>
</template>

The first section here renders a screen share tile anytime screen is truthy.

<template v-if="screen">
    <screenshare-tile :participant="screen" />
</template>

Next, we render a VideoTile component for each participant in our participants array on the data object and pass any relevant information as a prop to be used in that component.

<template v-for="p in participants" :key="p.session_id">
    <video-tile
        :participant="p"
        :handleVideoClick="handleVideoClick"
        :handleAudioClick="handleAudioClick"
        :handleScreenshareClick="handleScreenshareClick"
        :leaveCall="leaveAndCleanUp"
        :disableScreenShare="screen && !screen?.local"
    />
</template>

Lastly, we render an extra card if there’s only one participant so they don’t feel lonely while waiting. 👯

<template v-if="count === 1">
    <waiting-card :url="roomUrl" />
</template>

The very last component that gets rendered in our call UI is the Chat component, which is included whenever you have officially joined the call. It handles sending and displaying chat messages.

<chat :sendMessage="sendMessage" :messages="messages" />

That was a lot to go through, but we now officially have all our call UI included in our app! 💪

Our next steps will be to take a closer look at VideoTile and ScreenshareTile to see how we turn the media tracks provided by daily-js into actual video tiles in our app.

Call me a mason because we’re about to lay some tiles

Our VideoTile component is rendered for each participant and includes an <audio> element and a <video> element (or NoVideoTile placeholder component). For the local participant, it also renders the Controls element.

When VideoTile mounts, we do the following:

 data() {
   return {
     videoSource: null,
     audioSource: null,
     username: "Guest",
   };
 },
 mounted() {
   this.username = this.participant?.user_name;
   this.handleVideo(this.participant);
   this.handleAudio(this.participant);
 },

Set the username in our data object so we can display it in our tile UI
Handle updating the video and audio elements with the tracks for this tile’s participant

 methods: {
   handleVideo() {
     if (!this.participant?.video) return;
     const videoTrack = this.participant?.tracks?.video?.persistentTrack;
     const source = new MediaStream([videoTrack]);
     this.videoSource = source;
   },

To get the participant’s video playing in the component’s <video> element, we need to create a new MediaStreamby passing the participant’s video persistentTrack and setting that as the <video>’s srcObject.

For the participant’s audio, we do the same thing but with the participant’s audio persistentTrack.

handleAudio() {
    if (this.participant?.local) return;
        if (!this.participant?.tracks?.audio?.persistentTrack) return;
    const audioTrack = this.participant?.tracks?.audio?.persistentTrack;
    const source = new MediaStream([audioTrack]);
    this.audioSource = source;
},

Once that is managed, we can toggle our video and audio using the controls.

Adding a `ScreenshareTile`

The ScreenshareTile is almost identical to the regular VideoTile, except it uses the screenVideoTrack instead of a persistentTrack.

handleVideo() {
    if (!this.participant?.screen) return;
        const videoTrack = this.participant?.screenVideoTrack;
        const source = new MediaStream([videoTrack]);
    this.videoSource = source;
},

We’ve set up the ScreenshareTile to always show on top of the participants’ tiles, but how you want to style it is completely up to you!

Wrapping up

If you’re wondering about how Chat works, we’ll be sharing a follow up post soon that will do a deeper dive into how to quickly build the custom chat box included in this demo.

And, remember, this demo is just a jumping off point for all the custom UI you can build for video or audio-only apps using Daily’s call object mode. It really can be as creative and custom as you’d like.

If you want to expand on this app even more, you could:

Add prejoin UI to test devices and see your local video before joining
Allow users to create rooms via the app UI using Daily's REST API
Manage meeting permissions via room settings, like making the call a broadcast call. (Time for a webinar, anyone? 😊)

Designing web accessible video calls

Jess Mitchell — Thu, 16 Sep 2021 21:23:46 +0000

Tips from Daily on how we implement accessible UIs to ensure everyone can connect online through video

A major goal of ours at Daily is to build video and audio APIs that work for as many people as possible. This means not only building high quality APIs, but also building UIs (user interfaces) that accommodate more than just an imaginary “average user”; we want Daily Prebuilt, our Dashboard, and our docs to be accessible to everyone.

One way we’ve worked towards this at Daily is to build our UIs following web accessibility standards from the start. Internally, we use a component library with components that have all been built to meet these basic standards, which means all of our UIs using this library have accessibility baked in. 🍞

In this tutorial, we’ll review web accessibility basics, and take a look at how we’ve implemented web accessibility in Daily’s own UIs. We know a site's accessibility can almost always be improved — and this is something we’re committed to working on continuously. However, if you’re building video apps for the first time (or even the second or third), we hope that some of the steps we’ve taken can inspire your own designs.

Web accessibility: What exactly is it?

Web accessibility refers to making website information and interactions available to everyone, regardless of barriers, such as disability, geography, language, device restrictions, and more. These barriers may be temporary, such as a broken arm, or permanent, such as a visual impairment.

Note: The term “accessibility” is sometimes written as “a11y”, which is a numeronym. (There are 11 letters between the first letter (“a”) and last letter (“y”). Hence, a11y. 😉)

Who benefits from web accessibility?

In terms of who web accessibility is for, it truly benefits everyone. We want to emphasize that because even people who don’t require accessible websites still benefit from them. 🙌

Accessible websites are often just better designed websites. Basic accessibility guidelines—like making sure your font size is large enough or your colour palette is high contrast enough—make the website easier for everyone to understand.

However, when accessibility is not considered, there are often specific groups of people who are affected most. This includes people with:

Cognitive impairments (e.g. memory impairments)
Neurological disorders (e.g. Parkinson’s)
Physical, visual, auditory, or speech impairments (e.g. colour blindness, reduction in fine motor skills)
Temporary impairments (e.g. broken arm)
Poor network conditions (e.g. slow page load times)
Small or old devices (e.g. reduced CPU capacity)

POUR Principles

The WCAG (Web Content Accessibility Guidelines) outline four principles for web accessibility, also known as the POUR principles. These principles are incredibly useful for testing whether a website meets the goals set out by web accessibility standards.

POUR is an acronym for perceivable, operable, understandable, and robust. These principles represent the following goals:

Perceivable: Websites should be perceivable, i.e. available to the senses, such as vision, touch, and hearing.
Operable: Users can interact with any elements on a webpage that are meant to be interacted with regardless of the device they’re using (e.g. mouse, keyboard, etc.)
Understandable: Websites should be easy to understand regardless of how they’re read (e.g. visually, screen reader, etc.)
Robust: Websites should maximize how compatible they are with various browsers, devices, operating systems, network conditions, etc.

Web Accessibility at Daily

Now that we’ve done a quick overview of what web accessibility is, let’s take a look at some of the ways Daily has made its UIs accessible. This is not a complete list of how we incorporate accessibility into Daily products, but we hope this helps give some inspiration with your own apps!

The list we’ll cover today includes:

Making all UI elements keyboard-accessible, including how we use focus traps and avoid keyboard traps to enhance keyboard navigation
Adding skip links in Daily’s Dashboard
Special treatment of “hidden” elements
Using semantic HTML

Making all interactive UI elements keyboard-accessible

One of the most effective ways to make websites more accessible is to make sure your audience can always interact with your site without a mouse. The idea is to make sure any element on the page that can be interacted with can be interacted with in multiple ways, whether it be a keyboard, mouse, or other device.

This means the site visitor should be able to tab through elements, submit forms or inputs, or escape optional views, like modals, without using a mouse.

In the example below, notice how a participant can join a call and move through Daily Prebuilt’s video call UI only with a keyboard:

This is ideal because we never want site visitors to feel like they can’t join a call or, worse, can’t leave a call once they’ve joined. No one should ever feel “stuck” moving through the user flow.

If you’re curious what tabbing through a Daily call is like with a screen reader, watch this example below, which is using a screen reader Chrome extension.

Adding focus traps

Another way of helping non-mouse users is to include focus traps in your websites.

Focus traps refer to traps (or loops) of focusable elements within a parent element on the page. A common example of when to use this is with a modal. When a site visitor opens a modal, if they tab through the contents of the modal and get to the end, tabbing again should bring the user back to the first tabbable element in the modal. This is in contrast to another, less accessible option: continuing to tab to the next element in the DOM—past the modal— while the modal is still open.

The reason focus traps are useful is because we can assume while the modal is open, the modal is the only element the visitor is trying to interact with until they close it.

Avoiding keyboard traps

Wait, are “traps” bad or good? Well, it depends! We now know why focus traps are good for accessibility, but is there ever a time where trapping the focus is bad?

You can probably tell from the name of this section: yes!

A “keyboard trap” refers to when an element can be focused but can’t be unfocused. The site visitor gets trapped on an element if they’re only using a keyboard. Since some users can’t use a mouse, any action a site visitor takes with a keyboard should be able to be undone.

An example of this is if you open a modal to change your username in a Daily call.

In this first example below, we see a modal with a username form and one button to change the name. If I’m only using a keyboard, there’s no button to close the modal or cancel changing my name. If the keyboard’s Escape key doesn’t close the modal either, I’ll have to fill out the form to get back to the video call. This is what we don’t want.

Now let’s compare that scenario to how Daily Prebuilt’s username form is actually set up: The modal can be closed with a keyboard’s Escape key or by pressing the Cancel button. The call participant is never forced to change their username if the username modal has been opened.

Adding skip links to Daily’s Dashboard

Another web accessibility feature that can help non-mouse users a lot is to add skip links to websites with navigation bars or a lot of links in the header. Skip links are links that are styled to be off screen unless they’re tabbed to, which means you don’t see them if you’re using a mouse.

You can include more than one skip link; ideally, you want to give site visitors the option of skipping to whichever section of the page they may want to jump to without having to tab through the entire page.

As an example of this, let’s look at Daily’s Dashboard. If you’re looking at the Recordings page and want to get to the Learn how to retrieve rtp-tracks recordings link, you have to tab through the header and nav bar to get to the main content.

To make this easier to navigate by keyboard, we can add two skip links:

Skip to navigation to avoid having to tab through the header
Skip to main to avoid tabbing through the header and nav bar

Since we are already on the Recordings page in the example below, we can skip right to the main content with one tab and open that first link. 🎊

To create these skip links in the Daily Dashboard, we added two anchor tags to the top of our Dashboard header:

<header>
   <a className="skip-link" href="#main">
     Skip to main content
   </a>

   <a className="skip-link" href="#nav">
     Skip to navigation
   </a>
   ...

Then, we style them to not show by default and instead only show when they are being focused on. We do this by clipping the links to be 1 x 1px, and updating the clip property only when they’re focused.

.skip-link {
    clip: rect(1px, 1px, 1px, 1px);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;
}
.skip-link:focus {
    background-color: blue;
    color: white;
    clip: auto;
    height: auto;
    overflow: auto;
    padding: 2px;
    top: 0;
    width: auto;
    z-index: 999;
}

Lastly, we add an id attribute (#main and #nav) to the associated elements so clicking the link (the anchor tag) brings the focus to that part of the page. The end result is that all the content between the link and the target (i.e. the header and the nav bar) gets skipped in the tab order.

Special treatment of “hidden” elements

Along the same lines of skip links, there are other times when an element may be off screen. One example is when icons are used for buttons and we want screen readers to know how to interpret them, as well.

Creating hidden labels for screen readers

The way we handle this at Daily is by using a <VisuallyHidden> React component in the button contents, which is really just a <span> with text that is styled to not be visible. This means the screen reader can read it but site visitors who can visually see the UI will just see the icon.

It’s important to note when you are visually hiding an element meant for a screen reader, you should not use visible:hidden; or display:none;. Both of these CSS properties will hide the element visually and hide it from a screen reader, which is not what we want.

Instead, like in the previous skip link example, we want to style it to only not be visually shown. There are a few ways to do this, so let’s look at how we hide text in Daily’s component library:

export const VisuallyHidden: React.FC = ({ children }) => (
 <span>
   {children}
   <style jsx>{`
     span {
       clip: rect(1px, 1px, 1px, 1px);
       height: 1px;
       overflow: hidden;
       position: absolute;
       white-space: nowrap;
       width: 1px;
     }
   `}</style>
 </span>
);

Similar to the skip link, we clip the <span> to be 1 x 1px and hide any overflowing content. This successfully prevents the text from being seen while still letting the screen reader read it.

Our Daily Prebuilt full screen button is one example where this <VisuallyHidden> component is used. Since it is just a full screen icon in the Prebuilt UI, we add text to make it more descriptive for a screen reader.

To ensure it can be read properly by screen readers, a span with the text “Enter full screen” is included in the HTML but not shown in the UI.

Removing hidden elements from the tab order

Another example of special treatment of hidden elements is removing an element from the tab order if it is in the DOM but the site visitor is not meant to be aware of it.

For example, tooltips included in Daily Prebuilt are not shown unless hovered over. These tooltips don’t need to be read by the screen reader while the call participant tabs through the call elements because the buttons they’re related to are already being described by the screen reader.

<Tooltip
    title={`${ctrlKey} + D`}
    tabIndex={-1}
>
    <TrayButton onClick={toggleMic}>
        <MicrophoneIcon />
        {buttonText}
    </TrayButton>
</Tooltip>

In this case, we can remove the tooltip from the tab order with the attribute tabindex=”-1”. This will prevent the tooltip from getting keyboard focus, which will prevent the screen reader from reading the tooltip’s text.

Using semantic HTML

One of the most basic ways we’re committed to accessibility at Daily is using semantic HTML.

Semantic HTML refers to HTML elements that describe the element content. For example, if you are building a web form, writing the form with semantic HTML would use a <form> tag, with an <input type=”submit”> at the end to submit the form. In essence, you always want to use the element that represents what the element actually is (such as a <header>, a <footer>, an unordered list <ol>, etc.) This is in contrast to using non-semantic HTML, which would use a vaguer container element, like a <div>.

Semantic HTML helps communicate to the browser (and developer reading the code!) what each section of your markup is. This also makes it easier for screen readers to understand how to read the page’s content to its listener, and it makes the page more SEO-friendly.

It's win-win for everyone!

Wrapping up

As mentioned, these examples are just a few ways our frontend team at Daily—Christian, especially—is ensuring Daily products are accessible to everyone. We still have some areas to improve, but we do our best to ensure our product UIs are accessible at launch. 💫

Some additional tips we didn’t have space to go into include always labelling form inputs, testing color palettes to meet color contrast requirements, and actually testing websites with screen reader tools, like a screen reader Chrome extension.

Testing with screen reader extensions are not only useful for developers, but they also help show what it’s really like to rely on a screen reader to navigate the web. If you’ve never used a screen reader before, check out this example of how frustrating it can be when people use special characters unnecessarily.

Another area we didn’t touch on is optimizing site performance to help those with CPU or internet restrictions. Check out our previous post on improving video call performance to learn some quick ways to make your custom Daily calls easier to load.

Build a real-time video chat app with Vue and Daily Prebuilt in under ten minutes

Jess Mitchell — Mon, 30 Aug 2021 17:54:37 +0000

At Daily, we’ve spent a lot of time making sure our video and audio-only APIs can be used with any frontend framework, or no framework at all. 🍦 It’s important to us to make flexible APIs that can be incorporated into any app looking to add audio and video chat. We’ve created several demos for our customers using plain JavaScript, React, Next.js, React Native, and more to help cover as many use cases as possible.

Recently, we decided to expand our demo coverage even more with one of our favourite frameworks: Vue!

In today’s tutorial, we’ll cover how to incorporate Daily Prebuilt into your Vue app, as well as how to programmatically manage Daily Prebuilt controls via your app’s UI with our latest demo app.

If you are interested in building a custom video chat app with Vue, fear not; we have an upcoming tutorial series on how to do just that. Stay tuned! 👀

Tutorial requirements

Before we get started, be sure to sign up for a Daily account. Once you’re logged in, you can either create a room through the Dashboard or through the REST API.

For this tutorial, you can clone the Daily Prebuilt Vue demo repo and run it locally, or start from scratch and follow along as we build our Vue components.

To run the Daily Prebuilt Vue demo app locally, clone it and run the following in your terminal:

npm install
npm run serve

To view the app, open http://localhost:8080 in the browser of your choice.

Create a new Vue app

If you prefer to create your own Vue app to add Daily Prebuilt to, start by installing the Vue CLI globally to your machine.

npm install -g @vue/cli

Once installed, we can create a new Vue app to add Daily Prebuilt to using the Vue CLI.

In your terminal, run:

vue create daily-prebuilt-demo

Once the project is created, go to the project’s root directory and add daily-js as a dependency.

npm install @daily-co/daily-js

Then, following the same instructions as above for the demo app, start the server:

npm run serve

Demo project overview

The Daily Prebuilt Vue demo only has four components:

App.vue, the parent component for every other component included in the app.
Header.vue, a completely optional component we included for the app’s title and project links.
Home.vue, the main component which is where Daily Prebuilt is embedded and the control panel is added when in a Daily call.
Controls.vue, the control panel for programmatically controlling Daily Prebuilt. This is also optional but useful for understanding how to interact with daily-js to customize your app’s usage of Daily Prebuilt.

We won’t go into the details of what’s happening in the Header since it’s static content, but what’s important to know is that the App component imports the Header and Home component, and both are displayed at all times.

<template>
 <Header />
 <Home />
</template>

<script>
import Home from "./components/Home.vue";
import Header from "./components/Header.vue";

export default {
 name: "App",
 components: {
   Home,
   Header,
 },
};
</script>

Ready to go Home: Importing Daily Prebuilt to your Vue app

The Home component is the most important one in this demo because it loads all the main content, including the Daily call and control panel.

The default view of the Home component will include two buttons and an input:

The first button is only used if you’ve deployed the app via Netlify, so we’ll skip that for now. (Check out the project’s README for more information.)
The input and second button are used to submit the Daily room URL you’ll be joining (i.e. from the Daily room created above). The format of this URL is https://YOUR_DAILY_DOMAIN.daily.co/ROOM_NAME.

The container for this default home view is conditionally rendered depending on the status value in the component’s data option.

<div class="home" v-if="status === 'home'">
 …
</div>

The status can be home, lobby, or call. home refers to the default view, before a call has been started, and lobby refers to when a call has been started but not joined yet. (We call this the “hair check” view sometimes too, so you can view yourself and set up your devices before joining a call.) Lastly, call refers to when you are live in a Daily call. We’ll look at how the status value gets updated in a bit.

There is also a call container div that is included in the Home component, which is conditionally displayed depending on the app’s current status. This means it is in the DOM in the default view but only visible to the user once a call has been started.

Let’s look at the Vue template for how this is set up:

<template>
 <main class="wrapper">
   <div class="home" v-if="status === 'home'">
     <h2>Daily Prebuilt demo</h2>
     <p>Start demo with a new unique room or paste in your own room URL</p>
     <div class="start-call-container">
       <button @click="createAndJoinRoom" :disabled="runningLocally">
         Create room and start
       </button>
       <p v-if="roomError" class="error">Room could not be created</p>
       <p class="subtext">or</p>
       <!-- Daily room URL is entered here -->
       <input
         type="text"
         placeholder="Enter room URL..."
         v-model="roomUrl"
         pattern="^(https:\/\/)?[\w.-]+(\.(daily\.(co)))+[\/\/]+[\w.-]+$"
         @input="validateInput"
       />
       <!-- button to submit URL and join call -->
       <button @click="submitJoinRoom" :disabled="!validRoomURL">
         Join room
       </button>
     </div>
   </div>

   <div class="call-container" :class="{ hidden: status === 'home' }">
     <!-- The Daily Prebuilt iframe is embedded in the div below using the ref -->
     <div id="call" ref="callRef"></div>
     <!-- Only show the control panel if a call is live -->
     <controls
       v-if="status === 'call'"
       :roomUrl="roomUrl"
       :callFrame="callFrame"
     />
   </div>
 </main>
</template>

Now that we know how the Home component is structured, let’s look at the JavaScript code that gives it functionality:

<script>
import DailyIframe from "@daily-co/daily-js";
import Controls from "./Controls.vue";
import api from "../api.js";

export default {
 components: { Controls },
 name: "Home",
 data() {
   return {
     roomUrl: "",
     status: "home",
     callFrame: null,
     validRoomURL: false,
     roomError: false,
     runningLocally: false,
   };
 },
 created() {
   if (window?.location?.origin.includes("localhost")) {
     this.runningLocally = true;
   }
 },
 methods: {
   createAndJoinRoom() {
     api
       .createRoom()
       .then((room) => {
         this.roomUrl = room.url;
         this.joinRoom(room.url);
       })
       .catch((e) => {
         console.log(e);
         this.roomError = true;
       });
   },
   // Daily callframe created and joined below
   joinRoom(url) {
     if (this.callFrame) {
       this.callFrame.destroy();
     }

     // Daily event callbacks
     const logEvent = (ev) => console.log(ev);
     const goToLobby = () => (this.status = "lobby");
     const goToCall = () => (this.status = "call");
     const leaveCall = () => {
       if (this.callFrame) {
         this.status = "home";
         this.callFrame.destroy();
       }
     };
     // DailyIframe container element
     const callWrapper = this.$refs.callRef;

     // Create Daily call
     const callFrame = DailyIframe.createFrame(callWrapper, {
       iframeStyle: {
         height: "auto",
         width: "100%",
         aspectRatio: 16 / 9,
         minWidth: "400px",
         maxWidth: "920px",
         border: "1px solid var(--grey)",
         borderRadius: "4px",
       },
       showLeaveButton: true,
     });
     this.callFrame = callFrame;

     // Add event listeners and join call
     callFrame
       .on("loaded", logEvent)
       .on("started-camera", logEvent)
       .on("camera-error", logEvent)
       .on("joining-meeting", goToLobby)
       .on("joined-meeting", goToCall)
       .on("left-meeting", leaveCall);

     callFrame.join({ url });
   },
   submitJoinRoom() {
     this.joinRoom(this.roomUrl);
   },
   validateInput(e) {
     this.validRoomURL = !!this.roomUrl && e.target.checkValidity();
   },
 },
};
</script>

Let’s start by focusing on the joinRoom method, which is where all the Daily video call ✨magic✨happens.

joinRoom(url) {
  if (this.callFrame) {
    this.callFrame.destroy();
  }
  ...

First, if there is already a callFrame (i.e. the video call iframe), we destroy it to avoid multiple calls being loaded unintentionally. Defensive coding FTW. 💅

// Daily event callbacks
const logEvent = (ev) => console.log(ev);
const goToLobby = () => (this.status = "lobby");
const goToCall = () => (this.status = "call");
const leaveCall = () => {
   if (this.callFrame) {
      this.status = "home";
      this.callFrame.destroy();
   }
};

Next, we set up the callbacks that will be used by daily-js whenever an event happens in the call that will affect our app’s UI. This can be moved outside the joinRoom function too, but we won’t worry about optimizing for now.

These callbacks are where we update our data options’ status value to know what stage of the call we’re in.

const callWrapper = this.$refs.callRef;

Next, we select the div container that we’ll instruct daily-js to embed the video call iframe into (the DailyIframe instance).

<div id="call" ref="callRef"></div>

If we look back at the DOM structure, there was a div included with a ref added to it to simplify selecting that div in our joinRoom method. This is what we're targeting with const callWrapper = this.$refs.callRef;

// Create Daily call
const callFrame = DailyIframe.createFrame(callWrapper, {
  iframeStyle: {
      height: "auto",
      width: "100%",
      aspectRatio: 16 / 9,
      minWidth: "400px",
      maxWidth: "920px",
      border: "1px solid var(--grey)",
      borderRadius: "4px",
  },
  showLeaveButton: true,
});

this.callFrame = callFrame;

Getting back to joinRoom, we then actually create the DailyIframe that will host our video call and assign it to the variable callFrame. This variable then gets assigned to our data option so it can be referenced later. (If you were using a state management library, you would add it to your app’s state at this point.)

Note: The options passed to createFrame, like iframeStyle, are optional.

// Add event listeners and join call
callFrame
  .on("loaded", logEvent)
  .on("started-camera", logEvent)
  .on("camera-error", logEvent)
  .on("joining-meeting", goToLobby)
  .on("joined-meeting", goToCall)
  .on("left-meeting", leaveCall);

callFrame.join({ url });

Once the callFrame exists, we can attach all the Daily event listeners to it with our callbacks created earlier, and join the call. To join, make sure you pass the Daily room URL, which is the value the user entered into the input.

After the join method is called, you should see two possible views depending on your room’s prejoin UI settings.

If you have the prejoin UI option enabled, you will see the lobby view. The joining-meeting event will get triggered, which will call the goToLobby callback that we set above.

In the lobby view, you will no longer see the default view because the status value has changed to lobby. If we review our DOM elements, we can see the call container now shows because status !== ‘home’ (it equals lobby now). The controls do not show yet, though, because we’re not officially in the call yet.

<div class="call-container" :class="{ hidden: status === 'home' }">
     <!-- The Daily Prebuilt iframe is embedded in the div below using the ref -->
     <div id="call" ref="callRef"></div>
     <!-- Only show the control panel if a call is live -->
     <controls
       v-if="status === 'call'"
       :roomUrl="roomUrl"
       :callFrame="callFrame"
     />
</div>

The second possible view, if you have the prejoin UI disabled for the room you’re in, is seeing the call view. This means you are in the Daily call! 💪

The joined-meeting event would have been triggered, calling the goToCall callback we set, which will update the status to be call. This status change will cause the controls to now show.

Controlling your in-call experience programmatically

One of the best things about Daily Prebuilt is that the hard parts of building video calls are done for you but there are still lots of options that can be configured or customized.

Once the DailyIframe instance (our video call iframe) has been created, you have access to dozens of instance methods to help you manage your call functionality.

For example, let’s say you want to add a button to your app to leave a call. You can create a button that calls the .leave() instance method on click.

To look at how some of these methods work, we can review how the Controls component is set up.

To start, let’s see which props are passed to the Controls component where it’s used in Home.

<controls
   v-if="status === 'call'"
   :roomUrl="roomUrl"
   :callFrame="callFrame"
/>

The v-if means the controls are only rendered if the status value is equal to call. This means it only shows when a person is live in a call in this demo.

The roomUrl prop is the URL the user submitted in the default home view.

The callFrame prop is the DailyIframe instance created for the call, which gives us access to all the instance methods.

Note: Not all instance methods are available for Daily Prebuilt. Refer to our documentation to know which ones can be used.

Now let’s take a look at our Controls component and see how the HTML is structured:

<template>
 <div class="controls">
   <h2>Call overview</h2>
   <hr />
   <h3>Invite participants</h3>
   <label for="urlInput">Share URL below to invite others</label>
   <div>
<!-- Room URL to copy and share -->
     <input type="text" id="urlInput" :value="roomUrl" />
     <button @click="copyUrl" class="teal">{{ copyButtonText }}</button>
   </div>
   <hr />
   <h3>Example custom controls</h3>
   <p>
     You can also create your own meeting controls using daily-js methods
   </p>
   <div>
     <button @click="toggleCamera">Toggle camera</button>
     <button @click="toggleMic">Toggle mic</button>
     <button @click="toggleScreenShare">Toggle screen share</button>
     <button @click="expandFullscreen">Expand fullscreen</button>
     <button @click="toggleLocalVideo">
       {{ localVideoText }} local video
     </button>
     <button @click="toggleRemoteParticipants">
       {{ remoteVideoText }} remote participants (Speaker view only)
     </button>
     <button @click="leaveCall">
       Leave call
     </button>
   </div>
 </div>
</template>

We display the roomUrl prop in the input for the user to copy and share with others so they can join the call, too.

We also have eight buttons included in the control panel to programmatically interact with the DailyIframe instance. There interactions include:

Turning the local camera on and off
Turning the local microphone on an off
Sharing the local call participant’s screen
Expanding Daily Prebuilt to be fullscreen
Hiding and showing the local participant’s tile in the call
Hiding and showing the participants bar, which is where all the remote participants’ tiles are locally while in speaker mode
Leaving the call to go back to the default home view

Toggle your local camera programmatically

To understand how these work, let’s review a couple, starting with toggling the local camera.

<button @click="toggleCamera">Toggle camera</button>

To turn the local camera on and off, the control panel button has the following click event attached to it:

toggleCamera() {
  this.callFrame.setLocalVideo(!this.callFrame.localVideo());
},

this.callFrame refers to the callFrame prop passed in the Home component, which gives us access to the DailyIframe instance. We can then call .setLocalVideo(), an instance method that accepts a boolean value.

The current status of the local camera can be accessed with the .localVideo() instance method, which will return whether the local camera is currently on or off. Since we want this method to toggle the current state, we can pass .setLocalVideo() whatever the inverse of the current state of the camera is with !this.callFrame.localVideo().

So, if the camera is currently on, calling this.callFrame.setLocalVideo(!this.callFrame.localVideo()); is the same as calling this.callFrame.setLocalVideo(false); to turn it off.

Go fullscreen with the click of a button ✨

The other buttons in the control panel mostly work the same way. Let’s take a look at one more example to see how to update your Daily Prebuilt calls programmatically.

The control panel includes a button to make the Daily Prebuilt iframe fullscreen:

<button @click="expandFullscreen">Expand fullscreen</button>

The click handler on this button uses the callFrame prop to access the DailyIframe instance, which can then call the requestFullscreen() instance method.

And with one click, you're in fullscreen mode. It’s really as simple as that! 🙌

Wrapping up

Now that you know how to embed Daily Prebuilt in a Vue app, you can add Daily video chat to any Vue projects you’re building! Tag us on Twitter (@trydaily) to show us your projects. 😊

In terms of next steps, to learn how to customize your video apps even more, try updating your Daily Prebuilt colour theme.

What redesigning our product taught us about optimizing video call performance in React

Jess Mitchell — Wed, 21 Jul 2021 20:18:19 +0000

Recently, one of Daily’s front-end engineers, Christian Stuff, internally shared several performance improvement tips he discovered while working on Daily Prebuilt. The following discussion is based on that list.

One of our primary goals at Daily is to help our customers embed reliable and easy-to-use video calls into their apps in the shortest developer time possible. One way we’ve found to do this is by offering Daily Prebuilt.

Daily Prebuilt is Daily's ready-to-use, embeddable video chat that can be added to any app with just a few lines of code. This is in comparison to our call object option, which enables customers to build their own custom video calls with our core APIs.

Basically, if Daily Prebuilt is your favourite meal served at a restaurant, Daily's customizable call object is a bag of groceries and spices with a recipe included. Which one you choose ultimately depends on what your goal is and how many of your own flavours you want to include.

Redesigning and improving Daily Prebuilt

Recently, we decided to redesign Daily Prebuilt to incorporate some helpful customer feedback we knew would substantially improve Daily Prebuilt’s UX.

What some customers might not realize is that Daily Prebuilt is actually built with our call object. (Yes, we are one of our own customers!) This new, redesigned version also gave us the opportunity to do a deeper dive on the most performant ways to implement Daily’s call object.

Along the way, we’ve found several solutions to drastically improve Daily Prebuilt’s performance, especially on mobile devices and the problem child of browsers for WebRTC: Safari.

To help our customers avoid having to learn these lessons on their own, we’ll be covering our most important solutions related to improving performance while using Daily’s call object mode. Many of these are also applicable to WebRTC development in general.

Who will find this tutorial helpful?

You’ll find this tutorial useful if you're:

Interested in learning more about browser quirks related to video calls
A current Daily customer building a custom video chat app
Shopping around for a video API to help you build a custom video experience

Who will find this tutorial helpful?: Tech stack edition

We’re fond of React and Next.js at Daily, but these performance tips are mostly front-end framework-agnostic. Regardless of what you’re building your web app with, you can apply these tips to get the most out of your Daily video calls.

Excuse me, sir: What exactly is the problem?

Before we dive into all the performance optimizations we used to improve Daily Prebuilt, let’s first take a look at how we knew we had a problem.

One of the main motivators for improving performance has been due to our push to increase call sizes. (1000 participants now, have you heard? 😎) All these additional participants create a new problem: loading participant media. For example, if you’re in a Daily call in speaker mode and scroll through the participant list, videos should load efficiently as they come into view to create a positive user experience.

Here’s an example of participant bar scrolling in one of the earliest internal versions of the new Daily Prebuilt:

We felt the participant bar needed to load the videos faster and more reliably, as a user scrolls through. (Imagine that call with 1000 participants; no one’s got time for that!)

For comparison’s sake, let’s take a look at the participant bar after we implemented the following performance improvements. It quickly recovers from a scroll much more efficiently.

Another example of slow performance while the new Daily Prebuilt was in development was on mobile. We noticed issues like flickering videos, crackling audio, and delays to user interactions, like button presses. (We might have even heard the word “janky” a couple times during internal testing and cringed.)

We knew we could do better!

Improving performance in video call apps

In this tutorial we'll cover 7 main lessons we learned about improving performance in a custom video chat app. These lessons include:

Batching daily-js events, i.e. participant-related events that trigger re-renders
Manually subscribing to media tracks in specific use cases
Using virtual scrolling in scrollable elements containing videos
Using pagination to limit the number of videos shown at a time
Memoizing elements prone to re-renders
Reducing how often media elements are added and removed from the DOM
Checking if a video is paused before playing it

1. Batching daily-js events

daily-js is an events-based library. Whenever a participant joins a call, updates their device, becomes the active speaker, or anything in between, daily-js sends an event so you can decide how to update your call UI. (Check out our docs to see a full list of Daily events. 👀)

For example, you can use the participant-joined event if you want to listen for when a new participant joins the current call.

callFrame.on('participant-joined', (event) => { 
    console.log('participant-joined event', event);
    // add another video tile for the new participant 
})

The event payload itself will look something like this:

const participantJoinedEvent = {
    action: 'participant-joined',
    callFrameId: '16257681634230.996506976694651',
    participant: {
      audio: false,
      audioTrack: false,
      cam_info: {},
      joined_at: 'Thu Jul 08 2021 14:18:21 GMT-0400 (Eastern Daylight Time)',
      local: false,
      owner: false,
      record: false,
      screen: false,
      screenTrack: false,
      screen_info: {},
      session_id: 'd8c55cfb-5eff-4f92-ccee-004989f6b077',
      tracks: { audio: {}, video: {}, screenVideo: {}, screenAudio: {} },
      user_id: 'd8c55cfb-5eff-4f92-ccee-004989f6b077',
      user_name: 'Name',
      video: false,
      videoTrack: false,
      will_eject_at: 'Wed Dec 31 1969 19:00:00',
    },
  };

If a bunch of people all join a meeting you’re in at the same time, you’ll receive a participant-joined event for each and every one of them. It can be a lot to handle in calls with dozens (or hundreds!) of people! 😱

Now let’s say you’re updating a data store for each of these participant-joined events, such as updating a participants array in a React store. Updating the state for every participant-joined event would trigger a re-render for each one, which is not ideal. Instead, you can avoid this by batching participant-joined events and only update your state every 250ms with all the newly joined participants at once.

Let’s take a look at how this could look in React:

const joinedSubscriptionQueue = [];

const handleParticipantJoined = ({ participant }) => {
  joinedSubscriptionQueue.push(participant);
};

const joinBatchInterval = setInterval(() => {
  if (!joinedSubscriptionQueue.length) return;

  // Update participants list in React state based on the `joinedSubscriptionQueue` array of new participants
  // Reset queue
}, 250);

callFrame.on('participant-joined', handleParticipantJoined);

In this solution, the participant-joined event triggers the joinedSubscriptionQueue to update. Then, an interval is set that waits 250ms for any other new participants to be added to the joinedSubscriptionQueue before actually triggering any state changes.

Even with such a small interval of 250ms, batching event-based changes can improve performance, especially in large calls.

One thing to keep in mind, too, is that when you should actually use event batching will depend on how you are responding to Daily events in your app. Your own implementation will vary based on what is triggering the most avoidable re-renders or UI updates.

In addition to participant-joined, batching is useful in other Daily events that are triggered often in calls, such as:

participant-updated
participant-left
track-started
track-stopped

Advanced Daily events batching: Manual track subscriptions

Let’s take a look at a more advanced example of Daily event batching that uses manual track subscriptions. This is considered more advanced because Daily manages track subscriptions for you by default; turning on manual track subscriptions will add quite a bit of complexity to your state management and is only recommended in specific use cases.

If we take the example from above, we can update it for implementing manual track subscriptions for new participants. Let’s say we want to turn on track subscriptions for every new participant when they join, batching the subscriptions could look something like this:

const joinedSubscriptionQueue = [];

  const handleParticipantJoined = ({ participant }) => {
    joinedSubscriptionQueue.push(participant.session_id);
  };

  const joinBatchInterval = setInterval(() => {
    if (!joinedSubscriptionQueue.length) return;

    const ids = joinedSubscriptionQueue.splice(0);

    const participants = callFrame.participants();

    const updates = ids.reduce((o, id) => {
      const { subscribed } = participants?.[id]?.tracks?.audio;
      if (!subscribed) {
        o[id] = {
          setSubscribedTracks: {
            audio: true,
            screenAudio: true,
            screenVideo: true,
          },
        };
      }
      return o;
    }, {});

    callFrame.updateParticipants(updates);
  }, 250);

  callFrame.on('participant-joined', handleParticipantJoined);

In the code snippet above, we create a queue of new participants every 250ms and use the updateParticipants method to update all the new participants’ subscribed tracks at the same time.

This version of event batching helps avoid updating each and every new participant individually without creating any noticeable UI delays in displaying participant videos.

2. Manual track subscriptions: Only subscribe to visible participants

You may be wondering about when to use the example right above, which demonstrates manual track subscription. By default, Daily will handle track subscriptions for you and, for the most part, this is the best solution; let us do the work for you.

In some situations, however, you may want to take advantage of Daily’s call object option to manually subscribe to media tracks for participants. This can be useful for improving performance in large calls, as well as certain features like “breakout rooms” where a call is broken into sub-groups. (But, again, most apps do not need to use this feature!)

In terms of performance, manually subscribing or unsubscribing from tracks is useful in large calls where many videos are not visible. Since the video is not visible, you can unsubscribe from receiving the video tracks from those participants and reduce the amount of data being sent and received related to the call. Only when the participant is moved to being on-screen will you need to re-subscribe to the participant video track.

Using manual track subscription requires two main Daily methods:

setSubscribeToTracksAutomatically(false): Be sure to pass false as a parameter to override the default, which will automatically subscribe to all tracks.
updateParticipant() or updateParticipants(), which updates several participants at once. To update which the tracks are subscribed to for a participants, pass a setSubscribedTracks value like so:

callFrame.updateParticipant(
  “participant-id-string", 
  {
    setSubscribedTracks: {
      audio: true,
      video: false,
      screenVideo: false,
    },
  }
);

Note: If you’re not sure if using manual track subscriptions is a good option for your app, feel free to ask our team. We’re happy to help!

3. Using virtual lists to reduce how many `<video>` elements are rendered

One major update with the new Daily Prebuilt design was making the participant bar vertically scrollable. As Daily increases the call size limits, only rendering participant tiles that are actually visible provides a huge performance win. This can be achieved with virtualized lists.

Virtualized lists (or virtualized scrolling) refers to a list of items where only the visible subset of items is actually rendered in the DOM. As the list is scrolled through, new items (DOM elements) are rendered as they are scrolled into view (or into a “pre-render” area). Conversely, as DOM elements are scrolled out of view, they are destroyed. The goal here is to only render what is visually relevant to the user, and update the list as it is scrolled through.

The Daily Prebuilt participant bar is a good candidate for virtualized scrolling because there can be dozens or even hundreds of participants in the participant bar. Depending on the size of your browser window, you may only actually see 5-10 participants at a time.

To implement virtualized scrolling, there are thankfully several options. If you don’t mind doing some math, you can calculate where you expect the item to be on the screen based on its position in the list, the size of the element, the scroll position, and the height of the container element. If it is visible, you can render it and otherwise not. (Check out this blog post on virtualized lists that explains this well.)

To simplify virtualized scrolling even more, you can also use one of the many libraries that will handle the rendering logic for you. React, for example, has several available libraries, like react-virtualized.

Lastly, if you’re using Daily’s React Native library, react-native-daily-js, you can use React Native’s FlatList or SectionList components. They are both wrapper components for React Native’s Virtualized List component and will handle all the rendering logic for you, as well.

4. Limiting video feeds with pagination

In Daily Prebuilt on desktop, we limit the rendered participant tiles in two ways:

Virtualized lists
Pagination

In speaker mode, we used virtualized scrolling, as mentioned, to manage the participant bar videos. In grid mode, however, we use pagination to limit how many videos are on the screen at any given time. This allows all participants to be viewable, just not all at the same time.

The number of videos and the grid’s tile dimensions ultimately depend on the browser window size and what fits best based on our video aspect ratio requirements.

In Daily Prebuilt’s mobile designs, we’re a lot stricter with our grid layout and never render more than three remote participant tiles at a time. This is because mobile devices (especially iOS devices) use a noticeable amount of CPU resources to decode video. We’ve found mobile devices often can’t handle more than three (or so) videos at a time. Pagination helps manage this CPU bottleneck by allowing users to page through all participants while never rendering more than three remote videos.

To see an example of how pagination can be implemented with a grid of videos in Daily’s call object, let’s take a look at an example from a React app.

return (
    <div ref={gridRef} className="grid">
      {pages > 1 && page > 1 && (
        <button type="button" onClick={handlePrevClick}>
          Back
        </button>
      )}

      <div className="tiles">{tiles}</div>

      {pages > 1 && page < pages && (
        <button type="button" onClick={handleNextClick}>
          Next
        </button>
      )}
    </div>
  );

In the code block above, we render a parent div element. Inside the div, there’s a Back button conditionally rendered if you’re not on the first page. (Alternatively, you could render the button and disable it instead.) Next, we render the participant video tiles. Lastly, there’s another conditional Next button if you’re not on the last page.

Now let’s take a look at the tiles being rendered:

  const visibleParticipants = useMemo(() => {
    const participants = callFrame.participants();
    return (
      participants.length - page * pageSize > 0
        ? participants.slice((page - 1) * pageSize, page * pageSize)
        : participants.slice(-pageSize),
      [page, pageSize, callFrame]
    );
  });

  const tiles = useMemo(
    () => visibleParticipants.map((p) => <Video participant={p} />),
    [visibleParticipants]
  );

Here, we calculate which participants are visible by taking the total number of participants, the page number, and the number of participants per page. With those numbers, we can determine which participants should have tiles rendered for them.

Once we know the visible tiles, we can render a tile for each one. Each time the page number is increased or decreased by clicking the Next or Back buttons, the visible participants can be recalculated and the tile updates.

By restricting the number of tiles— and, therefore, the number of videos— being rendered at any given time, we can reduce the CPU load of a Daily video call substantially.

5. Memoizing components that re-render too often

You may have noticed in the example above, we’re using a React hook called useMemo.

const tiles = useMemo(() => {...}, [dependency1, dependency2]);

useMemo is an example of how to “memoize” React components. Memoization is an effective way to avoid re-computing potentially “expensive” calculations by using the cached computed value until one of the dependencies has changed. (A dependency is a value that affects the rendered output.) Memoization is used here to only update the tiles value when the dependencies— the values in the second parameter, the array— change.

Let’s look at another example to see how memoization works. In React, if you have a paragraph element (<p>) that displays the sum of two numbers that are each passed as props to a component, you could represent it like so:

const displayedSum = useMemo(() => {
    return (
      <p>Total: {num1 + num2}</p>
    )
}, [num1, num2]);

We can say pretty confidently that if num1 and num2’s values don’t change, the displayedSum element won’t change. (2+2=4, right?)

By using useMemo, we’re telling React that it doesn’t need to keep re-rendering this element unless num1 or num2 change, because then it will actually need to calculate the total again.

In the case of displayedSum, adding two numbers is probably not a very ”expensive” calculation in terms of CPU usage; however, with a grid of <video> elements, re-renders can get expensive fairly quickly, especially on mobile devices.

Preventing expensive re-renders via memoization (or any other methods) is one of the fastest ways to improve performance in your video or audio-only calls. If you’ve noticed any performance issues in your own Daily app, this is a great place to start.

6. Avoid unnecessarily removing and adding back videos

This one might sound contrary to what we’ve been saying so far but hear us out.

While it’s important to remove <video> elements that aren’t visible, you should avoid unnecessarily adding or tearing down media (video and audio) elements as much as possible. In React, for example, this could mean making sure your React hook dependencies are not too broad and you are not re-rendering media elements when you don’t need to.

This is especially important on iOS, which will have a noticeable CPU hit when adding and removing media elements unnecessarily.

7. Only play paused `<video>` elements

You might be starting to notice a pattern here and, well, you’d be right. If we could sum up our suggestions in one (possibly condescending) sentence, it would be, “Don’t do anything you don’t need to do.”

This is also the case for playing videos.

 useEffect(() => {
   const video = videoRef.current;
   if (!video) return;
   if (participant.videoTrack) {
         video.srcObject = new MediaStream([videoTrack]);
   } else {
     video.srcObject = null;
   }

   const handleCanPlay = () => {
     if (!video.paused) return;
     video.play();
   };

   video.addEventListener('canplay', handleCanPlay);
   return () => {
     video.removeEventListener('canplay', handleCanPlay);
   };
 }, [videoTrack, videoTrack?.id]);

In this snippet from Daily Prebuilt mobile code, we set the srcObject for the video element (represented by videoRef) if there’s a video track (videoTrack) available. Otherwise, the source is set to null.

We then add an event listener for the canplay event. The video element is then played as soon as it’s available if it is not already playing. For example, the video may get paused when disconnecting a Bluetooth audio device, so adding this event listener will help ensure the video is resumed as soon as its media stream is ready again.

You might be wondering if it really matters if you call play() on a video that’s not paused. It turns out checking if a video is actually paused before playing it does help performance, especially on iOS Safari.

As we discovered rewriting Daily Prebuilt for mobile, playing a video that is already playing on iOS Safari is not a "no-op". The action of playing a video, even if it is already playing, takes about 300ms to complete.

This means adding a simple check to see if the video is paused before playing will actually reduce the CPU usage of your Daily call on mobile.

Wrapping up

If there’s one thing we appreciate about WebRTC video calls at Daily, it’s that getting performance right across browsers and devices is tough. Hopefully, these lessons we’ve learned along the way help you customize your Daily calls even faster.

To learn more about building a custom Daily video call, check out our React demo repo, as well as our tutorial that goes along with it.

A New Kind of PR: Finding Running as a Remote Software Developer

Jess Mitchell — Mon, 26 Oct 2020 14:16:45 +0000

This week I had a new PR. Not my regular kind of PR that you'd see in my Github stats, but the kind I've been having before I start work in the mornings: a Personal Record. I hit 500 kilometers since I started tracking my runs back in April. I also hit a new longest distance with 15km yesterday.

Running, it turns out, has become the trick I've been looking for to stay healthy as a remote employee. I've been working remotely since 2017 and, for the most part, I've loved it. Despite being much more productive working from home, I've never totally felt like I've figured out the balance of being remote. Any socializing I used to get from being in an office I now had to make time for in my schedule. Any physical activity I got from going to work I'd also have to find time for. Scheduling became much more intentional too; flex schedules are great but can lead to long work days if you don't stay focused. Managing my anxiety also became a bigger challenge while spending so much time at home.

Finding this balance is likely what a lot of people have been thrown into unexpectedly this year: you need to get your work done, while also getting in some daily movement, while also having time to rest, while also not being crushed by the weight of 2020. (Shout out to parents who have way more on their plate than I do-- I genuinely don't know how you do it all.)

Previous to going remote, I just walked everywhere. It was the perfect solution for me because it gave me time to de-stress after work, to get in some movement, and to listen to audiobooks or podcasts (i.e. mental stimulation too). It also gave me the space to think and to solve coding problems I was stumped on at work. Walking pretty much helped every aspect of my day.

Then I went remote and didn't really need to walk further than a few meters from my bedroom to my desk. I tried going to a gym but it took up too much time and felt too body-focused. I also tried doing yoga every morning, which I still do pretty regularly, but I was definitely spending too much time inside already.

What I needed was an activity to burn off a lot of (mental and physical) energy, that I could do outside, didn't take up too much time, something that you can do through the winter, and had some sense of community to it.

Enter running. 🏃‍♀️

Last January I decided to try out the Couch to 5k app. I was a little skeptical because the last time I tried to get into running 4-5 years ago I got migraines after almost every run. And 5 or so years before that I had done some running but it was back when I was using exercise to manage my weight. Honestly, I hated every minute of it back then because it always felt like punishment.

This time I'd have to approach it from a more balanced perspective. Knowing that I'm sensitive to migraines, I had to figure out why running had been triggering them for me in the past. (Turns out I was going to hard, too fast, with terrible pre- and post- hydration routines.) I also knew I had to approach running from an anti-diet perspective: it shouldn't ever be in response to what I've eaten or to try to control my weight. It should literally just be to get out and run. To move, to get the mood boost, to challenge myself, and to have some space to think.

I decided to go slow and just follow the app's schedule. (I'm someone who likes to dive into things so going slow can feel pretty frustrating.) By March I ran my first 5k without stopping and I felt great about it. It got me out of the house, only took about 30 minutes, and gave me the chance to discover new parts of my neighbourhood. I noticed how much it was improving my mood and I made sure to never go if I really didn't want to to make sure it didn't become another thing I had to do.

(Sidenote: Hopefully this goes without saying, but whenever I run it's on a super quiet trail by my house with a mask in case I have to pass anyone.)

After completing the app, I had to decide what was next. A 10k? A half-marathon? Immediately I went from 1 to 100 in my head to see how far I could push myself. And then I stopped. This wasn't supposed to be something that was super challenging that I would eventually start to resent. It was meant to be a regular practice to help me feel mentally and physically balanced.

And so the practice began.

Instead, I decided to stick with 5k. It's not a big time commitment, it's long enough to be a real work out, and it could be as relaxed or challenging as I made it.

I decided to give myself a monthly total distance goal to stay motivated and increased it just a bit each month. 50k, 60k... by August I had finished 100k total in one month (or 20 5k runs). After running 100k total I decided not to increase anymore. Running 5 days a week was more than I was looking for long term, so I'd need a new goal.

After running 5k so many times and noticing that my legs were feeling a lot stronger, I decided it would be fun to see if I could do a 10k. There was a virtual race here in Hamilton (the Run for Women fundraiser) at the end of September, so the timing was perfect and it'd be an opportunity to raise some money as well.

Throughout September, I kept a few 5k runs during the week and used my Saturday runs to build up the longer distance. 6k, 7k, 8, 9k, and eventually 10k five Saturdays in a row. It felt incredible.

Since running my first 10k I've relaxed my weekday running schedule a bit to increase my Saturday long run distances. Yesterday I ran 15k. My pace was slow, I'm pretty sure I don't know how to breathe properly, and I avoided every hill I could. But I did it! And it felt great.

More than anything, running has represented one of my most important lessons-- one that I seem to need to learn over and over again and one that has made me a better programmer, as well: it's what we do a little over a long time (what we practice) that leads to real progress.

Now back to my regular PRs. 💻

DEV Community: Jess Mitchell

Build a video call app with Svelte in an afternoon

What exactly is Svelte?

Who is this tutorial for?

Getting started

App.svelte: Determining which view to show

Listening for custom events

Honey, I’m Home.svelte

Call on line 1, please

Embedding Daily Prebuilt in your Svelte app

Adding our custom control panel

Adding a Mute button to toggle local audio

Appetite for (call) destruction

Cleaning up after the party

Wrapping up

Build a real-time video chat app with React Native

Today's agenda

Who is this tutorial for?

A note on today’s stack and React Hooks

Getting started

App features and functionality

Displaying video tiles in your Daily React Native app

Iterating over our participant list

Rendering participant media

Controlling your local devices in-call

Resources

Build a mobile audio chat app in an afternoon with React Native

Who is this tutorial for?

Getting set up locally

Feature set and backlog

Component structure

CallProvider.jsx: The brain of this operation 🧠

How updating a participant type works using sendAppMessage

PreJoinRoom form

The in-call experience: Moderators and the rest of us

Sir, this is an Arby’s: Letting moderators mute speakers

You, you, you, oughta know

Resources

Build a custom video chat app with Daily and Vue.js

Planning our app’s features

Getting set up with Daily

Setting up your local dev environment

More spoilers: Looking at our component structure

Taking advantage of Vue’s data object

Okay, get to the code already

The App component: Determining our in-call state

Video call the radio star: Letting participants join with video and audio

Daily events and their callbacks

The joining-meeting event

The joined-meeting, participant-joined, participant-updated, participant-left events

The error event

The camera-error event

The app-message event

How our stored data impacts our rendered Call UI

Iterating over our participants array

Call me a mason because we’re about to lay some tiles

Adding a ScreenshareTile

Wrapping up

Designing web accessible video calls

Tips from Daily on how we implement accessible UIs to ensure everyone can connect online through video

Web accessibility: What exactly is it?

Who benefits from web accessibility?

POUR Principles

Web Accessibility at Daily

Making all interactive UI elements keyboard-accessible

Adding focus traps

Avoiding keyboard traps

Adding skip links to Daily’s Dashboard

Special treatment of “hidden” elements

Creating hidden labels for screen readers

Removing hidden elements from the tab order

Using semantic HTML

Wrapping up

Build a real-time video chat app with Vue and Daily Prebuilt in under ten minutes

Tutorial requirements

Create a new Vue app

Demo project overview

Ready to go Home: Importing Daily Prebuilt to your Vue app

Controlling your in-call experience programmatically

Toggle your local camera programmatically

`App.svelte`: Determining which view to show

Honey, I’m `Home.svelte`

How updating a participant type works using `sendAppMessage`

The `App` component: Determining our in-call state

The `joining-meeting` event

The `joined-meeting`, `participant-joined`, `participant-updated`, `participant-left` events

The `error` event

The `camera-error` event

The `app-message` event

How our stored data impacts our rendered `Call` UI

Adding a `ScreenshareTile`

3. Using virtual lists to reduce how many `<video>` elements are rendered

7. Only play paused `<video>` elements