[WIP] add local and session storage support

[LunicLynx]

A storage support implementation. Not really sure if this is the way how it should be done.
Would love some feedback!

[dnfclas]

All CLA requirements met.

[grahamehorner]

looks interesting, Q: would be great to have some events raised from the JavaScript when things change etc. and possibly async methods at the .net side. Great work looking forward to playing with this

[SteveSandersonMS]

Thanks @LunicLynx for this - it looks really interesting!

Rather than coupling it to Microsoft.AspNetCore.Blazor.Browser.dll, this looks like a candidate to be the first real Blazor add-on NuGet package, which would be pretty cool. We haven't yet figured out all the details of how such packages would work (e.g., how they include JavaScript and how it gets built into the Blazor application), but I do have some ideas. Would you be interested in working with me on figuring out how that should best work, and making this into the first proper Blazor package?

[grahamehorner]

@SteveSandersonMS @LunicLynx it’s definitely sweet to see this working, played around and I’ve got a geolocation interop working and now looking at SignalR now, but wondering how/if these interop packages would hook in without referencing or changing the current Browser/Browser.JS implementations

Also how would you envision the package/namespace/dlls would this be something akin to (company).AspNetCore.Blazor.Browser.{lib}[.JS]

[LunicLynx]

@SteveSandersonMS definitely interested.
The C# side of things would be fairly easy, it can be solved by DI(which it is already).

In one ASP.NET standup you said something about how the whole interop will be different from the first prototype, but i wasn't able to find something in the current bits. I think this will have an effect on how to solve this.

[LunicLynx]

Ok, i did some further investigation.

Atm Blazor.Build references the *Browser.JS.dll extracts the blazor.js file and puts it into the dist\_framework folder. This looks promising.

First i (just as a test) extended ReferencedAssemblyFileProvider.cs to also return a js file when returning from ComputeContents like so:

return foundAssemblies.Values.Select(assembly => (
                $"/{assembly.Definition.Name.Name}.dll",
                assembly.Data))
                .Concat(new[] { ("/my.js", Encoding.Default.GetBytes("alert('Hello world');")) });

Which resulted in creating a my.js in the dist\_framework\_bin folder.
Awesome.

My thought here is that Blazor.Build could look into every referenced assembly and look for an implementation of IFileProvider which then returns the js files.

So i created two projects

• Microsoft.AspNetCore.Blazor.Browser.Storage
• Microsoft.AspNetCore.Blazor.Browser.Storage.JS

One containing the c# part and one the js, as the Browser assemblies also do.

But here is the first problem, to make this work an app must reference both assemblies, which is not the case with the Browser assemblies.
Lets think this through, if we put both parts into one assembly this could work, but why extract the js from the embedded resource during build when the browser is going load the whole assembly anyway?

Which leads me to the general question: Should the js actually be loaded by the browser over network or should it be extracted from the embedded resources and injected into the page on the browser side it self?

[LunicLynx]

closed. see: #205