AspNetCore.Docs
AspNetCore.Docs copied to clipboard
dotnet
The "Preview an image provided by the InputFile component" content seems strange
A couple of aspects of the "Preview an image provided by the InputFile component" content seem odd to me:
- Why does it round-trip the data to .NET? That's potentially very expensive, and could be avoided. Instead, the .NET side already knows the
Nameof the file being uploaded, so it can send that to some JS functionsetImagealong with a reference to the<input type=file>element, and then the JS code can readinputFileElement.filesto look up the corresponding file data without it ever having to be sent to .NET - Why does it claim that "Because setImage is called from a form, it isn't necessary for the setImage function to call revokeObjectURL"? I don't know what "form" is being referred to here, or why that has any bearing on the fact that
createObjectURLwill leak memory if you fail to revoke the object URL later. As far as I'm aware, it is necessary to revoke the object URL.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
- ID: 66bb1712-60ac-77a6-10d2-f2d795126783
- Version Independent ID: 66bb1712-60ac-77a6-10d2-f2d795126783
- Content: Work with images in ASP.NET Core Blazor
- Content Source: aspnetcore/blazor/images.md
- Product: aspnet-core
- Technology: aspnetcore-blazor
- GitHub Login: @guardrex
- Microsoft Alias: taparik
@TanayParikh is the content provider for these scenarios.
Tanay, my recent UE ("user experience") pass was performed on https://github.com/dotnet/AspNetCore.Docs/pull/26161 about ten days ago, but IIRC the changes were limited to non-technical aspects. My PR opening comment calls out the changes, and I don't think they bear on @SteveSandersonMS's remarks.
The cross-ref for the original content submission is https://github.com/dotnet/AspNetCore.Docs/pull/23720 ... there were some minor updates along the way outside of my UE pass.
btw ... Just noticed this: I asked the following ...
You don't say/show where to call ...
URL.revokeObjectURL(url);
You replied ...
There isn't really a set location to call
URL.revokeObjectURL(url), it depends on when you're done with the image. For example, in a form, after the user "submits" the data, you may wish to revoke the object URL as it will no longer be needed.
... but I don't think that I made the update to incorporate that bit correctly. The full current remark is ...
> [!NOTE] > When implementing the preceding function for a form (<xref:Microsoft.AspNetCore.Components.Forms.EditForm> component), it usually isn't necessary to revoke the object URL because it's typically revoked after the user submits the form for processing, as the object URL is no longer required at that point. For a form that uses `setImage`, you can remove the call to [`revokeObjectURL`](https://developer.mozilla.org/docs/Web/API/URL/revokeObjectURL).
An update might also bear on https://github.com/dotnet/AspNetCore.Docs/issues/26270. We might end up working these two issues together.
Instead, the .NET side already knows the Name of the file being uploaded, so it can send that to some JS function setImage along with a reference to the element, and then the JS code can read inputFileElement.files to look up the corresponding file data without it ever having to be sent to .NET
Sounds good, we'd just need to call out the duplicate file name issue with a directory upload, that you mentioned in https://github.com/dotnet/aspnetcore/issues/31638#issuecomment-1171540860.
- Why does it claim that "Because setImage is called from a form, it isn't necessary for the setImage function to call revokeObjectURL"? I don't know what "form" is being referred to here, or why that has any bearing on the fact that
createObjectURLwill leak memory if you fail to revoke the object URL later. As far as I'm aware, it is necessary to revoke the object URL.
I think this may have been a miscommunication at some point. We definitely need to still revoke. The following should be better:
- When implementing the preceding function for a form (<xref:Microsoft.AspNetCore.Components.Forms.EditForm> component), it usually isn't necessary to revoke the object URL because it's typically revoked after the user submits the form for processing, as the object URL is no longer required at that point. For a form that uses `setImage`, you can remove the call to [`revokeObjectURL`](https://developer.mozilla.org/docs/Web/API/URL/revokeObjectURL).
+ When implementing the preceding function for a form (<xref:Microsoft.AspNetCore.Components.Forms.EditForm> component), the object URL should typically be revoked after the user submits the form for processing, as the object URL is no longer required at that point.
@guardrex please let me know if the above answers the needs-more-info query, or if there's any other info I can provide 😄
@TanayParikh ... Can you email me at my aquent.com address to discuss this offline? I don't have your email address, nor do I have access to the global address book.
@guardrex assigning this to myself as well, as I know I need to get back to you on this.
Thanks @TanayParikh ... No rush. I took out the offending code that I placed earlier 🙈🤣. We're not showing what he said was bad to show.
I just couldn't quite follow what Steve was saying to do. I understood bits and phrases but not the whole coding concept. Normally, he uses guru dev speak ... but there, he was using super-guru programmer god dev speak. A mere mortal 🦖 couldn't understand it! 😆