fix(app-shell): to only events for flag variations

[tdeekens]

Summary

This attempts to reduce the flag evaluation to occur for flags we don't request. This is the result of a LD support ticket.

[changeset-bot]

🦋 Changeset detected

Latest commit: e2a3691

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 37 packages

Name	Type
@commercetools-frontend/application-shell	Patch
@commercetools-frontend/cypress	Patch
@commercetools-applications/merchant-center-template-starter-typescript	Patch
@commercetools-applications/merchant-center-template-starter	Patch
@commercetools-applications/merchant-center-custom-view-template-starter-typescript	Patch
@commercetools-applications/merchant-center-custom-view-template-starter	Patch
@commercetools-local/playground	Patch
@commercetools-local/visual-testing-app	Patch
@commercetools-backend/eslint-config-node	Patch
@commercetools-backend/express	Patch
@commercetools-backend/loggers	Patch
@commercetools-frontend/actions-global	Patch
@commercetools-frontend/application-components	Patch
@commercetools-frontend/application-config	Patch
@commercetools-frontend/application-shell-connectors	Patch
@commercetools-frontend/assets	Patch
@commercetools-frontend/babel-preset-mc-app	Patch
@commercetools-frontend/browser-history	Patch
@commercetools-frontend/codemod	Patch
@commercetools-frontend/constants	Patch
@commercetools-frontend/create-mc-app	Patch
@commercetools-frontend/eslint-config-mc-app	Patch
@commercetools-frontend/i18n	Patch
@commercetools-frontend/jest-preset-mc-app	Patch
@commercetools-frontend/jest-stylelint-runner	Patch
@commercetools-frontend/l10n	Patch
@commercetools-frontend/mc-dev-authentication	Patch
@commercetools-frontend/mc-html-template	Patch
@commercetools-frontend/mc-scripts	Patch
@commercetools-frontend/notifications	Patch
@commercetools-frontend/permissions	Patch
@commercetools-frontend/react-notifications	Patch
@commercetools-frontend/sdk	Patch
@commercetools-frontend/sentry	Patch
@commercetools-frontend/url-utils	Patch
@commercetools-website/components-playground	Patch
@commercetools-website/custom-views	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
merchant-center-application-kit-components-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 6, 2024 8:50am

[emmenko]

Thanks

[tdeekens]

Thanks for the review. Will debug CI tomorrow.

[CarlosCortizasCT]

Thanks!

Just to better understand what this change does: is it about evaluation in the server side so the request time would potentially be shorter?

[tdeekens]

Thanks!

Just to better understand what this change does: is it about evaluation in the server side so the request time would potentially be shorter?

Not how I understood LaunchDarkly. There are some SDKs which have the legacy behaviour - to be non-breaking - that they send events to LaunchDarkly also for flags you don't requested.

The docs say:

Whether analytics events should be sent only when you call variation (true), or also when you call allFlags (false).
By default, this is false (events will be sent in both cases).

They recommend to only send analytic events for enabled flags as otherwise you run into cases in which false or non used flags send analytics data and then the flags are considered to be evaluated.

To be honest it's a recommendation they made. I will try out a local build to see what we get over the wire prior to merging this.

[github-actions]

Deploy preview for application-kit-custom-views ready!

✅ Preview
https://application-kit-custom-views-rbl9jqlc4-commercetools.vercel.app
https://appkit-cv-sha-d47dcacbaf67d4496251ae3ce4b0c1a5f22b947a.commercetools.vercel.app
https://appkit-cv-pr-3426.commercetools.vercel.app

Built with commit e2a3691.
This pull request is being automatically deployed with vercel-action

[CarlosCortizasCT]

Thanks!
Just to better understand what this change does: is it about evaluation in the server side so the request time would potentially be shorter?

Not how I understood LaunchDarkly. There are some SDKs which have the legacy behaviour - to be non-breaking - that they send events to LaunchDarkly also for flags you don't requested.

The docs say:

Whether analytics events should be sent only when you call variation (true), or also when you call allFlags (false).
By default, this is false (events will be sent in both cases).

They recommend to only send analytic events for enabled flags as otherwise you run into cases in which false or non used flags send analytics data and then the flags are considered to be evaluated.

To be honest it's a recommendation they made. I will try out a local build to see what we get over the wire prior to merging this.

Thanks for the explanation. I think I know understand better what we're trying to do. 👍

[tdeekens]

It doesn't seem to solve the issue but it should reduce a lot of networking we don't need/want anyway at this time.