feat(genqa): add rephrase buttons as an option

[jelmedini]

SVCC-4005

• Add rephrase buttons as an option.
• By default withRephraseButtons is set at false.
• When withRephraseButtons is set to true, we show the rephrase buttons.

By default:

When withRephraseButtons is set to true:

[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	244.1	244.1	0
commerce	341.1	341.1	0
search	414	414	0
insight	391.7	391.7	0
product-listing	306.4	306.4	0
product-recommendation	210.4	210.4	0
recommendation	257.2	257.2	0
ssr	405	405	0
ssr-commerce	338.5	338.5	0

SSR Progress

Use case	SSR (#)	CSR (#)	Progress (%)
search	39	44	89
recommendation	0	4	0
product-recommendation	0	10	0
product-listing	0	13	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
product-recommendation : missing SSR support
product-listing : missing SSR support
case-assist : missing SSR support
insight : missing SSR support
commerce : missing SSR support

[fbeaudoincoveo]

I believe this should be considered a breaking change as the rephrase buttons are currently being shown by default. So normally we would introduce this in a major version.

Was the decision to hide the buttons by default made by UX?

Is there a plan to communicate this change to live customers?

[louis-bompart]

Our cypress tests are frozen, we do not accept new tests with Cypress in Atomic.
Please do them with Playwright.
DXUI can offer guidance on Slack if required.

[jelmedini]

I believe this should be considered a breaking change as the rephrase buttons are currently being shown by default. So normally we would introduce this in a major version.

Was the decision to hide the buttons by default made by UX?

Is there a plan to communicate this change to live customers?

No not by UX, Yes there is a plan to communicate when they upgrade to this version, @MathieuLavoieSabourin I will let you explain better the purpose of this change

[jelmedini]

I believe this should be considered a breaking change as the rephrase buttons are currently being shown by default. So normally we would introduce this in a major version.

Was the decision to hide the buttons by default made by UX?

Is there a plan to communicate this change to live customers?

@louis-bompart @fbeaudoincoveo this is a first iteration for the rephrase buttons, they will be completely removed in the next weeks, so I just fixed the cypress tests with the current change.
The decison to remove it i will let @MathieuLavoieSabourin explain more, But we agreed to do a first iteration as an option and not completely remove it. then afterwards, after communicating with clients we will not use anymore the rephrase options.

[MathieuLavoieSabourin]

I believe this should be considered a breaking change as the rephrase buttons are currently being shown by default. So normally we would introduce this in a major version.
Was the decision to hide the buttons by default made by UX?
Is there a plan to communicate this change to live customers?

@louis-bompart @fbeaudoincoveo this is a first iteration for the rephrase buttons, they will be completely removed in the next weeks, so I just fixed the cypress tests with the current change. The decison to remove it i will let @MathieuLavoieSabourin explain more, But we agreed to do a first iteration as an option and not completely remove it. then afterwards, after communicating with clients we will not use anymore the rephrase options.

@louis-bompart @fbeaudoincoveo you can read more about the reasoning behind hiding the rephrase button here : RGA Component updates Q3 2024

We don't consider this PR alone a breaking change because of the following :

• Usage of the Rephrase buttons is very low, users mostly use it to try to get an answer when there is none, but we will also get rid of the "sorry..." message so this will stop

• We aren’t completely removing the Rephrase buttons at this point, just hiding them by default

• The Rephrase buttons can still be shown/used via the withRephraseButtons option

Finally, enablement is aware and will coordinate the client facing communications!

[fbeaudoincoveo]

We don't consider this PR alone a breaking change because of the following :

• Usage of the Rephrase buttons is very low, users mostly use it to try to get an answer when there is none, but we will also get rid of the "sorry..." message so this will stop

This does seem to justify the change from a product development perspective. Customers may not see it that way, though. That's why we normally introduce breaking changes in major versions: major versions are expected to be breaking / non-backward compatible, and the customer can decide when they're ready migrate to the new version.

• We aren’t completely removing the Rephrase buttons at this point, just hiding them by default

Modifying the default value of the option is breaking, though: if a customer relying on the default option value wants to keep the same behavior as before, they will have to adjust their code accordingly (i.e., explicitly set the option to true).

It may be alright if there's a fairly small number of customers using the feature and all of them can be convinced in a timely fashion (i.e., before the change is deployed to production) that this is for the best, and are all onboard to deal with the breaking change in a minor version.

It's important however that the change be communicated and agreed upon before the change is deployed to production, because otherwise customer implementations relying on the CDN and targeting v2 without a minor version number will automatically get the breaking change, which could, in worst case scenarios, break their live site if they have custom code relying on the fact that the feature is active by default.

• The Rephrase buttons can still be shown/used via the withRephraseButtons option

This does not make the change any less breaking. If all customers are onboard to stop using the feature, and we don't want any new implementaions to use it, we might as well remove it right now altogether.

Finally, enablement is aware and will coordinate the client facing communications!

👍

@MathieuLavoieSabourin see my comments above.

In short, I don't personally mind the change, and it does seem to be for the best, but it's quite unusual to introduce such a breaking change in a minor version, and should therefore be handled extremely carefully IMO.

[dmgauthier]

The code looks fine, although maybe more care should be put into the tests, even if it means re-writing them in playwright. I wont fight over this.

But I agree that overall, changing the default behavior of a client side component when they did not explicitly changed their setup is breaking. Not that its a bad change, as it has been well though of. But I think its important we all agree with this fact, a breaking change is a breaking change.

Is there any documented guidelines for breaking changes in the UI-kit? Or we just assume general knowledge of the concept ?

[fbeaudoincoveo]

Is there any documented guidelines for breaking changes in the UI-kit? Or we just assume general knowledge of the concept ?

@dmgauthier I'm not aware of official guidelines per-se.

In general, we only introduce breaking changes to generally available features in major versions.

In the case of features that are in a "beta" (or similar) state, where it is implicitly or explicitly acknowledged by early adopters that they're using the feature at their own risk, and breaking changes are likely to be introduced in the current major version, we'd communicate the changes to the customers we know are using the feature, but would not otherwise restrict ourselves from deploying them to production.

For instance, this is what we did with the headless commerce sub-package until it became officially GA in July.

There can be case by case exceptions, of course, but my point is introducing a breaking change in a minor version should not be taken lightly.

[jelmedini]

The code looks fine, although maybe more care should be put into the tests, even if it means re-writing them in playwright. I wont fight over this.

But I agree that overall, changing the default behavior of a client side component when they did not explicitly changed their setup is breaking. Not that its a bad change, as it has been well though of. But I think its important we all agree with this fact, a breaking change is a breaking change.

Is there any documented guidelines for breaking changes in the UI-kit? Or we just assume general knowledge of the concept ?

@dmgauthier it' s because we are removing this feature completely after, That' s why I fixed the current tests and not adding this change in Playwright as it will just be deleted after anyway.

Fixed! (and Louis is on vacation to check it)