Please do not add additional comments such as "+1" or "me too" to existing issues - instead please vote on the issue by adding a 👍 to the issue. The Amazon Chime SDK team will prioritize the request based on the number of 👍 the issue has received.
Please go through the existing issues to see if your request has already been recommended.
Please do not use this template to report bugs. This repository has an issue template for issues and documentation to help with your development.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.
Tell us about your request
What do you want us to build?
Specifically in the Chime React Component Library. We'd find it really helpful to have access to the Contexts used to link the various Providers to their Hooks.
Tell us about the problem you are trying to solve and why is it hard?
For a lot (all?) of the Provider components, they provide a Context that's used to attach the state for the relevant Hooks for use further down the component tree. This leaves a couple of issues:
Testing becomes more difficult because you can't mock out the Hooks that are provided. This leaves us either needing to use another pattern (eg: the Container pattern) on top of the existing hooks/contexts (feels like a big anti-pattern), or drop in another layer of abstraction to deal with mocking the hooks (eg: providing a set of hooks that wrap the Chime hooks that can be switched over to being mocked)
This means you need to be very careful around when/where you use these hooks if you're in an environment where you might not have a MeetingManager (eg: one where you only hook up Chime for a part of the workflow, but still reuse a lot of the UI, or where you have an AV-enabled and AV-disabled experience, or particularly when you're migrating from another WebRTC service provider...)
We use Storybook for visual diffs/component-level UI testing. For that, we use small chunks of the component tree, to provide deterministic+reproducible views. However - if our components depend on
How are you currently solving a problem?
We currently spend extra time refactoring our components out to split out the hooks to detach them from our code (think Container pattern). This is technically viable, but slows development and iteration down. Happy to hear other alternatives
Additional context
Happy enough to put a PR together for this, just want to know if it's a desired change or not before I sink time into it.
Community Note
Tell us about your request
What do you want us to build?
Specifically in the Chime React Component Library. We'd find it really helpful to have access to the Contexts used to link the various Providers to their Hooks.
Tell us about the problem you are trying to solve and why is it hard?
For a lot (all?) of the Provider components, they provide a Context that's used to attach the state for the relevant Hooks for use further down the component tree. This leaves a couple of issues:
We use Storybook for visual diffs/component-level UI testing. For that, we use small chunks of the component tree, to provide deterministic+reproducible views. However - if our components depend on
How are you currently solving a problem?
We currently spend extra time refactoring our components out to split out the hooks to detach them from our code (think Container pattern). This is technically viable, but slows development and iteration down. Happy to hear other alternatives
Additional context
Happy enough to put a PR together for this, just want to know if it's a desired change or not before I sink time into it.