-
Notifications
You must be signed in to change notification settings - Fork 308
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
feature(multi-bucket): add multi-bucket support to storage components #5562
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: b2349b1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
@@ -12,6 +12,15 @@ import { | |||
} from './ui'; | |||
import { StorageManagerDisplayText, PathCallback, UploadTask } from './utils'; | |||
|
|||
interface BucketInfo { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: should we share this type between components?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that makes sense to me. It didn't seem substantial enough to create a new shared types file for storage components, so I went with the definition in the Storage Manager types. There are already exported types and interfaces in that file, and none aside from props in Storage Image types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just import and extend FileUploaderProps
in the assignment of StorageManagerProps
and dedupe this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you suggesting the removal of this file and providing its exports from FileUploader types? Or reducing StorageManagerProps
to export interface StorageManagerProps extends FileUploaderProps {}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keeping this file and doing the latter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Thanks for the clarification
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated file to extend FileUploaderProps
instead of duplicating type declaration
<FileUploader | ||
acceptedFileTypes={['image/*']} | ||
bucket={{ | ||
bucketName: 'my-bucket-96e87892835c413e9963f3004a44e1ff', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: this is not an actual bucket name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a note so we don't wonder about that later, or make it more obvious like "my-bucket-xxxxxxx"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I like going with "my-bucket-xxxxxxxx"
@@ -170,6 +170,27 @@ describe('StorageImage', () => { | |||
); | |||
}); | |||
|
|||
it('should pass bucket to getUrl when supplied', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: we're not duplicating the testing of the functionality of the API supporting this, so this test is just confirming that the "bucket" property is successfully passed from the component to the API in the expected format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! Minor feedback, might make sense to add a FileUploader
example app as well imo
import { StorageBucket } from '../../types'; | ||
import { FileStatus } from '../../types'; | ||
import { FileUploaderProps } from '../../types'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These can be consolidated to a single import statement (same with the '../../utils' imports)
/** | ||
* Component overrides | ||
*/ | ||
bucket?: never; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The jsdoc description on lines 80-82 is for components
, would define bucket
last on the interface since there is no documentation for it on this interface
@@ -60,6 +60,7 @@ describe('getInput', () => { | |||
const expected: UploadDataWithPathInput = { | |||
data: file, | |||
options: { | |||
bucket: undefined, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to add explicit bucket: undefined
to the test inputs in this file?
@@ -36,6 +38,7 @@ export interface StorageImageProps extends Omit<ImageProps, 'src'> { | |||
|
|||
type OmittedPropKey = | |||
| 'accessLevel' | |||
| 'bucket' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think the intention of the omission would be clearer if documented the same way as path
/** | ||
* S3 bucket key, allows either a `string` or a `PathCallback`: | ||
* - `string`: `path` is prefixed to the file `key` for each file | ||
* - `PathCallback`: callback provided an input containing the current `identityId`, | ||
* resolved value is prefixed to the file `key` for each file | ||
*/ | ||
bucket?: StorageBucket; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The description here is for the path
prop 😅
Description of changes
Changes:
<StorageImage />
and<StorageManager />
.StorageBucket
object containing the bucket name generated on S3 and the region it exists inIssue #, if available
N/A
Description of how you validated changes
Checklist
yarn test
passes and tests are updated/addeddocs
,e2e
,examples
, or other private packages.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.