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

Adding column type label to dropdowns #4566

Merged
merged 6 commits into from
Mar 16, 2018

Conversation

michellethomas
Copy link
Contributor

@michellethomas michellethomas commented Mar 7, 2018

Adding column type information to the optionRenderer for any controls that use ColumnOption or MetricOption. So this will show up in the dropdown but not inline in the value renderer. This deviates from our original designs but it was making the page look pretty busy when I added it to our current page.

Would love to get more design feedback!

In the future, in the metrics section we can distinguish between aggregations and columns. Also, once some of the metrics work Gabe is doing gets in, I'd like to add this to all dropdowns for consistency.

@GabeLoins @williaster @mistercrunch

image
image
image
image

@codecov-io
Copy link

codecov-io commented Mar 7, 2018

Codecov Report

Merging #4566 into master will increase coverage by 0.04%.
The diff coverage is 86.84%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #4566      +/-   ##
==========================================
+ Coverage    71.2%   71.24%   +0.04%     
==========================================
  Files         187      190       +3     
  Lines       14785    14875      +90     
  Branches     1083     1099      +16     
==========================================
+ Hits        10527    10598      +71     
- Misses       4255     4274      +19     
  Partials        3        3
Impacted Files Coverage Δ
.../explore/components/controls/DatasourceControl.jsx 66.66% <0%> (ø) ⬆️
...set/assets/javascripts/explore/stores/controls.jsx 37.59% <0%> (-0.58%) ⬇️
...set/assets/javascripts/components/MetricOption.jsx 100% <100%> (ø) ⬆️
.../assets/javascripts/components/ColumnTypeLabel.jsx 100% <100%> (ø)
...set/assets/javascripts/components/ColumnOption.jsx 100% <100%> (ø) ⬆️
superset/jinja_context.py 73.33% <0%> (-4.93%) ⬇️
...ipts/explore/components/ControlPanelsContainer.jsx 86.95% <0%> (-0.93%) ⬇️
superset/models/core.py 86.7% <0%> (-0.62%) ⬇️
...javascripts/SqlLab/components/SqlEditorLeftBar.jsx 92.45% <0%> (-0.55%) ⬇️
... and 16 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 826d063...3665d4c. Read the comment docs.

} else if (type.match(/.*time.*/i)) {
stringIcon = 'time';
} else {
stringIcon = '?';
Copy link
Contributor

@gabe-lyons gabe-lyons Mar 7, 2018

Choose a reason for hiding this comment

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

I kinda feel like the null case should be blank rather than a ? to make things a bit cleaner

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I agree. I added the ? because there's a specific UNKNOWN type and was thinking maybe having ? as well as a blank could be confusing. But I agree they should either be separate or both blank.

stringIcon = '?';
}

const typeIcon = stringIcon === 'time' ? <i className="fa fa-clock-o text-muted type-label" /> : (
Copy link
Contributor

@gabe-lyons gabe-lyons Mar 7, 2018

Choose a reason for hiding this comment

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

nit: I think it would be a bit more readable to do

clause ?
  option1 : 
  option2;


export default function ColumnTypeLabel({ type }) {
let stringIcon;
let iconSize = '13';
Copy link
Contributor

Choose a reason for hiding this comment

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

these should all be fine as #s not strings

let stringIcon;
let iconSize = '13';
if (type === '' || type === 'expression') {
stringIcon = 'ƒ';
Copy link
Contributor

Choose a reason for hiding this comment

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

love this!

}

const typeIcon = stringIcon === 'time' ? <i className="fa fa-clock-o text-muted type-label" /> : (
<div className="text-muted type-label" style={{ fontSize: iconSize }}>{stringIcon}</div>);
Copy link
Contributor

Choose a reason for hiding this comment

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

is the 2px ABC font size off enough that it warrants inline styles? ideally avoided since you're already using a new css class. I'd say a slightly larger font consistently across all icons (like 14px?) would be ideal aesthetically. I think they'd be differentiated enough from the dropdown text with the muted style you apply.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To me, keeping the same default font for ABC seemed to compete a bit with the text next to it, but I don't have strong opinions.
image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated the original comment with new screenshots based off our conversation.

@mistercrunch
Copy link
Member

giphy


let wrapper;
let props;
const factory = o => <ColumnTypeLabel {...o} />;
Copy link
Contributor

Choose a reason for hiding this comment

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

I know there are a lot of places that do this already, but single character variable names don't facilitate readability.

const factory = o => <ColumnTypeLabel {...o} />;
beforeEach(() => {
wrapper = shallow(factory(defaultProps));
props = Object.assign({}, defaultProps);
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this pattern for test setup is difficult to read in terms of what props are actually applied and it seems strange to allow tests to modify the props object directly / reset them every test . I've also seen several code bases move away from using shared let variables because it can result in race conditions in more complex tests.

a more readable and common pattern I've seen is:

const props = { ...defaultProps };

describe('MyComponent', () => {
  function setup(overrides) {
    const wrapper = shallow(<MyComponent {...props} {...overrides} />);
    return wrapper;
  }

  it('does something', () => {
    const wrapper = setup(/* { optional: override } */);
    expect(...);
  });

  ...
});

@williaster
Copy link
Contributor

LGTM

@williaster williaster merged commit 3f1dfb3 into apache:master Mar 16, 2018
michellethomas added a commit to michellethomas/panoramix that referenced this pull request May 24, 2018
* Adding column type label to dropdowns

* Changing the style of column type label

* Adding tests for ColumnTypeLabel

* Adding tests for time and fixing if statement order

* Changing location of ColumnTypeLabel tests

* Updating ColumnTypeLabel structure
wenchma pushed a commit to wenchma/incubator-superset that referenced this pull request Nov 16, 2018
* Adding column type label to dropdowns

* Changing the style of column type label

* Adding tests for ColumnTypeLabel

* Adding tests for time and fixing if statement order

* Changing location of ColumnTypeLabel tests

* Updating ColumnTypeLabel structure
@mistercrunch mistercrunch added 🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 0.24.0 labels Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🏷️ bot A label used by `supersetbot` to keep track of which PR where auto-tagged with release labels 🚢 0.24.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants