-
Notifications
You must be signed in to change notification settings - Fork 16
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
Table: Create table components #695
Conversation
🦋 Changeset detectedLatest commit: 2161b85 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
size-limit report 📦
|
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.
Looks as though there's a little layout blip between when the Previous button is shown in the pagination vs. not.
Screen.Recording.2024-03-05.at.10.19.49.mov
/* eslint-disable @typescript-eslint/no-explicit-any */ | ||
public columns: 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.
I'm just spitballing here, but it could be interesting to think about a system where the column spec specifies the expected data type of each column, and that the types would guide telling a consumer if they've supplied data of the wrong types. At a minimum, perhaps we could make an alias type to avoid all the eslint-disable
s?
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.
Updated!
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've been thinking about your suggestion Dane. I wonder if it is possible in some cases the content in a column can be in multiple types. Do we require the consumer to provide all possible types? Will that be too heavy load for the consumer?
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 would generally hope that if we're displaying tabular data, that within a column the data type is consistent (or can be coerced to be consistent by way of string
, minimally). There's a tradeoff here between safety and tedium as you rightly call out...I don't really have strong feelings on this, and it can definitely be iterated on, so I don't want it to hold us up here too much!
Co-authored-by: Dane Hillard <github@danehillard.com>
Co-authored-by: Dane Hillard <github@danehillard.com>
Co-authored-by: Dane Hillard <github@danehillard.com>
Co-authored-by: Dane Hillard <github@danehillard.com>
public pageSizeOptions: number[] = [50, 100]; | ||
|
||
@property({ type: String, reflect: true, attribute: 'caption' }) | ||
public caption: 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 understand we need the caption for accessibility reasons, I'm curious if there should be any ability to visually hide it in certain cases or is the expectation should be having the practice of always showing a table caption?
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.
☝️ @sirrah-tam might have some insight into this, I think it could be "visually hidden" as long as it is still accessible to screen readers
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.
It would be great to be able to include an attribute that auto-visually-hides the caption as that does appear to be pretty common in other examples I'm finding. Similar to how the <title> element gives a SVG it's accessible name (accNam), the gives the Table it's accName, helpful when users of AT are reviewing the contents of a page. Visually hiding the captions would mean that a sighted user would have to use other information on the page to understand the context and purpose of the table, ex page title or heading preceding the table.
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.
If I understand correctly, we want to add another attribute, something like auto-visually-hide = true
, to control if we want to visually hide the caption? Does that mean we should make the caption attribute a required attribute so that we always have a accessible name for the table?
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 do feel like the caption should be required to enforce always having accessible tables generated but would leave that up to @sirrah-tam and the other wickies to officially answer yes/no.
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.
Updated!
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 caption element is not required per WCAG and there are some cases where the caption may not be needed, especially for simple tables where there is already a heading that precedes the table. However, I do like that we'd kind of take a stand that all tables need a caption by requiring it for our design system. I would however say we shouldn't have it hidden by default and instead make the user explicitly hide it.
} | ||
|
||
.hide-table-caption { | ||
visibility: hidden; |
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 CSS style will actually hide the content from a screen reader, similar to display: none
. It's better to use the following set of styles when trying to visually hide content:
.visually-hidden:not(:focus):not(:active) {
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}
Reference: https://www.scottohara.me/blog/2017/04/14/inclusively-hidden.html
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.
Updated!
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 this mixin is what you want within pharos
@mixin hidden { |
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!
public pageSizeOptions: number[] = [50, 100]; | ||
|
||
@property({ type: String, reflect: true, attribute: 'caption' }) | ||
public caption: 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.
The caption element is not required per WCAG and there are some cases where the caption may not be needed, especially for simple tables where there is already a heading that precedes the table. However, I do like that we'd kind of take a stand that all tables need a caption by requiring it for our design system. I would however say we shouldn't have it hidden by default and instead make the user explicitly hide it.
.table-controls { | ||
display: flex; | ||
justify-content: space-between; | ||
align-items: center; | ||
margin-top: var(--pharos-spacing-one-half-x); | ||
|
||
.item-per-page-wrapper { | ||
display: flex; | ||
align-items: center; | ||
column-gap: var(--pharos-spacing-one-half-x); | ||
|
||
.item-per-page-selector { | ||
width: 75px; | ||
} | ||
} | ||
|
||
.pagination { | ||
height: var(--pharos-spacing-one-and-a-half-x); | ||
} | ||
} |
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.
Typically we try to use a more BEM-like approach rather than deeply nested selectors. Because this isn't automated and is somewhat subjective currently, let's let it stand as a "TODO" for later 😄
Co-authored-by: Dane Hillard <github@danehillard.com>
public rowData: RowData[] = []; | ||
|
||
@property({ type: Boolean, reflect: true, attribute: 'hide-pagination' }) | ||
public hidePagination: boolean = true; |
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.
Might just be just personal opinion, but thoughts on making this showPagination
instead and defaulting it to false? Setting hidePagination="false" to show the pagination seems like a more complicated mental model than just showPagination="true" or showPagination="false" ?
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.
Yeah I feel showPagination makes more sense, updated!
it('is accessible', async () => { | ||
await expect(component).to.be.accessible(); | ||
}); | ||
|
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.
Might be nice to add a unit test like this one which verifies it throws an error when there is no caption?
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!
protected override firstUpdated(): void { | ||
this._pageSize = this.hidePagination ? this.rowData.length : this.pageSizeOptions[0]; | ||
this.totalResults = | ||
this.hidePagination || !this.totalResults ? this.rowData.length : this.totalResults; |
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 do we care about hidePagination 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.
Oh I guess we don't need it 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.
@jialin-he Just a couple of nits/questions, but this is looking awesome 🎉
Co-authored-by: Brent Swisher <brent@brentswisher.com>
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.
Small request to change the reference to hideCaption
vs hideCaptionVisually
as more concise way of setting that attribute.
Co-authored-by: Mat Harris <mat.harris@ithaka.org>
Co-authored-by: Mat Harris <mat.harris@ithaka.org>
Co-authored-by: Mat Harris <mat.harris@ithaka.org>
This change: (check at least one)
Is this a breaking change? (check one)
Is the: (complete all)
What does this change address?
Resolves #355 ; Create a basic table component
How does this change work?
A table component that takes in user input data and display with pagination.