-
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
feat(frontend): show browse paths for business attributes related entities - schema fields #11585
feat(frontend): show browse paths for business attributes related entities - schema fields #11585
Conversation
d70479c
to
61e8a7e
Compare
61e8a7e
to
8946e05
Compare
8946e05
to
7de9982
Compare
7de9982
to
c4723ca
Compare
c4723ca
to
c4904fe
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.
looking solid! i have a few suggestions to make sure things work as expected and to clean it up. nothing crazy then i think it's good to go
""" | ||
Additional properties about EntityName | ||
""" | ||
type EntityNameProperties { |
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 i see you using this as a means to add typing to your frontend properties. however we should only be adding things to the graphql schema that we plan to map back to the client, otherwise it would get confusing what's just existing as a type for the FE vs what exists as a returnable type from GMS
we can always define an interface
or type
in typescript if we need to cast objects on the frontend into a specific type and I would suggest we do that here instead
); | ||
renderPreview = (previewType: PreviewType, data: SchemaFieldEntity) => { | ||
const parent = data.parent as Dataset; | ||
const properties = parent.properties as EntityNameProperties; |
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.
could we not just use the properties on Dataset
here (DatasetProperties
)? they already have name
and qualifiedName
in the correct types i believe right?
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.
DatasetProperties
require lastModified
as a mandatory field which in our case was missing, hence we defined a new type EntityNameProperties
containing only name and qualifiedName
.
@@ -284,6 +289,9 @@ export default function DefaultPreviewCard({ | |||
parentEntities={parentEntities} | |||
parentContainersRef={contentRef} | |||
areContainersTruncated={isContentTruncated} | |||
parentDatasetUrn={urn} |
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 might be nice for DefaultPreviewCard
to explicitly take in an optional parentDatasetUrn
and pass that in from the schema field since right now passing in parentDatasetUrn={urn}
would mean every entity would pass in their own urn as the parentDatasetUrn
which could definitely cause confusion down the line
{parentDatasetUrn && parentDatasetProperties && parentDatasetIcon && ( | ||
<span> | ||
<StyledRightOutlined data-testid="right-arrow" /> | ||
<DatasetLink | ||
parentDatasetUrn={parentDatasetUrn} | ||
parentDatasetProperties={parentDatasetProperties} | ||
parentDatasetIcon={parentDatasetIcon} | ||
/> | ||
</span> | ||
)} |
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.
would you mind posting a screenshot of the final output in your PR description so we can see how this change looks in the UI?
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.
if (!parentDatasetUrn && !parentDatasetProperties) return null; | ||
|
||
const datasetUrl = entityRegistry.getEntityUrl(EntityType.Dataset, parentDatasetUrn); | ||
const datasetName = entityRegistry.getDisplayName(EntityType.Dataset, parentDatasetProperties); |
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.
does this retrieve the correct dataset name? i believe entityRegistry.getDisplayName
takes in a whole entity object, not just the properties object.
maybe it makes more sense to simply pass along the whole parentDataset
object from Preview
> DefaultPreviewCard
> DatasetLink
instead? then you can get the urn, the icon and the whatever else you may need where you need it
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.
Yes, it retrieves the correct dataset name as entityRegistry.getDisplayName
function looks for properties.name, if not present it looks for name in the object passed, we were passing the following object {properties : {name: datasetName, qualifiedName: datasetQualifiedName}}, so it was able to extract correct dataset name.
However, as suggested, now we are passing parentDataset
object from Preview, which addresses the following things:
- passing parentDataset object as Dataset from Preview which includes urn and properties
- doesn't require parentDatasetUrn to be passed explicitly
- no need to define type/interface for parentDatasetProperties as we did earlier by defining EntityNameProperties
This addresses the above comments as well.
c4904fe
to
bf2f357
Compare
bf2f357
to
3e3fe70
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.
nice thank you for addressing those comments! i have one more quick request and that's to remove the parentDatasetIcon
prop that's being passed multiple levels down and just get the icon using entity registry in DatasetLink
|
||
return ( | ||
<StyledLink to={datasetUrl} data-testid="dataset"> | ||
<DatasetIcon>{parentDatasetIcon}</DatasetIcon> |
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 passing parentDatasetIcon
down these levels is unnecessary since it should always just be a regular dataset icon you get by using entityRegistry.getIcon(EntityType.Dataset, 14, IconStyleType.ACCENT)
we could just get the icon here in this component and if we ever want to start providing dynamic icons we can accept that as a prop for this component
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.
Agreed, I have made the changes suggested above. Thanks!
…ities - schema fields
3e3fe70
to
1fcaa13
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.
looking good!
…ities - schema fields (datahub-project#11585)
…elds)
Checklist