Our host decorators that include optimized caching for getClientInfo() is currently hidden inside of LiveShareClient. If a developer wants to lookup client info from an incoming signal, they currently have to use LivePresence, or misuse the teams-js LiveShareHost which does not include optimized caching. This makes it hard for developers to correlate actions with client information, such as the name of the user who emitted the signal.
Describe the solution you'd like
We should provide a more accessible, officially supported API to make this information more accessible to developers. Some ideas for where this could be exposed:
LiveDataObject could expose an API for getClientInfo() so it is easy to access from their DDS event listeners
We could decorate the IFluidContainer class returned to developers through joinContainer() with an API to getClientInfo()
We could return the decorated host (though that seems awkward, since host is a prop when initializing LiveShareClient).
We could take some direction from the LiveShareTurboClient, which makes IFluidContainer an internally used construct.
This design should be carefully considered, since right now we don't have a "hub" for session-level APIs. LiveShareRuntime is the closest thing we have, though that isn't publicly exposed.
Describe your user scenario
Our host decorators that include optimized caching for
getClientInfo()is currently hidden inside ofLiveShareClient. If a developer wants to lookup client info from an incoming signal, they currently have to useLivePresence, or misuse the teams-jsLiveShareHostwhich does not include optimized caching. This makes it hard for developers to correlate actions with client information, such as the name of the user who emitted the signal.Describe the solution you'd like
We should provide a more accessible, officially supported API to make this information more accessible to developers. Some ideas for where this could be exposed:
LiveDataObjectcould expose an API forgetClientInfo()so it is easy to access from their DDS event listenersIFluidContainerclass returned to developers throughjoinContainer()with an API togetClientInfo()LiveShareClient).LiveShareTurboClient, which makesIFluidContaineran internally used construct.This design should be carefully considered, since right now we don't have a "hub" for session-level APIs.
LiveShareRuntimeis the closest thing we have, though that isn't publicly exposed.