-
-
Notifications
You must be signed in to change notification settings - Fork 598
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thread store and event parsing to create threads #1828
Conversation
e9f3d13
to
1811390
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally it looks sane, though a couple things: is this meant to be unstable functionality? If so, annotating the functions aggressively with unstable warnings would be appreciated (to allow for breaking changes during development / discouraging use until it's ready).
More documentation on the public fields/functions would be appreciated as well, to help with understanding and those who use this thing outside of us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
otherwise lgtm
@@ -146,7 +146,7 @@ export class Room extends EventEmitter { | |||
public oldState: RoomState; | |||
public currentState: RoomState; | |||
|
|||
private threads = new Set<Thread>(); | |||
public threads = new Set<Thread>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a little dangerous exposing this publicly, but not the end of the world. Can it get some jsdoc to guide the developer on using it safely? (ie: is it safe to mutate, or should it be treated as readonly?)
This is a first implementation for thread in the
js-sdk
. There is currently no UI associated yet but will follow shortlyGiven that the concept of thread will be completely client-side for now, references to the root and tails of the thread are kept, to be able to rebuild the reply chain upon a refresh or so that it can be synchronized between multiple clients