refactor: new sdk frontend code refactor part 4

[martin-trajanovski]

Description

Short description of the pull request

Motivation

Background on use case, changes needed

Fixes:

Please provide a list of the fixes implemented in this PR

• Items added

Changes:

Please provide a list of the changes implemented by this PR

• changes made

Tests included

• Included for each change/fix?
• Passing? (Merge will not be approved unless this is checked)

Documentation

• swagger documentation updated [required]
• official documentation updated [nice-to-have]

official documentation info

If you have updated the official documentation, please provide PR # and URL of the pages where the updates are included

Backend version

• Does it require a specific version of the backend
• which version of the backend is required:

Summary by Sourcery

Refactor the frontend code to improve type safety and alignment with the backend by replacing DatasetClass with OutputDatasetObsoleteDto and JobClass with CreateJobDto. Remove incorrect type assertions and use JSON.stringify for parameters in effects. Update package dependencies to the latest versions.

Enhancements:

• Refactor dataset effects to improve type safety and error handling by removing incorrect type assertions and using JSON.stringify for parameters.
• Update dataset actions to use OutputDatasetObsoleteDto instead of DatasetClass for better type alignment with the backend.
• Refactor proposal effects to improve type safety and remove unnecessary type assertions.
• Refactor sample effects to improve type safety and remove incorrect type assertions.
• Refactor job effects to improve type safety and remove unnecessary type assertions.
• Refactor policy effects to improve type safety and remove unnecessary type assertions.
• Refactor logbook effects to improve type safety and remove unnecessary type assertions.
• Refactor published data effects to improve type safety and remove unnecessary type assertions.
• Refactor user effects to improve type safety and remove unnecessary type assertions.
• Refactor dataset reducers to improve type safety by removing incorrect type assertions.
• Refactor dataset selectors to improve type safety by removing incorrect type assertions.
• Refactor dataset components to use OutputDatasetObsoleteDto instead of DatasetClass for better type alignment with the backend.
• Refactor proposal components to use OutputDatasetObsoleteDto instead of DatasetClass for better type alignment with the backend.
• Refactor sample components to use OutputDatasetObsoleteDto instead of DatasetClass for better type alignment with the backend.
• Refactor job components to use CreateJobDto instead of JobClass for better type alignment with the backend.
• Refactor logbook components to use Logbook type for better type alignment with the backend.
• Refactor policy components to improve type safety and remove unnecessary type assertions.
• Refactor shared services to use OutputDatasetObsoleteDto instead of DatasetClass for better type alignment with the backend.
• Refactor state management to improve type safety and remove unnecessary type assertions.

Chores:

• Update package.json to use @scicatproject/scicat-sdk-ts version 4.6.5 and @types/lodash-es version 4.17.12.

[sourcery-ai]

Hey @martin-trajanovski - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider splitting large refactoring PRs like this into smaller, more focused changes to make review easier - while this one is cohesive enough to be acceptable, smaller PRs reduce review burden

Here's what I looked at during the review

• 🟡 General issues: 1 issue found
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟡 Complexity: 1 issue found
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): Initialize the job object properly to avoid potential runtime errors

The job object is declared but not initialized. Consider using an object literal to properly initialize all required fields of CreateJobDto.

[sourcery-ai]

issue (complexity): Consider centralizing JSON serialization logic in the service layer rather than scattering it across effects

The scattered JSON.stringify() calls throughout the effects make the code harder to maintain. Consider moving JSON serialization into the service layer:

// In DatasetsService:
datasetsControllerFullquery(limits: any, query: any) {
  return this.http.post<Dataset[]>(
    `${this.baseUrl}/Datasets/fullquery`, 
    { 
      limits: JSON.stringify(limits),
      query: JSON.stringify(query)
    }
  );
}

// Then effects become cleaner:
fetchDatasets$ = createEffect(() => {
  return this.actions$.pipe(
    // ...
    mergeMap(({ query, limits }) =>
      this.datasetsService
        .datasetsControllerFullquery(limits, query)
        .pipe(
          map((datasets) => fromActions.fetchDatasetsCompleteAction({ datasets })),
          catchError(() => of(fromActions.fetchDatasetsFailedAction())),
        ),
    ),
  );
});

This centralizes the serialization logic in the service layer where the API is called, making the effects simpler and more consistent.

[nitrosx]

I would use the field id, which is consistent with the data model.

[martin-trajanovski]

Yes I see this but in the backend we are not exposing the id as @ApiProperty in the response we only have _id defined and I wasn't sure if this was by purpose or we need to fix it.

[martin-trajanovski]

I have checked that we don't even have the id property in the datablock schema in the backend. Here it is defined: https://github.com/SciCatProject/scicat-backend-next/blob/master/src/datablocks/schemas/datablock.schema.ts#L26. So maybe this is a bigger issue to address on the backend and define it. But we will need a database migration as well to copy the _id field to the new id as well and expose it.