feat: add reusable datalist component #312
Conversation
|
@Aqil-Ahmad is attempting to deploy a commit to the Hycom Team Team on Vercel. A member of the Team first needs to authorize it. |
|
/claim #305 |
|
👀 We've notified the reward creators here. |
|
@Aqil-Ahmad please run linter and fix the errors, it reports multiple issues both in the |
| <DataList | ||
| data={data.invoices.data} | ||
| getRowKey={(invoice) => invoice.id} | ||
| columns={ |
There was a problem hiding this comment.
please see if moving the columns definition out of the render (i.e. before the return) would make the code more readable - I'd like to keep the JSX part of the component quite simple if possible; this of course applies to other components as well
| return config; | ||
| }) as DataListColumnConfig<any>[] | ||
| } | ||
| actions={ |
There was a problem hiding this comment.
and perhaps let's move the actions definition out of the JSX as well - I suspect the code would be more clear this way; this also applies to other components
|
|
||
| export const WithBadges: Story = { | ||
| args: { | ||
| data: sampleTickets as any, |
There was a problem hiding this comment.
please try to avoid using any (here, but in other files too) - we'd like to have proper typings whenever possible
| /** | ||
| * Badge variant mapper function (for badge type columns) | ||
| */ | ||
| badgeVariant?: (value: any) => string; | ||
|
|
||
| /** | ||
| * Price configuration (for price type columns) | ||
| */ | ||
| priceConfig?: { | ||
| currencyKey?: keyof T; | ||
| }; | ||
|
|
||
| /** | ||
| * Link configuration (for link type columns) | ||
| */ | ||
| linkConfig?: { | ||
| hrefKey?: keyof T; | ||
| variant?: 'link' | 'default'; | ||
| className?: string; | ||
| }; | ||
| } |
There was a problem hiding this comment.
please see if we can get rid of declaring multiple optional fields here - perhaps it's possible to create a union of types, something like
interface DataListColumnCommonConfig {
// comon props
}
interface DataListColumnBadgeConfig extends DataListColumnCommonConfig {
type: 'badge';
badgeVariant: ...
}
interface DataListColumnPriceConfig extends DataListColumnCommonConfig {
type: 'price';
priceConfig: ...
}
...
type DataListColumnConfig = DataListColumnBadgeConfig | DataListColumnPriceConfig | ... | ...
this might make it easier to exactly detect the type of the column and perhaps make TS types easier to manage
|
@Aqil-Ahmad also, please provide a short feedback as per ticket description, either in a comment or better yet in the PR description: |
Thanks for the feedback! I'll fix all linting and type errors in ui and frontend. The app starts fine (login page appears), but I need to set up authentication to test the actual list components. I'll investigate the seed scripts or test user setup. |
|
@Aqil-Ahmad Ok, so the frontend app itself runs fine when you start it directly ( As for authentication, it should be already pre-configured (we have a simple sqlite database set up with prisma), you can find the credentials in our docs |
Aqil-Ahmad
force-pushed
the
feat/add-datalist-component
branch
from
3347ed4 to
fd2161c
Compare
2 participants
What does this PR do?
Related Ticket(s)
Notion: Data tables refactor (issue #305 )
Key Changes
DataList
component in packages/ui/src/components/DataList/
with typed column renderers (text, badge, date, price, link, badgeStatus, custom).
NEW DataList in:
packages/blocks/ticket-list/src/frontend/TicketList.client.tsx
packages/blocks/order-list/src/frontend/OrderList.client.tsx
packages/blocks/invoice-list/src/frontend/InvoiceList.client.tsx
packages/blocks/notification-list/src/frontend/NotificationList.client.tsx
[docs/dev] Storybook stories for DataList:
packages/ui/src/components/DataList/DataList.stories.tsx
How to test
Storybook:
npm run storybookVerify all stories render (Basic Text, With Badges, With Actions, With Price, Custom Cell Renderer, Empty State, With Custom Styling).
App test:
Login with test users:
Verify list pages render with DataList:
Feedback
The monorepo is well structured with clear separation between /packages and /apps and setup was smooth after npm install. the workspace organization made sense once explored @o2s/ui, for shared components, and @o2s/blocks, for feature modules, but understanding the relationship between framework types and block-level API harmonization took a bit of time. Overall the project is well organized and maintainable. Prettier configuration was quite strict (good for consistency tho).
Media (Loom or gif)