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

360 - Refactor Dataset Page to handle dataset ID via URL query #364

Conversation

nozomione
Copy link
Member

@nozomione nozomione commented Sep 17, 2024

Issue Number

Epic: #358

Closing #360 and #362

Feature branch: feature/epic-refactor-dataset-page-data-handling

Purpose/Implementation Notes

I've made the following changes to the dataset page and its sub-components:

  • Managed dataset data via URL query
  • Removed states for various dataset types
  • Moved the dataset status variables to sub-component level and simplify JSX
  • Added check to redirect users if dataset/id matches their My Dataset ID

Types of changes

  • Refactor (addresses code organization and design mentioned in corresponding issue)

Functional tests

N/A

Checklist

  • Lint and unit tests pass locally with my changes
  • I have added tests that prove my fix is effective or that my feature works
  • I have added necessary documentation (if appropriate)
  • Any dependent changes have been merged and published in downstream modules

Screenshots

N/A

…data structure (i.e., 'dataset') to sub-components, define dataset state variables (i.e., 'isProcessed', 'isUnprocessed') in sub-components and clean up the JSX rendering condition, in pages/dataset/[datast_id] and pages/download
…ternary in JSX, and destructure 'dataset' in DatasetSummary
@nozomione nozomione self-assigned this Sep 17, 2024
Copy link

vercel bot commented Sep 17, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
refinebio-web ✅ Ready (Inspect) Visit Preview 💬 Add feedback Oct 7, 2024 9:17pm

Copy link
Contributor

@davidsmejia davidsmejia left a comment

Choose a reason for hiding this comment

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

Wrote a couple of commnets. I'd like to improve how we distinguish between a dataset from a prop and the myDataset and when / if it matters. Let me know your thoughts on my suggestion. Otherwise the bulk of the PR looks correct to me.

@@ -79,7 +81,7 @@ export const DatasetPageHeader = ({ dataset }) => {
return (
<FixedContainer pad="none">
<Box>
{dataset?.data && (
{data && (
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we still need this check here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Could you give me feedback on this suggestion?
I think I'd like to make the following changes for consistency.

  • Keep the prop as dataset since that is the dynamic part and would match convention.
  • Instead of renaming dataset.data to datasetData always use dataset.data
  • Instead of renaming dataset.data and dataset.id from to myDatasetid and myDatasetData just rename the whole dataset to myDataset so we will always access attributes on myDataset or dataset.

In the future we may consider makeing myDataset an export of useDatasetManager but I need to review that holistically before suggesting that change.

Copy link
Member Author

@nozomione nozomione Sep 25, 2024

Choose a reason for hiding this comment

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

Thank you for these great suggestions 👍 I totally agree with keeping the prop as dataset and using dataset.data. Renaming the dataset context state to myDataset is an excellent idea for clarity and readability as well! Let’s discuss this further in our 1:1, and once we finalize the implementation strategy, we can file a new issue for it. Looking forward!

@@ -12,14 +12,14 @@ import { Modal } from 'components/shared/Modal'
import { TextInput } from 'components/shared/TextInput'

export const ShareDatasetButton = ({ dataset }) => {
const { id: datasetId } = dataset
Copy link
Contributor

Choose a reason for hiding this comment

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

Based on the outcome of my earlier comment we may want to keep dataset.id here so that it is clearer to future maintainers that any give datasetId is either from what is passed in vs myDataset and will indicate if it matters.

…mponents, and remove the conditional check for data (no longer required) in DatasetPageHader
@nozomione
Copy link
Member Author

I've applied your feedback and this PR is ready for another look. Thank you David!

…'id' and 'data' (until we rename the user-defined 'dataset' context state to 'myDataset' in a separate issue)
@nozomione
Copy link
Member Author

I've updated the naming of the user-defined dataset to myDataset at the component level. I'll file a new issue for the renaming of the dataset and datasetId context states (for user-saved data in LocalStorage) once we finalize the naming for datasetId etc.

I've also filed the issue for the getDatasetState helper which came up during our 1:1, please see #370.

This PR is now ready for your review. Thank you David!

@nozomione nozomione requested review from davidsmejia and removed request for davidsmejia September 26, 2024 19:35
const { push } = useRouter()
const { addSamples, getTotalSamples } = useDatasetManager()
const {
dataset: { id: myDatasetId, data: myDatasetData },
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
dataset: { id: myDatasetId, data: myDatasetData },
dataset: myDataset,

And then access the attributes in the same way so that it is consistent.

Comment on lines +37 to +45
const {
expires_on: expiredOn,
is_available: isAvailable,
is_processed: isProcessed,
is_processing: isProcessing,
success
} = dataset
const isExpired = moment(expiredOn).isBefore(Date.now())
const isProcessingError = success === false // 'success' may be null
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should replace this with a helper that wraps the actual meaning of these state attributes. They are not the clearest names on the API. We can't really change them very easily there because external scripts might be using them so here we should just abstract away the specifics into the actionable states.

I think you can clean this up but the important part is that logically only one of these states can be true at one #time.

  const getDatasetState = (dataset) => {

    // datasets go in the following states:
    // isNotProcessed -> isProcessing -> isReady -> isExpired
    //                              | -> isError


    // processing was attempted but an error occurred and no output was able to be created
    const isErrored = dataset.success === false

    // the dataset is still available to be edited by the token holder
    const isNotStarted = dataset.is_processing === false && dataset.is_processed === false && dataset.success === null

    // dataset is processing and has not encountered an error
    const isProcessing = dataset.is_processing && dataset.is_processed === false && dataset.success === null

    // processing completed but is no longer available
    const isExpired = dataset.is_processed && dataset.success === true && moment(dataset.expires_on).isBefore(Date.now())

    // dataset is ready to download and has not expired
    const isReady = dataset.is_processed && !isExpired


    return {
      isNotStarted,
      isProcessing,
      isReady,
      isExpired,
      isErorred,
    }
  }

Copy link
Member Author

@nozomione nozomione Oct 2, 2024

Choose a reason for hiding this comment

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

David, as chat on Slack (and noted in here as well #364 (comment)), I've filed a dedicated new issue (#370), for adding getDatasetState helper and refactoring the components that use dataset states.

This should make the review easier while keeping the file changes minimal and reducing the merge conflicts (the PR for it is also ready (#373). Thank you David!

Copy link
Contributor

@davidsmejia davidsmejia left a comment

Choose a reason for hiding this comment

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

One comment, otherwise everything else I would suggest should be handled in a future PR.

<>
<DatasetPageHeader dataset={selectedDataset} />
<Box>
{dataset?.data && (
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we can get rid of this check as well there should only be 2 states we care about. Loading and loaded. I would think that if dataset.data is undefined then loading would be true.

Copy link
Member Author

Choose a reason for hiding this comment

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

It has been cleaned up in 41e8260 👍

@nozomione nozomione deleted the branch feature/epic-refactor-dataset-page-data-handling October 7, 2024 20:53
@nozomione nozomione closed this Oct 7, 2024
@nozomione nozomione reopened this Oct 7, 2024
@nozomione nozomione merged commit f49dcc1 into feature/epic-refactor-dataset-page-data-handling Oct 7, 2024
2 checks passed
@nozomione nozomione deleted the nozomione/360-refactor-data-set-page-to-handle-dataset-id-via-url-query branch October 7, 2024 21:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants