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
PF4: feat(Tabs) Add Tabs for PF4 #1144
Conversation
PatternFly-React preview: https://1144-pr-patternfly-react-patternfly.surge.sh |
Pull Request Test Coverage Report for Build 4187
💛 - Coveralls |
export * from './Text'; | ||
export * from './TextArea'; | ||
export * from './TextInput'; | ||
export * from './Title'; | ||
export * from './Tooltip'; | ||
export * from './TextArea'; |
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.
Duplicates 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.
@tlabaj This is looking good but there are two issues I see.
-
Secondary tabs should be styled differently from primary tabs. See the core example that shows the correct secondary tab styling.
-
When the tabs do not fit horizontally, I don't believe we should be displaying a horizontal scroll bar. The purpose of adding the arrows to the end of the tab bar was to eliminate the need to scroll. @mceledonia can you confirm?
I've been chatting off-site with Titani, the secondary tab styling fix is in progress (was missing the @mcarrano Regarding the presence of scrollbars, based on my note in Core Issue 85 I think we agreed at the end of our meeting to keep scrollbars and remove the original scrollbar-hiding hack to avoid fighting with browsers (primarily Firefox). Soon after that discussion Firefox made it possible to fully hide scrollbars (covered in Core Issue 1103) but doing so will still negatively impact users who explicitly ask for scrollbars to be shown in their browser's settings. |
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.
Once the latest Core CSS changes are added and the .pf-m-tabs-secondary
modifier is added to secondary tabs the HTML/CSS looks good to me. Nice job Titani, especially with the fancy scroll button behavior! 🙂
I do recall that discussion now, @andybraren . @mceledonia what do you think about the scroll bar? |
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.
Secondary tabs are now correct. I'm OK to move forward.
The CSS is almost there - it just needs the refactoring and tweaks included in Core's PR #1068 to fix things like the scroll button bug that Christie noted here. |
@andybraren Workspace so it pulls in the updated css. Please try the latest preview. Make sure to clear your cache first. |
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.
HTML/CSS looks good, thank you for pulling in those latest changes! CSS approved.
From an IXD perspective, I notice two things:
-
The scroll buttons in the "Secondary buttons" example seem susceptible to breaking, particularly the ones for secondary tabs. Sometimes the regular "Scroll buttons" example breaks too, but less often. I'm not quite sure why this is. Chrome's Console doesn't report anything breaking.
-
The scroll button "math" seems to position the left-most pixel of the next tab directly underneath the left-most pixel of the scroll button, covering the first part of the tab's label (see below, "Tab" is covered). Could that math be tweaked to position the tab's left-most pixel directly to the right of the left scroll button's right-most pixel?
Now I see what you are saying about the scroll breaking @andybraren . I have to admit that this is pretty ugly from an IxD perspective, especially when there are two rows of tabs. @mceledonia have you looked at this? Is there possibly another way to handle this? The original intent was mainly to provide a solution for tabs on a mobile device. Has anyone tested it there? I wonder how well that works. In most desktop scenarios we should not see this unless there are an extreme number of tabs. |
The original design linked at the top of Core PR #868 didn't include an example of scrolling secondary tabs. Here's a video of what they look like on iOS 12; better but not perfect. If scrollbars on desktop are the main "ugly" part, that circles back to the discussion in Core Issue #859. Also notice in the video above that two taps are required to "click" a tab - the first one just activates the hover state. This could be solved either via CSS or JS. I'll bring this up within the CSS group to figure out which would be most appropriate. |
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.
CSS looks good here. I know there's some discussion about what will happen with scroll bars and arrows, but for the meantime this is consistent with Core
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.
(One sec, checking on the grey background)
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.
One last thing, the grey background issue is fixed in Core 1246, could you include that change?
I created issue patternfly/patternfly#1127 to provide consistent labels for
Is this possible with this implementation? Is this something that should be captured in a separate issue? |
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 work!!!
@jgiardino That makes sense to me - I created Core #1328 to track that change. |
@mcarrano @andybraren Please take another look. The PR to updated to the version of core with the background fix went in this morning. |
@jgiardino if you are ok with it. I think we should open a separate issue so we don't hold this PR up. |
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.
With the latest Core changes the grey background issue is now gone. Great job Titani! 🎉
@andy @jgiardino I added issue #1268 to track the accessibility issue. |
import { SFC, HTMLProps } from 'react'; | ||
|
||
export interface TabProps extends HTMLProps<HTMLDivElement> { | ||
children: any; |
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 children as that is included in html props.
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 removed this.
import { Omit } from '../../typeUtils'; | ||
|
||
export interface TabsProps extends Omit<HTMLProps<HTMLDivElement>, 'onSelect'> { | ||
children: any; |
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.
children included in html props
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.
don't I need to override . it here since it is required?
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.
You should import this and add this to the typescript integration app since it's more complicated component.
static propTypes = propTypes; | ||
static defaultProps = defaultProps; | ||
|
||
constructor(props) { |
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.
Since this is a class component & we are using the babel class properties plugin, we don't need a constructor. You can add the createref right on the class like tablist= React.createRef()
styles.tabs, | ||
isFilled && styles.modifiers.fill, | ||
isSecondary && styles.modifiers.tabsSecondary, | ||
this.state.showLeftScrollButton && styles.modifiers.start, |
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.
can we destructure these state values like we do for the props?
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.
good idea. thanks.
This reverts commit ca890d9.
826bca5
import { Omit } from '../../typeUtils'; | ||
|
||
export interface TabsProps extends Omit<HTMLProps<HTMLDivElement>, 'onSelect'> { | ||
children: any; |
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.
You should import this and add this to the typescript integration app since it's more complicated component.
What:#926
Additional issues: