-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ObsUx] Add feedback form to apm #173758
[ObsUx] Add feedback form to apm #173758
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
…b.com/jennypavlova/kibana into 172506-obsux-add-feedback-form-to-apm
/ci |
Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👏 ! The form is pre-filled as expected. Didn't test all possible combinations though.
Left a few minor coments.
@@ -29,6 +29,9 @@ const HOSTS_FEEDBACK_LINK = | |||
|
|||
export const HostsPage = () => { | |||
const { isLoading, loadSourceFailureMessage, loadSource, source } = useSourceContext(); | |||
const { | |||
services: { kibanaVersion, isCloudEnv, isServerlessEnv }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just realized that kibanaVersion
,isCloudEnv
, and isServerlessEnv
are under services
. Should we move them out of the services
object? They are just flags and not actual services
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to have a separate object here in the context for those values? Should we call it kibanaEnvironment or kibanaSettings maybe? (those flags are about the kibana deployment/version so not sure what the best name is 🤔 wdyt?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed I picked kibanaEnvironment
and added the changes here
const constructPath = `/${[pathParts[1], pathParts[2], pathParts[3]].join( | ||
'/' | ||
)}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: You could use slice
here. Should we be worried if pathParts length is less than 3?
const constructPath = `/${[pathParts[1], pathParts[2], pathParts[3]].join( | |
'/' | |
)}`; | |
const constructPath = `/${pathParts.slice(1, 4)].join( | |
'/' | |
)}`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed, thanks ✅
}; | ||
|
||
export const getPathForFeedback = (path: string) => { | ||
const pathStartingFromApp = shortenPath(path, '/app'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a safer way to get this /app
? I tried to find some constant or service that would provide this base path, but couldn't find any
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find it as a constant, I see it is used as a string in other places. I defined a constant here so we can reuse it in case we need to have it somewhere else
x-pack/plugins/apm/public/plugin.ts
Outdated
kibanaVersion?: string; | ||
isCloudEnv: boolean; | ||
isServerlessEnv: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are not services, is there any other place we can move these flags into?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are inside ApmPluginStartDeps
only telemetry
is in ApmServices
. Indeed, they are not service, where do you think we should put them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we pass them directly to renderApp
?
…b.com/jennypavlova/kibana into 172506-obsux-add-feedback-form-to-apm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the long term we are planning to remove the KibanaReactContext
utility, so ideally you would not add new functionality to it. Instead you could create a new React context to pass you KibanaEnvironment
state.
export const myEnvContext = React.createContext(/* ... */);
@vadimkibana Thank you for your review and for letting me know, I didn't know that. I moved the context inside of the plugins. And I reverted the changes inside the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey Jenny. I took another look at it, and I'm just concerned about the stuff we're adding to PluginStartDeps, both in infra (possibly tech debt) and now in APM.
If we compare with the rest of the code base, the start deps are supposed to be used for dependencies with other plugins and these flags don't quite fit in this scenario. Might just be me worrying too much, so I'd like to hear your opinion on this.
isCloudEnv, | ||
isServerlessEnv, | ||
kibanaVersion: this.kibanaVersion, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering whether these could go into a separate object named kibanaEnv
or something like that and decouple them from pluginsStart
.
The only difference is that in the renderApp
we would add another property to apmPluginContextValue
.
The same goes for what we currently have in the infra
plugin.
My concern is that we're adding things that are not related to plugin dependencies in the pluginsStart
object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the comments! IMO the Kibana environment data belongs to the KibanaReactContext
as it's something related to the Kibana environment and it's not part of the plugin ( as it is the same for all plugins and it's something that we get as a dependency - same as the services and it should be shared ) But based on the comment this context will be removed so I am not sure if we want to keep the concept of sharing a context (as package/utility) and reuse it. I don't know what will replace the KibanaReactContext
but it can be a good place to have this environment-specific data independently there.
So you are right that with the last changes is better to get them out of the pluginsStart
. I will do that and I think for now we can keep them in the plugin context until we find a better solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So for both infra and apm now I am passing kibanaEnvironment
object separately, can you please take a look again :)
@@ -70,11 +73,15 @@ export const CoreProviders: React.FC<CoreProvidersProps> = ({ | |||
pluginStart | |||
); | |||
|
|||
const MyEnvContextForPluginProvider = useKibanaEnvironmentContextProvider(plugins); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: completely up to you
const MyEnvContextForPluginProvider = useKibanaEnvironmentContextProvider(plugins); | |
const KibanaEnvContextForPluginProvider = useKibanaEnvironmentContextProvider(plugins); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, thanks ✅
a8c2a00
to
09d17d5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks for making the changes :)
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
Closes elastic#172506 ## Summary This PR adds a button to all APM pages navigating to a feedback form. The feedback button component exists in infra so in this PR the component is changed to meet the new requirements and moved to `observability_shared`. Now the feedback button component supports also prefilling the sanitized path (`entry.1876422621`). The requirements picked for the sanitized path are described in the issue - it should be for example `/app/apm/{page_name}` if the user is on the page with the exact path matching `/app/apm/{page_name}` and `/app/apm/{page_name}*` for all subpages (for example `/app/apm/{page_name}/something/else`) - different test scenarios can be found in the unit test: [get_path_for_feedback.test.ts](https://github.com/elastic/kibana/compare/main...jennypavlova:kibana:172506-obsux-add-feedback-form-to-apm?expand=1#diff-6396807e61353509c44fa38488dfb741549e60f25126024b92596f6b7ac933b8) ## Testing - Go to APM - All APM pages should have a yellow button with the text: `Tell us what you think!` - Hover on the button to see the prefilled properties and check if every property is prefilled <img width="1920" alt="image" src="https://github.com/elastic/kibana/assets/14139027/b57adf04-4e7b-42bb-827f-db554dc4a842"> - Click on the form and check if the form is prefilled - The questions that should be prefilled in APM - Where is your Elastic cluster deployed? (same as infra) - By default, the pre-selected option will be on-prem - To test the case with the cloud option preselected add `xpack.cloud.id: 'elastic_kibana_dev'` to your `kibana.dev.yaml` - To test the serverless option run Kibana in serverless mode (observability config) - What version of Elastic are you using? (same as infra) - Where in the UI are you? - After checking the APM go to the infra pages and check the feedback button/form https://github.com/elastic/kibana/assets/14139027/52cc886f-95a9-4099-b047-93fc64036572
Closes #172506
Summary
This PR adds a button to all APM pages navigating to a feedback form. The feedback button component exists in infra so in this PR the component is changed to meet the new requirements and moved to
observability_shared
. Now the feedback button component supports also prefilling the sanitized path (entry.1876422621
). The requirements picked for the sanitized path are described in the issue - it should be for example/app/apm/{page_name}
if the user is on the page with the exact path matching/app/apm/{page_name}
and/app/apm/{page_name}*
for all subpages (for example/app/apm/{page_name}/something/else
) - different test scenarios can be found in the unit test: get_path_for_feedback.test.tsTesting
Tell us what you think!
xpack.cloud.id: 'elastic_kibana_dev'
to yourkibana.dev.yaml
test_apm_feedback.mov