Make storage a default export

[jacobrask]

Is there any particular reason a named storage export was chosen over a default export? I would expect the vast majority of module consumers to only use the storage api, and it feels more in line with community modules to expose that as a default export.

It is quite likely that future built-in modules will look at this first module when designing API:s so I think this is a relevant discussion even if it's a pretty minor issue.

[domenic]

This is an interesting proposal! I kind of like them both being on equal footing now, especially since isolated storage areas are so useful, but it's possible we should make it easier to get at the default one.

Do you have examples of the community modules you're thinking of?

I'd personally prefer only one way to do things, so we'd get rid of the storage named export and instead have the default export be the main storage area. Does that align with your thinking as well?

[jacobrask]

If I look at the most depended on packages in npm, they all have a default export. I can't find any packages that feel like perfect comparisons to this API on npm, but in our application we have a memory storage module as a fallback for when localStorage fails. I could imagine us replacing window.localStorage with kv-storage and doing something like this

// appStorage.js
import { StorageArea } from 'std:kv-storage';
const appStorage = new StorageArea('my-app-storage');
export default appStorage;

// memoryStorage.js
const memoryStorage = new Map();
export default memoryStorage;

import globalStorage from 'std:kv-storage';
import appStorage from './appStorage';
import memoryStorage from './memoryStorage';

I would indeed only expect the default and a StorageArea named export.