Add collection request generating function#3637
Conversation
|
Skipping CI for Draft Pull Request. |
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
734834f to
3098e56
Compare
0905fb8 to
bf65ad2
Compare
3098e56 to
3e3194e
Compare
ee2cea2 to
a8ca9d0
Compare
3e3194e to
fa56354
Compare
968b3bd to
621f668
Compare
|
Images are ready for the commit at 6fef19d. To use with deploy scripts, first |
|
|
||
| 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.` |
There was a problem hiding this comment.
Can you ask docs team to suggest a synonym for in the UI
| return { | ||
| name: collection.name, | ||
| description: collection.description, | ||
| embeddedCollectionIds: collection.embeddedCollectionIds, |
There was a problem hiding this comment.
Can you double check it the key is embeddedCollectionIds or embeddedCollections
https://github.com/stackrox/stackrox/blob/master/proto/storage/resource_collection.proto#L28
There was a problem hiding this comment.
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'], |
There was a problem hiding this comment.
See comment below about this property name.
pedrottimark
left a comment
There was a problem hiding this comment.
Thank you for writing unit tests! A few comments.
Two observations here because independent of these changes:
- Do you want to include
useRestQueryas discussion item for next team meeting with goal to move from src/Containers/Dashboard/hooks to src/hooks folder? - 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
SelectorFieldfrom container types file? - first 8 lines from container types file move to CollectionsService.ts file?
- CollectionsService.ts import
|
|
Dave, what you suggest sounds good to me:
|

Description
This PR adds a function to convert the FE
Collectionobject to the expected BE request formatCollectionRequest. This also cleans up some cruft in the type system and naming that surfaced during the conversion.Collectiontype renamesresourceSelectorstoresourceSelector, since there is one a single one on the FE type, and renamesembeddedCollectionstoembeddedCollectionIdssince we are not dealing with full object instances.Checklist
If any of these don't apply, please comment below.
Testing Performed
Unit tests added for new
generateResponsefunction and existingparseCollectionfunction.