Repository navigation
[APM] Consistent flyout headers - #46312
Conversation
💔 Build Failed |
3a45c60 to
66c91d1
Compare
|
Really like how this looks, great work from the design team 👍. Do the badges perhaps need tooltips to explain type/subtype/action? |
Yes, I think those are still necessary on hover. |
💚 Build Succeeded |
|
I like this. Great work 👍 |
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. |
formgeist
left a comment
There was a problem hiding this comment.
Just a minor addition; looks very good @dgieselaar
Btw. did we settle on including the user.agent data in this PR?
There was a problem hiding this comment.
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.'There was a problem hiding this comment.
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 });There was a problem hiding this comment.
Actually... I'm not sure this is better... 🤔 You decide.
There was a problem hiding this comment.
select is much better indeed. I've used your first suggestion (with some minor changes).
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Checked with the server team, it can be removed.
There was a problem hiding this comment.
This is a good use-case for the null coalesce operator you ranted about :p
There was a problem hiding this comment.
I really like that operator! I'm just empathetic towards the people that have to write the parsers 😬
There was a problem hiding this comment.
Using arbitrary units feels wrong.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I think aligning it vertically (with flexbox or similar) is usually better than doing it manually based on pixels.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
result is a bit generic. What do you think about transactionResult to be more clear?
There was a problem hiding this comment.
Fixed. Also renamed the component to TransactionResultSummaryItem.
There was a problem hiding this comment.
Since this is not re-used anywhere, perhaps better to keep it in TransactionSummary?
There was a problem hiding this comment.
Moved it to TransactionSummary.tsx.
💚 Build Succeeded |
f7eea3c to
8723da1
Compare
| import { px, units } from '../../../../public/style/variables'; | ||
|
|
||
| interface Props { | ||
| items: Array<React.ReactElement | null | undefined>; |
There was a problem hiding this comment.
Why both null and undefined? Can't we pick one?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
(another great use case for the null-coalescing operator)
There was a problem hiding this comment.
Okay, good point. Leave it be.
| : idx(transaction, _ => _.url.full); | ||
|
|
||
| if (url) { | ||
| const method = idx(transaction, _ => _.http.request.method) || ''; |
There was a problem hiding this comment.
Perhaps make method optional, and then handle the undefined state in HttpInfoSummaryItem.
There was a problem hiding this comment.
My assumption was that method is always set when url is set, and I just need to trick TS. Is that assumption incorrect?
There was a problem hiding this comment.
I don't think transactions from the RUM agent has the method property. It creates a separate span for outgoing http requests.
There was a problem hiding this comment.
Good one, I'll check.
💚 Build Succeeded |
|
@dgieselaar Just checking, but since you added the timezone to the absolute timestamp tooltip, do you reckon we close this issue too? #46074 |
smith
left a comment
There was a problem hiding this comment.
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()}</> |
There was a problem hiding this comment.
This was bold in the designs previously. Did we decide to change it?
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
I think I originally suggested it, to differentiate it from the URL. I'm okay with removing it though
yeah, let's close it. I've added it to the description. |
* [APM] Consistent flyout headers Closes elastic#46078 and elastic#46074. * Tooltips for span flyout badges * Review feedback
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.
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.
|
Test plan: verified ✅ |
* [APM] Consistent flyout headers Closes elastic#46078 and elastic#46074. * Tooltips for span flyout badges * Review feedback
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.
Closes #46078 and #46074.
Trace summary:

=>
Transaction details flyout:

=>
Span details flyout:

=>
Error occurrence summary:

=>