DEV Community: Rehema

Test

Rehema — Wed, 30 Aug 2023 11:14:23 +0000

Introduction

We’re continuing our series on creating a Virtual Classroom using The Video SDK. In our last piece, we built the server-side for our Classroom. In part 2, we’ll build the client-side of our application using the following tech-stack:

-React as my framework
-Ant-Design as my UI library
-TailwindCSS as a CSS library (for slight style tweaking)
-Zoom Video SDK for media integration

The client-side has more going on that the server-side, so let’s take some time to break down the folder structure.

Context

This folder contains globalContext.js, which houses my created contexts objects. I'll import and use the objects throughout my project to take advantage of React Context for sharing state.
The second file in this folder is globalState.js. This is where I created my centralized state and reducer functions (for an in-depth look on how you can combine reducer functions with Context API, check out this React documentation).

Features

This folder contains a few sub-folders: 'Home', 'Stats', 'Student', 'Teacher', 'Video'. Each sub-folder houses the necessary files to build out the feature for which it's name (e.g.; the 'student' folder contains the styling and javascript files for the student page)

Hooks

This folder contains hooks made for global use throughout files in the client folder.

Icons

This folder contains images and fonts used for styling purposes (used primarily with ant-design UI library).

Miscellaneous

Lastly, we have the files a project typically starts with; App.js & index.js (and the styling files for each). App.js is where we render our different components, while Index.js is where we mount our application to the DOM. Let's start walking through the build-process in Index.js.

Rendering Our App & Creating Our Client

In index.js (/client/src/index.js), outside of rendering my App to the DOM, I also created my Zoom Client. I wanted to make sure my created client was accessible in all my rendered components. To ensure this, I:

Imported 'ZoomVideo' from 'zoom video sdk' npm package
Created my client and stored it in a variable
Used the Context API Provider method to pass in a value
Passed in my stored client to my imported 'ClientContext' as it's value
Wrapped my rendered 'App' component with my 'ClientContext.Provider', making use of the context provider.

Now that we've done these initial steps, let's move into our App.js file and start rendering our components.

Rendering Our Components to Our App

In App.js(/client/App.js), I created some state to use throughout my components with the useState hook, as shown below.

  const [mediaStream, setMediaStream] = useState();
  const [chatClient, setChatClient] = useState();
  const [memberState, memberDispatch] = useReducer(userReducer, userState);
  const [sessionState, sessionDispatch] = useReducer(sessionReducer, initsessionState);
  const [rosterState, setRosterState] = useState([])
  const [letterModal, setLetterModal] = useState(false)
  const [letter, setLetter] = useState('')

Making use of React's Context API again, I imported my created MediaContext, UserContext, and ClassroomContext from my globalContext.js file. To route my components, I used the package 'react-router-dom'. Let's go over how I routed my components:

I assigned values to each Context Provider I'd be using, and wrapped my components inside each of them
I wrapped them inside the BrowserRouter to manage the history stack & with the routes wrapper
Each route was assigned the appropriate component as its element and given a path

A snippet of the rendered UI for App.js is shown here:

<ClassroomContext.Provider value = {{
          rosterState,
          setRosterState,
          letter,
          setLetter,
          letterModal,
          setLetterModal,
        }}>
          <BrowserRouter>
            <Routes>
              <Route path = '/' element = {<Home/>} />
              <Route path = '/LandingPage' element = {<LandingPage/>} />
              <Route path = '/Video' element = {<VideoContainer/>} />
              <Route path = '/StudentVideo' element = {<StudentVideo/>} />
              <Route path = '/TeacherVideo' element = {<TeacherVideo/>} />
              <Route path = '/StudentHome' element = {<StudentHome/>} />
              <Route path = '/Nav' element = {<NavBar/>} />
              <Route path = '/LoginForm' element = {<LoginForm/>} />
              <Route path = '/classroom-stats' element = {<ClassroomStats/>}/>
              <Route path = '/session-stats' element = {<SessionStats/>}/>
              <Route path = '/attendance-stats' element = {<AttendanceStats/>}/>
            </Routes>
          </BrowserRouter>
            </ClassroomContext.Provider>
        </UserContext.Provider>
      </MediaContext.Provider>

Now that we've finished our starter pages, index.js and App.js, let's move into building our features, starting with our home page.

Building out The Home Feature

The 'Home' folder (/client/src/Features/Home) has three pages (with associated styling files):

Home.js
LandingPage.js
LoginForm.js
Nav.js

Looking at the Home component first, I used this page to do two main things: gather and assign information about the user, and conditionally render my LoginForm component. We'll review both pieces.

Assigning a User as Teacher or Student

