0.14.0

Improvements

• Improved type inference for useThrottledDailyEvent callback event objects
• Improved state management for useParticipantProperty: instead of looking up participant state properties from entire participant objects, we'll now store participant properties in separate state atoms, as recommended by Recoil. This means that participant state properties returned from useParticipantProperty don't subscribe to the entire participant object anymore, which leads to more targeted and fewer render cycles.

Bugfixes

• Fixed an issue in useNetwork where returned network state information could be stale
• Fixed an issue where participant audio tracks might not have been assigned to an <audio> tag in DailyAudio
• Fixed checks in usePermissions to avoid potential property lookups on undefined

0.13.0

Features

• New hook useDailyError: this hook returns a stateful representation of the last meetingError (emitted per error event) and nonFatalError (emitted per nonfatal-error event)

Improvements

• Improved type inference for useDailyEvent event objects: when passing a memoized callback you don't have to specify the event object types yourself anymore! (Thanks @HegarGarcia)
• New callback onError for useScreenShare: maps to nonfatal-error of type 'screen-share-error'
• New callback onError for useMeetingSessionState: maps to nonfatal-error of type 'meeting-session-data-error'
• New callback onLiveStreamingWarning for useLiveStreaming: maps to nonfatal-error of type 'live-streaming-warning'
• Improved type inference for onError callback for useInputSettings
• Improved state management for useScreenShare: before this release every instance of useScreenShare maintained its own version of state representing screen shares. This state management has now moved into an internal wrapper component, so screen share state is only managed once. Every instance of useScreenShare now returns the same state.
• Improved state management for useParticipantIds: recent refactors of this hook unveiled some complexities originating from different variations for the filter and sort options. We've updated useParticipantIds to always return optimized states from Recoil when using a string-based filter and/or sort option. This also means that instances of useParticipantIds with optimized filter/sort options will return the correct list of ids on first render. A custom function filter and/or sort will fall back to a manual state and remain the same behavior as introduced in 0.11.0.
• Improved state management for useParticipantProperty: we restructured our internal recoil selectors for participant properties to better handle arrays of properties.

0.12.0

Features

• DailyAudio now has an option autoSubscribeActiveSpeaker to automatically subscribe to the active speaker (only relevant when using manual track subscriptions)

Improvements

• Updated callback type definitions to infer arguments from the daily-js types. This affects
  • useActiveParticipant
  • useCPULoad
  • useInputSettings
  • useLiveStreaming
  • useNetwork
  • useParticipant
  • useParticipantCounts
  • useParticipantIds
  • useReceiveSettings
  • useRecording
  • useSendSettings
  • useTranscription
  • useWaitingParticipants
• useDevices can now skip the pending state, in case the browser's Permissions API reports granted access for camera and/or microphone.

Bugfixes

• Fixed an issue where some hooks were potentially returning stale state information after switching to a different Daily room.
• Fixed an issue where useThrottledDailyEvent potentially handled events for a session that was already left or destroyed.

0.11.6

Bugfixes

• Fixed an issue where useRecording would return stale state when leaving and joining a new meeting
• Fixed TypeScript definition for useAudioLevel hook (thanks @joakimgrr!)

Maintenance

• Simplified object comparison checks in our customDeepEqual method

0.11.5

Bugfixes

• Fixed an issue where comparing Maps and Sets internally inside the usePermissions would lead to an infinite recursive loop.

0.11.4

Bugfixes

• useParticipantProperty: fixed an issue where useParticipantProperty returned undefined on first render, despite the correct value being available in store already.

0.11.3

Bugfixes

• useScreenShare: Fixes an issue where optimized render cycles in useParticipantIds (see 0.11.0) could lead to stale screens returned from useScreenShare

0.11.2

Bugfixes

• useParticipantProperty: fixed an issue introduced in 0.11.1 where changes to tracks and permissions were not picked up correctly by useParticipantProperty.

0.11.1

Improvements

• useParticipantProperty: improved the hook's render performance by only re-rendering when the returned value(s) actually changed.

0.11.0

Features

• New handling of canAdmin permissions in usePermissions: the hook now returns canAdminParticipants, canAdminStreaming and canAdminTranscription in addition to the other permission fields. Read more about canAdmin in our docs.
• New hook useCPULoad: this hook keeps track of the CPU load state and reason (see getCpuLoadStats()) via 'cpu-load-change' events.
• New hook useRoomExp: this hook determines the meeting ejection date for the local participant, based on eject_after_elapsed, eject_at_room_exp and exp room/token configuration.

Improvements

• Improved rendering performance of useParticipantIds and useParticipantProperty: previously both hooks subscribed to all participant objects stored in the recoil state. This led to a lot of unexpected render cycles, e.g. useParticipantIds({ filter: 'remote' }) would re-render when the local participant toggled their cam or mic. We've restructured the way we store and subscribe to changes in participant objects to achieve only targeted re-renders. Every instance of useParticipantIds now sets up its own local state of returned ids, and only updates the state when the resulting array of ids doesn't match the previously stored one. To keep the connection to the recoil state store, we're now using the useRecoilTransactionObserver_UNSTABLE hook which worked flawlessly in our internal tests. Please be aware that with this change we've introduced at least 1 additional render cycle per useParticipantIds to initialize the state.