Skip to content

Add collection request generating function#3637

Merged
dvail merged 5 commits intomasterfrom
dv/collection-request-generating-function
Nov 4, 2022
Merged

Add collection request generating function#3637
dvail merged 5 commits intomasterfrom
dv/collection-request-generating-function

Conversation

@dvail
Copy link
Contributor

@dvail dvail commented Oct 31, 2022

Description

This PR adds a function to convert the FE Collection object to the expected BE request format CollectionRequest. This also cleans up some cruft in the type system and naming that surfaced during the conversion.

Checklist

  • Investigated and inspected CI test results
  • Unit test and regression tests added
  • Evaluated and added CHANGELOG entry if required
  • Determined and documented upgrade steps
  • Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.

Testing Performed

Unit tests added for new generateResponse function and existing parseCollection function.

@openshift-ci
Copy link

openshift-ci bot commented Oct 31, 2022

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@dvail
Copy link
Contributor Author

dvail commented Oct 31, 2022

@dvail dvail force-pushed the dv/collection-request-generating-function branch from 734834f to 3098e56 Compare October 31, 2022 18:20
@dvail dvail force-pushed the dv/ROX-12601-implement-view-mode-for-collections branch from 0905fb8 to bf65ad2 Compare November 1, 2022 14:19
@dvail dvail force-pushed the dv/collection-request-generating-function branch from 3098e56 to 3e3194e Compare November 1, 2022 14:19
@dvail dvail force-pushed the dv/ROX-12601-implement-view-mode-for-collections branch from ee2cea2 to a8ca9d0 Compare November 2, 2022 13:20
@dvail dvail force-pushed the dv/collection-request-generating-function branch from 3e3194e to fa56354 Compare November 2, 2022 13:20
@dvail dvail marked this pull request as ready for review November 2, 2022 13:48
Base automatically changed from dv/ROX-12601-implement-view-mode-for-collections to master November 2, 2022 13:51
@dvail dvail force-pushed the dv/collection-request-generating-function branch from 968b3bd to 621f668 Compare November 2, 2022 15:03
@dvail dvail requested review from bradr5 and pedrottimark November 2, 2022 15:04
@ghost
Copy link

ghost commented Nov 2, 2022

Images are ready for the commit at 6fef19d.

To use with deploy scripts, first export MAIN_IMAGE_TAG=3.72.x-476-g6fef19da3f.


if (data.resourceSelectors.length > 1) {
errors.push(
`Multiple 'ResourceSelectors' were found for this collection. Only a single resource selector is supported in the UI. Further validation errors will only apply to the first resource selector in the response.`
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you ask docs team to suggest a synonym for in the UI

return {
name: collection.name,
description: collection.description,
embeddedCollectionIds: collection.embeddedCollectionIds,
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you double check it the key is embeddedCollectionIds or embeddedCollections

https://github.com/stackrox/stackrox/blob/master/proto/storage/resource_collection.proto#L28

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 think the internal proto is different from what they will be sending/accepting at the service layer. I was basing the naming on the original BE design doc as well as following along with some of the PRs that get announced on the epic channel. It looks like for this type of request they are going with the ids version.

],
},
],
embeddedCollectionIds: ['12', '13', '14'],
Copy link
Contributor

Choose a reason for hiding this comment

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

See comment below about this property name.

Copy link
Contributor

@pedrottimark pedrottimark left a comment

Choose a reason for hiding this comment

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

Thank you for writing unit tests! A few comments.

Two observations here because independent of these changes:

  1. Do you want to include useRestQuery as discussion item for next team meeting with goal to move from src/Containers/Dashboard/hooks to src/hooks folder?
  2. What do you think are pro and con to distinguish which types correspond to payloads and responses versus which types are for rendering in form? That is, alternatives:
    • CollectionsService.ts import SelectorField from container types file?
    • first 8 lines from container types file move to CollectionsService.ts file?

@dvail
Copy link
Contributor Author

dvail commented Nov 4, 2022

1. Do you want to include `useRestQuery` as discussion item for next team meeting with goal to move from src/Containers/Dashboard/hooks to src/hooks folder?

2. What do you think are pro and con to distinguish which types correspond to payloads and responses versus which types are for rendering in form? That is, alternatives:
   
   * CollectionsService.ts import `SelectorField` from container types file?
   * first 8 lines from container types file move to CollectionsService.ts file?
  1. Agreed, that is on my personal clean up list to move that hook up. Better yet might be to reevaluate React-Query as the standard way to handle these. I know Saif used it for the ACSCS work so maybe I can get him to throw his opinion into the mix.
  2. This I'm not too sure on. There are some types that are clearly request/response oriented, and some that are clearly "in-container" oriented, but I'm not really sure where the best place to put the common bits is. Moving them into a top level src/types/collections directory seems neutral, but then splits types into three unrelated locations. I'd almost be inclined to weaken the types in the service file e.g. SelectorField -> string since we aren't doing runtime type validation anyway and the service layer types are more of a scout's honor that they are what they say they are. We have to run type guards on the response data in the parser anyway, so weakening the types might let us keep these decoupled without any loss of safety.

@dvail dvail enabled auto-merge (squash) November 4, 2022 20:30
@dvail dvail merged commit 8288028 into master Nov 4, 2022
@dvail dvail deleted the dv/collection-request-generating-function branch November 4, 2022 21:04
@pedrottimark
Copy link
Contributor

Dave, what you suggest sounds good to me:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants