Table Component - Solution Design

[ksolanki7]

I have reviewed Table DS over Figma, and trying to come up with a solution design that may best suit the elements. Please review and provide feedback.

Below is the suggested component structure

Component Structure

1. TableToolbar

Purpose:
The toolbar displays item count, a page size selector, and bulk action buttons (Button Group).

Configurations:
Text: Dynamic text for item count (Product driven)
Page Size Selector: Configurable and optional state.
Bulk Action Buttons: Uses a Button Group to support batch actions, optional.
Skeleton: Skeleton state will display skeleton of the toolbar until data is being loaded

2. Table

Implementation: Utilizes native HTML <table> elements to enhance accessibility (a11y), incorporating headers, rows, and columns for a consistent, screen-reader-friendly experience.

Configuration:
The table will consist of Table atoms like TableHeader, TableBody, TableCell, TableRow and etc.

3. TablePagination

Purpose: Supports paginated navigation, handling large datasets efficiently within the Table component.

---

Atomic and Molecular Components within Table
Both table-specific and generic components will be played as is own tickets and will be consumed by Table component.

Table-Specific Atoms/Molecules:

• Toolbar: Contains UI elements for table interactions like item count and bulk actions.
• SingleRowCell: Renders cells with single-row content.
• DoubleRowCell: Renders cells with dual-row content, if needed for specific use cases.

General UI Components:

• Pagination: Manages paginated content display.
• Checkbox: For row selection.
• Button/Button Group: Handles bulk action buttons within the toolbar.
• Text
• Date
• Feature Components:
• Badge
• Status
• Tag / Tag Group
• Avatar
• Image
• Menu
• Empty data

Each of these components supports reusability across the elements and aligns with the design requirements for accessibility and modularity.

Toolbar

This will be a new molecule and subset of Table, i.e., a Table-specific atom.

The toolbar will consist of text, a button group with buttons, and a menu.

The toolbar will have the following main prop interface

prop	Usage
entityNamePlural: string	Specifies the plural form of the entity's name to display domain-specific terminology (e.g., 85 properties or 21 contacts).
variant?: enum	Determines the display variant for page size or bulk action view
totalItems: number	The total count of items.
selectedItems: number	Represents the count of items currently selected

and standard rest props like className and any extra prop interface required.

Suggestion:

• A skeleton loading state will be displayed if the totalItem value is not provided, indicating that items are still loading.
• For page size options, the new menu component accepts ReactNode for each option, eliminating the need to define default or custom page size options explicitly.

---

Note: The atoms below and their prop interface do not include accessibility, which needs to be done separately in its own PR.

TableContainer

• This will serve as a simple div wrapper encompassing the toolbar, table, and pagination, with a fixed width.

---

Table

• This will implement a native HTML table, structured with standard table elements, including thead and tbody.

---

TableHeader

• This will serve as thead will optional prop interface

prop	Usage
stickyHeader?: boolean	Enables the table header to stick to the top of the viewport during vertical scrolling.

---

TableRow

• This will be simple row tr of the table which encapsulates TableCell

prop	Usage
link?: string	Specifies a URL that, if provided, will make the entire row clickable, redirecting to the specified link when the row is clicked.
isSelected?: boolean	Indicates whether the row is currently selected.

---

TableCell

• This will be represent cell td of the table which accepts different components as children

prop	Usage
alignment?: enum	Controls the text alignment within the cell
link?: string	Specifies a URL that, if provided, will make the cell clickable, redirecting to the specified link when the cell is clicked.
width?: string	Defines fixed width of the cell
minWidth?: string	Defines minimum width of the cell should have
maxWidth?: string	Defines the maximum width of the cell that can have

Note: Need to discuss width-related props in detail when picking up TableCell work. May require an enum to define enum for the type of width a cell has i.e. Fluid v/s Fixed v/s Fluid with min/max width, and hug content

---

PRs

	PR	Goal
