[MMB-178] Add members namespace #101
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lmars
reviewed
Aug 3, 2023
Merged
dpiatek
force-pushed
the
mmb-178-add-members-namespace
branch
3 times, most recently
from
2ae176d
to
c89efe6
Compare
dpiatek
force-pushed
the
mmb-178-add-members-namespace
branch
2 times, most recently
from
f0c71fa
to
9d0e6e1
Compare
artismarti
reviewed
Aug 7, 2023
added 4 commits
August 8, 2023 09:05
These are split into an external and internal ones, the latter being ones that we might want to change without introducing breaking changes.
Update as newer types were incompatible.
These tests add significant complexity to setup, and don't bring enough value on contrast to the mock tests.
dpiatek
force-pushed
the
mmb-178-add-members-namespace
branch
from
490ecc4
to
d4d0013
Compare
added 2 commits
August 8, 2023 09:15
This commit changes how we handle updates for presence spaces. An presence update becomes a PresenceMember:
export type PresenceMember = {
data: {
profileUpdate: {
id: string | null;
current: ProfileData;
};
locationUpdate: {
id: string | null;
previous: unknown;
current: unknown;
};
};
} & Omit<Types.PresenceMessage, 'data'>;
Which then gets translated for the developer to a SpaceMember:
export type SpaceMember = {
clientId: string;
connectionId: string;
isConnected: boolean;
profileData: ProfileData;
location: unknown;
lastEvent: {
name: Types.PresenceAction;
timestamp: number;
};
};
data on PresenceMember contains the last update for profileData an location. The current key is the value of these properties on SpaceMember.
profileUpdate and locationUpdate contain an id. This id is set on publish, but only when we are providing new data, not copying already set data.
The handlers check the id to decide if an update should be emitted (it will still be applied, and it should be the same).
dpiatek
force-pushed
the
mmb-178-add-members-namespace
branch
from
d4d0013
to
33c5990
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add a new
membersnamespace, as per MMDR14.To make this possible, a new for managing presence state was introduced. Internally, all messages now need to replay a members state, and "touch" updates which are new. On the subscriber side, all updates are applied, but only the "touched" updates get emitted as events.
This is first stage of a move towards not using a "shadow" presence set and having consistent, internal "update presence" API for spaces (it's fairly manual right now).
A couple of clean up tasks have been done as well:
mockClienttests to justtest.tsThis PR does not contain a docs update and will be part of a bigger release.