Skip to content

[APM] Consistent flyout headers - #46312

Merged
dgieselaar merged 3 commits into
elastic:masterfrom
dgieselaar:consistent-flyout-headers
Sep 25, 2019
Merged

dgieselaar merged 3 commits into
elastic:masterfrom
dgieselaar:consistent-flyout-headers

Conversation

@dgieselaar

@dgieselaar dgieselaar commented Sep 22, 2019 •

Copy link
Copy Markdown
Contributor

Closes #46078 and #46074.

Trace summary:
image

=>

image


Transaction details flyout:
image

=>

image


Span details flyout:
image

=>

image


Error occurrence summary:
image

=>

image

@elasticmachine

Copy link
Copy Markdown
Contributor

💔 Build Failed

@dgieselaar
dgieselaar force-pushed the consistent-flyout-headers branch 2 times, most recently from 3a45c60 to 66c91d1 Compare September 23, 2019 09:09
@dgieselaar

Copy link
Copy Markdown
Contributor Author

Really like how this looks, great work from the design team 👍. Do the badges perhaps need tooltips to explain type/subtype/action?

@dgieselaar
dgieselaar marked this pull request as ready for review September 23, 2019 09:13
@dgieselaar
dgieselaar requested a review from a team September 23, 2019 09:13
@formgeist

Copy link
Copy Markdown
Contributor

Do the badges perhaps need tooltips to explain type/subtype/action?

Yes, I think those are still necessary on hover.

@elasticmachine

Copy link
Copy Markdown
Contributor

💚 Build Succeeded

@sorenlouv

sorenlouv commented Sep 23, 2019 •

Copy link
Copy Markdown
Contributor

I like this. Great work 👍
I feel the separator below the "[Name] / Service / Transaction" section is still needed. What do you think @formgeist ?

@formgeist

Copy link
Copy Markdown
Contributor

I feel the separator below the "[Name] / Service / Transaction" section is still needed. What do you think @formgeist ?

Tbh, I think there are already too many grey dividers in the flyouts, so I'd rather go ahead without since now there's also a big enough difference in their styles. Before we had the same label/value look and feel.

Screenshot 2019-09-23 at 13 28 51

@formgeist formgeist left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a minor addition; looks very good @dgieselaar

Btw. did we settle on including the user.agent data in this PR?

@sorenlouv sorenlouv Sep 23, 2019 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of having a labels object you can use the select operator:

'The % of {parentType, select, span {span} trace {trace} other {transaction}} exceeds 100% because this {childType, select, span {span} trace {trace} other {transaction}} takes longer than the root transaction.'

@sorenlouv sorenlouv Sep 23, 2019 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To re-use the select you can probably do something like:

const getTranslatedType = type => i18n.translate('xpack.apm.transactionDetails.type', '{type, select, span {span} trace {trace} other {transaction}}', { type });

@sorenlouv sorenlouv Sep 23, 2019 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually... I'm not sure this is better... 🤔 You decide.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

select is much better indeed. I've used your first suggestion (with some minor changes).

@sorenlouv sorenlouv Sep 23, 2019 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps move this into Summary/index.tsx and change the type to:

items: Array<React.ReactElement | undefined>;

This way we can avoid the as React.ReactElement[] and falsy values are automatically removed

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to recall if this is still necessary. In 6.x we used to only have the type field with dots as delimiter. But to move to 7.x the user had to migrate their data afair. So maybe this is no longer necessary? If you remove it you might want to double check with apm server team.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked with the server team, it can be removed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good use-case for the null coalesce operator you ranted about :p

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like that operator! I'm just empathetic towards the people that have to write the parsers 😬

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using arbitrary units feels wrong.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only way I can get the error badge to align with the other badges. I think that's because the others are wrapped in a tooltip which adds a padding/margin one way or the other. Do you have any suggestions?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm getting nitpicky; Even with that added margin, the error badge is higher up than the other badges.

Screenshot 2019-09-25 at 14 52 08

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think aligning it vertically (with flexbox or similar) is usually better than doing it manually based on pixels.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've now opted for px(units.eighth). I tried centering it vertically but I couldn't get it to work in a reasonable amount of time.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

result is a bit generic. What do you think about transactionResult to be more clear?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Also renamed the component to TransactionResultSummaryItem.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is not re-used anywhere, perhaps better to keep it in TransactionSummary?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved it to TransactionSummary.tsx.

@sorenlouv sorenlouv left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few nits. LGTM

@elasticmachine