1	Deprecate existing Table Component	This PR will deprecate the current Table component, marking it as legacy and allowing its continued use while the new design system (DS) Table component and associated atoms are under development. This enables a smooth transition by maintaining existing functionality until the new components are fully implemented and integrated within the v5 elements.
2	Toolbar	This PR will introduce a customizable Toolbar component as part of the new Table's design. The Toolbar will contain item count, page size selector, and bulk action buttons, providing users with a clear and efficient interface for managing table data. These elements will be flexible and support different configurations to accommodate various use cases across products.
3	New Table Atoms	This PR will create the foundational atoms needed for the Table component, including table cells, headers, and row structures. These atoms will be designed with a composition-first approach, allowing for easy reuse and customization. Each atom will be built to support the overall Table layout, enabling responsive behavior, custom styling, and accessibility features for a consistent and flexible design.
4	Row Selection	This PR will implement row selection functionality, enabling users to select individual or multiple rows within the table. This feature will support common use cases such as batch actions and multi-row manipulation. Row selection will include keyboard and mouse accessibility in Accessibility PR, visual feedback for selected rows, and compatibility with the Toolbar’s bulk action buttons for a seamless experience.
5	Column Sort	This PR will introduce column sorting capabilities, allowing users to sort table data by specific columns. Each sortable column will display an indicator for the current sort direction (ascending or descending) and be keyboard-accessible (Will be done in Accessibility PR). This feature improves data interactivity and usability, allowing users to navigate and organize information in the table easily.
6	Accessibility	This PR will address key accessibility (a11y) enhancements across the new Table component, ensuring that it meets WCAG standards. This includes keyboard navigation support, ARIA roles and labels, focus management, and screen reader compatibility. Accessibility considerations will be integral to each component (e.g., rows, cells, Toolbar, and pagination), providing an inclusive experience for all users.

Component Code Structure (Pseudocode):

<TableContainer>
  <TableToolbar />
  <Table>
    <TableHeader>
      <TableRow>
        <TableHead>Heading 1</TableHead>
        <TableHead...
      </TableRow>
    </TableHeader>
    <TableBody>
      <TableRow>
        <TableCell>Data Content 1</TableCell>
        <TableCell...
      </TableRow>
      <TableRow>
        <TableCell>Data Content 2</TableCell>
        <TableCell...
      </TableRow>
      <TableRow...
    </TableBoday>
  </Table>
  <Pagination />
</TableContainer>

[kurtdoherty]

praise: thanks for all the work you've put into this design doc @ksolanki7 👏

Overall

question: In your code snippet above, you show a TableHead component being used for the cells within the TableHeader. Not only do I find this name a little confusing (it makes me think of <thead>), there's no discussion of the component in the design. Is it a wrapper around TableCell, or is it something else?

suggestion: I would recommend delaying the selection state management until after the a11y work has been done.

suggestion: Personally, I think we should have a clear plan for how we deal with the a11y concerns before we invest in implementing any of the atoms you've outlined. I would suck to do all this work implementing the atoms only to discover a bunch of changes are now need to facilitate good a11y.

Toolbar

suggestion: I think we could make this component a simple atom that has two props leftContent (or description) and actions, both of which accept ReactNode's. My thinking here is:

• entityNamePlural doesn't help us deal with singular result counts (e.g. "1 property"). This is something we ignored for the Console Cloud component;
• The consumer knows how many items are present and if any are selected, so they're best placed to decide whether the page size menu or bulk actions should be rendered, same deal with the result count or selection count text on the left. We're not buying ourselves a lot of value by encapsulating this decision because it's simple to get right and, if a dev gets it wrong, simple to fix. We can also build a hook or a higher-level component that owns more of the knowledge and state related to the amount of data and what is selected (i.e. we don't need to bake that decision-making into this atom, instead, we can bake it into a unit of code that will be making other similar decisions on behalf of these presentational atoms);
• There's really nothing different between the page size menu and the bulk actions. Both are positioned on the right; the bulk actions will just involve a ButtonGroup where the page size menu won't;
• I think the skeleton could be handled by a completely separate atom (e.g. ToolbarSkeleton). That said, skeletons probably deserve some specific thought, as React features like Suspense, if used by a consumer, will result in a very different code design than if they aren't used (this is what makes me wonder if the skeletons should be implemented as separate atoms).

TableHeader

