-
Notifications
You must be signed in to change notification settings - Fork 130
Agent SDK - ported on top of components-js primitives #1207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🦋 Changeset detectedLatest commit: d2d070d The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
ce80b15 to
ef0fed7
Compare
packages/core/src/messages/types.ts
Outdated
| type ReceivedMessageWithType< | ||
| Type extends string, | ||
| Metadata extends {} = {}, | ||
| > = { | ||
| id: string; | ||
| timestamp: number; | ||
|
|
||
| type: Type; | ||
|
|
||
| from?: Participant; | ||
| attributes?: Record<string, string>; | ||
| } & Metadata; | ||
|
|
||
| /** @public */ | ||
| export type ReceivedChatMessage = ReceivedMessageWithType<'chatMessage', ChatMessage & { | ||
| from?: Participant; | ||
| attributes?: Record<string, string>; | ||
| }>; | ||
|
|
||
| export type ReceivedUserTranscriptionMessage = ReceivedMessageWithType<'userTranscript', { | ||
| message: string; | ||
| }>; | ||
|
|
||
| export type ReceivedAgentTranscriptionMessage = ReceivedMessageWithType<'agentTranscript', { | ||
| message: string; | ||
| }>; | ||
|
|
||
| /** @public */ | ||
| export type ReceivedMessage = | ||
| | ReceivedUserTranscriptionMessage | ||
| | ReceivedAgentTranscriptionMessage | ||
| | ReceivedChatMessage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ported the existing ReceivedMessage abstraction from here on top of the pre-existing ReceivedChatMessage - this means that now,ReceivedChatMessage is now a ReceivedMessage subtype.
Note ReceivedChatMessage has one new type field addition which acts as the discriminant key in ReceivedMessage, but otherwise is identical. So this should be a fully backwards compatible change even though behind the scenes a lot has been updated.
how about proxying some of these on the return value of |
I opted to leave that out for now because of the hesitancy from ben/dz around new track abstractions. That being said, I mentioned in the comment above that I had been proposing a new hook, It sounds like you are pushing for that to exist now vs deferring it? If so I can add that new hook to this branch or possibly figure out how to fit it into |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, i like the direction where this is going.
This allows functions to limit whether they just want to take in TrackReferences from a given source - ie, the VideoTrack could be made to only accept TrackReference<Track.Source.Camera | Track.Source.Screenshare | Track.Source.Unknown>.
Note that just the return values are changing, not the argument definitions in other spots, so this shouldn't be a backwards compatibility issue.
…viously didn't accept it
The pre-existing state was broken.
…in useParticipantTracks
…s going to be important for future multi-agent type use cases
Longer term I think it might be worth discussing migrating away from that pattern since react won't be tree-shaken properly in end projects
This was causing prepareConnection to get run constantly since its reference depends on restOptions which changes every call. The way I see it, if a user is changing their options and wants prepareconnection to be run for something beyond the initial set (probably unusual), they can call it themselves on the returned session object.
This seems to work because of backwards compatibility in build tools, but if an index.js exists in addition to index.ts, this pulls in the wrong file.
This change comprises the new client agents sdk, a set of react hooks that are being built to make interaction with the livekit agents framework less complex.
This is version 3 - version 1 can be found here, and version 2 can be found here. Each step it has evolved significantly based on comments and perspectives from people who have taken a look!
Single file example
New API surface area
useSession(tokenSource: TokenSourceFixed | TokenSourceConfigurable, options: UseSessionConfigurableOptions | UseSessionFixedOptions): UseSessionReturnA thin wrapper around a
Roomwhich handles connecting to a room and dispatching a given agent into that room (or in the future, maybe multiple agents?). In the future it will probably become thicker as more global agent state is required.useAgent(session: UseSessionReturn): AgentA much more advanced version of the previously existing
useVoiceAssistanthook - tracks the agent's state within the conversation, manages agent connection timeouts / other failures, and largely maintains backwards compatibility with existing interfaces.useSessionMessagesA mechanism for interacting with
ReceivedMessages across the whole conversation. AReceivedMessagecan be aReceivedChatMessage(already exists today), or aReceivedUserTranscriptionMessage/ReceivedAgentTranscriptionMessage(both brand new). This is exposed at the conversation level so in a future world where multiple agents are within a conversation, this hook will return messages from all of themAdditional refactoring / cleanup
ParticipantAgentAttributesconstant and ported all usages oflk.-prefixed attributes (which previously were just magic strings in the code) to refer to this enum.handleMediaDeviceErrorcallback function inuseLiveKitRoomroomparameter to a few hooks and components that didn't support it previously, to make single file example type scenarios easier:RoomAudioRendererStartAudiouseChatuseTextStreamuseTrackToggleuseTranscriptions