Skip to content
This repository was archived by the owner on Sep 11, 2024. It is now read-only.

Replies #1741

Merged
merged 77 commits into from
May 2, 2018
Merged

Replies #1741

merged 77 commits into from
May 2, 2018

Conversation

…rix-org/matrix-react-sdk into t3chguy/m.relates_to
@t3chguy
Copy link
Member Author

t3chguy commented Feb 10, 2018

Seems like this is being built against the wrong js-sdk version
Riot-web tests (which include the react-sdk tests) pass, as they use the correct branches all the way soooo

Signed-off-by: Michael Telatynski <[email protected]>
Signed-off-by: Michael Telatynski <[email protected]>
@t3chguy
Copy link
Member Author

t3chguy commented Feb 10, 2018

Introduces one issue which I would like to fix before merging, on-hover of the Reply-set, the e2e icons and timestamp shuffle to the left, VERY ANNOYINGLY

FIXED

@t3chguy
Copy link
Member Author

t3chguy commented Feb 10, 2018

image

@tulir
Copy link
Member

tulir commented Feb 11, 2018

When I send an event that has an empty object as m.relates_to, Riot UI starts lagging a lot and the event doesn't appear. The console shows this when I try to switch to a room that has such an event (and switching fails):

image

Signed-off-by: Michael Telatynski <[email protected]>
…rix-org/matrix-react-sdk into t3chguy/m.relates_to
@lukebarnard1
Copy link
Contributor

lukebarnard1 commented Feb 16, 2018

OK, so I've had a play with this, and seems really really cool 🙂 VERY cool to see permalinks that can link to entire discussions by just linking the last event in the thread (ignoring branching potential)

I found a few bugs:

  • The timeline doesn't scroll down entirely to the bottom after sending a reply (sometimes).
  • The timeline doesn't scroll down entirely to the bottom when expanding replies (sometimes - seemingly only when expanding to view not the oldest message).
  • When switching to a room with replies, the timeline doesn't scroll down to the bottom if it was scrolled down to the bottom before switching to it.

Also, I had some design-related thoughts. If there's already been a design decision then fair enough. If @lampholder or @ara4n have thoughts on my thoughts, that'd be useful:

  • You don't get to see a preview of the entire previous thread when replying.
  • Timestamps for entire thread are shown if the thread is attached to the most recent message. Showing all timestamps for a thread on hover is a bit weird, but I suppose that's ok for now.
  • Clicking "in reply to" is a bit unintuitive, especially as it looks like someone has typed that out. I would prefer some sort of "more..." indicator.
  • As much as I love the use of Pills in general, it wasn't inserted by someone into the actual message so I think I'd prefer the non-Pill equivalent. Also whatever it is, clicking on it should show MemberInfo.

@lukebarnard1
Copy link
Contributor

FTR the tests fail because js-sdk develop is being used for the tests as opposed to the one we intend to merge at the same time as this. Ideally we'd merge the js-sdk branch first and then restart the tests here.

@t3chguy
Copy link
Member Author

t3chguy commented Feb 16, 2018

You don't get to see a preview of the entire previous thread when replying.

is a thing I broke but will re-add

@t3chguy
Copy link
Member Author

t3chguy commented Feb 16, 2018

Re

Clicking "in reply to" is a bit unintuitive, especially as it looks like someone has typed that out. I would prefer some sort of "more..." indicator.

and

As much as I love the use of Pills in general, it wasn't inserted by someone into the actual message so I think I'd prefer the non-Pill equivalent. Also whatever it is, clicking on it should show MemberInfo.

Design input welcome

@t3chguy
Copy link
Member Author

t3chguy commented Feb 16, 2018

(ignoring branching potential)

thats the whole boat of replies vs swimlanes (threading)
the latter of which would be really inefficient to resolve without server indexed aid

@t3chguy t3chguy assigned lukebarnard1 and unassigned t3chguy Apr 30, 2018
Copy link
Contributor

@lukebarnard1 lukebarnard1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest running tests locally and making sure they pass.


sendMessagePromise.done((res) => {
this.client.sendMessage(this.props.room.roomId, content).done((res) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running tests locally, I found that this.client might not be an object at this point.

@lukebarnard1 lukebarnard1 assigned t3chguy and unassigned lukebarnard1 May 1, 2018
@t3chguy
Copy link
Member Author

t3chguy commented May 1, 2018

this.client might not be an object at this point.

It will always be an object as the constructor sets it as such, just that sinon overwrites it with a stub that doesn't have sendMessage

@lukebarnard1
Copy link
Contributor

Ah ok, looks like a simple fix of adding sendMessage to the stub then.

@t3chguy
Copy link
Member Author

t3chguy commented May 1, 2018

Ah ok, looks like a simple fix of adding sendMessage to the stub then.

not quite, all the tests have to be refactored due to relying on checking whether the sendHtmlMessage and sendTextMessage get called but this is done now

@t3chguy t3chguy assigned lukebarnard1 and unassigned t3chguy May 1, 2018
@lukebarnard1
Copy link
Contributor

The tests pass! (locally) 🎉

Copy link
Contributor

@lukebarnard1 lukebarnard1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost there!

@@ -916,9 +916,14 @@ module.exports = React.createClass({

ContentMessages.sendContentToRoom(
file, this.state.room.roomId, MatrixClientPeg.get(),
).catch((error) => {
).done(() => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"any unhandled rejection that ends up here will ... be thrown as an error" (see http://bluebirdjs.com/docs/api/done.html)

this should be catch(...).then(...)

}
}

static async getEvent(room, eventId) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really think these statics should be defined after the constructor. That way, you can read down from componentWillMount to initialize instead of scrolling up through the statics.

</div>
</div>;
}
}

function dummyOnWidgetLoad() {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe leave a comment explaining that onWidgetLoad should be made optional in EventTile

@lukebarnard1 lukebarnard1 assigned t3chguy and unassigned lukebarnard1 May 1, 2018
@t3chguy t3chguy assigned lukebarnard1 and unassigned t3chguy May 1, 2018
dis.dispatch({
action: 'message_sent',
});
}).catch((error) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error could have been thrown in the then. Ultimately we want two branches. One that is called if the call was successful, one otherwise.

In a sync world, you'd do:

try {
  thingThatMightFail();
} catch (err) {
  handle(err);
  return;
}
success();

or equally with async await. Perhaps just make the function async.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, have done; but cannot do the same for handleReturn in MCI as it requires the boolean return type for Draft-js

@lukebarnard1
Copy link
Contributor

Also. #1869 has landed so the tests will pass if develop is merged into this branch. (Thanks @dbkr!)

@lukebarnard1 lukebarnard1 assigned t3chguy and unassigned lukebarnard1 May 2, 2018
@t3chguy t3chguy assigned lukebarnard1 and unassigned t3chguy May 2, 2018
@lukebarnard1 lukebarnard1 merged commit 6bf1eb1 into develop May 2, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants