Add usePersistentUserChoices hook to save device settings and username to local storage

[Ocupe]

This pull request adds a new hook, usePersistentUserChoices, which provides functionality to save and load user choices. This will allow users to persist their device settings and username across sessions.

The user choices object stored in local storage looks like this:

export type UserChoices = {
  videoInputEnabled: boolean;
  audioInputEnabled: boolean;
  videoInputDeviceId: string;
  audioInputDeviceId: string;
  username: string;
};

Settings in local storage are updated by changes in the ControlBar and the PreJoin component. The general goal is to always use the media devices that were last used.
I have added functionality to prevent the usePersistentUserChoices from writing to local storage, but by default we write to local storage.

[changeset-bot]

🦋 Changeset detected

Latest commit: 9bb9fb1

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

This PR includes changesets to release 5 packages

Name	Type
@livekit/components-core	Minor
@livekit/components-react	Minor
@livekit/component-example-next	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]

size-limit report 📦

Path	Size
LiveKitRoom only	1.87 KB (0%)
LiveKitRoom with VideoConference	31.15 KB (+1.84% 🔺)
All exports	36.49 KB (+1.91% 🔺)

[lukasIO]

I like the idea, I'm wondering if the stuff that is in core right now, might actually make sense in livekit-client directly? That way not only react users would profit.

[lukasIO]

could we instead of the boolean parameter simply not call the function if the user doesn't intend to save?

[Ocupe]

I wanted the default defaultUserChoices (if no defaults are passed by the user) to be defined and handled within the core. This API evolved from that decision. We could move the same logic one layer up into components-react, but that would increase the API surface a bit, and (if we support more frameworks in the future) we would have to reimplement it.

[lukasIO]

got it, that makes sense to me!

[lukasIO]

same question as above

[lukasIO]

wondering if save and load would make more sense than negating the option with prevent*

[Ocupe]

I have the feeling that preventSave=true tells you a bit more than just save=true.

[Ocupe]

What about skipSave: boolean?

[lukasIO]

Really just wanted to hear your opinion on it, I think your argument is fair. Let's stick with prevent* then!