tc39 / proposal-module-expressions

https://tc39.es/proposal-module-expressions/
MIT License
436 stars 20 forks source link

Can ModuleBlocks be stored in IndexedDB? #47

Open surma opened 3 years ago

surma commented 3 years ago

If they are strutured cloneable, they could technically also be stored in IndexedDB. Wondering if that’s useful and what the implications are.

Personally, I’m leaning towards not supporting that as I don’t have a clear use-case and I am worried about unexpected implications of allowing it.

Jack-Works commented 3 years ago

I support to not allow it being stored in the indexed db cause it seems like a security failure

Jamesernator commented 2 years ago

I can imagine one particularly nice use case and that would be the ability to associate deserialization steps with objects inside indexedDB. i.e. Libraries that wrap indexedDB could do something like:

import * as lib from "indexeddb-lib";

export default class MyCustomSerializableType {
    [lib.serialize]() {
        return {
            deserializerModule: module {
                import MyCustomSerializableType from "./MyCustomSerializableType.js";

                export function deserialize(serializedData) {
                    return new MyCustomSerializableType({
                        ...serializedData,
                    });
                } 
            },
            data: {
               // ...serialized data here
            },
    }
}
// Somewhere in the library code
const { deserializerModule, data } = await getEntryFromIndexedDBSomehow();
if (deserializerModule) {
    const { deserialize } = await import(deserializerModule);
    return deserialize(data);
} else {
    return data;
}

Although the implications for how this is stored would be weird, like what happens if the original module changes between page loads? Does a fresh copy get imported? Or do we cache the entire module graph for the module block and store this in the DB also and reevaluate that module graph too.

Either way around has weird implications, like if the module has changed but the module block hasn't the module block might no longer work. But if we cache the entire module graph then multiple versions of modules could be floating around.

I think at some point this might be worth supporting, but there is a large amount of discussion around how versioning would work to resolve the above concerns. For now I think the best action would just be throwing if attempting to serialize-for-storage would be best. If there's significant interest there could always be a follow up proposal with semantics around how these things get evaluated.