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

Remove private module dependencies from field formatters #12239

Merged
merged 18 commits into from
Jun 19, 2017

Conversation

nreese
Copy link
Contributor

@nreese nreese commented Jun 8, 2017

The PR removes all private module dependencies from field formatters. The PR is phase 1 for exposing field formatters on the server.

@nreese nreese changed the title [WIP] Remove front-end dependencies from field formatters Remove private module dependencies from field formatters Jun 13, 2017
@nreese nreese requested review from spalger and kimjoar June 13, 2017 21:20
Copy link
Contributor

@spalger spalger left a comment

Choose a reason for hiding this comment

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

A couple suggestions, one bug, and a spot of cleanup. But look great

@@ -0,0 +1,7 @@
export function ConfigProvider(config) {
return {
getConfig: (key, defaultValue) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

What value do you see in this service, over just defining const getConfig = (...args) => config.get(...args) above where it's used?

let TestFormat;

beforeEach(ngMock.module('kibana'));
beforeEach(ngMock.inject(function (Private) {
FieldFormat = Private(IndexPatternsFieldFormatProvider);
beforeEach(ngMock.inject(function () {
Copy link
Contributor

Choose a reason for hiding this comment

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

You can remove the ngMock stuff now that this doesn't need angular.

return getHighlightHtml(formatted, hit.highlight[field.name]);
}
// format a list of values. In text contexts we just use JSON encoding
return toJson(value.map(recurse), true);
Copy link
Contributor

Choose a reason for hiding this comment

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

This toJson function behaves like JSON.stringify(), the second argument is a replacer (boolean isn't compatible)


return Class;
Class.prototype.getParamDefaults = function () {
const paramDefaults = _.get(opts, 'paramDefaults', {});
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not a huge fan of splitting the param defaults up like this. What about something like this?

Class.prototype.getParamDefaults = function () {
  if (_.has(opts, 'getParamDefaults')) {
    return opts.getParamDefaults(this.getConfig)
  }

  return {
    pattern: this.getConfig(`format:${opts.id}:defaultPattern`)
  }
}

Then the instances can specify the getParamDefaults(getConfig) option and read config themselves.

@nreese
Copy link
Contributor Author

nreese commented Jun 14, 2017

Hold off on reviewing. Looks like this PR messed up field format editors. I need to clean that up

@nreese
Copy link
Contributor Author

nreese commented Jun 14, 2017

Field format editors have been fixed. Review away.

Copy link
Contributor

@spalger spalger left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@kimjoar kimjoar left a comment

Choose a reason for hiding this comment

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

just some nits, lgtm

}

export const contentTypes = {
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick:

export const contentTypes = { types, setup }

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is there a concern of naming collisions? Should setup and types get some kind of prefix to make them more unique?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looks like types is never even used by any external modules. I will just export setup as contentTypesSetup.

if (!value || typeof value.map !== 'function') {
return convert.call(format, value);
}
const subVals = value.map(function (v) {
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick: Maybe clean up some of these too:

const subVals = value.map(v => recurse(v, field, hit));

Same for useMultiLine

export function IndexPatternsFieldFormatProvider(config, $rootScope, Private) {
const contentTypes = Private(IndexPatternsFieldFormatContentTypesProvider);
export function FieldFormat(params) {
const self = this;
Copy link
Contributor

Choose a reason for hiding this comment

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

we can just remove this and rely on this instead here, I think


/**
* Get parameter defaults
* @param {string} [contentType=text]
Copy link
Contributor

Choose a reason for hiding this comment

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

bug ^? (no param used below)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just a copy and paste error

}

Source.id = '_source';
Source.title = '_source';
Source.fieldType = '_source';

Source.prototype._convert = {
text: angular.toJson,
text: (value) => {
return toJson(value);
Copy link
Contributor

Choose a reason for hiding this comment

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

why this change? If relevant, maybe we should add a comment that explains it?

Also, this can be: text: (value) => toJson(value). No need for {} here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@spalger recommended this to make things more clear

@nreese nreese merged commit 86d32da into elastic:master Jun 19, 2017
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.

4 participants