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

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

Open
javiercn opened this issue Aug 26, 2020 · 31 comments
Labels
affected-few This issue impacts only small number of customers area-blazor Includes: Blazor, Razor Components cost: L Will take from 5 - 10 days to complete design-proposal This issue represents a design proposal for a different issue, linked in the description enhancement This issue represents an ask for new feature or an enhancement to an existing one feature-blazor-server feature-blazor-server-experience Issues that make Blazor server experience different of Web assembly or Desktop Priority:1 Work that is critical for the release, but we could probably ship without severity-minor This label is used by an internal tool
Milestone

Comments

@javiercn
Copy link
Member

javiercn commented Aug 26, 2020

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

@javiercn javiercn added the area-blazor Includes: Blazor, Razor Components label Aug 26, 2020
@pranavkm pranavkm added the enhancement This issue represents an ask for new feature or an enhancement to an existing one label Aug 26, 2020
@pranavkm pranavkm added this to the Next sprint planning milestone Aug 26, 2020
@ghost
Copy link

ghost commented Aug 26, 2020

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.

@pranavkm pranavkm modified the milestone: Next sprint planning Aug 26, 2020
@ghost
Copy link

ghost commented Aug 26, 2020

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
Copy link

This sounds like a really nice feature.

@SteveSandersonMS
Copy link
Member

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>.

@SteveSandersonMS SteveSandersonMS added affected-few This issue impacts only small number of customers severity-minor This label is used by an internal tool labels Oct 7, 2020 — with ASP.NET Core Issue Ranking
@ghost
Copy link

ghost commented Oct 9, 2020

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.

@SteveSandersonMS SteveSandersonMS added the design-proposal This issue represents a design proposal for a different issue, linked in the description label Oct 27, 2020
@javiercn
Copy link
Member Author

#27802

@steamonimo
Copy link

This would be benefitial to reduce the attack surface of web applications: no additional rest interface needed for image creation. We currently use base64 encoded images and it would be nice to reduce the memory overhead for this.

@javiercn
Copy link
Member Author

#28110

@javiercn
Copy link
Member Author

javiercn commented Apr 7, 2021

Another instance of this #31585

@javiercn javiercn added feature-blazor-server feature-blazor-server-experience Issues that make Blazor server experience different of Web assembly or Desktop labels Apr 20, 2021
@TanayParikh
Copy link
Contributor

In the interim a new docs page covering best practices for working with images in Blazor (in .NET 6) is available here: https://docs.microsoft.com/aspnet/core/blazor/images?view=aspnetcore-6.0

@mkArtakMSFT mkArtakMSFT modified the milestones: Backlog, .NET 7 Planning Nov 5, 2021
@mkArtakMSFT mkArtakMSFT added triaged Priority:1 Work that is critical for the release, but we could probably ship without labels Nov 5, 2021
@TanayParikh
Copy link
Contributor

Thanks all for the discussion.

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>.

This is exactly the scenario https://docs.microsoft.com/aspnet/core/blazor/images?view=aspnetcore-6.0 covers. Closing out this issue accordingly.

@danroth27 danroth27 changed the title [Blazor] Image element to display images that are not accessible through HTTP endpoints Blazor Image component to display images that are not accessible through HTTP endpoints Aug 24, 2022
@danroth27
Copy link
Member

While we have made progress on this feature, at this point we think the risk is too high to include this in the .NET 7 release. Moving to .NET 8.

@javiercn
Copy link
Member Author

Another instance this component is useful #47449

@javiercn
Copy link
Member Author

javiercn commented May 9, 2023

Another problematic case #48123

@mkArtakMSFT mkArtakMSFT modified the milestones: .NET 8 Planning, Backlog Jun 29, 2023
@ghost
Copy link

ghost commented Jun 29, 2023

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.

@mkArtakMSFT mkArtakMSFT modified the milestones: Backlog, BlazorPlanning Nov 5, 2023
@mkArtakMSFT mkArtakMSFT modified the milestones: Planning: WebUI, Backlog Nov 10, 2023
@dotnet dotnet deleted a comment Nov 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affected-few This issue impacts only small number of customers area-blazor Includes: Blazor, Razor Components cost: L Will take from 5 - 10 days to complete design-proposal This issue represents a design proposal for a different issue, linked in the description enhancement This issue represents an ask for new feature or an enhancement to an existing one feature-blazor-server feature-blazor-server-experience Issues that make Blazor server experience different of Web assembly or Desktop Priority:1 Work that is critical for the release, but we could probably ship without severity-minor This label is used by an internal tool
Projects
None yet
Development

Successfully merging a pull request may close this issue.