Websockets Implementation for the Connecting screen

README.md

@@ -48,6 +48,8 @@ const App = () => {
 | `profiles`                     | [`ProfilesTypes`](./typings/connectProps.d.ts)             | The connect widget uses the profiles to set the initial state of the widget. [More details](./docs/PROFILES.md)                                                                  | See more details                              |
 | `userFeatures`                 | [`UserFeaturesType`](./typings/connectProps.d.ts)          | The connect widget uses user features to determine the behavior of the widget. [More details](./docs/USER_FEATURES.md)                                                           | See more details                              |
 | `showTooSmallDialog`           | `boolean`                                                  | The connect widget can show a warning when the widget size is below the supported 320px.                                                                                         | `true`                                        |
+| `webSocketConnection`          | `object`                                                   | An object containing `isConnected()` function and `webSocketMessages$` observable for real-time updates.                                                                         | `null`                                        |
+| `experimentalFeatures`         | `object`                                                   | An object to enable or disable experimental features like `useWebSockets: true`.                                                                                                 | `null`                                        |
 
 ## ApiProvider
 

architectureDecisionRecords/0003AutomatedTestingFrontend.md

@@ -18,7 +18,7 @@ We will use the following technologies to test:
 1. [Vitest](https://vitest.dev/) for unit/integration tests
 1. [MSW](https://mswjs.io/docs/getting-started/) for api mocking in unit/integration tests
 
-We will mock as little as possible in our tests and [prefer integration tests over unit tests](https://kentcdodds.com/blog/write-tests). The bulk of our tests will be integration tests, because they provide the best performance to confidence ratio.
+We will mock as little as possible in our tests and [prefer integration tests over unit tests](https://kentcdodds.com/blog/write-tests). The bulk of our tests will be integration tests, because they provide the best performance to confidence ratio. We also prefer to render real components rather than using mocks (e.g., `vi.mock`) in integration tests to ensure that context and side-effects are correctly wired.
 
 The purpose of our end to end tests will be to validate that the frontend is working with the backend properly, and that apis are working together properly. We don't need to test every edge case in our end to end tests, because using MSW allows us to test those edge cases in our integration tests.