refactor(atomic): split the atomic store into composable parts

[alexprudhomme]

https://coveord.atlassian.net/browse/KIT-3814

The atomic store was messy. The common store was way too big. There was no need for all that stuff in every store.

[github-actions]

Pull Request Report

PR Title

✅ Title follows the conventional commit spec.

Live demo links

• Storybook

• Playwright report

Bundle Size

File	Old (kb)	New (kb)	Change (%)
case-assist	243.7	243.7	0
commerce	354.8	354.8	0
search	414.8	414.8	0
insight	406	406	0
recommendation	255.9	255.9	0
ssr	408.3	408.3	0
ssr-commerce	372.1	372.1	0

SSR Progress

Use case	SSR (#)	CSR (#)	Progress (%)
search	39	44	89
recommendation	0	4	0
case-assist	0	6	0
insight	0	27	0
commerce	0	15	0

Detailed logs

search : buildInteractiveResult
search : buildInteractiveInstantResult
search : buildInteractiveRecentResult
search : buildInteractiveCitation
search : buildGeneratedAnswer
recommendation : missing SSR support
case-assist : missing SSR support
insight : missing SSR support
commerce : missing SSR support

[fbeaudoincoveo]

Isn't this a breaking change? Custom components can rely on store functions / attributes.

[alexprudhomme]

Isn't this a breaking change? Custom components can rely on store functions / attributes.

Maybe it is but this could be considered as a bug.

For example, all of those should not be available to use in the commerce store... They are only used in search & insight. Someone using them as of now in a custom component would be querying empty objects ?

    facets: {},
    numericFacets: {},
    dateFacets: {},
    categoryFacets: {},

[alexprudhomme]

The only real breaking change imo would be that I removed the get and set options. As written in the stencil-store documentation. These options are only there to support IE11 since it did not support Proxy...

I think I should re add those in case someone used .get() and .set() for valid store keys in custom components. And remove them in v4.

old interface

export interface CommonStencilStore<StoreData extends AtomicCommonStoreData> {
  state: StoreData;

  get: <PropName extends keyof StoreData>(
    propName: PropName
  ) => StoreData[PropName];

  set: <PropName extends keyof StoreData>(
    propName: PropName,
    value: StoreData[PropName]
  ) => void;

  onChange: <PropName extends keyof StoreData>(
    propName: PropName,
    cb: (newValue: StoreData[PropName]) => void
  ) => () => void;
}

[alexprudhomme]

Isn't this a breaking change? Custom components can rely on store functions / attributes.

Maybe it is but this could be considered as a bug.

For example, all of those should not be available to use in the commerce store... They are only used in search & insight.

    facets: {},
    numericFacets: {},
    dateFacets: {},
    categoryFacets: {},

only real breaking change would be this imo https://github.com/coveo/ui-kit/pull/4806/files#r1904333364

[alexprudhomme]

@fbeaudoincoveo I personally feel comfortable making all the possible breaking changes in this PR. Even if a custom component was using the store, They should have never used those I removed in this PR. Someone using AtomicRecs should have never used store.facets and even if they did, that constant would have been an empty object... This is a bug. Exposed stuff that should have never been there in the first place and that are useless.

I will re add the get & set functions tho. I do agree that those could have been used for a good reason.