-
Notifications
You must be signed in to change notification settings - Fork 404
Conversation
You get a tab. And you get a tab. Everybody gets a tab!
this is more consistent with how this content is displayed on github.com
Co-Authored-By: Katrina Uychaco <[email protected]>
Co-Authored-By: Katrina Uychaco <[email protected]>
and also add a really long commit body so I can test what that looks like asdkfjksajfklsdajfldsajfklsadjflskjfljdsklajfklsdajfkldsjfkldsajflkdasjfkldsjkldsjflksdajfdksklfdsaj
@kuychaco, as far as what kind of feedback I'm looking for in code review:
|
Something that came to mind when looking at the many commits of #1512 in the issueish pane: Should the order be reversed? So that new commits appear at the top and you don't have to scroll down and potentially click on "load more" a few times, just to see if new commits are made. The timeline also has the same issue. We don't have to change it now, just something to consider one day. |
To match the commits.
lib/views/issueish-detail-view.js
Outdated
<PrTimelineContainer | ||
{...childProps} | ||
switchToIssueish={this.props.switchToIssueish} | ||
/> : |
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.
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.
oh, that's a mistake! Thanks for pointing it out. Will remove.
…to tt-18-sept-tabs-tabs-tabs
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.
This all looks great! The code as well as the finished product. Well done! ✨
switchToIssueish={this.props.switchToIssueish} | ||
/> | ||
} | ||
{isPr ? this.renderPullRequestBody(issueish, childProps) : this.renderIssueBody(issueish, childProps)} |
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.
👍 nice nice
<div className="github-PrTimeline-load-more-link" onClick={this.loadMore}> | ||
{this.props.relay.isLoading() ? <Octicon icon="ellipsis" /> : 'Load More'} | ||
<div className="github-PrTimeline-loadMore"> | ||
<button className="github-PrTimeline-loadMoreButton btn" onClick={this.loadMore}> |
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.
👍 on this being a button
edges { | ||
cursor | ||
node { | ||
commit { |
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.
Let's extract this as a fragment on PrCommitView. See timeline/commits-view.js and timeline/commit-view.js as an example.
This keeps our query fragments co-located with the views that use the resulting data, which is inline with Relay's philosophy (reducing unnecessary coupling, reasoning about discrete units of an application in isolation, and breaking complex interfaces into reusable components). I think this may also allow relay to do some extra checking for us to make sure that data from our queries match with what is actually being used.
@@ -161,6 +163,7 @@ describe('check out a pull request', function() { | |||
}); | |||
} | |||
|
|||
// achtung! this test is flaky |
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.
hmm weird. Any idea why? 🤔
@@ -109,7 +109,7 @@ describe('IssueishTimelineView', function() { | |||
const wrapper = shallow(buildApp({ | |||
relayHasMore: () => false, | |||
})); | |||
assert.isFalse(wrapper.find('.github-PrTimeline-load-more-link').exists()); | |||
assert.isFalse(wrapper.find('.github-PrTimeline-loadMoreButton').exists()); |
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.
Not sure about the appropriate convention here, just noticing that we've switched from hyphen-separated to camelCase... same below.
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 think @simurai made that change - I'm happy to switch to kabob-case for the sake of consistency.
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.
The naming convention would be camelCase for child elements of a component. So it can easily be read in groups: github-PrTimeline-loadMoreButton
-> It's the loadMoreButton
inside the PrTimeline
component inside the github
package. We don't follow that convention everywhere, which isn't a big deal.
test/views/pr-commit-view.test.js
Outdated
committerName: 'Margaret Hamilton', | ||
date: '2018-05-16T21:54:24.500Z', | ||
messageHeadline: 'This one weird trick for getting to the moon will blow your mind 🚀', | ||
abbreviatedOid: 'bad1dea', |
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.
😆
Oh oops. Yeah the order should totally be recent items first |
Co-Authored-By: Katrina Uychaco <[email protected]>
Co-Authored-By: Katrina Uychaco <[email protected]>
Co-Authored-By: Katrina Uychaco <[email protected]>
I knew I was going to do that. Co-Authored-By: Katrina Uychaco <[email protected]>
…to tt-18-sept-tabs-tabs-tabs
f07bb6a
to
4d2e7f1
Compare
Description of the Change
This change moves some of the information from the pull request view into tabs.
Screenies
docked:

TODO
Commits
tab.Alternate Designs
We had some back and forth about what information goes on each tab. @simurai's initial designs called for
description
,timeline
,commits
, andchanges
as the tab items. We had some back and forth about whether it might be better to use consistent language with what's used on dotcom. See the issue for details. Ultimately it would be best to validate our assumptions with uxr before we ship.I could have rolled my own tabs instead of using a lib. Although it sounded like fun, I thought it might be a more efficient use of time to not reinvent wheels. This lib is small and well maintained and uses good a11y practices.
Benefits
Separating the information into tabs gives us room for pull request reviews in the editor, which is where all this is headed.
Possible Drawbacks
It's possible that users will find the new UI confusing since we're moving information around.
Applicable Issues
#1656
Test plan
PrCommitView
component to verify that:IssueishDetailView
to test that it renders 3 tabs with the right text and iconsPrCommitsView
to verify that:TODOs for future prs:
IssueishDetailView
to improve readability