Skip to content
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

Merged
merged 32 commits into from
Aug 22, 2017

Conversation

akalin-keybase
Copy link
Contributor

@akalin-keybase akalin-keybase commented Aug 16, 2017

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.

@akalin-keybase akalin-keybase changed the base branch from master to akalin/DESKTOP-4391-inbox-filter-ui August 16, 2017 04:53
@akalin-keybase
Copy link
Contributor Author

r? @keybase/react-hackers

@keybase-ci-visdiff
Copy link

The commits 9385d8a...9f7c93c introduce visual changes on linux.

🔎 26 changed

@akalin-keybase
Copy link
Contributor Author

Hmm...not sure why this would cause visual changes. I'll investigate tomorrow.

@akalin-keybase akalin-keybase force-pushed the akalin/DESKTOP-4391-inbox-filter-ui branch from e70d369 to 4789f10 Compare August 16, 2017 18:53
@akalin-keybase akalin-keybase force-pushed the akalin/DESKTOP-4391-inbox-filter-style branch 2 times, most recently from 6f87abd to 32fc188 Compare August 16, 2017 18:56
@akalin-keybase akalin-keybase force-pushed the akalin/DESKTOP-4391-inbox-filter-ui branch from 4789f10 to 5ebd64d Compare August 18, 2017 00:02
@akalin-keybase akalin-keybase force-pushed the akalin/DESKTOP-4391-inbox-filter-style branch from 32fc188 to e96d582 Compare August 18, 2017 05:14
@akalin-keybase akalin-keybase force-pushed the akalin/DESKTOP-4391-inbox-filter-ui branch from 5ebd64d to 224cf55 Compare August 18, 2017 17:02
@akalin-keybase akalin-keybase force-pushed the akalin/DESKTOP-4391-inbox-filter-style branch 2 times, most recently from 1cc12fd to f5bb6bc Compare August 18, 2017 18:12
@akalin-keybase akalin-keybase changed the base branch from akalin/DESKTOP-4391-inbox-filter-ui to master August 18, 2017 18:12
@akalin-keybase
Copy link
Contributor Author

Okay, rebased, ready for a look. I think the visual changes went away?

Copy link
Contributor

@chrisnojima chrisnojima left a 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

return name.toLowerCase().indexOf(filter.toLowerCase()) >= 0
}

const sortNamesWithFilter = (names: Array<string>, filter: ?string): Array<string> => {
Copy link
Contributor

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

Copy link
Contributor Author

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.

@akalin-keybase akalin-keybase force-pushed the akalin/DESKTOP-4391-inbox-filter-style branch from f5bb6bc to 37cd242 Compare August 18, 2017 21:57
@@ -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})}
Copy link
Contributor Author

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

Copy link
Contributor

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
Copy link
Contributor Author

@akalin-keybase akalin-keybase Aug 19, 2017

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Reverted making it functional

youNeedToRekey: boolean,
}

function BottomLine(props: BottomLineProps) {
Copy link
Contributor Author

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

Copy link
Contributor

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

Copy link
Contributor Author

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...

Copy link
Contributor Author

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?

Copy link
Contributor

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.

facebook/react#5677

type="BodySemibold"
plainDivider={isMobile ? undefined : ',\u200a'}
containerStyle={{...boldOverride, color: usernameColor, paddingRight: 7}}
users={teamname ? [{username: teamname}] : participants.map(p => ({username: p})).toArray()}
Copy link
Contributor Author

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?

Copy link
Contributor

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

const {participants, showBold, usernameColor} = props
const boldOverride = showBold ? globalStyles.fontBold : null
return (
<Box
Copy link
Contributor Author

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
Copy link
Contributor Author

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?

Copy link
Contributor

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

Copy link
Contributor Author

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

@akalin-keybase
Copy link
Contributor Author

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))
Copy link
Contributor Author

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?

Copy link
Contributor

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

@akalin-keybase
Copy link
Contributor Author

Addressed latest comments, PTAL!

@akalin-keybase akalin-keybase force-pushed the akalin/DESKTOP-4391-inbox-filter-style branch from 987ac29 to 9c96e05 Compare August 22, 2017 09:00
@akalin-keybase akalin-keybase merged commit d3270ec into master Aug 22, 2017
@akalin-keybase akalin-keybase deleted the akalin/DESKTOP-4391-inbox-filter-style branch August 22, 2017 10:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants