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

[Canvas] Feat: static tags for elements #28779

Merged
merged 5 commits into from
May 8, 2019

Conversation

cqliu1
Copy link
Contributor

@cqliu1 cqliu1 commented Jan 15, 2019

Phase 1 of #25532.
Closes #23172.

This adds static tags to Canvas element plugins (not custom elements yet...) and makes the element selection filterable by tags.

  • adds stories for Tag and TagList components
  • updates stories for ElementCard and ElementGrid
  • adds type def for @kbn/interpreter/Registry

Note: I added type definition files to Registry in the @kbn/interpreter package and typescriptified all the tag related files so CI would stop failing. Since I made changes to a package, you'll want to run yarn kbn bootstrap while checked out in this branch.

Screen Shot 2019-05-03 at 5 04 39 PM

jan-16-2019 13-57-09

Tags added:

chart for the plot/pie/progress elements

jan-16-2019 14-00-28

filter

screen shot 2019-01-15 at 1 45 59 pm

graphic for image and shape elements

screen shot 2019-01-16 at 2 00 47 pm

proportion for elements that compare a part to a whole (pie, progress, reveal image, and repeat image)

jan-16-2019 14-04-48

text

screen shot 2019-01-15 at 1 48 38 pm

@cqliu1 cqliu1 added review v7.0.0 Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v6.7.0 labels Jan 15, 2019
@cqliu1 cqliu1 requested review from w33ble and ryankeairns January 15, 2019 19:45
@cqliu1 cqliu1 requested a review from a team as a code owner January 15, 2019 19:45
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-canvas

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@w33ble
Copy link
Contributor

w33ble commented Jan 15, 2019

One thing I've learned about tags is that less is more. I think we could cull the list a little (tags like "line", "point" and "bar" can probably go, likely others too).

@cqliu1
Copy link
Contributor Author

cqliu1 commented Jan 15, 2019

Yeah, I went a little overboard with the tags. Would it be helpful to differentiate between plot and pie or is chart sufficient?

@w33ble
Copy link
Contributor

w33ble commented Jan 15, 2019

I think chart is enough, the others are already names of visualizations. I suspect users trying to filter with tags are more concerned with separating data and not data elements, and the chart and graphic tags do this already.

Shoot for the least amount of tags here, we can always add more later, but it's hard to remove them. And the more tags we have, the less useful they become.

@ryankeairns
Copy link
Contributor

+1 on the small set of tags. Chart, text, graphic, and progress probably cover a lot and leave us with 1 per asset in most, if not all, cases.

This is looking great, I'll give it a spin locally.

@cqliu1
Copy link
Contributor Author

cqliu1 commented Jan 15, 2019

@w33ble @ryankeairns I trimmed down the list of tags and updated the screenshots in the description ^

@w33ble
Copy link
Contributor

w33ble commented Jan 15, 2019

Looking a lot better. One question; isn't a progress element a type of chart element? And if you're intent on keeping the progress tag, wouldn't it make sense to add it to revealImage as well?

@elasticmachine
Copy link
Contributor

💔 Build Failed

Copy link
Contributor

@ryankeairns ryankeairns left a comment

Choose a reason for hiding this comment

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

Looking good, one small change regarding the card layout for badges.

<br />
<TagList tags={tags} tagType={tagType} />
</Fragment>
}
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 make the badges appear in the same place (bottom) of each card to tidy things up layout-wise. Just use the footer prop on EuiCard like so:

...
          description={
            <Fragment>
              {help}
            </Fragment>
          }
          footer={
            <TagList tags={tags} tagType={tagType} />            
          }
...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good call! The spacing looks much nicer.

screen shot 2019-01-15 at 3 41 37 pm

@ryankeairns
Copy link
Contributor

One additional minor UI nitpick. The close icon overlaps the Tag selector just a bit (see below). A quick fix would be to give the .euiModalHeader one more pixel of padding-right or move the close icon over. With either solution, we would want to add a custom css class to apply that override as opposed to overriding any existing .eui... class names.

screenshot 2019-01-15 16 10 29

@cqliu1
Copy link
Contributor Author

cqliu1 commented Jan 15, 2019

@ryankeairns 1 pixel makes a big difference
screen shot 2019-01-15 at 3 46 41 pm

@cqliu1 cqliu1 requested a review from a team as a code owner January 15, 2019 22:48
Copy link
Contributor

@ryankeairns ryankeairns left a comment

Choose a reason for hiding this comment

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

Thanks for making those changes, it's so close :) In the component and in the scss file modal is misspelled as model (e.g. canvasElements__modelHeader). Other than that, this looks good!

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@w33ble
Copy link
Contributor

w33ble commented Jan 16, 2019

screenshot 2019-01-15 17 02 45

Arbitrary tag handling, nice!

Copy link
Contributor

@w33ble w33ble left a comment

Choose a reason for hiding this comment

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

This is looking good. I like that you can use tag:whatever in the search bar, nice touch!

type: PropTypes.string.isRequired,
};

