We identified some usability problems in the interface of the block, the goal of this ticket is to humanise it and narrow the usage to the use cases that we will find in Plone, making it more intuitive and usable with the current patterns. Also provide documentation and tools (StoryBook) for allowing other developers to learn how to use the component under any use case below.
We have the component that @davisagli wrote to adapt some of these use cases.
We should provide a better interface to the component:
<Image
src={}
alt=""
loading="lazy"
????
/>
for all the use cases below, provide a way of instantiate it. Having a basic StoryBook for covering all use cases would be amazing too. Proper documentation of the use cases as well.
We can identify, basically two use cases, based in the image source and nature. Also some derived use cases.
Catalog data coming from a block schema
This happens when the content has been saved in a block for caching purposes or as a reference to the original content (eg. image or teaser block). The data could be refreshed via a block serializer from the backend.
We take some assumptions for granted:
We use the ObjectBrowser to establish the relation and save the reference.
In the ObjectBrowser we save the catalog data image_scales and image_field
Then the component should fallback to use only the provided image URL.
TODO: decide how we get this, and which property do we should use
Image data does not have blurhash
Could be that we do not provide blurhash data. The component should detect this and adapt and fallback to not use it at all.
Image data is external
Could be that the image provided is external to the service. The component should detect this and adapt and fallback to not use it at all.
TODO: How does the instantiation should like then? src prop?
Direct data coming from the serialization of a content type
This happens when the content has been requested somehow and the data comes directly from waking up the object and has been directly serialized and it's fresh from the backend.
In a content type (does not have to be an Image type), there are image fields that serialize from the default content request like:
Problem
We identified some usability problems in the interface of the block, the goal of this ticket is to humanise it and narrow the usage to the use cases that we will find in Plone, making it more intuitive and usable with the current patterns. Also provide documentation and tools (StoryBook) for allowing other developers to learn how to use the component under any use case below.
We have the component that @davisagli wrote to adapt some of these use cases.
We should provide a better interface to the component:
for all the use cases below, provide a way of instantiate it. Having a basic StoryBook for covering all use cases would be amazing too. Proper documentation of the use cases as well.
All work should be done in: https://github.com/kitconcept/volto-image-block
We can identify, basically two use cases, based in the image source and nature. Also some derived use cases.
Catalog data coming from a block schema
This happens when the content has been saved in a block for caching purposes or as a reference to the original content (eg. image or teaser block). The data could be refreshed via a block serializer from the backend.
We take some assumptions for granted:
ObjectBrowser
to establish the relation and save the reference.ObjectBrowser
we save the catalog dataimage_scales
andimage_field
Image data does not provide scales
Then the component should fallback to use only the provided image URL.
TODO: decide how we get this, and which property do we should use
Image data does not have blurhash
Could be that we do not provide
blurhash
data. The component should detect this and adapt and fallback to not use it at all.Image data is external
Could be that the image provided is external to the service. The component should detect this and adapt and fallback to not use it at all.
TODO: How does the instantiation should like then?
src
prop?Direct data coming from the serialization of a content type
This happens when the content has been requested somehow and the data comes directly from waking up the object and has been directly serialized and it's fresh from the backend.
In a content type (does not have to be an
Image
type), there are image fields that serialize from the default content request like:These images are always internal, since they are stored in the content type. They provide the scales directly in the serialization.