Skip to content

fixing ordering of series in legend - #14113

Merged
ppisljar merged 4 commits into
elastic:masterfrom
ppisljar:fix/filterOrder
Oct 2, 2017
Merged

ppisljar merged 4 commits into
elastic:masterfrom
ppisljar:fix/filterOrder

Conversation

@ppisljar

@ppisljar ppisljar commented Sep 22, 2017 •

Copy link
Copy Markdown
Contributor

Summary: order of legend for series should be same as provided in the configuration.

Resolves #10543

@ppisljar ppisljar added Feature:Visualizations Generic visualization features (in case no more specific feature label is available) review labels Sep 22, 2017

@thomasneirynck thomasneirynck left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

whoa, I like the small footprint of the fix a lot, and it makes sense to me to do that correction in tabify.

I only have one minor suggestion, not 100% sure if we should introduce a new side-effect in tabify.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The reorder call creates a side-effect, fairly significant, and is only called from the tabify module. I'm not a 100% sure if this would have other impacts on the code, but it does break encapsulation somewhat.

I'd consider making the reorder() method return a clone of the buckets object, but with the keys ordered against the filters. So in tabify you'd have something like:

 if (buckets.length) {
    const reorderedBuckets = buckets.orderBucketsAccordingToFilterParams(agg.params);
    //... and then just work with reorderedBuckets...
 }

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Getting reorderedBuckets is undefined errors on this line because orderBucketsAccordingToFilterParams is still mutating this instead of returning a value.

@ppisljar

ppisljar commented Sep 26, 2017 •

Copy link
Copy Markdown
Contributor Author

@thomasneirynck i moved back to the original approach (changing the Buckets itself)
Buckets is a collection and I think its ok if calling order on the collection does the ordering in place (same as js Array.sort) ... also the implementation gets simplified that way (buckets has a prototype forEach function which does some magic behind the scenes)

i also added support for range and ip range aggregations

@ppisljar ppisljar changed the title fixing ordering of series produced on filters fixing ordering of series in legend Sep 26, 2017

@thomasneirynck thomasneirynck left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

perhaps we can split the difference :)

Can we mutate in the constructor then, and keep this out of the flow of tabify.

//in tabify
const buckets = new Buckets(bucket[agg.id], agg.params);

and then in buckets

unction Buckets(aggResp, params) {
    if (_.has(aggResp, 'buckets')) {
      this.buckets = aggResp.buckets;
    } else {
      // Some Bucket Aggs only return a single bucket (like filter).
      // In those instances, the aggResp is the content of the single bucket.
      this.buckets = [aggResp];
    }

    this.objectMode = _.isPlainObject(this.buckets);
    if (this.objectMode) {
      this._keys = _.keys(this.buckets);
      this.length = this._keys.length;
    } else {
      this.length = this.buckets.length;
    }

 if (this.length){
 this.orderBucketsAccordingToParams(params);
}
  }

@ppisljar

ppisljar commented Sep 27, 2017 •

Copy link
Copy Markdown
Contributor Author

@Bargs this should be ready for another look
please ignore my last comment, tests are failing

@Bargs

Bargs commented Sep 27, 2017

Copy link
Copy Markdown
Contributor

Looks like they're passing now?

@ppisljar

Copy link
Copy Markdown
Contributor Author

yup, good for another look

@Bargs Bargs left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM

@ppisljar
ppisljar merged commit de7db5b into elastic:master Oct 2, 2017
ppisljar added a commit to ppisljar/kibana that referenced this pull request Oct 2, 2017
* fixing ordering of series produced on filters

* updating based on review from Thomas

* adding support for range and iprange aggregations

* updating based on review from Thomas
ppisljar added a commit to ppisljar/kibana that referenced this pull request Oct 2, 2017
* fixing ordering of series produced on filters

* updating based on review from Thomas

* adding support for range and iprange aggregations

* updating based on review from Thomas
ppisljar added a commit that referenced this pull request Oct 2, 2017
* fixing ordering of series produced on filters

* updating based on review from Thomas

* adding support for range and iprange aggregations

* updating based on review from Thomas
ppisljar added a commit that referenced this pull request Oct 2, 2017
* fixing ordering of series produced on filters

* updating based on review from Thomas

* adding support for range and iprange aggregations

* updating based on review from Thomas
@alexfrancoeur

Copy link
Copy Markdown

@ppisljar I know we discussed but can't recall where we ended up, did we end up backporting to 5.x or is this fixed in 6.0?

@Bargs

Bargs commented Oct 2, 2017

Copy link
Copy Markdown
Contributor

PRs should have version labels on them

@ppisljar ppisljar removed the review label Oct 2, 2017
patrykkopycinski pushed a commit to patrykkopycinski/kibana that referenced this pull request May 6, 2026
* fixing ordering of series produced on filters

* updating based on review from Thomas

* adding support for range and iprange aggregations

* updating based on review from Thomas
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Feature:Visualizations Generic visualization features (in case no more specific feature label is available) v6.0.0 v6.1.0 v7.0.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants