More Flexible SDK Components

[shanepadgett]

Currently we are using this library for the hooks and providers -- they have been an immense help to interface with the SDK. We have reviewed the SDK components provided by this library and, while they provide all of the functionality we require, we cannot use them due to the UI styling. We have our own internal design system and there is no simple way to just inject classes into your UI components to make them fit into our design language. So currently we are replicating all of the functionality provided by your SDK components and using our own UI components. We are also required to install styled-components as a peer dependency to use this library, which is something we would prefer to not do if possible.

Anything you can do to make this library more flexible in how it handles UI components would be greatly appreciated.

Some of the SDK components we currently copy the logic from: MicSelection, CameraSelection, LocalVideo, RemoteVideo, VideoPreview

[nicklera1]

Thank you @shanepadgett for a great feedback, we will definitely look into designing our components to be more flexible.

[p-foucht]

Hey @shanepadgett -- we're thinking about ways to address this, and have two main options. Let me know if you have any feedback, or alternative suggestions

1. More/better hooks - Building out more hooks so that developers can more easily build out their own UI

Example - a useLocalVideoElement hook that handles the binding and active state of the local video. You render whatever you want, and the hooks will try to handle as much of the SDK integration as they can

This would allow you to remove the StyledComponents dependency, but there will be more work/effort in handling all the hooks yourself as opposed to just dropping in a <LocalVideo /> component

2. Component injection - Allow a component to be passed through props that the SDK components will use for rendering

Example - <LocalVideo component={CustomVideoEl} />

The LocalVideo will render the video element as CustomVideoEl, and it will need to make sure to use the props pass correctly (such as setting the ref)

This would not get rid of the StyledComponents dependency though, since the default component would still be the styled component. Developers would need to make sure they're handling the passed props to their custom component properly

Other alternatives

• Component injection with no fallback. Same as #2, but provide no fallback so you could get rid of StyledComponents as a dependency. I am not a fan of this, as it would be a breaking change, and would require additional work for developers that do just want to drop in the existing components

Example - <LocalVIdeo component={VideoTile} /> and <LocalVideo component={CustomVideo} />

• We also thought about completely style-less SDK components, but there'll probably be some issues around markup flexibility

[wootsbot]

@p-foucht I really value the ease that reach-ui provides to override the style.

It could generate a discussion on the subject could be more ideas.

[p-foucht]

Closing due to inactivity

[vidya-mohan]

Reactivating as this is still an issue

[prashanthacharyam]

@p-foucht i would prefer approach 1. Library to provide hooks and using that to manage the UI. We also have the same issue where we are replicating the components to use with our own UI.

[CodySchaaf]

I would consider how MUI https://github.com/mui/material-ui accomplishes this. All of their components are 100% customizable. This is usually accomplished by top level theming, passing in override components, or targeting exposed selectors.