feat: #218 v5-table-component table-part-[01]#307
Conversation
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferencesCodacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more Footnotes
|
kurtdoherty
left a comment
There was a problem hiding this comment.
Thanks @rpt-rfoxy. I've left a few comments; I think there'll need to be a bit of conversation on some, particularly the file structure and display mode.
| import { TableContainer } from '../../table-container' | ||
| describe('Table', () => { | ||
| test('should match snapshot', () => { | ||
| const { asFragment } = render( |
There was a problem hiding this comment.
issue: It's important to design our tests to fail well. You can read more about this here. Right now, this test is will fail:
- ✅ when our subject changes (
TableContainer); and, - ❌ when one of the subject's collaborators change (e.g.
Table)
Failure (2) is not what we want.
suggestion: To avoid this happening, we can simply change our test as follows:
render(<TableContainer>Fake child</TableContainer>)This way, we're only snapshotting the subject (and it's fake child), not the subject AND a bunch of collaborators. Each collaborator will have it's own tests to validate they function correctly.
src/components/table/table/table.mdx
Outdated
|
|
||
|
|
||
| The Table component can be used from the Table molecule components, e.g. `TableRow`, `TableCell`, etc | ||
| There are two visual styles for the table, dependant on screen width. |
There was a problem hiding this comment.
issue: Again, I don't see anything about this kind of responsive behaviour on the Figma design spec.
| padding: 0.75rem 0.5rem; | ||
| ${isBelowDesktop} { | ||
| display: flex; | ||
| } |
There was a problem hiding this comment.
issue: I don't see anything about this kind of responsive behaviour on the Figma design spec. It's really important that we do not add complexity to our components if we're not required to by the design spec.
Unless I'm mistaken, "responsiveness" will be done by hiding/showing columns; it will not be done by adjusting the way a table's cells are laid out.
| import { isBelowDesktop } from '../../../styles/media' | ||
| import { styled } from '@linaria/react' | ||
|
|
||
| export const ElTable = styled.table` |
There was a problem hiding this comment.
issue: I do not think we should be using the default table display mode. Instead, I think we should be using a flex or grid display mode. That said, I think this concern was missed on the solution design as I can't see any details around how we plan to size columns in the table correctly.
Might need further discussion on this one 🤔
src/components/table/table/table.tsx
Outdated
| import React, { FC, TableHTMLAttributes } from 'react' | ||
| import { ElTable } from './styles' | ||
|
|
||
| export interface ITableProps extends TableHTMLAttributes<HTMLTableElement> {} |
There was a problem hiding this comment.
todo: Can you please keep the names for prop types and interfaces consistent with the rest of the repo? Specifically, we don't use prefixes like I to denote an interface.
src/components/table/index.ts
Outdated
There was a problem hiding this comment.
issue: I don't think it was discussed in the solution design, but do we really need the nested folder structure here? Feels like we could just have something like:
table/
__tests__/
table.tests.tsx
table-container.tests.tsx
styles.tsx
table.tsx
table.stories.tsx
table-container.tsx
table-container.stories.tsx
...
|
thanks @kurtdoherty for the feedback, i'll change the code |
kurtdoherty
left a comment
There was a problem hiding this comment.
Thanks @rpt-rfoxy, just the one question, otherwise looks good.
src/components/table/index.test.ts
Outdated
There was a problem hiding this comment.
question: why are we testing our barrel file?
There was a problem hiding this comment.
Haha, okay, that's just "gaming the system." We don't want to add tests for the sake of our coverage metrics; that approach will just lead to low-value, high-maintenance tests, and undermine the value coverage metrics are meant to provide: namely, the identification of possible risk in our code.
Instead of simply adding test coverage against a module that does not need tests, we need to assess whether there's any meaningful coverage gaps being reported. Barrel files are not a meaningful gap.
To help with this, I'll make a change to our coverage settings to exclude barrel files. Once that's merged in, rebase you changes and see what your coverage comes back as for the components you're adding in this PR.
| export * from './components/skeleton' | ||
| export * from './components/tooltip' | ||
| export * from './components/table/table-container' | ||
| export * from './components/table/table-toolbar' |
There was a problem hiding this comment.
@rpt-rfoxy question: Is there a reason why this is being removed now? We agreed upon having separate folders for atoms. This will allow you to avoid having a barrel file.
@kurtdoherty Please do correct me if I am wrong here.
There was a problem hiding this comment.
I didn't notice this change sorry 🙈 I agree with you, removing these doesn't seem to be necessary.
There was a problem hiding this comment.
thanks for the feedback, i already remove the barrel

Pull request checklist
Detail as per issue below (required):

as perdiscusstion here Discussion
schreenshoot