suggestion: isSticky instead of stickyHeader. I tend to prefer the use of auxiliary verbs for boolean props (at least when they're not native HTML attributes).

question: TableHead instead of TableHeader? 🤔 I can't decide what I prefer...

TableRow

suggestion: It could be nice to rely on :has(input[checked="true"]) (or something like that) via CSS to determine whether the row has a checkbox that is checked instead of requiring consumers to double up on that state.

suggestion: href instead of link. Also, onClick may be necessary in some cases, depending on how a product decides to implement the opening/closing of drawers (more on that when we get to the drawer work). Either way, I like the idea of having this feel similar to the interface for our buttons and menu items.

question: Do you have an idea on how we'll handle the a11y for tables that involve hyperlinked rows (which will be most tables)? It's okay if you don't yet, just curious.

TableCell

question: How do the single row and double row cell components relate to the TableCell you've described in this design doc?

question: Why do we need cells to have a href/link? Is this a futurism or has design expressed this as a specific requirement? If content in a cell needs to link to another page, I'd expect design to make the primary text in the cell a hyperlink instead of the whole cell 🤔

[ksolanki7]

Thank you @kurtdoherty for the detailed feedback.

question: In your code snippet above, you show a TableHead component being used for the cells within the TableHeader. Not only do I find this name a little confusing (it makes me think of ), there's no discussion of the component in the design. Is it a wrapper around TableCell, or is it something else?

There is a mention of Table Head row, and I am following the standards which can be found over mdn doc for the Table structure.
Below is the HTML definition for the atoms

Atom	HTML element
TableContainer	<div>
Table	<table>
TableHeader	<thead>
TableRow	<tr>
TableHead	<th>
TableCell	<td>

This is how the actual rendered HTML would look like

<div class="el-new-table-container">
  <table class="el-new-table">
    <thead role="rowgroup" class="el-new-thead">
      <tr role="row" class="el-new-table-row">
        <th role="columnheader" class="el-new-table-head">Head 1</th>
        <th role="columnheader" class="el-new-table-head">Head 2</th>
        <th role="columnheader" class="el-new-table-head">Head 3</th>
      </tr>
    </thead>
    <tbody role="rowgroup" class="el-new-table-body">
      <tr role="row" class="el-new-table-row">
        <td role="cell" class="el-new-tabel-cell">Data 1</td>
        <td role="cell" class="el-new-tabel-cell">Data 2</td>
        <td role="cell" class="el-new-tabel-cell">Data 3</td>
      </tr>
      <tr tabindex="0" role="row" class="el-new-table-row">
        <td role="cell" class="el-new-tabel-cell">Data 4</td>
        <td role="cell" class="el-new-tabel-cell">Data 5</td>
        <td role="cell" class="el-new-tabel-cell">Data 6</td>
      </tr>
    </tbody>
  </table>
</div>

Do you have an idea on how we'll handle the a11y for tables that involve hyperlinked rows (which will be most tables)? It's okay if you don't yet, just curious.

I am working on POC for this and will represent to the team for feedback on it.

How do the single row and double row cell components relate to the TableCell you've described in this design doc?

They are just a table specific atoms and not generic elements other than that there is no relation directly to TableCell

Why do we need cells to have a href/link? Is this a futurism or has design expressed this as a specific requirement? If content in a cell needs to link to another page, I'd expect design to make the primary text in the cell a hyperlink instead of the whole cell

I agree; it's preferable for the cell content to contain the link, rather than having the entire cell act as a link.

---

Regarding your suggestions.
I’ll keep your suggestion in mind as I work on this and I will note it in the ticket for reference as well.

[kurtdoherty]

I am following the standards which can be found over mdn doc for the Table structure.

I'm confused. The MDN docs for <thead> describe it as the "Table Head element", while the MDN docs for <th> describe it as the "Table Header element". So, it feels like TableHead and TableHeader should at least be swapped:

Atom	HTML element
TableContainer	<div>
Table	<table>
TableHead	<thead>
TableRow	<tr>
TableHeader	<th>
TableCell	<td>

That said, I find "Table Header" to be quite a confusing name name for a table cell component. Other names that I think work better for the <th> atom include:

• TableColumnHeader;
• TableHeaderCell; or,
• Have TableCell handle both the <td> element when a child of the TableBody (<tbody>) and the <th> element when a child of the TableHead (<thead>). This behaviour can be achieved using React context.

This is how the actual rendered HTML would look like

Just keep in mind that when the native HTML elements are used (like <table>, <tr> etc), we should not provide a role. The native elements have an intrinsic role in the a11y tree. We only need to specify the role when we're using non-table elements like <div> and <a> etc to represent the different parts of a table.

[kurtdoherty]

Actually, I've just noticed <th> cells can be scoped to a column or the row, so I think making TableCell handle both and will probably over-complicate things, which just leaves TableColumnHeader or TableHeaderCell as my naming suggestions for the atom that represents <th> (I probably lean towards TableHeaderCell).

[ksolanki7]

@kurtdoherty Thank you again.

I'm confused. The MDN docs for describe it as the "Table Head element", while the MDN docs for describe it as the "Table Header element". So, it feels like TableHead and TableHeader should at least be swapped:

Oops, my bad, I accidentally swapped those across.

Have TableCell handle both the element when a child of the TableBody () and the element when a child of the TableHead (). This behavior can be achieved using React context.

I like the idea of using React context so that consumers have less to decide about what to use and when. But I believe we won't be considering this as TableRow also supports <th>.

Just keep in mind that when the native HTML elements are used (like <table>, <tr> etc), we should not provide a role. The native elements have an intrinsic role in the a11y tree. We only need to specify the role when we're using non-table elements like <div> and <a> etc to represent the different parts of a table.

Noted.

Actually, I've just noticed <th> cells can be scoped to a column or the row, so I think making TableCell handle both and will probably over-complicate things, which just leaves TableColumnHeader or TableHeaderCell as my naming suggestions for the atom that represents <th> (I probably lean towards TableHeaderCell).

I prefer TableHeaderCell too.

[DanishAli-Reapit]

Hi @kurtdoherty & @ksolanki7

Please check my design solution and the POC for the Table Row Selection component.

Table Row Selection Solution Design

The table row selection will have the following prop interface.

Prop	Default	Usage
id?: string		checkbox row id
isSelectAll?: boolean	false	To mark as "Select All"

The table context will have the following prop interface.

Prop	Default	Usage
selectedRowIds?: string[]		An array of selected row ids
toggleRowSelection?: string		This is an ID key passed to the provider
toggleSelectAll?: void		This will be used to select and deselect all the rows
isAllSelected?: boolean	false	To mark as "Select All"

The table provider will have the following prop interface.

Prop	Usage
children?: ReactNode	Table components will be declared
rows?: any[]	Array of objects [Data]
idKey?: string	To identify the id from the array of objects provided

Component Code Structure (Pseudocode):

The whole table component will be wrapped inside the TableProvider which stores the table selected row state and the <TableRowSelection isSelectAll/> component will have the Checkbox component and perform the state update of select all or deselect all. The <TableRowSelection /> with no isSelectAll acts as a row checkbox that will update the selected row state

<TableProvider>
  <TableContainer>
    <TableToolbar />
    <Table>
      <TableHeader>
        <TableRow>
          <TableHead>
            <TableRowSelection isSelectAll/>
          </TableHead>
          <TableHead...
        </TableRow>
      </TableHeader>
      <TableBody>
        <TableRow>
          <TableCell>
            <TableRowSelection />
          </TableCell>
          <TableCell...
        </TableRow>
      </TableBody>
    </Table>
  </TableContainer>
</TableProvider>

[DanishAli-Reapit]

Hi @kurtdoherty & @ksolanki7, when you find time, please review my POC if you have any suggestions or improvements.

[DanishAli-Reapit]

Hi @kurtdoherty and @ksolanki7 can you please review my POC for any suggestions or improvements.

[kurtdoherty]

Sorry @DanishAli-Reapit, this is still on my TODO list 😬

[ksolanki7]

@DanishAli-Reapit I have looked into your POC; it is tightly coupled with sort functionality, so hard to review your POC in detail just for row selection. But after our discussion and going through the approach, I am happy to get this progress through the PR where we can review the work and if any call outs to amend any approach then we can take it from there.

[ksolanki7]

@DanishAli-Reapit In terms of sort function, I believe you are supporting three sort states here.

• Default
• ASC
• DESC

These require some discussion. May be hold on this till @kurtdoherty comes back.

[rpt-rfoxy]

Hello Genks,
cc @kurtdoherty && @ksolanki7

From the Figma design, Here's my proposed solution for Table:

---

Table Atoms Solution Design

1 table

The Table will have the following main prop interface

Prop	Value	Default	Usage
data?: IData<THead, TRow>	Array of	undefined	its used for datatable

---

2 table-body

The table-body will have the following main prop interface

Prop	Value	Default	Usage
children?: (ReactNode)	((props: ITableBodyChildProps<TRowItem, THeadItem>) => ReactNode)	ReactNode or Function that Return Reactnode	undefined

---

3 table-cell

The table-cell is come from two element, its td and div, since td didnt have absolute style, so i wrate the table-cell using div, its will have the following main prop interface

Prop	Value	Default	Usage
alignment?: enum	"left" , "center" , "right"	"left"	its used for aligment the content
link?: string	string of any	undefined	its used for rendering cell as
width?: string	string of size Width	undefined	its used for sizing width of cell
minWidth?: string	string of size minWidth	undefined	its used for sizing minWidth of cell
maxWidth?: string	string of size maxWidth	undefined	its used for sizing maxWidth of cell
narrowLabel?: string	string of any	undefined	its used for showing label heading if its on mobile device

---

4 table-head

The table-head is come from th element, its will have the following main prop interface

Prop	Value	Default	Usage
children?: (ReactNode)	((props: ITableBodyChildProps<TRowItem, THeadItem>) => ReactNode)	ReactNode or Function that Return Reactnode	undefined
isSticky?: boolean	false, true	undefined	its used for showing sticky heads

---

5 table-header-cell

The table-header-cell is come from two element, its td and div, since td didnt have absolute style, so i wrate the table-header-cell using div, its will have the following main prop interface

Prop	Value	Default	Usage
alignment?: enum	"left" , "center" , "right"	"left"	its used for aligment the content
width?: string	string of size Width	undefined	its used for sizing width of cell
minWidth?: string	string of size minWidth	undefined	its used for sizing minWidth of cell
maxWidth?: string	string of size maxWidth	undefined	its used for sizing maxWidth of cell

---

6 table-row

The part will used @DanishAli-Reapit code, see Danish POC

---

Code Concept

to see the detail implementation, you can check it here (POC) please let me know if the link didnt work

[kurtdoherty]

@rpt-rfoxy thanks for prepping the POC and solution design for these atoms 👏 Appreciate the effort and thought you've put into them so far.

issue: At this stage, my feedback is similar to what I've given Danish above: you're making the table atoms handle more than just their presentational concerns which is giving them too much responsibility. Our atoms should not be directly handling data, facilitating render props or anything like that; we just want nice simple atoms that enable us to layout our table content correctly. Once we have good atoms, we can then explore our options for reducing the amount of boilerplate via higher-level components.

Perhaps the only "intelligence" these atoms may want to encapsulate is what DOM element they render as: for simple tables, the standard <table>, <tr> et al elements are fine, but for more complex tables that involve rows that link to other pages in the product or open drawers, I think we'd want to be using <div>, <a> et al paired with the correct role attributes.

question: I'm not sure I understand what link is for on the table cell atom. Can you please expand? (I assume I've missed some on the design spec).