Tag.defaultProps = {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: you don't need to add default props when the propType is marked as required

Copy link
Contributor

@w33ble w33ble left a comment

Choose a reason for hiding this comment

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

Bah, of course I find a bug after approving :(

If I search for a garbage string, I get no results, as expected:

screenshot 2019-01-15 17 11 58

But if I search for a garbage tag, it just shows everything:

screenshot 2019-01-15 17 12 04

Seems like a bug in the tag search/filter logic.

@cqliu1
Copy link
Contributor Author

cqliu1 commented Jan 16, 2019

@w33ble It should actually be tags: instead of tag: if you want to type in your tags. Typing in tags:foo returns 0 results.

screen shot 2019-01-16 at 2 53 50 pm

Should I rename that field from tags to tag?

@cqliu1 cqliu1 force-pushed the feat/element-tags branch from 9f74380 to 391f3f7 Compare January 16, 2019 21:59
@w33ble
Copy link
Contributor

w33ble commented Jan 16, 2019

Should I rename that field from tags to tag?

Nope, it's still a bug, but that's not it. On master, I can't even put a : in the search box, so this is definitely a new bug. It looks like if you put <anything>:<anything> you always get all of the results. Below I enter wat:, and get no results, but as soon as I add anything to the right of the colon, it just shows everything.

jan-16-2019 15-08-07

I don't know why it works this way. Maybe it's an EUI bug? After some discussion, it does seem like a bug in this PR, somewhat related to the Query object that comes out of that component. We're planning to ignore that completely and just use the queryText and do our own parsing.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

Copy link
Contributor

@monfera monfera left a comment

Choose a reason for hiding this comment

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

Great work Catherine, fantastic PR 🎉

Super minor things, maybe to circle back to in some future PR:

  • the report tag is now yielding the empty set
  • 'graphicandreport` have identical-looking colors
  • depending on the element count, a vertical scrollbar comes and goes, changing the width of the container

Currently, selecting multiple tags forms an intersection rather than a union of the elements - you have my vote here, despite that 1) there are few tags, and 2) they don't hugely overlap, so a union might work slightly better right now. On the other hand, when we eventually have more numerous, orthogonal tabs, a selection like timeline&area&ohlc&annotated would let a user select only those elements (from possibly many! idea of Canvas is eg. render plugins and clients may roll a big roster) that are timeline visualizers that can render areas OHLC bars and support user annotations. So, imo good future-proof choice there!

Copy link

@shaunmcgough shaunmcgough left a comment

Choose a reason for hiding this comment

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

Hi @cqliu1 - This looks good. I basically noticed the same things that @monfera noticed. Quite minor things indeed. Great work!

@cqliu1
Copy link
Contributor Author

cqliu1 commented May 8, 2019

  • the report tag is now yielding the empty set

@monfera That's bc report exists as a tag on one of the workpad templates but not any of the elements. The tag filter is populated by the tag registry with both tags from templates and elements. I'm not sure if there's a nice way to separate the two lists, but this is similar to the behavior of labels on github where issues and PRs use labels from the same set.

Copy link
Contributor

@ryankeairns ryankeairns left a comment

Choose a reason for hiding this comment

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

LGTM. A couple of minor things:

  • perhaps we should remove 'presentation' from the dropdown since there aren't any elements using that tag
  • something to keep an ear open for - do people expecting selecting multiple tags to be an "OR" situation as opposed to an "AND". Currently, it if you select multiple tags it only shows elements that have all those tags. I expected it to show all elements with either tag, but this feels like a 50/50 so we can just ship and see what feedback we get.

@cqliu1
Copy link
Contributor Author

cqliu1 commented May 8, 2019

@ryankeairns @monfera @shaunmcgough Thanks for the feedback! I chose to "AND" the tags filters, but that's the behavior I expected and what I saw on github, but it may not be expected for other users. If we get complaints about the behavior, we can always switch to "OR" or maybe someone let the user choose "OR" or "AND".

RE: the list of tags in the filter, the tag list is populated with the entire tag registry which registers element and workpad template tags. We can consider filtering the list of tags with the tags that exist in the object they're filtering.

Screen Shot 2019-05-08 at 9 27 41 AM

@elasticmachine
Copy link
Contributor

💔 Build Failed

cqliu1 added 5 commits May 8, 2019 12:08
…lates

    Added tag filtering to element selection modal

    Added tags to elements

    Removed unused tags

    Fixed spacing in element card

    Pruned out extraneous tags

    Added padding to element types modal header. Moved tags to EuiCard footer

    Fixed typo

    Fixed prop types

    Replaced progress with proportion tag. Updated tags

    Fixed search bar behavior in element picker and workpad templates

    Added type definitions to Registry in @kbn/interpreter

    Typescriptified tags

    Renamed 'tags' field to 'tag' in EuiSearchBar filter config

    Fixed import paths

Added tags filter to ElementTypes

Converted tag component

Added stories for Tag and TagList components
@cqliu1 cqliu1 force-pushed the feat/element-tags branch from fc62d5b to c1900ef Compare May 8, 2019 19:09
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@cqliu1 cqliu1 merged commit 9c6a58c into elastic:master May 8, 2019
cqliu1 added a commit to cqliu1/kibana that referenced this pull request May 10, 2019
* Extract Tags component and tag filter config object from workpad templates

    Added tag filtering to element selection modal

    Added tags to element

    Added type definitions to Registry in @kbn/interpreter

    Added stories for Tag and TagList components

    Changed graphic tag color
cqliu1 added a commit that referenced this pull request May 14, 2019
* Extract Tags component and tag filter config object from workpad templates

    Added tag filtering to element selection modal

    Added tags to element

    Added type definitions to Registry in @kbn/interpreter

    Added stories for Tag and TagList components

    Changed graphic tag color
@cqliu1 cqliu1 deleted the feat/element-tags branch May 6, 2020 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_note:enhancement review Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v7.2.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Additional Element Filters
6 participants