Skip to content

chore(react): deprecate legacy useTrackTranscriptions#1200

Merged
lukasIO merged 5 commits intomainfrom
lukas/deprecate-old-transcription
Aug 14, 2025
Merged

chore(react): deprecate legacy useTrackTranscriptions#1200
lukasIO merged 5 commits intomainfrom
lukas/deprecate-old-transcription

Conversation

@lukasIO
Copy link
Copy Markdown
Contributor

@lukasIO lukasIO commented Aug 13, 2025

No description provided.

@changeset-bot
Copy link
Copy Markdown

changeset-bot bot commented Aug 13, 2025

🦋 Changeset detected

Latest commit: 687419e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages
Name Type
@livekit/components-core Patch
@livekit/components-react Patch
@livekit/component-example-next Patch
@livekit/components-js-docs Patch
@livekit/component-docs-storybook Patch
@livekit/components-docs-gen Patch

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

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Aug 13, 2025

size-limit report 📦

Path Size
LiveKitRoom only 6 KB (0%)
LiveKitRoom with VideoConference 30.59 KB (0%)
All exports 38.14 KB (0%)

@lukasIO lukasIO requested a review from 1egoman August 13, 2025 12:26
Comment on lines 6 to 9
* @internal
* @deprecated Use useTrackSyncTime instead
*/
export function useTrackSyncTime(ref: TrackReferenceOrPlaceholder | undefined) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this saying that a function is deprecated, but that a user should use the same deprecated function instead? Maybe there's a different useTrackSyncTime somewhere this is referring to, but as is it's kinda confusing.

Something that could maybe help that confusion - there's a @link tsdoc directive (more info) that could maybe be used to link to the correct implementation. If this seems like a good plan, I can make a ticket to do a pass and apply this everywhere?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uff, thanks for catching, that doesn't make any sense. It was used internally only anyways, the deprecated marker serves primarily as a reminder for us to remove it entirely for the next iteration

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, using the link directive would be great!

@lukasIO lukasIO merged commit 1406465 into main Aug 14, 2025
6 checks passed
@lukasIO lukasIO deleted the lukas/deprecate-old-transcription branch August 14, 2025 13:58
@github-actions github-actions bot mentioned this pull request Jul 24, 2025
@MirShayan
Copy link
Copy Markdown

TypeScript error in useTrackSyncTime: type mismatch between trackSyncTimeObserver and useObservableState

Bug Description

TypeScript compilation error in useTrackSyncTime.ts hook.

Error Message

TS2345: Argument of type 'number' is not assignable to parameter of type 
'{ timestamp: number; rtpTimestamp?: number | undefined; }'.

Location

node_modules/@livekit/components-react/src/hooks/useTrackSyncTime.ts, line with useObservableState(observable, ...)

Environment

  • @livekit/components-react: 2.9.16
  • @livekit/components-core: 0.12.11
  • livekit-client: 2.16.0
  • TypeScript: 5.9.3
  • Node: 20.16.0

Expected Behavior

Code should compile without TypeScript errors.

Actual Behavior

TypeScript reports type mismatch between trackSyncTimeObserver return type and useObservableState expected parameter type.

Possible Fix

The observable returned by trackSyncTimeObserver appears to emit number instead of { timestamp: number; rtpTimestamp?: number }. Either:

  1. Update trackSyncTimeObserver to emit the correct object shape, or
  2. Map the observable before passing to useObservableState

Workaround

Using skipLibCheck: true in tsconfig.json, but this is not ideal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants