-
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
137 - Files table UI [2/2] - Filters #147
Conversation
…m/IQSS/dataverse-frontend into feature/137-files-table-filters-ui
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 code looks really good!
I have left a couple of comments with some details.
...es/design-system/src/lib/components/dropdown-button/dropdown-separator/DropdownSeparator.tsx
Show resolved
Hide resolved
{ tag: new FileTag('document'), count: 5 }, | ||
{ tag: new FileTag('code'), count: 10 } | ||
] | ||
} // TODO (filesCountInfo) - Get from use case, pending to be discussed if this is going to have its own use case or not |
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.
Let's discuss about this to decide how to implement the use case logic before accepting this PR.
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.
My personal preference is getting the filesCountInfo from the getDataset use case. Just because I think that having another use case will increase the time for opening a dataset view. But let me know what you think so I can implement it
…m/IQSS/dataverse-frontend into feature/137-files-table-filters-ui
Yep, I know, the functionality is implemented and there are tests to check that the filters are not shown when there are no files, but since I have the variable We can decide now if we want to get filesCountInfo from its own use case or if we prefer to get it from an existing use case, and then the storybook mock would display correctly the no files state. My personal preference is getting the filesCountInfo from the getDataset use case. Just because I think that having another use case will increase the time for opening a dataset view. But let me know what you think so I can implement it @GPortas |
Let's consider a separate use case for files count (by datasetId and datasetVersionId, just as for the GetDatasetFiles use case). It's not just counting all the files in the dataset, but we also need to get counts by type, access, and tags. These different counts will end up in different queries, which I don't think is appropriate to run from the getDataset API endpoint and use case, as they would add too much file-specific logic to the operation, which would also worsen performance. |
@GPortas new use case implemented! |
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 good to me!
137 - Files table UI [2/2] - Filters
What this PR does / why we need it:
This PR adds the UI of the Files Table filters (no backend)
Which issue(s) this PR closes:
Special notes for your reviewer:
This is only the UI, no backend connected yet
I had to do some changes to the design system, in order to apply some styles to the Dropdown component.
In Bootstrap there is no variant for the Dropdown as a Link, so I had to use the "secondary" variant for the filters
Suggestions on how to test this:
npm i
cd packages/design-system && npm run build
npm run storybook
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
Is there a release notes update needed for this change?:
Added filters selectors to the Files Table
Additional documentation: