[cloud] Create IFRAME chat component; add to Unified Integrations

[clintandrewhall]

Summary

Based on the code and feedback from #123339

This PR creates the Chat component for Cloud and adds it to Unified Integrations.

Testing

You can test the component in Storybook: /kibana yarn storybook cloud

You can also test locally by adding the following to kibana.dev.yml:

xpack.cloud.id: "some-id"
xpack.cloud.chat.enabled: true
xpack.cloud.chat.chatURL: "https://elasticcloud-production-chat-us-east-1.s3.amazonaws.com/drift-iframe.html"
xpack.cloud.chatIdentitySecret: "some-secret" <- you have to get this from the Drift Widget Security console

Integration tests can be run by adding CHAT_URL and CHAT_IDENTITY_SECRET to both the functional test server and runner:

CHAT_URL="some-url" CHAT_IDENTITY_SECRET="some-secret" node scripts/functional_tests_server.js --config x-pack/test/cloud_integration/config.ts
CHAT_URL="some-url" CHAT_IDENTITY_SECRET="some-secret" node scripts/functional_test_runner.js --config x-pack/test/cloud_integration/config.ts

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[lukeelmers]

First pass; added a handful of comments with some ideas on how to simplify. I'm admittedly not a storybook expert, so I focused mainly on the rest of the changes to cloud.

Still needs tests, but overall I think it makes sense so far.

[lukeelmers]

nit

Suggested change

	import { defaultConfig } from '@kbn/storybook';
	module.exports = defaultConfig;
	export { defaultConfig } from '@kbn/storybook';

[clintandrewhall]

FFR: Storybook crashes if you do this.

[lukeelmers]

really? interesting

[clintandrewhall]

@elasticmachine merge upstream

[SergeyPoluektov]

@osmanis To be clear, you're saying Drift has all it needs to hide the chat iframe without Kibana sending any additional information? Because, at present, the chat icon always appears. It doesn't appear that any rules are currently in place to not display it.

@clintandrewhall I can confirm that Drift already will have all the user data it needs to control the chat display logic by the time a user visits Kibana. We assume that a user visits Kibana after they visit Cloud UI and a user in Kibana has the same email as a user in Cloud UI. In that case we already have sent all the relevant data over to Drift (trial status, domain, etc). And at the moment a user visits Kibana we send a user's email to a Drift as a part of SET_CONTEXT message. That means that Drift can match a user up by email and apply predefined rules to display or hide a chat in Kibana.

At present the chat icon always appears because there is a playbook in Drift matching a visitor context (see screenshot).

If we remove that playbook, then no playbook is matched, then no chat icon displayed in Kibana.

[clintandrewhall]

@pgayvallet I started with its own plugin in #123339. 🤷

It's going to be placed in a few plugins, yes. I think if we hit a circular dependency, we'll have to extract it out. I'll take a look when I'm back at my desk, see if we have a conflict.

Thank you so much for your review, as well!!

[lukeelmers]

I started with its own plugin in #123339. 🤷

It's going to be placed in a few plugins, yes. I think if we hit a circular dependency, we'll have to extract it out. I'll take a look when I'm back at my desk, see if we have a conflict.

I had advocated for keeping this centralized in the Cloud plugin until we have an agreed-upon long term plan (Clint is cooking up an RFC for that). My reasoning was mainly that we could have 3rd party code -- Fullstory & Drift -- living in one place in Kibana, which would make it very clear to on-prem users where cloud-specific code lives, and give us some assurance that this code would never run unless explicitly configured in a cloud deployment.

But I agree that eventually we'll need a generalized solution for handling 3rd party code in Kibana, and due to the existing cloud plugin dependencies, this may need to be its own plugin.

[clintandrewhall]

@elasticmachine merge upstream

[pgayvallet]

It's going to be placed in a few plugins, yes. I think if we hit a circular dependency, we'll have to extract it out

But I agree that eventually we'll need a generalized solution for handling 3rd party code in Kibana, and due to the existing cloud plugin dependencies, this may need to be its own plugin.

Keeping it in the cloud plugin until we encounter such cyclic dependencies issues is fine with me, I just wanted to point this out in case it was overlooked in the design decision.

[clintandrewhall]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 3743c5c
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
cloud	11	18	+7

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
cloud	22	23	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
cloud	12.3KB	14.2KB	+1.9KB
fleet	644.5KB	644.7KB	+192.0B
total			+2.1KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
cloud	6.5KB	8.5KB	+2.0KB
fleet	112.8KB	113.0KB	+223.0B
total			+2.2KB

Unknown metric groups

API count

id	before	after	diff
cloud	22	28	+6

async chunk count

id	before	after	diff
cloud	1	2	+1

ESLint disabled line counts

id	before	after	diff
actions	27	25	-2
cloud	5	7	+2
total			-0

References to deprecated APIs

id	before	after	diff
cloud	1	2	+1

Total ESLint disabled count

id	before	after	diff
actions	32	30	-2
cloud	7	9	+2
total			-0

History

• 💚 Build #20563 succeeded 7e078f5
• 💚 Build #20559 succeeded a9e65a4
• 💚 Build #20529 succeeded 4b56959
• 💚 Build #20463 succeeded 85f9504
• 💚 Build #19944 succeeded c5a5059
• 💔 Build #19936 failed 2926d14

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[lukeelmers]

Overall I am comfortable with where we ended up on this. Thanks for all your patience @clintandrewhall ❤️

Could we wait to merge until Monday afternoon (NASA time) so that @pgayvallet has an opportunity to provide any remaining feedback he may have?

[pgayvallet]

LGTM. Thanks for the observable changes

[ymao1]

ResponseOps changes LGTM!