Skip to content
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

Merged
merged 5 commits into from Oct 1, 2020

Conversation

kaydelaney
Copy link
Contributor

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)

@kaydelaney kaydelaney requested review from hugohaggmark and a team September 23, 2020 16:03
@kaydelaney kaydelaney requested review from a team as code owners September 23, 2020 16:03
@kaydelaney kaydelaney self-assigned this Sep 23, 2020
@kaydelaney kaydelaney added this to In Review in Frontend Platform Backlog via automation Sep 23, 2020
@kaydelaney kaydelaney requested review from peterholmberg, aknuds1, kylebrandt and aocenas and removed request for a team September 23, 2020 16:03
@aknuds1 aknuds1 removed their request for review September 23, 2020 16:06
@@ -316,3 +316,5 @@ export function getTimeSrv(): TimeSrv {
}

coreModule.service('timeSrv', TimeSrv);

export default getTimeSrv();
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

@hugohaggmark hugohaggmark left a 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...

Copy link
Member

@torkelo torkelo left a 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).

@kaydelaney
Copy link
Contributor Author

There are indeed some situations where data sources use TemplateSrv methods that aren't part of the public interface, for example the influx data source makes use of templateSrv.variableExists and templateSrv.getAdhocFilters.
Should these methods perhaps get added to the public interface? @torkelo

@torkelo
Copy link
Member

torkelo commented Sep 24, 2020

For those cases you can keep using the internal ones for now.

@torkelo
Copy link
Member

torkelo commented Sep 24, 2020

But I would still avoid export default

Copy link
Member

@torkelo torkelo left a 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 :)

@hugohaggmark
Copy link
Contributor

Shouldn't we try to use grafana/runtime in all the cases except the ones that use more then the exported functions?

@dprokop
Copy link
Member

dprokop commented Sep 25, 2020

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');
Copy link
Contributor

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');
Copy link
Contributor

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?

@hugohaggmark
Copy link
Contributor

@kaydelaney maybe I'm just tired :) but I can still find components that only use the replace function which means that we could use the getTemplateSrv from grafana/runtime

@@ -138,5 +138,5 @@ const getTemplatedRegex = (variable: QueryVariableModel): string => {
return '';
}

return templateSrv.replace(variable.regex, {}, 'regex');
return getTemplateSrv().replace(variable.regex, {}, 'regex');
Copy link
Contributor

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);
Copy link
Contributor

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

Copy link
Contributor

@hugohaggmark hugohaggmark left a 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

@kaydelaney kaydelaney merged commit 1854421 into master Oct 1, 2020
Frontend Platform Backlog automation moved this from In Review to Done Oct 1, 2020
@kaydelaney kaydelaney deleted the datasource-services branch October 1, 2020 17:51
ryantxu pushed a commit that referenced this pull request Nov 18, 2020
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants