-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
removes angular from fieldFormatts #17581
removes angular from fieldFormatts #17581
Conversation
ppisljar
commented
Apr 5, 2018
•
edited
Loading
edited
- Angular dependency is removed from field formatts (pretty much just removing the provider wrapper)
- FieldFormatterRegistry is refactored to not depend on angular
function init() { | ||
config.watch('format:defaultTypeMap', parseDefaultTypeMap); | ||
} | ||
this._config.subscribe(({ key, newValue }) => { |
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.
@spalger: i am not sure why the watch was used here and i couldn't get this subscribe to fire ... do we need this ? if so does it look correct ? when would we need to unsubscribe ?
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.
It is called whenever the uiSettings change, seems to be working when I test it:
when would we need to unsubscribe ?
That's a good question... I don't think we need to unsubscribe since the fieldFormatsRegistry is never torn down, but I'm concerned how that will work with tests, especially since the uiSettingsClient
is currently stubbed out for each test https://github.com/elastic/kibana/blob/master/src/ui/public/test_harness/test_harness.js#L33-L49
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.
How about we add this as another method on the chrome
object, like https://github.com/elastic/kibana/blob/master/src/ui/public/chrome/api/ui_settings.js#L12-L14, and then stub it out in the tests just like we do for the uiSettings
client. Then I'll prioritize migrating the uiSettings
and fieldFormats
services over to the new platform once we have that plumbing in place.
💔 Build Failed |
createSomeFormat(FieldFormat) | ||
)); | ||
}, | ||
this._config = chrome.getUiSettingsClient(); |
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 know it used to be the config
service, but now that this class is using the uiSettings
client can we reflect that in the property naming? this._uiSettings
?
|
||
beforeEach(ngMock.module('kibana')); | ||
beforeEach(ngMock.inject(function (Private) { | ||
Vis = Private(VisProvider); | ||
AggType = Private(AggTypesAggTypeProvider); | ||
AggConfig = Private(VisAggConfigProvider); | ||
indexPattern = Private(FixturesStubbedLogstashIndexPatternProvider); | ||
fieldFormat = Private(RegistryFieldFormatsProvider); |
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.
If we move the fieldFormat registry to be like the uiSettings
client, we'll want to keep the fieldFormat = chrome.getFieldFormatsRegistry()
at this point so that it gets the unique registry for this test.
4120bc9
to
f41220b
Compare
💔 Build Failed |
💔 Build Failed |
return { settings: stubUiSettings.getAll() }; | ||
} | ||
// stub the UiSettingsClient | ||
if (chrome.getUiSettingsClient.restore) { |
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 check is only necessary if we are calling this logic multiple times.
a8b7e0b
to
d4a8411
Compare
💔 Build Failed |
💔 Build Failed |
c621654
to
69814df
Compare
💔 Build Failed |
💚 Build Succeeded |
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.
Looking good, just a couple lame naming asks
init(); | ||
} | ||
}); | ||
export const registryFieldFormats = new FieldFormatRegistry(); |
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.
registryFieldFormats
seems backwards, can we please just call this fieldFormats
like we do nearly everywhere we use it?
name: 'fieldFormats', | ||
index: ['id'], | ||
group: ['fieldType'], | ||
class FieldFormatRegistry extends IndexedArray { |
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 move this into ui/field_formats/field_formats.js
. IMO this isn't really a registry, and that's fine but we might as well keep it next to the rest of the field formats code.
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.
that folder doesn't exist so i'll leave it where it is for now
💚 Build Succeeded |
@@ -5,23 +5,22 @@ import { VisProvider } from 'ui/vis'; | |||
import { AggTypesAggTypeProvider } from 'ui/agg_types/agg_type'; | |||
import { VisAggConfigProvider } from 'ui/vis/agg_config'; | |||
import FixturesStubbedLogstashIndexPatternProvider from 'fixtures/stubbed_logstash_index_pattern'; | |||
import { RegistryFieldFormatsProvider } from 'ui/registry/field_formats'; | |||
import { fieldFormats } from 'ui/registry/field_formats'; |
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.
Just use import { fieldFormats as fieldFormat }
then we can get rid of the const fieldFormat = fieldFormats
in this file ... (or use search and replace :D)
const getConfig = (...args) => config.get(...args); | ||
const self = this; | ||
let defaultMap; | ||
this._uiSettings.subscribe(({ key, newValue }) => { |
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 wonder whether we maybe should introduce a subscribeTo('key', (newVal) => {})
to UiSettingsClient
, since it seems for me like most people who want to subscribe want to subscribe to specific changes in the long run, and all just having that if
statement then. @spalger
Though just a thought nothing to change in this 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.
LGTM, if Spencer approves the way test harness is handled.
💔 Build Failed |