You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@makeTransaction
MyReactComponent extends React {
initialize(){}
render() {}
}
@makeTransaction
MySomethingFunction extends Unknown {
// does stuff, may be Modals,Widgets, Tooltips, or something else
// same stuff we auto-instrument (http, database) will keep getting captured as spans
}}
and then MyReactComponent and MySomethingFunction should appear here as dedicated items in the Peformance Dashboard along with 'Home' 'Cart' 'Checkout' in the below screenshot.
Maybe decorate an entire Class so you don't have to do this per function. Hmm maybe this is not any different than instrumenting a Custom Span? Not sure.
If moving away from transactions towards a 'span based' approach then call it @makeSpan. Do not require user to then instrument every sub-span, that'd be an incredible amount of work. UI.load, user-interactions, file i/o, db, http, async, all these things shoould just appear if the decorator was used.
Problem: not everything falls under 'ui.load' or 'navigation' or 'ui.action.touch'. Sometimes the UI they care about is one single ui component out of 10 ui components rendered in a single HomeScreen, but they wanted it treated as more of a first-class entity. Currently they just see 'HomeScreen' as the transaction but they'd rather see the sub-component, maybe it's called 'FoodItems' and then there's 'Restaurants' and 'Delivery' components too all in the home screen but it's too over-aggressive to have it grouped into a single HomeScreen.
The text was updated successfully, but these errors were encountered:
Thanks for the message,
I agree that in some apps grouping per screen is too general and the respective code owners are only interested in ComponentA and ComponentB.
I don't think any new API or decorator is need to solve this. When Sentry operates only based on spans, developer will be able to look up the appropriate spans which can be created by Sentry.startSpan or Sentry.withProfiler.
Until then forceTransaction can be used to capture the wanted data. This ensures the created span shows up in Sentry UI as transaction. The auto instrumented span won't be attached to this transaction. This is not possible because we can have only one active span on the scope, and the case of multiple components on one screen would require multiple active spans.
and then
MyReactComponent
andMySomethingFunction
should appear here as dedicated items in the Peformance Dashboard along with 'Home' 'Cart' 'Checkout' in the below screenshot.Maybe decorate an entire Class so you don't have to do this per function. Hmm maybe this is not any different than instrumenting a Custom Span? Not sure.
If moving away from transactions towards a 'span based' approach then call it
@makeSpan
. Do not require user to then instrument every sub-span, that'd be an incredible amount of work. UI.load, user-interactions, file i/o, db, http, async, all these things shoould just appear if the decorator was used.Problem: not everything falls under 'ui.load' or 'navigation' or 'ui.action.touch'. Sometimes the UI they care about is one single ui component out of 10 ui components rendered in a single HomeScreen, but they wanted it treated as more of a first-class entity. Currently they just see 'HomeScreen' as the transaction but they'd rather see the sub-component, maybe it's called 'FoodItems' and then there's 'Restaurants' and 'Delivery' components too all in the home screen but it's too over-aggressive to have it grouped into a single HomeScreen.
The text was updated successfully, but these errors were encountered: