-
Notifications
You must be signed in to change notification settings - Fork 3
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
Ability to join an arbitrary room and use it as a target for higlights #11 #28
base: master
Are you sure you want to change the base?
Conversation
…eration speed. It also can provide better facilities for manifest manegement, but not using that now
"fixes" #27 too |
Thanks for your work! I don't have time to review the whole thing today, but I am somewhat concerned about the added uses of Otherwise, about the WebExtension plugin: we're still at manifest V2 with this change, and thus barred from the chrome web store? |
the non-null assertions are indeed because of the SDK upgrade and presumably them improving their types. I agree that ideally we should properly deal with that, but the current change doesn't change things functionally - just highlights that there is a problem we need to deal with 🤷♂️ Also, it'd be great to update to the latest major sdk version at some point!
Yes, though it should make it easier to write a manifest that would be cross-compatible between v2 and v3 (it allows specifying browser-specific fields) |
7ef4b86
to
05bb8de
Compare
05bb8de
to
cbec6be
Compare
Hi, checking in on this! :) |
Hey @Stvad, sorry about the delay. I really appreciate the work you're putting in. I work a full-time software job nowadays, and in all honesty I'm a little too tired most of the time to do much else software related. Now, my thinking re: the Thanks again for your help. |
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.
Thank you! I do have a few suggestions / design questions.
const createEvent = state.getStateEvents("m.room.create", ""); | ||
const configEvent = state.getStateEvents(HIGHLIGHT_STATE_EVENT_TYPE, "") | ||
|
||
return configEvent?.getContent()?.url || createEvent.getContent()[HIGHLIGHT_PAGE_KEY]; |
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.
const createEvent = state.getStateEvents("m.room.create", ""); | |
const configEvent = state.getStateEvents(HIGHLIGHT_STATE_EVENT_TYPE, "") | |
return configEvent?.getContent()?.url || createEvent.getContent()[HIGHLIGHT_PAGE_KEY]; | |
const createEvent = state.getStateEvents("m.room.create", ""); | |
const createData = createEvent.getContent()[HIGHLIGHT_PAGE_KEY]; | |
const configEvent = state.getStateEvents(HIGHLIGHT_STATE_EVENT_TYPE, "") | |
return configEvent?.getContent()?.url || createData; |
Though this makes me wonder: we get url
out of the config event, but just return the createData
from the creation event's content. Is the latter a string? Can the former be made a string (rather than an object?) too?
Reading the JS SDK, looks like an object is required. Oh well!
(event.type === 'room-configured' || | ||
(event.type === 'room-membership' && event.membership === 'join')) | ||
&& state.tab === 'join') { | ||
newState.tab = null |
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.
Joining a room from other tabs would close the join menu in this tab?
@@ -181,10 +196,17 @@ export class Client { | |||
this._emitEvent(event, false); | |||
}); | |||
this._sdkClient.on("Room.timeline", (event: sdk.MatrixEvent, room: sdk.Room, toStartOfTimeline: boolean, removed: boolean, data: {liveEvent: boolean}) => { | |||
if (event.getType() === HIGHLIGHT_STATE_EVENT_TYPE) { | |||
this._emitRoom(room); |
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.
What if we're already in a room (we joined it) and someone else joins and tries to set the state event? Won't this double-count the events then?
@@ -265,4 +289,14 @@ export class Client { | |||
this._loadRoom(message.roomId); | |||
} | |||
} | |||
private async joinAndConfigureRoom(roomId: string, url: string) { |
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.
I'm not sure I like this approach (sorry 😞 ). Barging into a room and trying to set state events just seems... impolite? The use case for explicitly joining a room (rather than being invited, which is a case already handled, I hope) is some sort of public room that stores highlights. But that room would already be configured, then.
I suggest we split the two actions somehow:
- Joining a room (this) -- you join an existing room and just assume it has a state event already set (or a create event). Then, the existing
Room
handler of the matrix client should take care of emitting the room, and all is well. - "Promoting" a room (new) -- take an existing room, that you're in and have permission to modify via state events -- and send the new state event to it, making it a room for your current URL.
Co-authored-by: Daniel <[email protected]>
There are two TODO sections in the code that need additional discussion.
I'm also not entirely sure I handled the UI/state transitions as intended and would appreciate double-checking on that!