With our application being a classroom, we need to correctly identify the type of user we have entering. With that, I decided to use a dropdown menu to select the type of user. Here's the UI for this:

 return ( 
      <div className = "homePage">
      <div>
      {memberState.status === '' && 
      <div>
        <Select
          defaultValue="I am A..."
          style={{
          width: 150,
          }}
          className='homeDropdown'
          onChange={onClick}
          options={[
            {
              value: '1',
              label: 'Student',
            },
            {
              value: '2',
              label: 'Teacher',
            },
            {
              value: '3',
              label: 'Guest',
            },
          ]}
        />   
      </div>
      }

You should notice that this dropdown is only being rendered if our memberState.status is an empty string. The memberState object was brought into this file using the 'useContext' hook.

As a quick refresher, memberState was created and passed down to our components in App.js, and its making use of the userState we created in globalState.js.

When a selection is made from the dropdown menu, the function 'onClick' runs. Heres' a breakdown of what it does:

Assigns a variable meetingArgs to the value of the imported devConfig object. This object contains necessary properties about a user; topic, name, password, roleType.
Uses a conditional to properly assign the roleType property, based on the value selected from the dropdown (roleType 1 makes the user the host, while roleType 0 makes them a standard user).

let meetingArgs = {...devConfig};
    if (value === '1' || value === '3') {
      user = 'Student';
      meetingArgs.roleType = 0;
    } else {
      meetingArgs.roleType = 1;
      user = 'Teacher'
    }

Check if the meetingArgs object contains a signature property, assigning one if the condition is not met, with the 'getToken' function

GetToken

  const getToken = async(options) => {
    let response = await fetch('/generate', options).then(response => response.json());
    return response;
    }

Updates the root userState with the 'updateArgs' functionn to change the meeting arguments, and the 'updateStatus' function to change the memberState.status property

updateArgs and updateStatus

  const updateArgs = (args) => {
    memberDispatch({
      type: 'UPDATE_ARGS',
      payload: {
        meetingArgs: args
      }
    })
  }

  const updateStatus = (user) => {
    memberDispatch({ 
      type: 'UPDATE_STATUS', 
      payload: {
        status: user
      }
    })
  }

If our status property of memberState is not an empty string, we'll render our login form. Let's go ahead and move into that component.

Building Our Login Form

The goal of this page/component(/client/src/Features/Home/LoginForm.js) is to check the user's credentials against our database and get them securely logged in. Here's a breakdown of the component:

A form is used to collect user login credentials (in this case, we're using the form component from ant design)

 <Form.Item
      label="Username"
      name="username"
      rules={[
        {
          required: true,
          message: 'Please input your username!',
        },
      ]}

    >
      <Input onChange={(e) => updateUsername(e.target.value)} />
    </Form.Item>

    <Form.Item
      label="Password"
      name="password"
      rules={[
        {
          required: true,
          message: 'Please input your password!',
        },
      ]}
    >
      <Input.Password onChange={(e) => updatePassword(e.target.value)} />
    </Form.Item>

As seen in the above snippet, username and password are both updated in real-time with the created functions updateUsername and updatePassword

const updateUsername = (username) => {
    memberDispatch({
      type: 'UPDATE_USERNAME',
      payload:{
        username: username
      }
    })
  }
  const updatePassword = (password) => {
    memberDispatch({
      type: 'UPDATE_PASSWORD',
      payload:{
        password: password
      }
    })
  }

The function 'submitUserData' will run when the user submits their credentials
'submitUserData' makes a POST request to our '/login' endpoint on the server-side

const requestOptions = {
      method: 'POST',
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify({"username": memberState.username, "password": memberState.password})
    };
    let result;
    result = await fetch("http://localhost:4000/login", requestOptions).then(res => res.json());

Based on the result from the fetch-call, the function either renders an 'error' to the user if the login fails, or navigates to the Landing Page if it is successful

else {
      memberDispatch({
        type: 'UPDATE_ERROR',
        payload: {
          error: false,
        }
      })
      navigate('/LandingPage')
    }

Using local storage to maintain status, the function saves a value of 'Logged_in' as true, and 'User_Type' as the current status property in my memberState object

    localStorage.setItem('Logged_In', JSON.stringify(true));
    localStorage.setItem('User_Type', JSON.stringify(`${memberState.status}`))

Updates our stored meetingArgs name property with saved username we got from the user
Lastly, the function 'getRoster' is called. This makes a GET request to the '/session' endpoint. The received result is a list of session users, which is saved to the rosterState. This keeps our list of users current whenever a login occurs

  const getRoster = async() => {
    let roster = await fetch('/session').then(roster => roster.json());
    setRosterState([...rosterState, roster]);
    }

That's it for our login form component. Now, we'll move into our Navigation Component.

The Navigation Bar

Although a small feature in appearance, the navigation component houses a bit of functionality. In this component, we:

Initialize and join our Video SDK Session
Set our administrative permissions
Create a button to log out of a session, open a letter modal, and enter a video session

I wrapped my initialization and join function inside a useEffect React hook. This allows me to create and join a session whenever necessary, but never duplicate the function. Let's break down what's happening inside this useEffect function:

Create an asynchronous function that initializes the session and updates the root sessionState's sessionStarted property to true. The initialize function is a promise, so we'll perform the following functionality inside a try...catch block if the promise resolves

    useEffect(() => {
      const init = (async () => {
        console.log('session init')
        await client.init('en-US', 'CDN') 
        try {
          sessionDispatch({
            type: 'UPDATE_SESSION',
            payload: {
              sessionStarted: true
            }
          })

Call client.join (on our client that was created back in index.js, and imported in using the useContext hook), passing in values from our meeting arguments object stored in memberState const {topic, signature, name, password, roleType} = memberState.meetingArgs;

await client.join(topic, signature, name, password);

Captured our mediaStream using client.getMediaStream
Captured our chat client using client.getChatClient

const stream = client.getMediaStream();
          setMediaStream(stream);
          const chat = client.getChatClient();
          setChatClient(chat)

-Updated the root sessionState's sessionJoined property to true
-Check to see if our roleType for our user is set to 1. If so, we're going to save a new value to local storage: a key of 'admin' set to true

          if (memberState.meetingArgs.roleType === 1) {
              localStorage.setItem('admin', JSON.stringify(true))
            }

If the promise fails, send an error to the client
Lastly, call our initialization function we created

The navigation bar has a few buttons that trigger different functions. We'll take a look at each.

End Session destroys the session and sends the user back to the homepage. This button is only available on the teacher landing page

    const endSession = async () => {
      if(sessionState.sessionStarted) {
        console.log('destroying Session')
        ZoomVideo.destroyClient();
        sessionDispatch({
          type: 'UPDATE_SESSION',
          payload: {
            sessionStarted: false
          }
        })
        navigate('/')
      }
    };

Join Video sends the user the appropriate video call page

    const joinVideo = () => {
      navigate(`/${memberState.status}Video`)
    }

Login/Logout works in different ways conditionally. If a user is logged in, the button will read 'Logout' and a click will cause local storage to be cleared and redirect the user to the homepage. If a user is not logged in, the button will read 'Login' and a click will redirect the user to the login page. (note: to make sure logging out does not log _all users out, you can create two separate properties in local storage; for teacher logged in and student logged in. Then, reset the appropriate property value to false when the log out function is triggered)

    const logout = () => {
      if (localStorage.getItem('Logged_In')) {
        localStorage.clear();
        navigate('/');
        console.log(localStorage)
      } else {
        navigate('/LoginForm')
      }
    }

Check for Letters! opens up a modal to show received letters. This button is only available on the teacher landing page. We'll review the letter modal later on

That wraps up the navigation component. Now let's move onto our landing page.

Creating the Landing Page

LandingPage.js (/client/src/Features/Home/LandingPage.js) is a pretty simple component, used to render the appropriate user's homepage-either student or teacher (in hindsight, building this component could've skipped altogether, and you could instead conditionally render the right homepage within the submitUserData function in Login.js).

LandingPage.js makes use of memberState, checking the user status. If status is 'Teacher', the app will render the 'TeacherHome' component. If status is 'student', 'StudentHome' will be rendered.

 return (
    <div>
      {
      memberState.status === 'Teacher' && 
      <div> 
         <TeacherHome/>
      </div>
      }
      {
        memberState.status === 'Student' && 
        <StudentHome/>
      }  
    </div>
  )
}

Let's look at each of those components.

Student Landing Page

This page (/client/src/Features/Student/StudentHome) renders our navigation bar and a space for students to write letters to their teacher. It renders the:

NavBar Component
LetterBox Component

We already dove into the NavBar. Let's look at the LetterBox component.

Sending Letters

Here (/client/src/Features/Student/letterBox), we're creating an input box and storing the input for display somewhere else. This component make use of the Video SDK Chat feature. Here's a breakdown of what's going on:

Inside our input box, I updated the stored message whenever something was typed by invoking the function 'updateMessage' when onChange for the input is triggered
To "send" the message, we're using the send method for the Zoom Video SDK Chat Client. The first parameter passed is the message, and the second is the user ID of who we're sending the message to

  const updateMessage = (input) => {
    setInputMessage(input)
  }

  const sendMessage = () => {
    message.info('Your Message Has Been Sent!')
    chatClient.send(`${inputMessage}`, (JSON.parse(localStorage.getItem('teacherId'))))
  }

We'll be able to see the message that was sent on the teacher landing page, so let's jump into that now.

Teacher Landing Page

On the teacher homepage (/client/src/Features/Teacher/TeacherHome.js) we give teachers the options to end a session, check for student-sent letters, or view different classroom statistics. We're going to look more closely at the letter-checking option.

Receiving Letters

To make sure letters are sent properly, I needed to collect and set the teacher's user ID:

```js localStorage.setItem('teacherId',client.getSessionInfo().userId);



_(Reminder that we use this on letterBox.js to identify who we're sending our letter to)_

Next, I used an event-listener to receive the message and save it to a piece of state:



```js
  client.on('chat-on-message', (payload) => {
    console.log(payload.message);
    setLetter(payload.message)
  })

The received letter is viewed by clicking a button to open a modal. Moving into LetterModal.js (client/src/Features/Teacher/LetterModal.js), I pulled in my letter state with useContext and rendered it in the return statement. Additionally, I used pieces of state to determine where or not the modal should be open.

  const {letter, letterModal, setLetterModal} = useContext(ClassroomContext);
  return (
    <>
      <Modal
        title="A Letter For You"
        style={{
          top: 20,
        }}
        open={letterModal}
        onOk={() => setLetterModal(false)}
        onCancel={() => setLetterModal(false)}
      >
       {letter}
      </Modal>

Moving to the other options for teachers from their homepage, we're going to dive into the classroom statistics components.

Getting Classroom statistics

The folder Stats (/client/src/Features/Stats) has three files:

attendance-stats.js
classroom-stats.js
session-stats.js

In attendance-stats.js, I created a table using the Table component from ant-design and the roster I worked with in LoginForm.js:

  const data = rosterState[0].map((user) => {
  return (
      {
        name: user.name,
        userId: user.userId, 
        //time is hard-coded for demo purposes, to display actual arrival time, access via user.TOA
        Arrived_At: '10:30AM'
      }
    )
  })

In classroom-stats.js, I followed the same format, creating a table with the Table component. For demo purposes, my data has been hard-coded, but the steps to gather and render classroom statistics:

Make a fetch-call to your server-side endpoint to gather your users from your database. Mine is shown below:
Cycle through your received information using the map array method, assigning key-pair values for each element
Render the data by saving the output to a variable and passing that variable into the the dataSource prop of the Table component, like shown below:

 <Table dataSource={data} columns={columns} />

Lastly, in sessionStats.js, I gathered information about the session by making a fetch-call to my appropriate end point. To keep this current, this needed to be done every time this component is loaded. Because of this, I wrapped the function in a useEffect:

  useEffect(() => {
    const getSessionStats = async() => {
      let details = await fetch('/details').then(res => res.json());
      setStats(details)
    }
    getSessionStats();
    console.log(stats)
  }, [])

Next, I followed the same pattern as in my last two stat components. A code snippet is shown below:

  const data = [
    {
      sessionId: stats.id,
      startTime: stats.start_time,
      duration: stats.duration,
      classCount: stats.user_count,
      //recording must be enabled on account
      recorded: stats.has_recording
    }
  ]

  const columns = [
    {
      title: 'Session ID',
      dataIndex: 'sessionId', 
      key: 'sessionId'
    },
    {
      title: 'Start Time', 
      dataIndex: 'startTime',
      key: 'startTime'
    },
    {
      title: 'Session Duration', 
      dataIndex: 'duration',
      key: 'duration'
    },
    {
      title: 'Attendance Count',
      dataIndex: 'classCount',
      key: 'classCount'
    },
    {
      title: 'Session Recorded',
      dataIndex: 'recorded',
      key: 'recorded'
    }
  ]

  return (
    <div className = 'attendance-container'>
      <div className = 'attendance-wrapper'>
         <Table dataSource={data} columns={columns} />
      </div>
    </div>
  );

We've finished with the statistics! Next, we'll move into customizing our video-call.

Customizing Your Video-Call

To create my video component, I followed the steps outline in this article, in addition to utilizing custom hooks from the sample-web-application to customize sizing. These files are very tedious, so I'd highly suggest utilizing the Video SDK UI Toolkit to create your video-call container, then personalize from there.

In this virtual classroom application, I wanted to take things a step further and take advantage of customization opportunities that come with the SDK. Therefore, I made two separate video-call components; one for the teacher and one for the student.

Creating Video-Call Components

I used the video-footer file (/client/src/Features/Teacher/Video/components/VideoFooter.js), to manage my buttons for the video-call. I added useful features for virtual audience management. Those features are:

Timed mute button, which gives teachers the option to only allow participants to unmute for a certain amount of time. This gives more ability for audience control. Here is the code snippet I used to achieve this:

else {
      await mediaStream?.startAudio();
      setIsStartedAudio(true);
      if (memberState.status === 'Student') {
        setTimeout(() => {
          mediaStream?.stopAudio();
          setIsStartedAudio(false);
          message.info('Time is Up! Thanks for Sharing')
        }, 10000);   
      }
    }

In the student video-footer page, I disabled the 'screen-share' button to prevent students in the virtual classroom from sporadically sharing their screen. This is a simple addition, but you could further customize by timing how long someone can screen-share, sending a notification to the teacher to either allow or deny screen-sharing, etc.

The code snippet (/client/src/Features/Teacher/Video/components/ScreenShareButton.js) I used to achieve my feature is below:

(
        <Tooltip title={memberState.status === 'Student' && 'Students Cannot Share Screen'}>
        <Button
          className={classNames('screen-share-button', {
            'started-share': isStartedScreenShare
          })}
          disabled={memberState.status === 'Student' ? true : false}
          icon={<IconFont type="icon-share" />}
          ghost={true}
          shape="circle"
          size="large"
          onClick={onScreenShareClick}
        />
        </Tooltip>

Conclusion

That's it for this piece on building a Virtual Classroom with The Video SDK. Let's recap what we accomplished:

Built out our front-end with specific components for both types of users -Gathered and displayed statistics from either our database or the Video SDK API
Customized Video-Call features to meet audience needs

Thanks for following along with me!

Build with Me! - Getting Started with the Video SDK

Rehema — Fri, 06 Jan 2023 16:10:48 +0000

Intro

At Zoom, we're known for the consistently high-quality media we provide to our users. As a platform for customers and developers alike, not only can you rely on that quality for your meetings, but you can also build with our servers to integrate said quality into your own apps.

How you ask? Enter, Zoom Video-SDK. With the Video SDK, you can pull high-quality audio and media into your application, while customizing it to fit your brand and voice. Want to live stream your at-home yoga class? You got it. Build out a virtual classroom? You can do that, too. With such an array of possibilities, the goal of this article is to simply get you started.

In this post, we'll go over how I built I simplified version of the published Web Video SDK app, using React. We'll cover:

Tech-stack used for the project
Generating our JWT Token & Storing our Variables
Building Out Core Functionality in index.js & App.js
Video, Audio, & Screen-Share Functionality

Again, the goal of this demo is to provide an easy-to-follow framework, as a starting point for working with the Video SDK. For a more complex build of this application, feel free to clone and review the published Video SDK Web sample application, on which this project is based.

Tech Stack Overview

For this project, we’ll be using React to develop our frontend, taking advantage of Context API to pass and share data relevant to our created Zoom client. In addition, our project will utilize react-router-dom for dynamic routing throughout.

This project makes use of ant design for styling, but Vanilla CSS or any UI library can be used, such as Material UI, Bootstrap, etc. Additionally, our project will require encryption for JWT generation. For this, we’ll use jsrsasign as our cryptography library.

To build out my API on the backend, I’ll be using Nodejs with Express. Also, I (of course) used the '@zoom/videosdk to create, manage, and join sessions.

Lastly, this project will be built using Create-React-App. Of course, if preferred, manually building and creating your own webpack file, or using parcel to create your project are effective options, as well.

Now that we’ve reviewed the packages being used in this project, let’s get to building the application! The first thing we want to do is safely create and store variables.

Generating our JWT on the Server-Side

When building with the Video SDK, a JWT signature will always be required to initialize or join a session. To generate and use your token within your application, it's best practice to write your functionality on the server-side, to ensure safe-keeping. I did this using express on top of Nodejs, making use of middleware to perform the logic for creating my token.

I first created my 'server.js' file, where I added a variable, 'router', set equal to the express.Router() class to manage my routes. After properly configuring my server.js file (pulling in requirements, setting up my port, error handling, etc.), I created a post request to send my generated token to the front end.

server/server.js

router.post('/generate', middleware.generateToken, (req, res) => {
    res.status(200).send(res.locals.token)
})

You'll see an added function in my post request 'middleware.generateToken', which was created in a separate file and then imported in. There, I handled our token generation. I destructured my request body to access my meeting arguments for use in my JWT payload. After creating my signature, I save it to my res.locals object, which was sent to the frontend in my post request. From there, I finished creating my middleware function, which can be seen below.

server/middleware.js

const KJUR = require('jsrsasign')
require('dotenv').config();

const middleware = {};

middleware.generateToken = async(req, res, next) => {
    console.log(req.body)
    try {
        let signature = '';
        const iat = Math.round(new Date().getTime() / 1000);
        const exp = iat + 60 * 60 * 2;

        const oHeader = { alg: 'HS256', typ: 'JWT' };
        const {topic, passWord, userIdentity, sessionKey, 
              roleType} = req.body
        const sdkKey = process.env.SDK_KEY;
        const sdkSecret = process.env.SDK_SECRET;
        const oPayload = {
            app_key: sdkKey,
            iat,
            exp,
            tpc: topic,
            pwd: passWord,
            user_identity: userIdentity,
            session_key: sessionKey,
            role_type: roleType,
        };
        const sHeader = JSON.stringify(oHeader);
        const sPayload = JSON.stringify(oPayload);
        signature = KJUR.jws.JWS.sign('HS256', sHeader, sPayload, sdkSecret);
        res.locals.token = signature;
        return next();
    }
    catch(err) {
        return next({err})
    }
}

(The logic used for token generation can also be found in our documentation, here).

Safely Storing Your Variables

You may have noticed in the code snippet above that the values for the sdkKey and sdkSecret are read in using process.env. This is to ensure I'm keeping my private data (API key and secret) private. I created a ‘.env’ file to store both of those credentials, and used 'dotenv' to read them into my middleware function.

Building out index.js

After building out my backend functionality for token generation, I jumped into my frontend and started with my entry-point file, index.js. Here, the first thing I did was pull in all necessary imports, including local files for styling/component rendering, and all my React necessities (react, react-Dom, used hooks, etc.). I’ve also imported the ZoomVideo’ component from the @zoom/videosdk package, which will be used to create our client.

I also imported my devConfig file. This was where I created an object to house all the necessary parameters (outside of my sdk key and sdk secret) for initializing and joining a Video SDK session. It can be seen below:

client/src/dev.js

export const devConfig = {
  topic: ' test topic',
  name: 'Chrome',
  password: 'pass', 
  role: 1, 
};

Lastly, I imported a file called ZoomContext to make use of the Context API. In this file, I created a context to easily pass values to nested components.

Imports in client/src/index.js

import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';
import { devConfig } from './config/dev';
import { generateVideoToken } from './tools/tools.jsx'
import ZoomVideo from '@zoom/videosdk';
import ZoomContext from './context/zoom-context';

client/src/context/zoom-context.js

import { VideoClient } from '@zoom/videosdk';
import React from 'react';

export default React.createContext(VideoClient);

After my imports, the next thing I did was build out my meeting arguments object, which is used to initialize and join sessions. To do this, I first declared the variable 'meetingArgs' and assigned it to a copy of my imported ‘devConfig’ object.

From there, I needed to generate and add my JWT signature to the meeting arguments object, contingent on it already containing the topic. To get this done, I first created the function 'getToken', which makes a fetch call to my backend API (described in the previous section).

client/src/index.js

let meetingArgs = {...devConfig};

const getToken = async({options}) => {
  let result; 
  result = await fetch("http://localhost:3001", options);
  result = await result.json();
  return result;

}

Next, I want to call my created function inside a conditional that checks my meeting arguments object for the necessary elements. Inside of my conditional, before calling the function, I created my requestOptions object to send to my backend route (this is necessary when making a post request).

As seen, the body of the request is my meeting arguments object (converted to a JSON string). After this, while still in my conditional, I called my 'getToken' function, passing in my 'requestOptions' object as my argument. Since this function receives and returns my generated token from the backend, I set it's output equal to my meeting argument's signature value.

client/src/index.js

if (!meetingArgs.signature && meetingArgs.sdkSecret && meetingArgs.topic) {
  const requestOptions = {
    method: 'POST',
    headers: {'Content-Type' : 'application/json'},
    body: JSON.stringify(meetingArgs) 
  }
  getToken(requestOptions).then((res)={meetingArgs.signature 
  =res})
}

My next step was creating my Video SDK client, which is used to manage my sessions. This is done by simply using the createClient method on my ZoomVideo component.

client/src/index.js

const client = ZoomVideo.createClient();

Now that I have my meeting arguments object properly configured and my client created and stored, I used React DOM to render my application. Inside my render function, I passed in my imported ‘App’ component, adding a context wrapper around it. Using the provider method (ZoomContext.Provider), I passed in my created client as the provider’s value so that it is now accessible in my App Component. Lastly, I prop-drilled down my meetingArgs object.

client/src/index.js

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
      <ZoomContext.Provider value = {client}>
        <App meetingArgs = {meetingArgs}/>
      </ZoomContext.Provider>
  </React.StrictMode>
);

Building out App.js

In App.js, I built out the necessary functionality for when the application first launches. This includes pulling in my client & joining and starting a session. To ensure efficiency, I made use of different React Hooks;

useState to manage different pieces of simple state throughout the application, such as loading text shown on the screen
useEffect to mimic componentDidMount and perform different side effects, such as initializing a session whenever there’s a change to meeting arguments
useContext to access values passed down in provider wrappers. Here, it was used to create and store my Video SDK client

After making my necessary imports (react hooks, react-router-dom, styling components, context files, etc.) and moving into my functional component, I took some preliminary steps to give myself a good starting framework. The first one was some object destructuring to access the values I prop-drilled down in index.js. This gives me easy access to those meeting arguments for future use.

client/src/app.js

const App = (props) => {
  const {
    meetingArgs: { sdkKey, topic, signature, name, password }
  } = props;

Next, I made use of the useState hook, as mentioned before, to set up pieces of state to appropriately render different parts of my application.

client/src/app.js

  const [loading, setIsLoading] = useState(true);
  const [loadingText, setLoadingText] = useState(' ');
  const [mediaStream, setMediaStream] = useState();
  const [status, setStatus] = useState(false);

The last preliminary step was using the useContext hook to grab that value I passed through in index.js, and create my client here in my App Component.

client/src/app.js

 const client = useContext(ZoomContext);

With those things out of the way, I dove into my first function, init, which is an asynchronous function that makes use of the ‘try…catch’ block for error handling. Inside init, I called client.init(), which is a Zoom Video SDK built-in method that initializes a session.

I passed in the two required parameters to this method; the language being used (English, in this case), and the dependent asset deployment path (‘CDN’, in this case. A more detailed explanation on this be found in our reference guide).

Inside my ‘try’ block, I wrote the logic for joining the session (after a successful session initialization). The join method takes in four necessary parameters; the user’s meeting topic, signature, name, and password.

After joining, I needed to set mediaStream state. I created a variable 'stream', & set it equal to the output of using the getMediaStream method on my client. Now, I’m able to use my ‘stream’ variable to manipulate any incoming media, such as audio and video. This is the variable I used to set my mediaStream state.

The last thing I’ll do inside of my ‘try’ block is set my loading state to false because we’re finished initializing and joining.

client/src/app.js

    try {
      setLoadingText('Joining Session...')
      await client.join(topic, signature, name, password)
      const stream = client.getMediaStream();
      setMediaStream(stream);
      setIsLoading(false);
    }

When I wrote all this logic for initializing and joining a session, I wrapped it inside of a useEffect hook. The side-effect performed is the execution of the init function, and the clean-up functionality for it is destroying the client, effectively ending any sessions. To do the destroying, I used the destroyClient method on my imported ZoomVideo component.

My dependency array for this useEffect functionality includes the following elements: sdkKey, signature, client, topic, name, password. Put together, all of this means that the created init() function will be performed as a side effect if there is any change to those previously listed elements, and before that side effect ever re-renders, the client will be destroyed. The complete functionality is shown below.

client/src/app.js

useEffect(() => {
    const init = async () => {
      await client.init('en-US', 'CDN')

    try {
      setLoadingText('Joining Session...')
      await client.join(topic, signature, name, password)
      const stream = client.getMediaStream();
      setMediaStream(stream);
      setIsLoading(false);
    }
    catch(err) {
      console.log('Error Joining Meeting', err);
      setIsLoading(false);
      message.error(err.reason);
    }
  }
    init();
    return () => {
      ZoomVideo.destroyClient();
    }
    }, [sdkKey, signature, client, topic, name, password])

The next piece of my App component was adding in my UI and component navigation (making use of React-Router-Dom for the latter). Really, the only UI actually written within this component was a conditional ‘loading’ statement. Otherwise, the displayed UI after loading comes from the rendered ‘home’ component, since its path is listed as ‘/’ (this makes it the default page for the loaded application. You can set whatever component you've created to be your default page).

A key aspect of App.js’s return statement is the use of Context API to pass down a value to the nested components. I made use of the MediaContext component I created and imported, and passed in my mediaStream variable as the provider’s value. This is what allowed me access to incoming media in my nested component used for video.

client/src/app.js

 return (
    <div className="App">
      {loading && <LoadingLayout content = {loadingText}/>}
      {!loading && (
        <MediaContext.Provider value = {mediaStream}>
          <Router>
          <Routes>
          <Route path = "/" element = {<Home props={props} status = {status} onLeaveOrJoin = {onLeaveOrJoin}/>}/>
          <Route path = "/video" element = {<VideoContainer/>} />
          </Routes>
          </Router>
         </MediaContext.Provider>
      )}
    </div>
  );

With that, let’s go ahead and move on to the Video Component!

Note: (While the home page is a component, it’s not essential to understanding the Video SDK, and therefore we’re skipping over it.)

Video Component

Accessing Video, Audio, and enabling Screen-sharing

Alright, now it’s time to really use the magic of the Video SDK. Inside of my video component, after pulling in my imports, the first thing I did was create some pieces of state that helped me make appropriate use of my features:

videoStarted, to know whether or not the camera is on audioStarted, to know whether or not the microphone is on
isMuted, to know whether or not the user is muted
isShareScreen, to know whether or not there’s an active screen share happening
isSAB, to know whether or not SharedArrayBuffer is enabled (discussed in further detail later)

Next, I created my client and mediaStream variables through the use of the useContext hook, accessing those passed down values ('client' passed down in index.js, and 'mediaStream' passed down in my App Component). Now that these steps are done, let’s look at what I did for my video functionality.

Video Functionality

To get started here, I created an asynchronous function to handle the turning on and off of the camera and checked my 'videoStarted' state before anything else.

To turn on and access my video as self-view, I’m going to use the startVideo method on my mediaStream variable (remember, the mediaStream variable was created in App.js by calling the .getMediaStream method, then passed down through the MediaContext Provider). The parameter that I pass through to startVideo(), though, is dependent on whether or not the browser has SharedArrayBuffer enabled.

Let’s look at the difference in how we start our video based on this factor:

When working to achieve self-view video with the Video SDK, without SharedArrayBuffer, you must pass through your HTML element as a video tag.

client/src/feature/video.js

 if (!videoStarted) {
   if (!!window.chrome && !(typeof SharedArrayBuffer 
   ==='function')) {
     setIsSAB(false);
     await mediaStream.startVideo({videoElement: 
     document.querySelector('#self-view-video')})

When working to do the same with SharedArrayBuffer enabled, the 'startVideo' method won’t take any parameters. Instead, they’ll be passed into an additional method, renderVideo. 'RenderVideo' is called on your mediaStream variable immediately following the invocation of .startVideo()
Further, your HTML element passed through to .renderVideo() will be a canvas tag, in addition to several other parameters to determine dimension. These parameters are current userID, width, height, x coordinate, and y coordinate.

client/src/feature/video.js

} else {
  setIsSAB(true);
  await mediaStream.startVideo();
  mediaStream.renderVideo(document.querySelector('#self-view- 
  canvas'),client.getCurrentUserInfo().userId, 1920, 1080, 0, 
  0,3)
 }

To stop my video, I simply invoked the stopVideo method, followed by the stopRender method if necessary (based on SharedArrayBuffer). If we do have SharedArrayBuffer enabled and are using 'stopRender', know that it only calls for two parameters; canvas element and the current userID.

My video functionality is wrapped in a useCallback hook so that the functionality is memoized, and its dependency array includes the following: mediaStream, videoStarted, isSAB, client.

The full functionality is shown below, for starting and stopping video, with and without SharedArrayBuffer enabled.

client/src/feature/video.js

   const startVideoButton = useCallback(async () => {
     if (!videoStarted) {
       if (!!window.chrome && !(typeof SharedArrayBuffer 
       ==='function')) {
         setIsSAB(false);
         await mediaStream.startVideo({videoElement: 
         document.querySelector('#self-view-video')})
       } else {
         setIsSAB(true);
         await mediaStream.startVideo();
         mediaStream.renderVideo(
         document.querySelector('#self-view-canvas'), 
         client.getCurrentUserInfo().userId, 
         1920, 1080, 0, 0, 3)
        }
       setVideoStarted(true)
   } else {
        await mediaStream.stopVideo();
        if (isSAB) { 
         mediaStream.stopRenderVideo
         (document.querySelector('#self-view-canvas'), 
         client.getCurrentUserInfo().userId)
         }
     setVideoStarted(false);
      }

  }, [mediaStream, videoStarted, client, isSAB])

Audio Functionality

Starting our audio is a bit simpler than working with our video. In this app, I wrote functionality to start audio, mute, and unmute audio, which was all controlled by one button.

The methods for starting, muting, and unmuting audio require no parameters, making it fairly simple functionality to write out. I used the 'unmuteAudio' method to unmute, the 'muteAudio' to mute, and the 'startAudio' method to start audio and prompt the browser to ask for microphone permission. A code snippet is shown below.

client/src/feature/video.js

 const startAudioButton = useCallback(async () => {
   if (audioStarted) {
     if(isMuted) {
       await mediaStream.unmuteAudio();
       setIsMuted(false)
       } else {
           await mediaStream.muteAudio();
           setIsMuted(true);
         }
      } else {
          await mediaStream.startAudio();
          setAudioStarted(true);
        }
  }, [mediaStream, audioStarted, isMuted])

Also wrapped in a useCallback hook, my audio functionality will only fire when there’s a change to my audio state, muted state, or mediaStream variable, as shown above.

(Note: While not shown here, stopping audio is done with the 'stopAudio' method. You can incorporate this into the same button used for muting/unmuting/starting audio using a menu option, or separate the stop/start audio and mute/unmute audio buttons. For a more in-depth example, please refer to the published (Video SDK web sample application)[(https://github.com/zoom/videosdk-web-sample)], as previously mentioned).

Screen Share Functionality

The last feature I added was screen-sharing. The first piece of logic I wrote was to stop screen-sharing after checking my ‘isShareScreen’ state. I did this with the 'stopShareScreen' method, called on my mediaStream variable.

client/src/feature/video.js

const shareScreen = useCallback(async () => {
  if (isShareScreen) {
    await mediaStream.stopShareScreen();
    setIsShareScreen(false)
  }

Next, to start screen sharing, I needed to first check and see if my browser supports the WebCodecs API. Similar to working with SharedArrayBuffer for the video functionality, the HTML element I use for displaying the shared screen is determined by whether or not this browser feature is supported. If WebCodecs is supported, we’ll display on a video tag. Else wise, we’ll display on a canvas tag. The code snippet below shows the full functionality.

client/src/feature/video.js

   const shareScreen = useCallback(async () => {
     if (isShareScreen) {
       await mediaStream.stopShareScreen();
       setIsShareScreen(false)
     } else {
         if (isSupportWebCodecs()) {
           await mediaStream.startShareScreen(
          document.querySelector('#share-video'));
         } else {
             await mediaStream.startShareScreen(
             document.querySelector('#share-canvas'));
           }
           setIsShareScreen(true);
         }
   }, [isShareScreen, mediaStream])

You'll see the dependency array for my share-screen functionality includes the shareScreen state, and my mediaStream variable.

Looking at Our UI

Alright, we're almost to the finish line (woo-hoo!). Our last stop is a quick look at our UI. As mentioned at the beginning of this article, I used ant design as my styling library, so you’ll see some tags specific to it throughout the code.

The first thing I did was create both my canvas element and my video element, rendering the appropriate one based on my ternary operator (notice that the dimensions given in my video tag match the dimensions passed through in my .renderVideo() method earlier).

I did the same with another ternary operator for my screen-share element. For this demo, my screen-share is displayed on an HTML element directly next to my self-view video element.

For a more complex display, similar to that of an actual Zoom meeting, take a look at the (published sample app)[(https://github.com/zoom/videosdk-web-sample)].

client/src/feature/video.js

   return (
     <div>
       { isSAB ?
         <canvas id="self-view-canvas" width="1920" 
         height="1080"></canvas> 
         :
         <video id="self-view-video" width="1920" 
         height="1080"></video>
       }
       {!isSupportWebCodecs() ? 
         <canvas id="share-canvas" width="1920" height="1080"> 
         </canvas> 
         :
         <video id="share-video" width="1920" height="1080"> 
         </video>
       }

The rest of the logic here is where I created my buttons. I utilized ternary operators to ensure my buttons showed the appropriate text, based on the state of the feature (i.e.; 'unmute' if audio is muted). Remember, this app was built with ant design as its UI library, so certain styling elements are specific to that.

   <div className="video-footer">
     <Tooltip title={`${videoStarted ? 'Stop Camera' : 'Start 
     Camera'}`}>
       <Button 
         className='camera-button' icon={videoStarted ? 
         <VideoCameraOutlined /> : <VideoCameraAddOutlined />} 
         shape='circle'
         size='large'
         onClick={startVideoButton}
        />
      </Tooltip>

      <Tooltip title={`${!isShareScreen ? 'Share Screen':'Stop 
      Sharing Screen'}`}>
        <Button
          className='camera-button'
          icon={isShareScreen ? <FullscreenOutlined /> : 
          <FullscreenExitOutlined />}
          shape='circle'
          size='large'
          onClick={shareScreen}
        />
       </Tooltip>
       <Tooltip title={`${audioStarted ? isMuted ? 'unmute' : 
       'mute' : 'Start Audio'}`}>
         <Button
           className='camera-button'
           icon={audioStarted ? isMuted ? <AudioMutedOutlined 
           /> : <AudioOutlined/> : <IconFont type ="icon- 
           headset" />}
           shape="circle"
           size="large"
           onClick={startAudioButton}
          />
         </Tooltip>
       </div>
    </div>

Summary

That’s it! All the functionality was achieved through some simple browser-feature checks, state management, UI manipulation, and using the built-in methods from the Video SDK package. Using a convenient styling library and/or some basic CSS, you can easily render the different pieces (buttons, canvases, etc.). While I created a simple video-chat application, the possibilities of what you can do are exponential (check out how one of our engineers used it to create a claw machine)!

Thanks for building with me! For a video walk-through of this build, check it out on our youtube!