Skip to content
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

[DCJ-741] refactor dataset table into two dataset and studies table #2691

Merged
merged 7 commits into from
Oct 22, 2024

Conversation

s-rubenstein
Copy link
Contributor

Addresses

  • Splits the collapsing table into two tables, studies and datasets

Summary

  • I added typing to the table, and abstracted it out into its own components
  • I added optional tooltips if the text overflowed, rather than expanding the rows - this reduces screen jitter.
Screen.Recording.2024-10-16.at.4.15.47.PM.mov

Have you read Terra's Contributing Guide lately? If not, do that first.

  • Label PR with a Jira ticket number and include a link to the ticket
  • Label PR with a security risk modifier [no, low, medium, high]
  • PR describes scope of changes
  • Get a minimum of one thumbs worth of review, preferably two if enough team members are available
  • Get PO sign-off for all non-trivial UI or workflow changes
  • Verify all tests go green
  • Test this change deployed correctly and works on dev environment after deployment

@s-rubenstein s-rubenstein requested a review from a team as a code owner October 17, 2024 19:18
@@ -104,7 +104,7 @@ const DataRows = ({rowData, baseStyle, columnHeaders, rowWrapper = ({renderedRow
let output;
//columnHeaders determine width of the columns,
//therefore extract width from columnHeader and apply to cell style
const columnWidthStyle = columnHeaders[cellIndex].cellStyle;
const columnWidthStyle = { width: columnHeaders[cellIndex].cellStyle.width };
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know where to check where this was used - but I was noticing we said we were extracting just the width, but actually pulling everything. I figured this would be cleaner.

history.push(`/dar_application/${darDraft.referenceId}`);
};

const clearSearchRef = () => {
searchRef.current.value = '';
filterHandler(null, datasets, '', '');
};

const openTranslatedDUL = (dataUse) => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was unused in the new version - I figure we can add it back if need be. Not sure because I didn't see dataUse in the mocks: https://www.figma.com/design/MkffpVbUdP4lWvkN9OWiro/Data-Library?node-id=23-43&node-type=frame

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed - I'm usually in favor of aggressive pruning, it's easy enough to re-add. Especially for anything related to data use translations, we have some very inefficient code related to that functionality. If we do need it, we need to re-evaluate how we do it.

@@ -463,14 +248,6 @@ export const DatasetSearchTable = (props) => {
}
</Box>
</Box>
{
showTranslatedDULModal &&
<TranslatedDulModal
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why did this go away?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It wasn't used - I don't know if the new mocks have it or not, but I figure we can always readd it if need be

updateUser: UserTerm;
dac: DacTerm;
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to hear more about the design of your approach. I'm wondering about the distinctions between this file and the constants file. Additionally, I'm wondering about the abstraction to the Display file.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall, this looks great and the video looks good, just looking for a bit more info for my understanding!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rjohanek great question! The goal was to break up and separate concerns. Previously, the DatasetSearchTable handled a lot - I wanted to reduce what it handled. The first abstraction was to pull out the table. Eventually I thought pulling out the constants would be nice as well, so DatasetSearchTableDisplay just handled the rendering of the table, and DatasetSearchTableConstants handled the constant values describing the rendering.

model.ts is specifically the type definitions of the API responses, and doesn't include any scope beyond that.

@rushtong

This comment was marked as resolved.

@rushtong

This comment was marked as resolved.

@s-rubenstein
Copy link
Contributor Author

Got it. I'll merge it in!

@s-rubenstein
Copy link
Contributor Author

Screen.Recording.2024-10-18.at.2.08.46.PM.mov

Copy link
Contributor

@rushtong rushtong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some really nice UX improvements here. We need to circle back and figure out where the export to TDR functionality fits now - I don't think it's in the mocks, but it is in the original version of the data library. I'm open to re-implementation in a different way if we can make that a priority.

src/components/Tooltips.tsx Outdated Show resolved Hide resolved
history.push(`/dar_application/${darDraft.referenceId}`);
};

const clearSearchRef = () => {
searchRef.current.value = '';
filterHandler(null, datasets, '', '');
};

const openTranslatedDUL = (dataUse) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed - I'm usually in favor of aggressive pruning, it's easy enough to re-add. Especially for anything related to data use translations, we have some very inefficient code related to that functionality. If we do need it, we need to re-evaluate how we do it.

src/components/data_search/DatasetSearchTable.jsx Outdated Show resolved Hide resolved
Copy link
Contributor

@fboulnois fboulnois left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After all the improvements this looks great! Thank you 👍

src/components/data_update/DatasetUpdate.jsx Outdated Show resolved Hide resolved
Copy link
Contributor

@rjohanek rjohanek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good! thanks for the changes and explanations

@s-rubenstein s-rubenstein merged commit 746abfc into develop Oct 22, 2024
9 checks passed
@s-rubenstein s-rubenstein deleted the sr/dcj-741-refactor-dataset-table branch October 22, 2024 14:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants