Allow support for multiple sites concurrently w/ commerce-sdk-react

[bendvc]

Prefix your cookies with milk

Description

To be in alignment with plugin_slas this PR ensures that the storage keys we use during the authentication process are prefixed with the id of the ecomm back-end we are connecting to. This means that you can jump from one site to another without loosing your guest or registered session, but more importantly the cookie keys will be the same format as what plugin_slas expects, so there will be no issues navigating from PWA to SFRA experiences.

Changes

• Make BaseStorage an abstract class instead of an interface to add prefixing functionality.
• Remove clearing of storage as it's not in use anymore.
• Add new storage class for server side storage instead of using Maps directly (solves typing issue).

How to Test-Drive This PR

• In the test-commerce-sdk-react project execute the command npm start.
• Goto the slas login helpers page.
• Open your inspector and goto the application --> cookies tab and look at the cookies being created.
• You should see the cc-nx-g cookie prefixed with the currently selected site.
• Try changing the site, you should see an additional cookie created with the newly selected site's id prefix to it.
• Now try logging in as a registered user, the guest cookie (<prefix>_cc-nx-g) will be replaces with the registered cooke (<prefix>_cc-nx)

Checklists

General

• Changes are covered by test cases
• CHANGELOG.md updated with a short description of changes (not required for documentation updates)

[kevinxh]

We probably want some sort of test that make sure the multi-site feature is working.

Particularly two test cases

1. I switch site, and things still works
2. I switch site, and switch back, i can use the old token

Any idea where these kind of tests belong to?

[wjhsf]

We could potentially return boolean ("was deleted?") to fully conform with the Map interface. Not important if we don't, though.

[wjhsf]

🤔 We could add static type: StorageType to each implementation. That could potentially enable some fancy type magic. Not sure we have a use case for fancy type magic here, but maybe someone downstream will...

[wjhsf]

Not relevant to this PR, but I was curious if there was a way to use TokenResponse so that we don't need to manually list the keys. Turns out there is!

// Helpers
type RemoveNeverValues<T> = {
    // Key remapping, fancy stuff! https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/#key-remapping-in-mapped-types
    [K in keyof T as T[K] extends never ? never: K]: T[K]
}
type StringIndexNever<T> = {
    [K in keyof T]: string extends K ? never : T[K]
}
type KnownKeys<T> = keyof RemoveNeverValues<StringIndexNever<T>>

// Implementation
type TokenResponseKeys = KnownKeys<ShopperLoginTypes.TokenResponse>
type AuthDataKeys =
    | Exclude<TokenResponseKeys, 'refresh_token'>
    | 'idp_access_token'
    | 'refresh_token_guest'
    | 'refresh_token_registered'
    | 'site_id'

[bfeister]

@wjhsf This is nice 👌, this either close to (if not exactly) what I was mentioning in the typescript chat we had with @kevinxh last week

[bendvc]

Looks promising to my TS n00b eyes. Maybe you can contribute this is a separate PR? @wjhsf

[kevinxh]

I believe jest has util functions to restore mocks, I think it's jest.restoreAllMocks() (or maybe jest.resetAllMocks()).

We could do that in afterEach to DRY it.

afterEach(() => {
  jest.restoreAllMocks()
})

[wjhsf]

Re: #911 (comment)

Our use case is to use a shared context. Is our use case common enough that it should be the default, or should we default to isolated contexts?

[bendvc]

I chose the default to be isolated maps, as I think it's the most natural. Is it weird that our only use of this is not the default.. maybe.. but I think that our use case of wanting global storage from lambda run to another is a little wweird.

[kevinxh]

What do you think if we have a test case that looks something like below, to ensure the multisite feature works...

warning: pseudo code 😛

test('Multi-site support', () => {
  const {rerender} = render(<CommerceApiProvider siteId={'en'} />)
  
  // expect storage keys are pre-fixed with siteId EN, pseudocode
  expect(storage.keys).has('en-access_token')

  // re-render the provider with a different site id
  rerender(<CommerceApiProvider siteId={'fr'} />)

  // old access token still exists and value do not change
  expect(storage.keys).has('en-access_token')

  // new access token for FR
  expect(storage.keys).has('fr-access_token')
})