diff --git a/apps/website/screens/components/accordion/overview/AccordionOverviewPage.tsx b/apps/website/screens/components/accordion/overview/AccordionOverviewPage.tsx index 12b7e2bed..44f3c9320 100644 --- a/apps/website/screens/components/accordion/overview/AccordionOverviewPage.tsx +++ b/apps/website/screens/components/accordion/overview/AccordionOverviewPage.tsx @@ -187,119 +187,116 @@ const sections = [ ), }, + ], + }, + { + title: "Best practices", + content: ( + + To ensure a clean, efficient, and user-friendly experience, follow these best practices when designing and + implementing accordion components: + + ), + subSections: [ { - title: "Best practices", + title: "Use accordions to manage space and structure", content: ( - - To ensure a clean, efficient, and user-friendly experience, follow these best practices when designing and - implementing accordion components: - + + + Apply accordions when you need to organize large or secondary content into collapsible sections. + + + They are particularly useful for FAQs, optional content, or detailed information nested under high-level + summaries. + + + Collapsing content helps reduce scrolling and offers users control over what they choose to engage with. + + + ), + }, + { + title: "Keep headers simple and informative", + content: ( + + + Each accordion header must include a clear, concise title that describes the content inside. + + + Use a sublabel only when additional context is necessary —it should not overpower the title. + + + Avoid hiding essential or primary information inside an accordion panel. + + + ), + }, + { + title: "Limit secondary elements for clarity", + content: ( + + + Use only one secondary element per side of the header (left and right) to avoid clutter. + + + Choose either an icon or a badge for the left side, and a helper text, badge, or status light for the + right side —never more than one per side. + + + Avoid placing two elements of the same type in one header (e.g., two badges), as this reduces scannability + and can confuse users. + + + ), + }, + { + title: "Respect visual hierarchy and semantic meaning", + content: ( + + + Always prioritize the visibility of mandatory elements like the title over optional elements. + + + If both a badge and a status light are present, avoid applying semantic colors (e.g., red, green) to the + badge to prevent visual conflict with the status indicator. + + + Maintain consistency in layout and alignment to support content scanning, especially when multiple + accordion sections are used together. + + + ), + }, + { + title: "Choose the appropriate expand behavior", + content: ( + + + Use single-open behavior when content is interdependent, linear, or when space is + limited. + + + Use multi-open behavior when content is independent or when users may need to view + multiple sections at once. + + + Consider the context of use and user goals when deciding which interaction pattern is most appropriate. + + + ), + }, + { + title: "Design for mobile and accessibility", + content: ( + + + Accordions should span the full width of the screen on smaller devices for easier interaction. + + + Ensure all interactive elements are large enough to be tapped comfortably on touchscreens. + + ), - subSections: [ - { - title: "Use accordions to manage space and structure", - content: ( - - - Apply accordions when you need to organize large or secondary content into collapsible sections. - - - They are particularly useful for FAQs, optional content, or detailed information nested under - high-level summaries. - - - Collapsing content helps reduce scrolling and offers users control over what they choose to engage - with. - - - ), - }, - { - title: "Keep headers simple and informative", - content: ( - - - Each accordion header must include a clear, concise title that describes the content inside. - - - Use a sublabel only when additional context is necessary —it should not overpower the title. - - - Avoid hiding essential or primary information inside an accordion panel. - - - ), - }, - { - title: "Limit secondary elements for clarity", - content: ( - - - Use only one secondary element per side of the header (left and right) to avoid - clutter. - - - Choose either an icon or a badge for the left side, and a helper text, badge, or status light for the - right side —never more than one per side. - - - Avoid placing two elements of the same type in one header (e.g., two badges), as this reduces - scannability and can confuse users. - - - ), - }, - { - title: "Respect visual hierarchy and semantic meaning", - content: ( - - - Always prioritize the visibility of mandatory elements like the title over optional elements. - - - If both a badge and a status light are present, avoid applying semantic colors (e.g., red, green) to - the badge to prevent visual conflict with the status indicator. - - - Maintain consistency in layout and alignment to support content scanning, especially when multiple - accordion sections are used together. - - - ), - }, - { - title: "Choose the appropriate expand behavior", - content: ( - - - Use single-open behavior when content is interdependent, linear, or when space is - limited. - - - Use multi-open behavior when content is independent or when users may need to view - multiple sections at once. - - - Consider the context of use and user goals when deciding which interaction pattern is most - appropriate. - - - ), - }, - { - title: "Design for mobile and accessibility", - content: ( - - - Accordions should span the full width of the screen on smaller devices for easier interaction. - - - Ensure all interactive elements are large enough to be tapped comfortably on touchscreens. - - - ), - }, - ], }, ], }, diff --git a/apps/website/screens/components/resultset-table/ResultsetTablePageLayout.tsx b/apps/website/screens/components/resultset-table/ResultsetTablePageLayout.tsx index e244a14d8..d860d0b72 100644 --- a/apps/website/screens/components/resultset-table/ResultsetTablePageLayout.tsx +++ b/apps/website/screens/components/resultset-table/ResultsetTablePageLayout.tsx @@ -16,10 +16,8 @@ const ResultsetTablePageHeading = ({ children }: { children: ReactNode }) => { - Data table is a component with a high rate of usage within the applications. It allows to show the user a - big amount of information in a simple and simplified way. All the information contained in the table has a - grid structure, defining columns and rows to place the data and allow the users to scan, analyze, compare - and filter that information. + The resultset table is a data-rich component designed for displaying large sets of information with built-in + features like sorting, pagination, and scroll behavior to support efficient exploration and comparison. diff --git a/apps/website/screens/components/resultset-table/code/ResultsetTableCodePage.tsx b/apps/website/screens/components/resultset-table/code/ResultsetTableCodePage.tsx index 546f4d220..32fe8a20a 100644 --- a/apps/website/screens/components/resultset-table/code/ResultsetTableCodePage.tsx +++ b/apps/website/screens/components/resultset-table/code/ResultsetTableCodePage.tsx @@ -79,30 +79,55 @@ const sections = [ - - rows + + hidePaginator - Row[] -

- being Row a Cell[] and being Cell an object with the following - properties: -

- {cellTypeString} + boolean + If true, paginator will not be displayed. - An array of objects representing the rows of the table, you will have as many objects as columns in the - table. Each row is a set of cells that have the following properties: - + false + + + + itemsPerPage + + number + + Number of items per page. + + 5 + + + + itemsPerPageFunction + + {"(value: number) => void"} + + + This function will be called when the user selects an item per page option. The value selected will be + passed as a parameter. + + - + + + itemsPerPageOptions + + number[] + + An array of numbers representing the items per page options. + - + + + margin + + 'xxsmall' | 'xsmall' | 'small' | 'medium' | 'large' | 'xlarge' | 'xxlarge' | Margin + + + Size of the margin to be applied to the component. You can pass an object with 'top', 'bottom', 'left' and + 'right' properties in order to specify different margin sizes. - @@ -134,17 +159,32 @@ const sections = [ - - hidePaginator + + rows - boolean + Row[] +

+ being Row a Cell[] and being Cell an object with the following + properties: +

+ {cellTypeString} - If true, paginator will not be displayed. - false + An array of objects representing the rows of the table, you will have as many objects as columns in the + table. Each row is a set of cells that have the following properties: + + - showGoToPage @@ -156,46 +196,6 @@ const sections = [ true - - itemsPerPage - - number - - Number of items per page. - - 5 - - - - itemsPerPageOptions - - number[] - - An array of numbers representing the items per page options. - - - - - itemsPerPageFunction - - {"(value: number) => void"} - - - This function will be called when the user selects an item per page option. The value selected will be - passed as a parameter. - - - - - - margin - - 'xxsmall' | 'xsmall' | 'small' | 'medium' | 'large' | 'xlarge' | 'xxlarge' | Margin - - - Size of the margin to be applied to the component. You can pass an object with 'top', 'bottom', 'left' and - 'right' properties in order to specify different margin sizes. - - - - tabIndex diff --git a/apps/website/screens/components/resultset-table/overview/ResultsetTableOverviewPage.tsx b/apps/website/screens/components/resultset-table/overview/ResultsetTableOverviewPage.tsx index 82f18c1e5..218ca03dd 100644 --- a/apps/website/screens/components/resultset-table/overview/ResultsetTableOverviewPage.tsx +++ b/apps/website/screens/components/resultset-table/overview/ResultsetTableOverviewPage.tsx @@ -1,19 +1,170 @@ -import { DxcBulletedList, DxcFlex } from "@dxc-technology/halstack-react"; +import { DxcBulletedList, DxcFlex, DxcParagraph } from "@dxc-technology/halstack-react"; import QuickNavContainer from "@/common/QuickNavContainer"; import QuickNavContainerLayout from "@/common/QuickNavContainerLayout"; import DocFooter from "@/common/DocFooter"; +import Code from "@/common/Code"; +import anatomy from "./images/resultset_table_anatomy.png"; +import Image from "@/common/Image"; const sections = [ { title: "Introduction", + content: ( + + The resultset table component is designed for displaying large datasets with interactive features such as + sorting, pagination, and selection. Unlike the basic table component, this one offers built-in functionality + that allows users to explore and manipulate data efficiently, making it ideal for use cases like search results, + reports, or management dashboards. + + ), + }, + { + title: "Anatomy", + content: ( + <> + ResultsetTable's anatomy + + + Header row: displays the column titles and defines the data categories for the table. It + also includes optional sorting icons to help users organize content. + + + Cell: represents an individual data point within the table. Cells are aligned with the + header columns and typically show text, numbers, or icons. + + + Sorting icon: indicates whether a column is sortable and shows the current sorting + direction (ascending or descending). Appears next to the header label when sorting is enabled. + + + Row: Represents a single entry in the dataset. Each row groups related cells and can + respond to user interactions like selection or hover. + + + Scrollbar: allows horizontal and vertical navigation when the table's content exceeds the + visible area. It ensures accessibility for large datasets. + + + Paginator: provides controls to navigate through multiple pages of results. It helps manage + large sets of data by splitting them into manageable views. + + + + ), + }, + { + title: "Using resultset tables", + content: ( + + The resultset table is intended for scenarios where users need to work with dynamic or high-volume data. Here + are key aspects to keep in mind: + + ), + subSections: [ + { + title: "Sorting and filtering", + content: ( + + Resultset tables support client-side or server-side sorting, which allows users to reorganize the data by + column. Use this feature to improve discoverability and simplify decision-making. + + ), + }, + { + title: "Pagination", + content: ( + + Built-in pagination controls prevent overwhelming the user with too much data at once and help maintain + performance. Choose the pagination strategy depending on your backend setup. + + ), + }, + { + title: "Row selection", + content: ( + + Users can select one or multiple rows to perform bulk actions. Use checkboxes for multi-selection and radio + buttons for single-selection. Selected rows can persist across pages if needed. + + ), + }, + { + title: "Action column", + content: ( + + Resultset tables can include an action column where users can perform row-level actions (e.g., edit, delete, + view details). This column should remain consistent across rows to maintain usability. + + ), + }, + { + title: "Custom content and responsiveness", + content: ( + + Cells can contain more than just text: icons, buttons, or status indicators are supported. However, maintain + clarity and avoid overloading. The layout can adapt to different screen sizes with horizontal scroll if + necessary. + + ), + }, + { + title: "Virtualization", + content: ( + + For very large datasets, virtualization improves performance by rendering only the visible rows within the + viewport, significantly reducing DOM load and enabling smooth scrolling. To enable virtualization, the{" "} + height prop must be set to a valid value on the resultset table. This defines the scrollable + area and allows the table to calculate which rows should be rendered dynamically. + + ), + }, + { + title: "Accessibility", + content: ( + + The resultset table is fully keyboard navigable and screen-reader friendly. Ensure all custom content also + follows accessibility guidelines. + + ), + }, + ], + }, + { + title: "Best practices", content: ( - Use the table component to compare information in rows and columns. - Every table cell requires a logical column header/row header. - Don't use the table for create visual layout of the content of a page. + Use the resultset table when displaying large sets of interactive data: it is ideal for + workflows where users need to search, sort, or take action on rows. + + + Limit the number of columns to what is strictly necessary. Too many columns can make the + table hard to read and navigate. + + + Keep cell content focused: if you need to include actions or visuals, make sure they serve a + purpose and don't clutter the interface. + + + Do not place more than one or two actions per row. If additional actions are needed, consider + using a dropdown or context menu. + + + Label all interactive elements inside the table properly. This improves accessibility and + helps users understand the functionality. + + + Use consistent patterns across all rows. Keep the structure and interaction model predictable + to support learnability. + + + Optimize performance by using pagination, enabling virtualization and minimizing real-time + rendering when working with large datasets. + + + Adapt for responsiveness. If the table is used in narrow viewports, allow horizontal + scrolling or collapse less relevant columns. - Avoid truncating content, wrap instead. ), }, diff --git a/apps/website/screens/components/resultset-table/overview/images/resultset_table_anatomy.png b/apps/website/screens/components/resultset-table/overview/images/resultset_table_anatomy.png new file mode 100644 index 000000000..4ad897af5 Binary files /dev/null and b/apps/website/screens/components/resultset-table/overview/images/resultset_table_anatomy.png differ diff --git a/apps/website/screens/components/table/TablePageLayout.tsx b/apps/website/screens/components/table/TablePageLayout.tsx index ca1e32491..c6cddad05 100644 --- a/apps/website/screens/components/table/TablePageLayout.tsx +++ b/apps/website/screens/components/table/TablePageLayout.tsx @@ -16,10 +16,7 @@ const TablePageHeading = ({ children }: { children: ReactNode }) => { - Data table is a component with a high rate of usage within the applications. It allows to show the user a - big amount of information in a simple and simplified way. All the information contained in the table has a - grid structure, defining columns and rows to place the data and allow the users to scan, analyze, compare - and filter that information. + Tables allow users to show a big amount of information in a easy and simplified way. diff --git a/apps/website/screens/components/table/overview/TableOverviewPage.tsx b/apps/website/screens/components/table/overview/TableOverviewPage.tsx index f4c1f5106..02d242bc2 100644 --- a/apps/website/screens/components/table/overview/TableOverviewPage.tsx +++ b/apps/website/screens/components/table/overview/TableOverviewPage.tsx @@ -1,18 +1,161 @@ -import { DxcParagraph, DxcFlex } from "@dxc-technology/halstack-react"; +import { DxcParagraph, DxcFlex, DxcBulletedList } from "@dxc-technology/halstack-react"; import QuickNavContainer from "@/common/QuickNavContainer"; import QuickNavContainerLayout from "@/common/QuickNavContainerLayout"; import DocFooter from "@/common/DocFooter"; +import Image from "@/common/Image"; +import anatomy from "./images/table_anatomy.png"; const sections = [ { title: "Introduction", content: ( - The Table component is a powerful and flexible tool for displaying tabular data in a structured format. It - allows users to present information in rows and columns, making it easy to read and analyze large datasets. + The table component provides a lightweight and accessible way to{" "} + display structured data in rows and columns. It is ideal for presenting small to medium-sized + datasets that don't require complex interactions such as in-line editing or row expansion. The component + supports different table densities and content types, ensuring clarity and visual consistency across use cases + like summary lists, comparison views, or static reports. Unlike the datagrid or resultsate table component, our + table is designed for non-complex scenarios where the priority is clear data display over + advanced functionality. ), }, + { + title: "Anatomy", + content: ( + <> + Table's anatomy + + + Header row: defines the label for each column and helps users understand the structure and + meaning of the data presented. It can also include sorting controls when applicable. + + + Cell: displays the individual content within the table. + + + Action cell: contains interactive elements such as buttons or icons that allow users to + perform specific actions related to that row. + + + + ), + }, + { + title: "Using tables", + content: ( + + The table component is designed for clear and structured data presentation, with minimal interactivity and a + strong focus on readability. Below are key aspects to keep in mind when using this component: + + ), + subSections: [ + { + title: "Layout and content", + content: ( + <> + + Tables are best suited for displaying moderate amounts of data with consistent structure. + Each column should represent a single data type or category, while each row corresponds to a data entry. + Keep content concise to avoid horizontal scrolling and ensure legibility. + + + ), + }, + { + title: "Responsiveness", + content: ( + + While the table is not responsive by default, content can be adjusted to fit smaller + screens using wrapping text, truncation, or custom scroll containers. If your use case involves extensive + data manipulation or mobile-first design, consider using the datagrid instead. + + ), + }, + { + title: "Text alignment and formatting", + content: ( + + Align text consistently within columns based on content type: left-align text, right-align numbers, and + center-align icons or action buttons. + + ), + }, + { + title: "Styling and density", + content: ( + + The component supports different visual densities to adapt to the use case. Use higher + density for data-heavy views where space is limited, and lower density for overviews or summary pages where + clarity takes priority. + + ), + }, + { + title: "Table vs ResultsetTable", + content: ( + <> + + While both components present structured data in tabular format, their purposes and features are + different: + + + + Table is a lightweight component intended for static data. It doesn't + include interaction features such as sorting or pagination. It's ideal for small datasets or summary + views where simplicity and clarity are the main goals. + + + Resultset table, on the other hand, is a more advanced component built for dynamic + datasets. It includes support for pagination, sorting, and density control. It's best suited for result + views where users need to browse through large volumes of data efficiently, such as search results or + query outputs. + + + + Choose between them based on your needs: use the table for simple data display, and the resultset table + for user-driven exploration of data. + + + ), + }, + ], + }, + { + title: "Best practices", + content: ( + + + Use the table component for structured, static data that doesn't require user interaction, + such as summaries, configuration overviews, or comparison tables. + + + Keep content concise and scannable: avoid long text blocks inside cells to preserve + readability and prevent layout issues. + + + Maintain a clear visual hierarchy by using appropriate text styles for headers, totals, and + other relevant indicators. + + + Ensure alignment consistency: text should be left-aligned, numbers right-aligned, and icons + or controls centered, depending on their function. + + + Use a maximum of two or three actions per cell: avoid overcrowding cells with multiple + buttons or icons to maintain clarity and avoid interaction confusion. + + + Use density thoughtfully: apply higher density when screen real estate is limited, and lower + density when space allows for better readability. + + + Avoid using this component for large, interactive datasets. For those scenarios, opt for the + resultset table or datagrid instead. + + + ), + }, ]; const TableOverviewPage = () => ( diff --git a/apps/website/screens/components/table/overview/images/table_anatomy.png b/apps/website/screens/components/table/overview/images/table_anatomy.png new file mode 100644 index 000000000..84b5597c2 Binary files /dev/null and b/apps/website/screens/components/table/overview/images/table_anatomy.png differ