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

feat: Adds sortable table detail page #691

Merged
merged 13 commits into from
Sep 29, 2020
Merged

feat: Adds sortable table detail page #691

merged 13 commits into from
Sep 29, 2020

Conversation

Golodhros
Copy link
Member

@Golodhros Golodhros commented Sep 28, 2020

Summary of Changes

Adds ability to sort the table columns on the Table detail page

core_fact_rides_-_Amundsen_Table_Details

Tests

Added tests

CheckList

Make sure you have checked all steps below to ensure a timely review.

  • PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"
  • PR includes a summary of changes, including screenshots of any UI changes.
  • PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
  • In case of new functionality, my PR adds documentation that describes how to use it.
    • All the public python functions and the classes in the PR contain docstrings that explain what it does
  • PR passes all tests documented in the developer guide

@Golodhros Golodhros force-pushed the mi-sorting-table branch 2 times, most recently from f05dce2 to b8e9a7c Compare September 28, 2020 20:56
@@ -8,8 +8,14 @@ import { UpIcon, DownIcon } from '../SVGIcons';

import './styles.scss';

type TextAlignmentValues = 'left' | 'right' | 'center';
// export type SortDirection = 'asc' | 'desc';
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are these commented out?

Copy link
Member Author

Choose a reason for hiding this comment

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

I will implement it shortly!

@@ -153,17 +197,26 @@ const ColumnList: React.FC<ColumnListProps> = ({
name: item.name,
database,
},
usage: hasItemStats ? item.stats[0].stat_val : '',
sort_order: item.sort_order,
usage: hasItemStats ? +item.stats[0].stat_val : null,
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think the api guarantees the column usage will be the first statistic, so perhaps we should have a helper method to intentionally search for the column_usage statistic and extract the value.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good call!
Right now this will work, but as we add more stats it will definitely break.
I will add something now.

Copy link
Member

Choose a reason for hiding this comment

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

+1, currently we have single stat at Lyft, but we will ingest more stat later. I think we should either define the query / metric name in config for sorting or redefine the usage not part of stat. I wonder whether we could choose the former?

isEditable: item.is_editable,
editText,
editUrl,
index,
};
});
const statsCount = formattedData.filter((item) => !!item.stats).length;
const hasStats = statsCount >= SHOW_STATS_THRESHOLD;
const hasStats =
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Is this more accurately hasUsage?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, will change

@ttannis
Copy link
Contributor

ttannis commented Sep 28, 2020

Looks like tests are failing because of amundsencommon? cc @allisonsuarez since I think you were working on it. On my end only concern is my comment about reliable logic to extract the column usage from the stats.

@feng-tao
Copy link
Member

Looks like tests are failing because of amundsencommon? cc @allisonsuarez since I think you were working on it. On my end only concern is my comment about reliable logic to extract the column usage from the stats.

let me take a look at the code as well. I was raising a question: could we sort based on a metric which defined by usage? We name column usage but other OSS could name it differently.

Also is @ttannis 's concern extracting column usage in stats requiring certain hack? do you think if we put query / column usage as separate node helps?

@@ -76,6 +90,50 @@ type ExpandedRowProps = {
};

const SHOW_STATS_THRESHOLD = 1;
const USAGE_STAT_TYPE = 'column_usage';
Copy link
Member Author

Choose a reason for hiding this comment

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

This would probably be the item to move to the config, however I am wary of creating that abstraction now, without knowing more about what it is to come.

Copy link
Member

Choose a reason for hiding this comment

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

could you add a todo for moving it to config as follow up as column_usage is just a stat name used internally for query usage?

Copy link
Contributor

Choose a reason for hiding this comment

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

I can understand that. I am alright with it as it since the community will be able to follow existing examples to make this more flexible if/when needed.

@@ -76,6 +90,50 @@ type ExpandedRowProps = {
};

const SHOW_STATS_THRESHOLD = 1;
const USAGE_STAT_TYPE = 'column_usage';
Copy link
Member

Choose a reason for hiding this comment

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

could you add a todo for moving it to config as follow up as column_usage is just a stat name used internally for query usage?

: stringSortingFunction;
};

const getUsageStat = (item) => {
Copy link
Member

Choose a reason for hiding this comment

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

it seems sometimes we have type for input and sometimes not?

isEditable: item.is_editable,
editText,
editUrl,
index,
};
});
const statsCount = formattedData.filter((item) => !!item.stats).length;
const hasStats = statsCount >= SHOW_STATS_THRESHOLD;
const hasUsageStat =
getTableSortCriterias().usage && statsCount >= SHOW_STATS_THRESHOLD;
Copy link
Member

Choose a reason for hiding this comment

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

so if the column has 0 usage, it won't show stat?

Copy link
Member Author

Choose a reason for hiding this comment

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

If no element on the data has usage, we won't show the whole column, right.

name: 'Alphabetical',
key: 'name',
direction: SortDirection.descending,
},
Copy link
Member

Choose a reason for hiding this comment

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

if we want to sort the column based on column usage, are we going to add new criteria at here as well?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep, that change is on the private repo, only for us right now.

@ttannis
Copy link
Contributor

ttannis commented Sep 29, 2020

Looks like tests are failing because of amundsencommon? cc @allisonsuarez since I think you were working on it. On my end only concern is my comment about reliable logic to extract the column usage from the stats.

let me take a look at the code as well. I was raising a question: could we sort based on a metric which defined by usage? We name column usage but other OSS could name it differently.

Also is @ttannis 's concern extracting column usage in stats requiring certain hack? do you think if we put query / column usage as separate node helps?

I wouldn't call it a hack, rather extra logic to explicitly search the stats array for column_usage. Having it as a separate node would make it such that we don't need that extra logic, but I still believe your original perspective that column usage is a statistic in the metadata is fair. The case here is that the UI design has chosen to display usage differently from other column statistics, so I think it is appropriate for the frontend to have to have go parse the data because of how our designs have chosen to display them.

In short, no strong opinion on changing it!

Copy link
Contributor

@ttannis ttannis left a comment

Choose a reason for hiding this comment

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

Pending passing CI checks.

@Golodhros
Copy link
Member Author

Looks like tests are failing because of amundsencommon? cc @allisonsuarez since I think you were working on it. On my end only concern is my comment about reliable logic to extract the column usage from the stats.

let me take a look at the code as well. I was raising a question: could we sort based on a metric which defined by usage? We name column usage but other OSS could name it differently.
Also is @ttannis 's concern extracting column usage in stats requiring certain hack? do you think if we put query / column usage as separate node helps?

I wouldn't call it a hack, rather extra logic to explicitly search the stats array for column_usage. Having it as a separate node would make it such that we don't need that extra logic, but I still believe your original perspective that column usage is a statistic in the metadata is fair. The case here is that the UI design has chosen to display usage differently from other column statistics, so I think it is appropriate for the frontend to have to have go parse the data because of how our designs have chosen to display them.

In short, no strong opinion on changing it!

Done!

Marcos Iglesias added 13 commits September 29, 2020 11:35
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
Signed-off-by: Marcos Iglesias <miglesiasvalle@lyft.com>
@Golodhros Golodhros merged commit 36aebd2 into master Sep 29, 2020
@feng-tao feng-tao deleted the mi-sorting-table branch September 29, 2020 23:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants