feat(store-sdk): Add Session to store-sdk

[tlgimenes]

What's the purpose of this pull request?

This PR adds the session context to store-sdk.
Session context is a minimalistic React context that can be used by store implementors to store session value on it. Also, note that the storage is scoped, so different bindings can actually have different session values stored on the browser without overriding one anotther.

How it works?

The ideia behind this context is to be very simple and leave to the store implementors chose how they are going to change these values. The standard way will be implemented in our graphql infrastructure via a query similar to:

type Mutation {
 session {
   update (key: string, value: string, session: Session): Session
 }
}

this way devs can cause sideEffects on the backend, like setting the postalCode and changing the region/priceTable for instance.

How to test it?

There is currently nobody using this session.

[netlify]

✔️ Deploy Preview for storeui ready!

🔨 Explore the source changes: 79bf0b0

🔍 Inspect the deploy log: https://app.netlify.com/sites/storeui/deploys/611d25663874980007535d48

😎 Browse the preview: https://deploy-preview-896--storeui.netlify.app

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 79bf0b0:

Sandbox	Source
Store UI Typescript	Configuration

[icazevedo]

I think we should consider using localForage for this. It's not a heavy library (but certainly heavier than this ofc) and it brings numerous advantages over using only localStorage directly. I think it's way more scalable to go with localForage.

[tlgimenes]

I'm not sure. According to bundlephobia this lib has 8.5 min+gzip, which is huge, specially comparing to other deps, like swr that has 5 min+gzip and handles the whole IO or react-use-cart that is 1.5 min+gzip

[tlgimenes]

What do you think on leaving this localStorage iimplementation and if we see this doesn't scale well we use a different approach

[icazevedo]

Makes sense. Then I propose for us to migrate to IndexedDB, since it doesn't block the main thread as LocalStorage does. We also gain more freedom regarding storage quotas.

I have found this good read.

LocalStorage should be avoided because it is synchronous and will block the main thread. It is limited to about 5MB and can contain only strings. LocalStorage is not accessible from web workers or service workers.

[icazevedo]

What do you think on leaving this localStorage iimplementation and if we see this doesn't scale well we use a different approach

I only worry about having to release a major for store-sdk only to upgrade it to indexeddb. I think that for 99% of use-cases, localStorage will be enough, but we would have to break this 99% because of the 1% that isn't contemplated. I don't think transferring data between systems would be a trivial task.

indexeddb is by far more complicated to use, but I think we can make an opportunity out of this. Maybe create a super simple to manage wrapper around indexeddb that's also super lightweight.

I'm okay with using localstorage as long we don't go stable without changing it to indexeddb. For me, that's a must.