UI for Blazor version 5.0 improved the FileSelect Stream performance by removing legacy code that meant to support older .NET versions.
However, the Stream performance is still worse and the component works slower, compared to the standard Blazor InputFile.
I'm trying to add image previewing to our .Net 6.0.8 Blazor Wasm app using the Telerik Blazor UI FileSelect component. I'd like to be able to create a local url for previewing and also hold onto the file's contents for saving later. There currently doesn't seem to be any great examples/references for doing this using the Telerik FileSelect locally. So, I started looking at the official MS Blazor documentation around images, file uploads and downloads - the most relevant content seemed to be around giving a file's stream to a DotNetStreamReference, then handing it off to JS interop to create a URL from a Blob.
It was already quite slow when testing with a 4KB~ image, but became absolutely unusable once testing things with a larger 4MB~ image. To rule out the Telerik FileSelect's involvement I started testing with the native Blazor FileInput component. I noticed that the sending the DotNetStreamReference to JS interop took a long time itself and learned that .Net 6 added the ability to pass a byte almost instantly to JS interop. I was then able to see image previews quickly using the native FileInput component while hosting a file from a byte. With this new knowledge in hand I attempted to migrate this new workflow over to the Blazor FileSelect component, but unfortunately there doesn't seem to be a faster way to get a byte from the FileSelectFileInfo's Stream.
I'm seeing similar performance issues between the native FileInput using a stream and the Telerik FileSelect using a stream or byte. These are both taking around 4-5 minutes to host a file with a locally generated url and preview the image. In contrast I'm seeing wait times around 3-12 seconds using the native FileInput/IBrowserFile, this
byte iBrowserFileBytes = new byte[iBrowserFile.Size];
Please see the attached Blazor Wasm code to recreate the issue. I've included 6 file inputs to test out the difference in performance between each scenario, but the most important file input is the "Blazor InputFile - HostFromByteArray" which shows the most promise. Attached is also the larger file that I was testing against. This might be a bug or maybe I'm just not reading from the FileSelectFileInfo's Stream in the most efficient way.
The only relevant code not attached is likely just this one from Program.cs:
builder.Services.AddSingleton<IJSInProcessRuntime>(services => (IJSInProcessRuntime)services.GetRequiredService<IJSRuntime>());
When the Multiple parameter is set to false, it should restrict the user to selecting only one file. However, the user can still select and upload multiple files if they are dragged.
To reproduce the problem open the following REPL and try to drag a few files in the FileSelect.
Add a parameter to the FileSelect component that enables users to control the visibility of the file list.
We have found a strange issue that I have created a REPL to reproduce: https://blazorrepl.telerik.com/cnupFJbS23F6HHJ006
1. Select a .doc file
2. Select a second file
3. Click the "Copy Memory Stream" Button
the method stops at CopyToAsync for the .doc file
It seems to work fine if the files are selected together or if different file types are used
I have been testing with the attached .doc and a blank .txt file
unfortunatelly we're not able to set the button text for the file input. The <span> is empty and the component does not allow setting the caption:
No ChildComponent seems to be allowed - when I manually modify the html and put something in the empty <span>, the text appears:
I am using the TelerikFileSelect component and I noticed that the user can select the same file multiple times and it just adds to the list
I was wondering if it's possible to maybe add logic to the OnSelect event that prevents the file from being added to the list of files under certain conditions such as duplication.
This could be achieved through cancelling the OnSelect event based on the desired condition - for instance, duplicated file names.