feat(quantic): added logic to include quantic version in analytic payloads

[mmitiche]

SFINT-5760

Description

Created the logic that will include the Quantic version in the analytic payloads pf every event logged by a Quantic component.

This logic relies on a new static resource that I created called. quanticMetadata which is a JSON file that contains the Quantic version, that's how it will work:

• When building the Quantic library, the Quantic version is read from the package.json file and is written in the new static resource quanticMetadata.json.
• The Quantic interfaces components for search, insight, case assist and recommendation use cases all fetch this static resource on their connected callback and pass an analytics middleware to the Headless engine they creating, this middleware handles adding the Quantic version to the analytics payload.

[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	241.4	241.4	0
commerce	346	346	0
search	413	413	0
insight	403.8	403.8	0
recommendation	253.6	253.6	0
ssr	406.5	406.5	0
ssr-commerce	358.3	358.3	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

[erocheleau]

The issue with adding a new static resource is that this requires at minimum a network call to load it.

I would much rather we simply create a version.js file under quanticUtils for example, and simply write this in it:

export const version = '3.3.0';

and under quanticUtils.js we can have export * from './version.js';

and then we can import {version} from 'c/quanticUtils'; wherever we need it, this way instead of a new network call to load a static resource, it'll already be compiled in the components themselves who need it.

[mmitiche]

The issue with adding a new static resource is that this requires at minimum a network call to load it.

I would much rather we simply create a version.js file under quanticUtils for example, and simply write this in it:

export const version = '3.3.0';

and under quanticUtils.js we can have export * from './version.js';

and then we can import {version} from 'c/quanticUtils'; wherever we need it, this way instead of a new network call to load a static resource, it'll already be compiled in the components themselves who need it.

The reason I did not go for the QuanticUtils solution is because I didn't want to source control a file that we are not supposed to change and that should not be change manually.
Mainly to avoid changing this by mistake or having to maintain this in our code base, and just because it made sense to not source control a file that we are never supposed to change.

Additionally, preserving this information in the Quantic Utils would probably require a logic that will automatically commit a change in this version.js file whenever we create a new version of Quantic, which means this is an additional logic to create and to maintain.

Another reason , less important the the two others, is to avoid writing the same information twice in our codebase, in the version.js and in package.json.

In the other hand, using static resources, true that it is an additional network call but I think we can all agree that it's insignificant in a Salesforce Env, especially that the file to be fetch is extremely light so practically I don't think there is a concrete or noticeable impact.
Additionally, it's the simplest way and it avoids source controlling the file that holds the version, saving us from maintaining this file and creating the logic to automatically commit to this file and maintain the logic that does this and it avoids us from having the same information duplicated in two files.

That being said, and because static resource is a natural way of handling this in SF, when I balanced the pros and cons I found that using static resources seems better than using the Quantic Utils.