-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Style inbox differently when filter is non-empty #8130
Style inbox differently when filter is non-empty #8130
Conversation
r? @keybase/react-hackers |
The commits 9385d8a...9f7c93c introduce visual changes on linux. 🔎 26 changed
|
Hmm...not sure why this would cause visual changes. I'll investigate tomorrow. |
e70d369
to
4789f10
Compare
6f87abd
to
32fc188
Compare
4789f10
to
5ebd64d
Compare
32fc188
to
e96d582
Compare
5ebd64d
to
224cf55
Compare
1cc12fd
to
f5bb6bc
Compare
Okay, rebased, ready for a look. I think the visual changes went away? |
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 it'll likely be better longer term if the filter concept isn't leaked to these components. like Usernames shouldn't know about a filter at all. if we're doing something like changing the sorting, we should change the sort before passing it to this component. We're attempting to make our components dumber and things like our connectors smarter.
I think likely the best approach is if you're in filter mode, we have a different list thats rendered entirely. It can render itself with some of the same sub components (like TopLine) but I don't think we want to keep the original list and plumb through more details the components inside need to know.
While the 1:1 convos will appear pretty close the team stuff will be entirely different, and longer term the list structure will be different so i think its likely best to divide it further upstream. lets discuss more on slack
shared/common-adapters/usernames.js
Outdated
return name.toLowerCase().indexOf(filter.toLowerCase()) >= 0 | ||
} | ||
|
||
const sortNamesWithFilter = (names: Array<string>, filter: ?string): Array<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 don't think we change the sorting at all, see the design: https://zpl.io/aRMyk0V
search is 'malg' we don't change the tlf order though
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.
Ahhh, I had thought that 'jack,cjb,miles,mark' in https://app.zeplin.io/project/56b25ffc64fc91773a73aaf8/screen/598a3926676fff2f2ab6f780 was 'jack,cjb,miles,mark,...,malg', and it turned into 'jack,cjb,miles,malg'. Will fix.
f5bb6bc
to
37cd242
Compare
@@ -96,7 +97,7 @@ class Inbox extends PureComponent<void, Props, {rows: Array<any>}> { | |||
keyExtractor={this._keyExtractor} | |||
renderItem={this._renderItem} | |||
onViewableItemsChanged={this._onViewChanged} | |||
getItemLayout={(data, index) => ({length: 64, offset: 64 * index, index})} | |||
getItemLayout={(data, index) => ({index, length: 64, offset: 64 * index})} |
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.
eslint complained about key ordering here
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 is actually a warning in eslint. we've not moved forward with making it an error. i'm kinda wishing it was something that could be auto fixed by lint. i tend to sort it as i think it makes things cleaner but its def. not required just fyi
import memoize from 'lodash/memoize' | ||
import {List} from 'immutable' | ||
|
||
// All this complexity isn't great but the current implementation of avatar forces us to juggle all these colors and |
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.
Didn't change much here, except made the components functional
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.
Reverted making it functional
shared/chat/inbox/row/bottom-line.js
Outdated
youNeedToRekey: boolean, | ||
} | ||
|
||
function BottomLine(props: BottomLineProps) { |
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.
Didn't change much here, except made the components functional
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.
actually we should keep these as PureComponent as they're optimized to not rerender w/ shallowcompare. react hasn't yet made a pass at optimizing this sadly
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.
Ah, okay. I assume you mean this and all the others I converted? Will do...
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.
Converted everything back. Can you explain a bit more about why functional components aren't as optimized in this case? Is it just a general thing that inheriting from PureComponent does the right thing whereas functional components don't?
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.
Purecomponent has a shallow equal compare of props and state so if those === it'll not rerender. Currently functions don't do this check (even though it's safe for us). We could wrap with recompose and it has a pure helper or we can just extend from pure component.
type="BodySemibold" | ||
plainDivider={isMobile ? undefined : ',\u200a'} | ||
containerStyle={{...boldOverride, color: usernameColor, paddingRight: 7}} | ||
users={teamname ? [{username: teamname}] : participants.map(p => ({username: p})).toArray()} |
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.
we don't need this teamname logic anymore, right, since we branched those off into their own components?
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 bringing this back. the row for this and teams that are simple teams is so close its not worth splitting it up. the thing thats key to be different is for the filtered stuff
shared/chat/inbox/row/top-line.js
Outdated
const {participants, showBold, usernameColor} = props | ||
const boldOverride = showBold ? globalStyles.fontBold : null | ||
return ( | ||
<Box |
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.
Collapsed the two outer Boxes into one here
|
||
import type {Props} from './plaintext-usernames' | ||
|
||
const inlineStyle = isMobile |
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's some duplication here with usernames.js...should I try and factor those out?
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.
why split this out at all? its used by filtered and non filtered right
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.
Done, moved back into usernames.js
All right, I took a crack at moving the logic further up and using branch. This PR got a lot bigger, though, so let me know if I should split it up into smaller ones. PTAL! |
@@ -146,7 +146,8 @@ const ConnectedRow = compose( | |||
// $FlowIssue | |||
pausableConnect(mapStateToProps, mapDispatchToProps, mergeProps), | |||
branch(props => props.teamname && !props.channelname, renderComponent(TeamRow)), | |||
branch(props => props.teamname && props.channelname, renderComponent(ChannelRow)) | |||
branch(props => props.teamname && props.channelname, renderComponent(ChannelRow)), | |||
branch(props => props.filtered, renderComponent(FilteredRow)) |
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 noticed that flow doesn't catch, e.g. mistakenly putting props.filter
or something -- will this be fixed once we update to 0.53? Is that what the $FlowIssue tag above is?
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.
Hopefully. There's a flow-types recompose that'll be out but it's not there yet
Addressed latest comments, PTAL! |
987ac29
to
9c96e05
Compare
Just show the participants' names, and move the filter-matching
names to the front.
Split Usernames component into PlaintextUsernames and Usernames.
Split off TopLine, BottomLine, and Avatars into their own files.
Split TopLine component into FilteredTopLine and SimpleTopLine.
Split Row into SimpleRow and FilteredRow.