-
Notifications
You must be signed in to change notification settings - Fork 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
Combine siblings in autocomplete #8610
Combine siblings in autocomplete #8610
Conversation
combineSiblingsInSearchResults, | ||
shouldEntityBeTreatedAsPrimary, | ||
} from '../siblingUtils'; | ||
import { combineEntityDataWithSiblings, shouldEntityBeTreatedAsPrimary } from '../siblingUtils'; |
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 stuff was ported to combineSiblingsInSearchResults.test.ts
@@ -202,53 +203,56 @@ export const combineEntityDataWithSiblings = <T>(baseEntity: T): T => { | |||
return { [baseEntityKey]: combinedBaseEntity } as unknown as T; | |||
}; | |||
|
|||
export type CombinedSearchResult = { | |||
export type CombinedEntityResult = { |
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.
combineSiblingEntities is now more generalized and less about search specifically so other use cases can just pass in some entities and combine siblings (as long as you provided a gql entity that actually had siblings). Should make it more reusable.
): Array<CombinedSearchResult> { | ||
return combineSiblingEntities(input?.map((value) => value.entity)).map((combinedResult) => ({ | ||
...combinedResult, | ||
matchedFields: [], |
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.
Oversight on my part, gotta make sure this is preserved.
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.
looking solid! a couple of minor questions and just a warning about the conflict
@@ -2,7 +2,8 @@ import merge from 'deepmerge'; | |||
import { unionBy, keyBy, values } from 'lodash'; |
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.
looks like we have a conflict from my changes to display consistent combined search results for sibling entities in this PR: https://github.com/datahub-project/datahub/pull/8602/files#diff-dbeb733a628595000d108fe2f57b5c464d52b6da55f57d57ad4bc6e246af3914
so let's make sure we keep that functionlity! the main thing I did is simply combine the siblings entity data in combineSiblingsInSearchResults
and refactored a function above it to make it reusable between its two uses
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.
Think I got the conflict resolved 👍
const parentContainers = | ||
entities | ||
.map((ent) => { | ||
const genericPropsForEnt = entityRegistry.getGenericEntityProperties(ent.type, ent); | ||
const entParentContainers = genericPropsForEnt?.parentContainers?.containers || []; | ||
return [...entParentContainers].reverse(); | ||
}) | ||
.find((containers) => containers.length > 0) ?? []; |
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 feel like this should be taken care of when we combine sibling data so we end up just getting one parentContainers
based on the combined data.
In fact, with my changes in #8602 we can now get proper parentContainers
combined so you can just use the combined entity 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.
Awesome. So like if one sibling had no parentContainers and another one missed them, it would automatically choose the one that had them present?
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.
It does seem to work thought! Shows the bigquery containers even on the dbt primary.
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.
yup exactly! so it'll choose the primary if both fields are filled out, but if one is filled out and not the other, it'll take the non-empty one
const platformNames = entities | ||
.map((ent) => { | ||
const genericPropsForEnt = entityRegistry.getGenericEntityProperties(ent.type, ent); | ||
const platform = genericPropsForEnt?.platform; | ||
if (platform?.properties?.displayName) return platform.properties.displayName; | ||
if (platform?.name) return capitalizeFirstLetterOnly(platform.name) || ''; | ||
return ''; | ||
}) | ||
.filter(Boolean); |
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.
nit: i feel like this could be pulled out into its own function. Also I see elsewhere that we have siblingPlatforms
on genericProperties
that you can maybe use 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.
Updated! I left the iteration in this component but reused an existing helper function we already have.
@@ -149,6 +142,7 @@ export const SearchBar = ({ | |||
hideRecommendations, | |||
showQuickFilters, | |||
viewsEnabled = false, | |||
combineSiblings = false, |
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.
so we default want to not combine siblings in our search bar? is there somewhere where we particularly don't want them combined?
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.
Right the idea was to make siblings an opt-in behavior, where the home/searchResults pages have that behavior but not assume that all use cases in the UI would get that behavior was my thought.
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.
nice man looking good!
This PR merges autocomplete results similar to how we do it in the frontend for things like search cards.
Changes
any
types, etcSiblings
Single