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
Chore: Remove angular dependency from data sources #27735
Conversation
@@ -316,3 +316,5 @@ export function getTimeSrv(): TimeSrv { | |||
} | |||
|
|||
coreModule.service('timeSrv', TimeSrv); | |||
|
|||
export default getTimeSrv(); |
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 think we should try to avoid default exports.
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.
Aha ok, I see what you're doing in the rest of the PR.
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 but I wasn't aware that we had exported TemplateSrv as default which is a pattern that we've previously tried to avoid.
Another thing that came up during the review is that datasource plugins should depend on @grafana/runtime and not files under app/features...
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.
Nice!
yes, if possible would be better to get function and types from @grafana/runtime (but might be some cases where there are functions that are used that are not part of the public interface).
There are indeed some situations where data sources use |
For those cases you can keep using the internal ones for now. |
But I would still avoid export default |
9c1cd0c
to
cdad148
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 good. Not super happy with getTemplateSrv().replace in many places harder to read than templateSrv.replace . The idea behind the get functions was to help in jest mocks and with lazy eval of a singleston but this was before I knew you can have module variables that you can change and have that impact all places that already imported that variable.
So we could technically stop with the get functions and just export/import the singleton variable instead. Maybe a good topic to discuss on a frontend weekly :)
Shouldn't we try to use grafana/runtime in all the cases except the ones that use more then the exported functions? |
I think we should and I believe this is what we did until now. |
@@ -69,7 +69,7 @@ export class DashboardRow extends React.Component<DashboardRowProps, any> { | |||
'dashboard-row--collapsed': this.state.collapsed, | |||
}); | |||
|
|||
const title = templateSrv.replace(this.props.panel.title, this.props.panel.scopedVars, 'text'); | |||
const title = getTemplateSrv().replace(this.props.panel.title, this.props.panel.scopedVars, 'text'); |
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.
This component uses only the replace function, should be ok to just import getTemplateSrv
from grafana/runtime?
@@ -131,7 +131,7 @@ export class PanelHeader extends Component<Props, State> { | |||
render() { | |||
const { panel, scopedVars, error, isViewing, isEditing, data, alertState } = this.props; | |||
const { menuItems } = this.state; | |||
const title = templateSrv.replace(panel.title, scopedVars, 'text'); | |||
const title = getTemplateSrv().replace(panel.title, scopedVars, 'text'); |
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.
This component uses only the replace function, should be ok to just import getTemplateSrv
from grafana/runtime?
@kaydelaney maybe I'm just tired :) but I can still find components that only use the |
6a76fc7
to
06f9eb3
Compare
@@ -138,5 +138,5 @@ const getTemplatedRegex = (variable: QueryVariableModel): string => { | |||
return ''; | |||
} | |||
|
|||
return templateSrv.replace(variable.regex, {}, 'regex'); | |||
return getTemplateSrv().replace(variable.regex, {}, 'regex'); |
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.
Maybe runtime import for this one?
@@ -245,7 +245,7 @@ export function createMetricLabel(labelData: { [key: string]: string }, options? | |||
let label = | |||
options === undefined || _.isEmpty(options.legendFormat) | |||
? getOriginalMetricName(labelData) | |||
: renderTemplate(templateSrv.replace(options.legendFormat ?? '', options.scopedVars), labelData); | |||
: renderTemplate(getTemplateSrv().replace(options.legendFormat ?? '', options.scopedVars), labelData); |
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.
This seems to be a runtime import too
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.
Fantastic work Kay, found some more places that I think could use a runtime import
Also uses @grafana/runtime versions of the interfaces where possible
06f9eb3
to
f71135c
Compare
* Chore: Remove angular dependency from data sources * Removes default export for time and template srvs Also uses @grafana/runtime versions of the interfaces where possible * Replace usage of internal templateSrv where possible * Use runtime templateSrv in a couple more places
What this PR does / why we need it:
Removes the use of
@ngInject
for dependency injection from data sources. Dependency injection is still used, but is done through default parameters. In some cases this can simplify testing since the ceremony of jest mocks is no longer required.Builds upon some earlier work by @hugohaggmark (#23048)