[uiSettings] make service request based #12243

spalger · 2017-06-08T18:33:52Z

Closes #12047

Summary:

removes server.uiSettings() (throws error with instructions)
Adds request.getUiSettingsService() which returns a unique instance of UiSettingsService per request
Methods on UiSettingsService no longer require a request object
Adds server.uiSettingsServiceFactory(options) which can be used to create an instance of UiSettingsService with a custom callCluster() function

spalger · 2017-06-08T23:04:14Z

@kjbekkelund @azasypkin in case you looked at this before I added the tests, this is ready for review now.

azasypkin

Hey @spalger, sorry for the delay! I've reviewed everything except for the ui_settings tests - will finish reviewing them on Monday.

I've left several questions (mostly related to the changed behaviour) and just a few nits.

azasypkin · 2017-06-09T16:31:29Z

src/ui/ui_settings/ui_settings_service_factory.js

+ *  Create an instance of UiSettingsService that will use the
+ *  passed `callCluster` function to communicate with elasticsearch
+ *
+ *  @param  {Function} callCluster should accept a method name as a string and a params object


nit: doesn't look like that it really describes the arguments this function expects. Could you please fix?

By the way I've noticed that Kibana's Style Guide doesn't set JSDoc rules, that IMO we need to set at some point. It would be easier to auto-generate API docs eventually (at least for "public" API, that is available to plugins) and keep the same style across the teams.

azasypkin · 2017-06-09T16:46:34Z

src/ui/ui_settings/ui_settings_service_factory.js

+ *  @param  {Function} callCluster should accept a method name as a string and a params object
+ *  @return {UiSettingsService}
+ */
+export function uiSettingsServiceFactory(server, options = {}) {


question: since we have default value for options that means it's optional, but is callCluster function really optional?

As a side note, I usually try to avoid property-bag-as-the-only-function-argument. From my experience developers who will be changing this class later on will most likely add new argument to that catch-all bag without even thinking what the role new argument has (required or just optional). Same thing for users of this class/function, it's difficult to say what combination of options is considered valid and what is not just by looking at the function signature :)

As a side note, I usually try to avoid property-bag-as-the-only-function-argument.

Yeah, I generally do my best to keep function arguments to a one/two values, but when there are more, or some/all of them are optional, I move to "named args" for a couple reasons:

doesn't lead to multi-line argument lists

makes it easier to specify a couple args and not all of them

makes it really easy to merge arguments/provide defaults in wrappers

I find it really easy to read when the options value is destructured as the first statement in the code

generally leads to using the same name for values in all uses/locations

azasypkin · 2017-06-09T16:49:01Z

src/ui/ui_settings/ui_settings_service.js

+}
+
+export class UiSettingsService {
+  constructor(options = {}) {


nit: same question as I left in uiSettingsServiceFactory, are all these arguments really optional?

++ I think we should stay away from optionals like this as much as possible, and if we want to define one it should list all the key/value pairs with their defaults.

azasypkin · 2017-06-09T16:58:06Z

src/ui/ui_settings/ui_settings_mixin.js

+  // If the ui settings status isn't green we shouldn't be attempting to get
+  // user settings, since we can't be sure that all the necessary conditions
+  // (e.g. elasticsearch being available) are met.
+  const readUiSettingsInterceptor = () => {


optional nit: maybe that's just me, but when function returns results of different types it's a potential bug IMHO. I used to return null for nullable return type if I don't have anything to return.

I know it's very arguable, but what do you think?

I'm theoretically a huge fan of never using undefined to represent nothing and using null instead (reserving undefined to mean "uninitialized" or similar).

In practice though I find that opinion pretty controversial and think it's somewhat impractical to require. Also, requiring interceptors to return null seems like an unexpected API, based on my experience with such things... In general I treat null and undefined as equivalent, which is why I use == null a lot.

Okay, got it, sounds like a team-wide agreement :)

azasypkin · 2017-06-09T17:04:15Z

src/ui/ui_settings/ui_settings_service.js

+  }
+
+  async _read(options = {}) {
+    const interceptValue = await this._readInterceptor(options);


nit: do we need await here?

We do it we want _readInterceptor to support async logic, which it might need to do if the interceptor implemented some sort of auth check, or read values from a different cluster. IMO, using async for "extensions" when possible just make the extensions more usable.

Interesting point, thanks!

azasypkin · 2017-06-09T18:19:56Z

src/ui/ui_settings/ui_settings_service_for_request.js

+  }
+
+  const adminCluster = server.plugins.elasticsearch.getCluster('admin');
+  const uiSettingsServices = uiSettingsServiceFactory(server, {


typo: uiSettingsServices ----> uiSettingsService.

azasypkin · 2017-06-09T18:23:03Z

src/ui/ui_settings/ui_settings_service_for_request.js

+  const adminCluster = server.plugins.elasticsearch.getCluster('admin');
+  const uiSettingsServices = uiSettingsServiceFactory(server, {
+    readInterceptor,
+    callCluster(...args) {


question: wondering if callAdminCluster would make the intention clearer? But if admin cluster here is really an obvious thing for other developers then it's fine as is.

I chose not to include admin in the name because it's really not a concern of the UiSettingsService what type of cluster it's calling. UiSettingsService just cares that it can talk to elasticsearch.

azasypkin · 2017-06-09T18:36:11Z

src/ui/ui_settings/ui_settings_service.js

+      ignore401Errors = false
+    } = options;
+
+    const isIgnorableError = error => (


👏 Great that you got rid of that confusing "catch-with-filter" from Bluebird!

azasypkin · 2017-06-09T18:41:54Z

src/ui/ui_settings/ui_settings_service.js

+      };
+
+      const resp = await this._callCluster('get', clientParams, callOptions);
+      return resp._source;


question: original code was returning resp._source || {}. Was it just legacy and now we can be sure that resp._source is always an object?

yep, the original code was using a single handler for the "ignored error" and "successful response" branches, now we branch on that condition and this is only for successful responses.

Ah, right, I missed that.

azasypkin · 2017-06-09T18:47:01Z

src/ui/ui_settings/ui_settings_service.js

+  }
+
+  async setMany(changes) {
+    await this._write(changes);


question: original code (for this and few other methods) was always (if promise is resolved) returning an empty object for some reason via .then(() => ({}));. We don't need this behaviour now?

Correct, I verified nothing was consuming the resolved value of the "write" methods on this class so I just removed them, especially since they were useless.

kimjoar · 2017-06-08T19:56:43Z

src/ui/ui_settings/ui_settings_mixin.js

+
+  server.decorate('server', 'uiSettings', () => {
+    throw new Error(`
+      server.uiSettings has been removed, see https://github.com/elastic/kibana/pull/12243.


I ❤️ this

kimjoar · 2017-06-09T19:26:23Z

src/ui/ui_settings/ui_settings_service.js

+      ignore401Errors = false
+    } = options;
+
+    const isIgnorableError = error => (


kimjoar · 2017-06-09T19:30:55Z

src/ui/ui_settings/ui_settings_service.js

+
+  async _read(options = {}) {
+    const interceptValue = await this._readInterceptor(options);
+    if (interceptValue != null) {


I usually prefer specific checks, but I'm okey with != null in JS (with a typesystem it should be more specific). I just read it as "I expect x to be defined"

(in JS some people set a value to null to mean not defined, while others do undefined — until we are more consistent on that, I think != null makes sense)

kimjoar · 2017-06-09T19:36:02Z

Baaaaah, I was commenting on some of Aleh's comments above. But stupid Github UI is stupid.

kimjoar

The code itself LGTM.

In general though I'm not really a fan of adding things to req. It feels like the Array.prototype.myThing days of JavaScript. I'm okey with this change for now though, then we can explore ways in the new platform to make this "cleaner" (moving away from a "third-party owned" req to our own req with a clearly defined API might be enough from my perspective).

kimjoar · 2017-06-12T10:35:35Z

src/ui/ui_settings/ui_settings_service.js

+}
+
+export class UiSettingsService {
+  constructor(options = {}) {


++ I think we should stay away from optionals like this as much as possible, and if we want to define one it should list all the key/value pairs with their defaults.

azasypkin

Okay, I finished :) Everything looks good except for few things and many questions (mostly for my understanding).

azasypkin · 2017-06-12T08:43:07Z

src/ui/ui_settings/__tests__/ui_settings_service.js

+  describe('overview', function () {
+    it('has expected api surface', function () {
+      const { uiSettings } = setup();
+      expect(typeof uiSettings.get).to.equal('function');


nit: it's possible to get rid of typeof with expect(uiSettings.get).to.be.a('function'); here and below.

Hold over from the previous tests, but happy to fix and get better error messages.

azasypkin · 2017-06-12T08:45:53Z

src/ui/ui_settings/__tests__/lib/promises.js

+  assertPromise(promise);
+
+  try {
+    await promise;


issue: Hmm, it looks like you should throw an exception right at the end of this function to make sure we really get a rejected promise, otherwise it just masks the error in the code that is supposed to return rejected promise, but returns a resolved one instead.

azasypkin · 2017-06-12T08:57:03Z

src/ui/ui_settings/__tests__/ui_settings_service.js

+
+    it('throws if the first error is not a request', async () => {
+      const { uiSettings } = setup();
+      await assertRejection(uiSettings.get(null), 'hapi.Request');


issue: Heh, it's the thing I've just mentioned above in assertRejection: your code doesn't throw anymore (assertRequest no longer exists), but the test is still green.

azasypkin · 2017-06-12T09:03:55Z

src/ui/ui_settings/__tests__/lib/promises.js

+import expect from 'expect.js';
+
+export function assertPromise(promise) {
+  if (!promise || typeof promise.then !== 'function') {


question: why don't you like expect(promise).to.be.a(Promise); right inside the tests? Honestly, it feels more natural to use kind of built-in Promise assertion (especially since we don't have that nasty Bluebird there anymore).

Ah, if expect(promise).to.be.a(Promise); is good for you then it seems we may not need this file at all(assertRejection is only used in one test that is broken and redundant, see my note below).

azasypkin · 2017-06-12T09:49:27Z

src/ui/ui_settings/__tests__/lib/call_cluster_stub.js

+
+  callCluster.assertUpdateQuery = doc => {
+    sinon.assert.calledOnce(callCluster);
+    expect(callCluster.firstCall.args).to.eql([


nit: since it's called only once you can leverage sinon assert here as well (a bit easier to read):

sinon.assert.calledWithExactly(callCluster, 'update', { index, type, id, body: { doc } });

Oh, I figured calledWithExactly did a === strict equality check... works for me

azasypkin · 2017-06-12T09:57:56Z

src/ui/ui_settings/__tests__/lib/call_cluster_stub.js

+  const currentEsDocValue = merge({}, esDocSource);
+
+  const callCluster = sinon.spy(async (method, params) => {
+    expect(params)


question: Do you guys have team agreement on how sophisticated stubs should be? I usually try to make them as dumb as possible without much (any) logic/state inside them. So, in this case, I'd rather write something like this (assuming we don't need the state here):

const callCluster = sinon.stub(); callCluster.withArgs('get', sinon.match({ index: sinon.match.string, type: sinon.match.string, id: sinon.match.string })).returns({ _source: merge({}, currentEsDocValue) }); callCluster.withArgs('update', sinon.match({ index: sinon.match.string, type: sinon.match.string, id: sinon.match.string, body: sinon.match.string, doc: sinon.match.string })).returns({});

And the fact that tests are still green with the snippet above makes me wonder whether we need the "state" here at all (eg. merge(currentEsDocValue, params.body.doc);) or maybe we don't have enough checks. How does it affect tests?

This method would work fine without the state, so I'll remove it, but do you know if the sinon.stub() that has multiple withArgs() branches will throw if calls don't match the stubbed arg tests? Also, I didn't realize you could do what you did with sinon.match()... I'm all for less stub logic but think that implementing a function inside of sinon.spy() can be a bit easier to read and understand (especially since I don't understand sinon inside an out)

but do you know if the sinon.stub() that has multiple withArgs() branches will throw if calls don't match the stubbed arg tests?

Off the top of my head, it won't throw and just return undefined. That should work okay in most of the cases since we usually test what we expect to see (e.g. verify that expected methods have been called with the right args, correct number of times, in the right order etc.) and not what "the thing" does internally.

Also, I didn't realize you could do that you did with sinon.match()...

Yeah, it's a pretty powerful thing that validates args and their types in one go.

I'm all for less stub logic but think that implementing a function inside of sinon.spy() can be a bit easier to read and understand (especially since I don't understand sinon inside an out)

I'm fine with it, whatever you like more

azasypkin · 2017-06-12T10:21:03Z

src/ui/ui_settings/__tests__/ui_settings_mixin_integration.js

+    describe('enabled', () => {
+      it('registers a handler for kbnServer.ready()', () => {
+        const { readyPromise } = setup();
+        sinon.assert.calledOnce(readyPromise.then);


optional nit: maybe it will be safer to add sinon.assert.calledWithExactly(readyPromise.then, sinon.match.func); too, to make sure that code adds resolve callback.

azasypkin · 2017-06-12T10:25:30Z

src/ui/ui_settings/__tests__/ui_settings_mixin_integration.js

+
+
+        const states = chance.shuffle(['red', 'green', 'yellow']);
+        states.forEach(state => {


nit: state => { ----> (state) => {

azasypkin · 2017-06-12T10:29:29Z

src/ui/ui_settings/__tests__/ui_settings_service.js

+        _default_: { id: 'string', params: {} }
+      };
+
+      Object.keys(mapping).forEach(function (dataType) {


optional nit: maybe use arrow function here, just for the consistency?

azasypkin · 2017-06-12T10:32:26Z

src/ui/ui_settings/__tests__/ui_settings_service.js

+      const result = await uiSettings.getAll();
+      const defaults = getDefaultSettings();
+      const expectation = {};
+      Object.keys(defaults).forEach(key => {


nit: key => { ----> (key) => { here and in all other test cases below.

…equest-based

* [server/uiSettings] make uiSettings service request based * [server/uiSettings] disambiguate UiSettings/Service * [server/uiSettings] link to PR in removal error * [server/uiSettings] await _read before hydrating * [server/uiSettings] focus tests, remove server integration * [server/uiSettings] add tests for readInterceptor() arg * [server/uiSettings] add server integration tests * [server/uiExports] fix replaceInjectedVars tests * [server/uiSettings] convert all methods to use async/await * [uiSettings/serviceFactory] fix doc block * [uiSettings/service] fix doc block * [uiSettings/tests/callClusterStub] stop tracking state needlessly * [uiSettings/tests] remove invalid tests and pointless promise helpers * [uiSettings/forRequest] fix typo * [uiSettings/tests] remove mixture of arrow and function expressions * [uiSettings/tests/callClusterStub] leverage sinon.calledWithExactly * [uiSettings/mixin/tests] add exception for eslint import/no-duplicates * [uiSettings/mixin/tests] wrap single args in parens (cherry picked from commit 65d6b5d)

* [uiSettings] make service request based (#12243) * [server/uiSettings] make uiSettings service request based * [server/uiSettings] disambiguate UiSettings/Service * [server/uiSettings] link to PR in removal error * [server/uiSettings] await _read before hydrating * [server/uiSettings] focus tests, remove server integration * [server/uiSettings] add tests for readInterceptor() arg * [server/uiSettings] add server integration tests * [server/uiExports] fix replaceInjectedVars tests * [server/uiSettings] convert all methods to use async/await * [uiSettings/serviceFactory] fix doc block * [uiSettings/service] fix doc block * [uiSettings/tests/callClusterStub] stop tracking state needlessly * [uiSettings/tests] remove invalid tests and pointless promise helpers * [uiSettings/forRequest] fix typo * [uiSettings/tests] remove mixture of arrow and function expressions * [uiSettings/tests/callClusterStub] leverage sinon.calledWithExactly * [uiSettings/mixin/tests] add exception for eslint import/no-duplicates * [uiSettings/mixin/tests] wrap single args in parens (cherry picked from commit 65d6b5d) * [uiSettings] support defining settings with uiExports (#12250) * [uiSettings] add `uiSettingDefaults` export type * [uiSettings/uiExportsConsumer] ensure that there are not conflicts * use `sinon.assert.calledWithExactly()` * describe the UiExportsConsumer class * make uiExport consumers filtering intention more clear * fix typo * fix typos * add note about why getDefaults() is a function (cherry picked from commit 7bec60c)

havidarou · 2017-09-11T21:12:48Z

Hi, I have updated from 5.5.2 to 5.6.0 and my server.uiSettings() no longer works.

I've read this thread but can't understand what is the new way of doing this.

Thank you in advance.

spalger · 2017-09-15T02:00:44Z

@havidarou if you have a Hapi request object then you can do it like this. If you don't have a request then you'll need to do something like this

The second example is a little more complicated, but hopefully you are working with a request. If you aren't please give me some more information about what you're doing. A code example on github would be excelent 😄

havidarou · 2017-09-19T23:52:25Z

Hi @spalger

I don't have a request, so I would use the second approach.

Anyway, I ended up doing an elasticsearch request...though I plan to test this eventually.

Thank you.

spalger added 2 commits June 8, 2017 11:24

[server/uiSettings] make uiSettings service request based

817d261

[server/uiSettings] disambiguate UiSettings/Service

04a543d

spalger added review v6.0.0 labels Jun 8, 2017

spalger requested review from kimjoar and azasypkin June 8, 2017 18:33

[server/uiSettings] link to PR in removal error

a0b7f1f

spalger changed the title ~~Ui settings/request based~~ Make uiSettings service request based Jun 8, 2017

spalger added tests_needed and removed review labels Jun 8, 2017

[server/uiSettings] await _read before hydrating

f3221b8

spalger force-pushed the ui-settings/request-based branch from ddc49d2 to 8ddd0cf Compare June 8, 2017 22:31

spalger added 2 commits June 8, 2017 15:38

[server/uiSettings] focus tests, remove server integration

c583035

[server/uiSettings] add tests for readInterceptor() arg

04a1658

spalger force-pushed the ui-settings/request-based branch from a688112 to c4e0b35 Compare June 8, 2017 22:38

spalger added 2 commits June 8, 2017 15:44

[server/uiSettings] add server integration tests

bd38111

[server/uiExports] fix replaceInjectedVars tests

b74e71e

spalger force-pushed the ui-settings/request-based branch from c4e0b35 to b74e71e Compare June 8, 2017 22:44

[server/uiSettings] convert all methods to use async/await

c8a410e

spalger added review and removed tests_needed labels Jun 8, 2017

spalger mentioned this pull request Jun 9, 2017

[uiSettings] support defining settings with uiExports #12250

Merged

spalger changed the title ~~Make uiSettings service request based~~ [uiSettings] make service request based Jun 9, 2017

azasypkin reviewed Jun 9, 2017

View reviewed changes

kimjoar reviewed Jun 9, 2017

View reviewed changes

kimjoar approved these changes Jun 12, 2017

View reviewed changes

azasypkin approved these changes Jun 12, 2017

View reviewed changes

elastic deleted a comment from azasypkin Jun 12, 2017

spalger added 10 commits June 12, 2017 12:53

Merge branch 'master' of github.com:elastic/kibana into ui-settings/r…

885791d

…equest-based

[uiSettings/serviceFactory] fix doc block

19279f3

[uiSettings/service] fix doc block

099964c

[uiSettings/tests/callClusterStub] stop tracking state needlessly

1ae25cd

[uiSettings/tests] remove invalid tests and pointless promise helpers

3c141b4

[uiSettings/forRequest] fix typo

c3e330a

[uiSettings/tests] remove mixture of arrow and function expressions

452393a

[uiSettings/tests/callClusterStub] leverage sinon.calledWithExactly

993ed24

[uiSettings/mixin/tests] add exception for eslint import/no-duplicates

381fd49

[uiSettings/mixin/tests] wrap single args in parens

c58dbfa

spalger merged commit 65d6b5d into elastic:master Jun 12, 2017

spalger deleted the ui-settings/request-based branch June 12, 2017 21:16

spalger mentioned this pull request Jul 7, 2017

[kbnServer/extensions] formalize request factories with helper #12697

Merged

jimgoodwin added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc release_note:fix labels Jul 25, 2017

jimgoodwin added the v6.0.0-rc1 label Sep 28, 2017



		const states = chance.shuffle(['red', 'green', 'yellow']);
		states.forEach(state => {

[uiSettings] make service request based #12243

[uiSettings] make service request based #12243

Conversation

spalger commented Jun 8, 2017 • edited Loading

spalger commented Jun 8, 2017

azasypkin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spalger Jun 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spalger Jun 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spalger Jun 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spalger Jun 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kimjoar commented Jun 9, 2017

kimjoar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azasypkin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

spalger Jun 12, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

havidarou commented Sep 11, 2017

spalger commented Sep 15, 2017

havidarou commented Sep 19, 2017

spalger commented Jun 8, 2017 •

edited

Loading

spalger Jun 12, 2017 •

edited

Loading

spalger Jun 12, 2017 •

edited

Loading

spalger Jun 12, 2017 •

edited

Loading

spalger Jun 12, 2017 •

edited

Loading

spalger Jun 12, 2017 •

edited

Loading