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

feat(ui-react-storage): add loadingElement to StorageImage #6448

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

aadimch
Copy link

@aadimch aadimch commented Mar 21, 2025

Description of changes

Currently, when using StorageImage, the user would see the fallback text while the image is still being fetched. The issue is more prominent when the network is throttled.

This PR adds an loadingElement to StorageImageProps and uses the loading state exposed by useGetUrl and returns the loadingElement when loading, if provided.

Issue #6254

Description of how you validated changes

Checklist

  • Have read the Pull Request Guidelines
  • PR description included
  • yarn test passes and tests are updated/added
  • PR title and commit messages follow conventional commit syntax
  • If this change should result in a version bump, changeset added (This can be done after creating the PR.) This does not apply to changes made to docs, 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.

Sorry, something went wrong.

@aadimch
Copy link
Author

aadimch commented Mar 21, 2025

Previous PR

Comment on lines 105 to 107
if (isLoading && loadingElement !== undefined) {
return loadingElement;
}
Copy link
Member

Choose a reason for hiding this comment

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

Leaning towards returning null if isLoading is true and no loadingElement is provided. What do you think @dbanksdesign

Copy link
Author

@aadimch aadimch Mar 25, 2025

Choose a reason for hiding this comment

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

I would like to add that if we plan to return null if isLoading is true, we do similar to what I had in the previous PR.

if (isLoading) {
    return <View style={{ ...style }}></View>;
 }

Returning null will cause an layout shift in user application, whereas if a user provides an style with fixed width and height, this will not cause an layout shift even if the loadingElement is not present.

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 the PR is good as is. The customer could pass null to loadingElement and it would effectively work the way you are describing @calebpollman ?

Copy link
Member

Choose a reason for hiding this comment

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

That's true @dbanksdesign. My concern here is that existing consumers will still have the issue that this PR is meant to address as there is no default loadingElement

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Copy link

changeset-bot bot commented Mar 25, 2025

⚠️ No Changeset found

Latest commit: 93bc7db

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

calebpollman and others added 2 commits March 26, 2025 10:39

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
@@ -27,6 +27,27 @@ Storage Browser for Amazon S3 is an open source component that you can add to yo

End users work with S3 _locations_ within the Storage Browser interface. _Locations_ are S3 buckets or prefixes that you authorize end users to access using Amazon S3 Access Grants or Identity and Access Management (IAM) policies, depending on your use case. When the Storage Browser component is first rendered, it will show the LocationsView which displays only the locations you have granted them access to. Once an end user has selected a location, they can browse the S3 bucket or prefix, and all the data contained further down the S3 resource path, but they cannot browse buckets or prefixes higher up the S3 resource path.

## Quick start
Copy link
Member

Choose a reason for hiding this comment

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

This diff should already be merged to main. Not sure why it eixsts here

@@ -11,7 +11,7 @@
"dependencies": {
"@aws-amplify/ui-react": "^6.1.0",
"react": "^18.3.0",
"next": "^14.2.21",
"next": "^14.2.25",
Copy link
Member

Choose a reason for hiding this comment

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

This diff is from other PR as well. Can you rebase your PR?

Copy link
Author

Choose a reason for hiding this comment

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

Thank you, I will do them once this conversation is resolved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants