-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[search ui] Add asset filter fields to search index #20372
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @clairelin135 and the rest of your teammates on |
Deploy preview for dagit-core-storybook ready! ✅ Preview Built with commit ed88cdc. |
1c9b8ca
to
445969c
Compare
AssetGroup = 'AssetFilterSearchResultType.AssetGroup', | ||
} | ||
|
||
export function isAssetFilterSearchResultType( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how to check if a value exists in a given enum... I was seeing the following always return true:
x: SearchResultType | AssetFilterSearchResultType = ...
x in AssetFilterSearchResultType // Returns true??
For now, just tested for strict equivalence to make this logic work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking the value against each enum member individually is fine, though I suspect that you won't need this function if the asset search UI is built separately from SearchDialog
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, thanks.
I think we still need this logic within the asset search component to render asset results and filter results a little differently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved this function to the other PR where it's actually used
445969c
to
104a5dd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some thoughts inline about separating the search components/hooks, related to comments on #20373.
const searchAndHandleSecondary = React.useCallback( | ||
async (queryString: string) => { | ||
async (queryString: string, returnAssetFilters: boolean) => { | ||
const {queryString: queryStringForResults, results} = await searchSecondary(queryString); | ||
dispatch({type: 'complete-secondary', queryString: queryStringForResults, results}); | ||
if (!returnAssetFilters) { | ||
dispatch({ | ||
type: 'complete-secondary', | ||
queryString: queryStringForResults, | ||
results: results.filter((result) => result.item.type === SearchResultType.Asset), // Only return asset results | ||
}); | ||
} else { | ||
dispatch({type: 'complete-secondary', queryString: queryStringForResults, results}); | ||
} | ||
}, | ||
[searchSecondary], | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine to add another parameter to configure what gets pushed to the worker, but here's a spot where I'd say that the behavior is specific to the search behavior itself, and not the component. I think you could pull this useCallback
out into a hook that can be reused by SearchDialog
and the new Asset UI. That way, SearchDialog
never has to know about this behavior -- it can just skip the asset filters (by passing false
to the hook, something like that) and otherwise remain unchanged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation here.
I played around with pulling this callback out into a hook, though I realized after your other comment about avoiding building unwanted results that we could configure whether asset filters are returned at the useGlobalSearch
hook level.
After that change, this filtering logic is no longer needed.
AssetGroup = 'AssetFilterSearchResultType.AssetGroup', | ||
} | ||
|
||
export function isAssetFilterSearchResultType( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking the value against each enum member individually is fine, though I suspect that you won't need this function if the asset search UI is built separately from SearchDialog
.
dispatch({ | ||
type: 'complete-secondary', | ||
queryString: queryStringForResults, | ||
results: results.filter((result) => result.item.type === SearchResultType.Asset), // Only return asset results |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like it would be a bit more efficient to avoid building the unwanted results, instead of discarding them here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call, I implemented that within useGlobalSearch
. A flag now is provided to useGlobalSearch
to indicate whether asset filter results should be returned or not.
1010eea
to
ecffd16
Compare
@hellendag appreciate the explanations here. I addressed the feedback and now |
type AssetDefinitionMetadata = { | ||
definition: { | ||
owners: Array< | ||
{__typename: 'UserAssetOwner'; email: string} | {__typename: 'TeamAssetOwner'; team: string} | ||
>; | ||
computeKind: string | null; | ||
groupName: string | null; | ||
repository: { | ||
name: string; | ||
location: {name: string}; | ||
}; | ||
} | null; | ||
}; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would go with something like this in order to keep a single source of truth for the base types.
type AssetDefinitionMetadata = {
definition: Pick<AssetNode['definition'], 'owners' | ' computeKind' | 'groupName' | 'repository'>;
}
or if you don't like picking keys like that you could do
type AssetDefinitionMetadata = {
definition: {
owners: AssetNode['definition']['owners']
...
},
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good call, I added this
ecffd16
to
ce41857
Compare
ce41857
to
b58b72c
Compare
One down side to this approach is that since there can be 2 instances of |
I guess for now it's probably fine and we can optimize that later if it becomes a problem. |
2ed0ed1
to
9b8a2ec
Compare
b58b72c
to
c92d186
Compare
// This is the version of the secondary query, used as part of the cache key. | ||
// When the data in the cache must be invalidated, this version should be bumped to prevent | ||
// fetching stale data. | ||
export const SEARCH_SECONDARY_DATA_VERSION = 'v1;'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We recently added caching to store the latest asset query result to load the search UI when the query hasn't completed. This PR adds additional fields to that query, but this causes an issue on the first load as the logic assumes those fields exist but they don't on the cached query data. This causes the asset search UI to be unloadable.
This PR adds a version to the key to ensure that we won't fetch stale data.
As the title. Used in #20372 <img width="1149" alt="image" src="https://github.com/dagster-io/dagster/assets/29110579/07bf4abb-a5aa-4a8d-88a4-140f76e63d81"> <img width="1455" alt="image" src="https://github.com/dagster-io/dagster/assets/29110579/506fd9e5-74e6-493d-96fe-a9040def6b22">
c92d186
to
1cdabc9
Compare
As the title. Used in #20372 <img width="1149" alt="image" src="https://github.com/dagster-io/dagster/assets/29110579/07bf4abb-a5aa-4a8d-88a4-140f76e63d81"> <img width="1455" alt="image" src="https://github.com/dagster-io/dagster/assets/29110579/506fd9e5-74e6-493d-96fe-a9040def6b22">
1cdabc9
to
289c094
Compare
@@ -207,7 +297,7 @@ export const useGlobalSearch = () => { | |||
loading: secondaryDataLoading, | |||
} = useIndexedDBCachedQuery<SearchSecondaryQuery, SearchSecondaryQueryVariables>({ | |||
query: SEARCH_SECONDARY_QUERY, | |||
key: 'SearchSecondary', | |||
key: `SearchSecondary:${SEARCH_SECONDARY_DATA_VERSION}`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works but it leaves the old cache in place so it never gets cleaned up. I think instead useIndexedDBCachedQuery
should take a third parameter version
that can be used to tell useIndexedDBCachedQuery
to ignore caches on a different version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. This PR is updated to now also store the data version in the cache.
I added a data version for both the primary and secondary queries since we should always be providing a version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet
This PR enables adds the following asset filters to the search index results: - asset owner - compute kind - code location - asset group This involves: 1. Querying for these fields per-asset on `SECONDARY_SEARCH_QUERY` 2. Grouping by field to determine the # of assets per filter 3. Adding each filter to the list of possible search results Open questions: - Perf impact of fetching these additional fields for each asset in graphQL?
As the title. Used in #20372 <img width="1149" alt="image" src="https://github.com/dagster-io/dagster/assets/29110579/07bf4abb-a5aa-4a8d-88a4-140f76e63d81"> <img width="1455" alt="image" src="https://github.com/dagster-io/dagster/assets/29110579/506fd9e5-74e6-493d-96fe-a9040def6b22">
This PR enables adds the following asset filters to the search index results: - asset owner - compute kind - code location - asset group This involves: 1. Querying for these fields per-asset on `SECONDARY_SEARCH_QUERY` 2. Grouping by field to determine the # of assets per filter 3. Adding each filter to the list of possible search results Open questions: - Perf impact of fetching these additional fields for each asset in graphQL?
This PR enables adds the following asset filters to the search index results:
This involves:
SECONDARY_SEARCH_QUERY
Open questions: