Closed KristofferStrube closed 1 year ago
In the new packages that this project will rely on which are Blazor.Streams and Blazor.FileAPI I have started a new wrapper structure that simplifies how to have the functionality that is supported in Blazor Server, but also the easy accessors that are available in Blazor WASM through the use of IJSInProcessObjectReferences
.
The new structure that I use in those projects should be familiar to people as I basically have some implementation supported in Blazor Server (i.e. the Blob wrapper class) and then another wrapper class that has the features from Blazor WASM which extends the Blazer Server version. (i.e. the BlobInProcess wrapper class). This is similar to the relationship between the IJSRuntime
and IJSInProcessRuntime
.
I want to adopt this structure in this project. This will be a breaking change but will make it possible to use the package in both Blazor Server and Blazor WASM.
This was implemented as a part of #28 and has been published in version 2.0.0 to NuGet.
We have normalized the structure of the wrapper classes to have Blazor Server compatible base implementations and Blazor WASM versions that extend these.
Some might use this package in Blazor Server. In Blazor Server we can't use
IJSInProcessObjectReferece
s which we currently use to get properties likeName
from aFileSystemHandle
synchronously. It would be nice to have a sample project that uses Blazor Server and to set up the service structure so that you don't need to initialize anIJSInProcessObjectReferece
if you don't use it. A proposed name for the asynchronous counterpart i.e. theName
property would beGetNameAsync()
.