To preface this, I think the component view is an awesome idea. It provides a great middle-ground between a full-page client and a low-level SDK, like the Video SDK, where you must build everything yourself.
Choosing it was initially a no-brainer for our use-case, however trying to use it in a production-grade app for the past few months (we are an ed-tech startup, running cohorts of 20-25 kids at a time, where they do game-based learning), we keep running into issues and limitations, which are making me question how mature this SDK really is and if we are making the right choice sticking with it or if we should already be exploring alternatives.
These are some of the main issues we have encountered. Some of these have been posted by me or other posters in these forums in the past:
-
The component view SDK does not remember the user’s selected devices and keeps reverting to the default every time Zoom connects or when joining/leaving a breakout room. This is a major hindrance, especially for non-tech-savvy users who are the target group of our meetings, as they keep losing audio every time we open or close the breakout rooms, and we have to halt the flow of the meeting to help them reconfigure it. We also tried to solve it ourselves enumerating the devices and trying to remember the preference ourselves, but there is no way to pass it to Zoom as there is no API to select a device programmatically either during Zoom’s initialization or during the call.
-
Some features outright don’t work correctly or have major bugs that make them unusable. These are two that I have personally experienced:
-
a. Co-hosts cannot see breakout room controls and they cannot move to a breakout room on their own. This restriction does not exist in the client-view (or any of the other Zoom clients I have used) and is forcing us to propose terrible solutions like having the co-hosts open a separate Zoom desktop client in order to be able to move themselves. I created a thread about it back in May (Co-host cannot see breakout rooms control), but it received no response and this bug is still there.
-
b. maximumVideosInGalleryView does not work for anyone who goes through the waiting room. A poster also made a thread about this here maximumVideosInGalleryView not working when join as guest/role=0 - #2 by dnna. That basically makes the feature unusable, as the only ones who are affected by it are the hosts and everyone else just reverts to the default 9.
-
-
New API releases lack important features in the component view that exist in the client view. For example, in the component view there is no createBreakoutRooms API, which means if someone wants to use these APIs, they have to first create the breakout rooms manually through the UI, which nullifies the biggest use case of this API. I posted this thread Opening new breakout rooms without roomId programmatically in 2.14 about it in case I missed something, but having triple-checked the docs now, I think the feature just isn’t there and there isn’t really a way to do it.
So the question is, is the component view considered a first-class SDK by the team, and is it expected that some or all of these issues have a chance to be fixed in 1-2-3 months, or is this SDK meant for lighter/less serious use-cases and all the focus is being put either into the full-page client-view and the low-level Video SDK solutions?