Feature: Serialize / Deserialize object to be able to store in indexedDB

[yoHasse]

Love this package, made my life a lot easier.

I am just missing one thing and thats the posibility to serialize / deserialize a filehandler to be stored in indexeddb.

I am able to serialize using the JSReference but am unable to deserialize it to a FileSystemHandler, would be a great feature.

[KristofferStrube]

Hey, Marcus. Awesome idea.

I think this would be possible with minor changes to some constructors that are currently internal and making them public.

Would being able to do something like this sound good to you?

FileSystemHandle handle = new FileSystemHandle(JSReference);
FileSystemFileHandle handle = new FileSystemFileHandle(JSReference);
FileSystemDirectoryHandle handle = new FileSystemDirectoryHandle(JSReference);

I think that would just be a minor release as I only add to the existing API surface.

Alternatively, I could add a custom Deserializer that would actually take an IJSObjectReference from JSON and create an instance from that. It is possible, but a bit more complicated. I also think the other solution would be more broadly usable.

I can work on this next week.

[yoHasse]

The public constructor would solve it for me so that would be awsome. 😀

Thanks!

[KristofferStrube]

Currently, I also parse the IJSInProcessObjectReference helper through the internal constructor so that I can have a single instance of that across all objects in the library, but I'm thinking that instantiating the helper when using the public constructor should be fine.
I want to make this change in some of the other classes that are in the lib as well. You can see in Blob.cs that it has a CreateAsync method for creating an instance. That might also be an option for solving your problem which would result in something like this:

FileSystemHandle handle = await FileSystemHandle.CreateAsync(JSReference, JSRuntime);
FileSystemFileHandle handle = await FileSystemFileHandle.CreateAsync(JSReference, JSRuntime);
FileSystemDirectoryHandle handle = await FileSystemDirectoryHandle.CreateAsync(JSReference, JSRuntime);

[fixnil]

Excellent!
I think this also solved my problem by the way #17

[KristofferStrube]

Yep @fixnil,

I figured it was something similar that you were looking for.
I haven't gotten around to implementing it yet, but I will get to it later this week. 😉

I will make sure to add a demo of using it to write to IndexedDB. Is there any Blazor library that you can recommend for working with IndexedDB?

[fixnil]

Maybe this one: https://github.com/Tavenem/Blazor.IndexedDB
Or this way: ericsink/SQLitePCL.raw#472 (comment)

[KristofferStrube]

I am currently facing some problems writing the demo with IndexedDB so I might not use that as the final demo.

To clarify my problem with using https://github.com/wtulloch/Blazor.IndexedDB which I chose as my IndexedDB library:

Currently, you can't have IJSObjectReferences that live across multiple reloads of a Blazor application.
Blazor keeps track of IJSObjectReferences using an int __jsObjectId that it append to the JS object. Then if/when the object is returned to blazor it tries to look that id up across existing JS references that it has created so it is simply a Blazor limitation that you can't get IJSObjectReferences back through JsonSerialization and that you can only return an IJSObjectReference by calling InvokeAsync<IJSObjectReference(...).
I'm currently trying to develop a workaround by tricking Blazor into believing that it had already seen the object before, but I can't promise anything.

The issue in the ASP.NET Core repo that keeps track of this issue and many others related to JSInterop is the follow: dotnet/aspnetcore#31151
If you would like this to be supported with more ease then I would love if you gave that a thumbs up to show interest in working on that issue.

[KristofferStrube]

I got it resolved and created the IndexedDB demo.