question: Likewise, I'm not sure I understand what narrowLabel is for on the table cell atom. Can you please expand on this one too? 🙏

[rpt-rfoxy]

hi @kurtdoherty thanks for the feedback, i already updated the code as the request, and here the PR

table-cell (link) params is use for Specifies a URL that, if provided, will make the cell clickable, redirecting to the specified link when the cell is clicked. and its just the params from previous @ksolanki7 Document Design Solution

table-cell (narrowLabel) params is for rendering the table header when the table is in mobile mode / responseive mode, this is influence from old code that have feauture for rendering header label inside cells, here the schreenshot:

please tell me if it not neccesary

[kurtdoherty]

Thanks @rpt-rfoxy, I'll take a look at the updated POC shortly.

table-cell (link) params is use for Specifies a URL that, if provided, will make the cell clickable, redirecting to the specified link when the cell is clicked. and its just the params from previous @ksolanki7 Document Design Solution

Yes, and there is discussion about that above where we establish it is not needed.

table-cell (narrowLabel) params is for rendering the table header when the table is in mobile mode / responseive mode, this is influence from old code that have feauture for rendering header label inside cells.

Unless the design spec outlines the need for this, we should not be implementing it. My understanding is responsiveness for tables will mostly be handled by something other than a table (e.g. a list of cards).