Copy link
Copy Markdown
Contributor

💚 Build Succeeded

@dgieselaar
dgieselaar force-pushed the consistent-flyout-headers branch from f7eea3c to 8723da1 Compare September 25, 2019 13:22
import { px, units } from '../../../../public/style/variables';

interface Props {
items: Array<React.ReactElement | null | undefined>;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why both null and undefined? Can't we pick one?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can, but that puts the onus on the consumer of this component to make sure that any falsey value is either null or undefined, which is not the case right now because we use {condition} && {component} in some places, rather than {condition} ? {component} : null.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(another great use case for the null-coalescing operator)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, good point. Leave it be.

: idx(transaction, _ => _.url.full);

if (url) {
const method = idx(transaction, _ => _.http.request.method) || '';

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps make method optional, and then handle the undefined state in HttpInfoSummaryItem.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My assumption was that method is always set when url is set, and I just need to trick TS. Is that assumption incorrect?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think transactions from the RUM agent has the method property. It creates a separate span for outgoing http requests.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good one, I'll check.

@elasticmachine

Copy link
Copy Markdown
Contributor

💚 Build Succeeded

@formgeist

Copy link
Copy Markdown
Contributor

@dgieselaar Just checking, but since you added the timezone to the absolute timestamp tooltip, do you reckon we close this issue too? #46074

@smith smith left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

You might want to check with @katrin-freihofner if you haven't already about having the request method be bold.

<HttpInfoBadge title={undefined}>
<EuiToolTip content={methodLabel}>
<strong>{method}</strong>
<>{method.toUpperCase()}</>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was bold in the designs previously. Did we decide to change it?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@smith @katrin-freihofner I decided to remove the strong because it was rendering the label a little too strong IMO. I suppose I get that we wanted to differentiate between request method and URL, but is it really that important?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I originally suggested it, to differentiate it from the URL. I'm okay with removing it though

@dgieselaar

Copy link
Copy Markdown
Contributor Author

@formgeist:

@dgieselaar Just checking, but since you added the timezone to the absolute timestamp tooltip, do you reckon we close this issue too? #46074

yeah, let's close it. I've added it to the description.

@dgieselaar
dgieselaar merged commit bca9750 into elastic:master Sep 25, 2019
@dgieselaar
dgieselaar deleted the consistent-flyout-headers branch September 25, 2019 18:11
dgieselaar added a commit to dgieselaar/kibana that referenced this pull request Sep 25, 2019
* [APM] Consistent flyout headers

Closes elastic#46078 and elastic#46074.

* Tooltips for span flyout badges

* Review feedback
dgieselaar added a commit to dgieselaar/kibana that referenced this pull request Sep 26, 2019
In elastic#46312, we moved the service name property to the StickySpanProperties component. However, the import of SERVICE_NAME was incorrect, resulting in the tooltip showing the string 'licensing' instead of 'service.name'. The import now correctly points at our elasticsearch field names file.
dgieselaar added a commit that referenced this pull request Sep 26, 2019
* [APM] Consistent flyout headers (#46312)

* [APM] Consistent flyout headers

Closes #46078 and #46074.

* Tooltips for span flyout badges

* Review feedback

* Fix import for SERVICE_NAME in StickySpanProperties
dgieselaar added a commit that referenced this pull request Sep 27, 2019
In #46312, we moved the service name property to the StickySpanProperties component. However, the import of SERVICE_NAME was incorrect, resulting in the tooltip showing the string 'licensing' instead of 'service.name'. The import now correctly points at our elasticsearch field names file.
@sorenlouv sorenlouv added the apm:test-plan-done Pull request that was successfully tested during the test plan label Oct 21, 2019
@sorenlouv

Copy link
Copy Markdown
Contributor

Test plan: verified ✅

patrykkopycinski pushed a commit to patrykkopycinski/kibana that referenced this pull request May 6, 2026
* [APM] Consistent flyout headers

Closes elastic#46078 and elastic#46074.

* Tooltips for span flyout badges

* Review feedback
patrykkopycinski pushed a commit to patrykkopycinski/kibana that referenced this pull request May 6, 2026
In elastic#46312, we moved the service name property to the StickySpanProperties component. However, the import of SERVICE_NAME was incorrect, resulting in the tooltip showing the string 'licensing' instead of 'service.name'. The import now correctly points at our elasticsearch field names file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

apm:test-plan-done Pull request that was successfully tested during the test plan release_note:enhancement v7.5.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[APM] Consistent flyout headers

5 participants