Amplify-js: [RFC]: Amplify Storage UI Component Refactor

Created on 17 Jun 2020 · 3Comments · Source: aws-amplify/amplify-js

This issue is a Request For Comments (RFC). It is intended to elicit community feedback regarding a proposed change to the Amplify JS UI components. Please feel free to post comments or questions here.

Background:

The Phase 1 of Amplify UI components refactor was completed around March 2020 where we refactored existing codebase into newer web components that would bring parity for all Auth UI components across different frameworks. You can read more about the project in the RFC here. As mentioned in the previous RFC, we are starting Phase 2 of UI component refactor.

The first milestone of Phase 2 is to refactor Amplify Storage UI components. This RFC is intended to collect feedback on the proposed changes to these components.

Current state of Amplify Storage Components:

Amplify Storage UI components provides a convenient way of using AWS S3 for managing different types of data in an UI application. The existing storage UI components are S3Image, S3Text, S3Album.

The Problem:

The problems for the need of the refactor still remains the same as initial RFC.

Lack of feature-parity across frameworks
Duplication of code logic and developer efforts
Divergent design patterns
Ramp up for learning and maintaining multiple frameworks
Inconsistent interaction and styling across frameworks
Decreased developer velocity in creating new components
Limited customizability of components

Additionally, specific to storage category, since each of the storage components is tightly coupled with a pickerprop causing ambiguity to use them. Depending on the picker prop's value, the other properties of these component behave differently. For instance, in the S3Image component, if the picker is not set, imgKey or path prop is used as the S3 file path to get the image from the bucket. But if the picker prop is set, then the path prop is used as the S3 file path prefix along with sanitized filename of the local file to upload and get the image.

If picker prop is not set,
- For download, imgKey or path prop is used as the S3 file path to get the image.
- For upload, body prop along with imgKey or path is used as the S3 file path to upload and get the image.
If picker prop is set, placeholder image is rendered until the user pick an image
- For upload and download, the path prop is used as the S3 file path prefix along with sanitized filename of the picked local file.

The Proposed Solution:

We plan to address these issues by simplifying existing component and adding new components.

_Milestone 1 of Storage Refactor:_

For this milestone, we are planning to modify the 3 storage component - S3Image, S3Text by splitting each of them into two components - A core component and its picker counterpart. S3Album will be modified to support only image file type.

S3Image

S3Image will be split into amplify-s3-image and amplify-s3-image-picker. amplify-s3-image component will deal with uploading an image into s3 bucket and rendering an image. amplify-s3-image-picker will provide a customizable image file picker component and uploads the image to S3.

S3Text

S3Text will be split into amplify-s3-text and amplify-s3-text-picker. amplify-s3-text component will deal with uploading of a text file into s3 bucket and rendering the text in a pre tag. amplify-s3-text-picker will use amplify-s3-text along with a text file picker component.

S3Album

S3Album component, given a path prop, will render all images from the specified S3 file path in an image grid. With the picker enabled, it will restrict uploading content type to image and render it into the image grid.

Additional improvements would be

Themability and Style customization using CSS custom properties
I18N support
Responsive and Accessible UI

_Milestone 2 of Storage Refactor:_

In this milestone we will add new components for primitive S3 functionalities such as upload, download and preview any S3 supported file type.

Basic design - (Rough Draft):

Design Requirements:

This remains the same as the UI refactor RFC.

Components should be useable within our currently supported browser-based frameworks (React, Angular, Vue) with little-to-no friction for developers using Amplify JS. This could conceivably entail the creation of framework-specific wrappers for the components, but at this time it is thought that Stencil generated web components should suffice.
Components must be functional within other web components, UI frameworks, and plain HTML/JS pages.
This project should offer feature parity with the sum of functionality between our existing UI packages; in other words, developers currently operating within a given framework should not find that they have lost capabilities upon migration.
Components should be responsive.
Components should be customizable and themeable. For example, users of an 'Authenticator' component should be able to define their 'Sign-In' child component which uses their own markup and styling, but which seamless integrates with the out-of-the-box behavior of the Authenticator.
All efforts should be taken to maintain as small a bundle size as possible.
Components should be Typescript-compatible with well-defined and understandable typings.
Components must be compatible with AWS supported browsers.
SSR (Server Side Rendering) of Amplify UI components should be supported

Related Github Issues:

Thank you!

The feedback that you all give is extremely helpful and gives us a better understanding of what people want us to build. If anyone would like to contribute ideas to what components you’d like to see added in the future please post it in this RFC.!

Amplify UI Components Storage feature-request

Source

ashika01

👍7 🎉4 🚀3

Most helpful comment

Hello everyone,

We have launched Phase 1 of Storage components 🚀🚀 As mentioned in the RFC, we have introduced the following components that has the functional parity with existing ones as part of Phase 1.

amplify-s3-image
amplify-s3-image-picker
amplify-s3-text
amplify-s3-text-picker
amplify-s3-album

These new components should enable better customizability and flexibility on usage

I18N support for all text within the components
Styling can be done using CSS custom properties both brand level (root) as well as component level
Responsive UI

The storage components should be available now in the latest version

| Framework | Package | Version |
| ------------------ | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| React | @aws-amplify/ui-react | |
| Angular | @aws-amplify/ui-angular | |
| Vue | @aws-amplify/ui-vue | |
| Web Components | @aws-amplify/ui-components | |

Docs:

_Docs for the usage of the components in your app_ - https://docs.amplify.aws/ui/storage/s3-image/q/framework/react
_Migration Docs_ - https://docs.amplify.aws/ui/storage/s3-image/q/framework/react#migration

Thank you

The feedback that you all give is extremely helpful and gives us a better understanding of what people want us to build. Go ahead and try out the new component libraries and let us know what you think. Feel free to open up FR for improvements and any issues you find, we are actively looking to improve the UI components.

ashika01 on 10 Jul 2020

👍2

All 3 comments