[rpt-rfoxy]

hi @kurtdoherty thanks for the feedback, here the new updated POC

and heres the PR

[rpt-rfoxy]

hi @ksolanki7 as your feedback, here my new PR

notes: i create component as simple as i can, and for table-cell (narrowLabel) if you have sugestion about new name, please let me know.

[rpt-rfoxy]

hi @kurtdoherty , i already split the PR, i mark the PR with bumber, here the list

• [part -1] component Table PR
• [part -2] component TableBody PR
• [part -3] component TableHead & TableHeaderCell PR
• [part -4] component TableRow PR this row will handle by @DanishAli-Reapit Code
• [part -5] component TableCell PR

[DanishAli-Reapit]

Hi @rpt-rfoxy, As mentioned in part 4 PR. My branch for row selection will be a separate component as there will be only one row that will be used as the row selection rest will still use the normal TableRow component. You will still need to style the row's selected state.

[rpt-rfoxy]

hi @DanishAli-Reapit thanks for your notify, i already create and styling the row as Figma design, you can check the PR

[DanishAli-Reapit]

Hi @kurtdoherty & @ksolanki7 Please review my Single and Double Row Cell POC and Solution Design

Single Row Cell

The Single Row Cell will have the following main prop interface

Prop	Value	Usage
children?: ReactNode	ReactNode	It can have any components in it

Double Row Cell

The Double Row Cell will have the following main prop interface

Prop	Value	Usage
avatar?: ReactNode	ReactNode	It will have an avatar component
firstRow?: ReactNode	ReactNode	It can have any components in it
secondRow?: ReactNode;	ReactNode	It can have any components in it

[DanishAli-Reapit]

Hi @kurtdoherty, My main concern was the Icon and text together in the SingleLineCell if we put the icon in the mediaItem props that is fine but it will restrict the user to use only one icon and that is to the left only.

What about the following scenarios:

1. <Icon> <Text> <Icon>
2. <Text> <StatusIndicator>

All multi-components scenarios won't have a gap in between as each component doesn't have the outer padding to create a space in between.

So either we create a ComponentGroup component for scenarios like this and keep the SingleLineCell simple

<SingleLineCell>
  <ComponentGroup gap="4px">
    <Image ... /><Date ... /><Time ... />
  </ComponentGroup>
</SingleLineCell>

<SingleLineCell>
  <ComponentGroup gap="6px">
    <Icon ... /><Text ... /><Icon ... />
  </ComponentGroup>
</SingleLineCell>

This ComponentGroup component will be completely generic.

[DanishAli-Reapit]

@ksolanki7 any feedback from you?

[kurtdoherty]

@DanishAli-Reapit Ah, I see where the confusion is. My suggestion is only to handle the layout of a "media item" (e.g. avatar or image) consistently, not necessarily an icon. There's nothing stopping an icon or other visual element being supplied via children if that's what the consumer needs, we're just supporting the avatar/image layout as a first-class concern, just like we are with the double line cell.

Re ComponentGroup, I don't really see the value sorry, and the way you show it being used will still result in gaps being place between each DOM element rendered by the children, which is not necessarily what a consumer will want.

Our alternative is to do nothing for now and just wait and see how Design use SingleLineCell in practice. In future, if we see designs where there's an avatar + single line and consumers have to space them out themselves, we can implement first-class support for it. They may never do that in practice though.

[ksolanki7]

@DanishAli-Reapit I have raised a couple of queries about DS Figma to better understand it before I provide any further feedback. Once I hear from the DS team, I will be better positioned to provide directive feedback.

See the below links for the questions I raised with the DS team.

• https://www.figma.com/design/XJ6qcAV8gHscsUodqJMNEF?node-id=1139-8522&m=dev#1181062187
• https://www.figma.com/design/XJ6qcAV8gHscsUodqJMNEF?node-id=1139-8511&m=dev#1185212461

[ksolanki7]

@DanishAli-Reapit The DS team has now updated the Figma with the queries raised.

• No more Avatar + Single Line Cell, DS team has removed it from Figma.
• Text + Icon now in singleLineCell and doubleLineCell are aligned with same gap value.

Note: Text + Icon can be one component - Refer https://www.figma.com/design/XJ6qcAV8gHscsUodqJMNEF?node-id=1139-8476&m=dev#1189088121

[DanishAli-Reapit]

Hi @ksolanki7, I have updated my POC reflecting your suggestions.

Introduced:

1. TableText accepts children, iconLeft, iconRight, variant, and size props.
2. The avatar was removed in the SIngleLineCell component.