Blazor Image component to display images that are not accessible through HTTP endpoints

[javiercn]

Summary

Introduce an Image component to display images coming from dynamic sources like API calls or databases.

Motivation

Currently the most common way to display an image coming from the Database is to base64 encoded it and create an object URL for it. This is problematic since images have a big size and that results in the allocation of large strings, which has a big impact on performance. We want to display images on the browser without allocating large amounts of memory on the .NET side.

Goals

• Simplify rendering images that come from sources that are not addressable via URLs.
• Prevent users from allocating large amounts of memory on their applications to display images.

Non-goals

• Implement responsive images or advanced functionality available in HTML like srcset and Picture

Scenarios

• As a developer I want to display a profile picture for my users that comes from the database.

<Image Source="_imageSource" />

@code
{
    private ImageSource _imageSource;

    protected override OnInitializedAsync()
    {
        var data = await client.GetProfileAsync();
        _imageSource = new ImageSource("img/jpg", "profile.jpg", data);
    }
}

Risks

• Customers might not discover the feature:
  • We can limit that with docs, and maybe an "analyzer like" warning.

Interaction with other parts of the framework

Detailed design

This is a rough sketch, but the idea is to create an object on the JS side attached to the image. Use JS interop or other means to transfer the image down to the client (at which points its not longer on the .NET memory) and display it.

Drawbacks

We'll likely want to cache these things in the browser and will have to handle what happens when the input data changes and so on in the server.
We'll likely also want to avoid performing unnecessary requests on the server to retrieve an image that has already been retrieved, which might complicate things.

Considered alternatives

The current alternatives are:

• Base64 encode the image and add it to the source element.
  • This allocates large strings which we are trying to avoid.
• Create a separate endpoint on the server to retrieve and serve the image specifically.
  • This can interfere with the authorization rules in your app since the browser is making the request and might not have access to the credentials you need to call the API.
  • In general it requires much more work and knowledge to get it right.

Open questions

TBD

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mihaimyh]

This sounds like a really nice feature.

[SteveSandersonMS]

We could consider this a special case of "support passing byte[] in JS interop calls without base64 serialization". If we supported that, then it would be trivial to convert a byte[] to a blob URL, which could then be used on an <img src>.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[dennisbdannunzio-leonardo]

This is a useful feature. But, the "support passing byte[]" in JS interop calls is a better generalization and more flexible approach.