microsoft-graph-toolkit
microsoft-graph-toolkit copied to clipboard
Person-Card: It should be possible to link the image
Proposal: Person-Card: It should be possible to link the image to a custom URL or trigger a custom action on click
Description
In the SharePoint first-party person card the extended user profile layer is opened when the image in the person card is clicked. While it's not possible to have the same behavior in MGT (because the extended profile overlay can't be triggered as far as I know) it would be beneficial for developers to have the possibility to link the image to a custom URL at least.
Rationale
To mimic the behavior of the first-party person card in the best possible way, the developer should be able to react on the click of the image.
Preferred Solution
The best option would be to expose the click event on the image, so that the developer can react to this and perform a custom action, e.g. open a custom profile page. Therefore the event should contain the information in which user profile this event was triggered.
Additional Context
I checked, but didn't find a solution by customizing the current MGT person card. If there is a good solution with the current implementation, I would be happy to hear of it.
Hello nmtoblum, thank you for opening an issue with us!
I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌
Thanks for the feature request @nmtoblum
I have to admit to being a little out of the loop on SharePoint things these days, and as such I'm not quite following your request here.
In the context of a SharePoint page there might be some component showing a person:
For MGT this is analogous to the mgt-person
control.
When this is clicked on a bigger details card opens:
However, when clicking on the image in the expanded card in SharePoint nothing appears to happen.
We have a similar, optional behavior, on click or hover in the mgt-person
where the mgt-person-card
is shown as demonstrated in this story: https://mgt.dev/?path=/story/components-mgt-person-properties--person-card
I see that we don't have any events emitted on either the mgt-person when the user picture element is clicked but we do for each of the lines of text. Given that the mgt-person-card
is using the mgt-person
to show the simple user data, we could add a click event to the image on mgt-person
and extend mgt-person-card
to expose the click events for all the lines and the image, would that be sufficient for your purposes?
Secondary thought, would having the option to open an mgt-person-card
in the expanded view meet the needs here or is that unnecessary?
Hi @gavinbarron,
thank you for your feedback.
I think I may not have explained very well what my concern was.
My focus is the representation of the person together with a person card. In SharePoint standard, the profile picture is clickable in the Card and leads to an extended profile layer. I made a short video showing this in SharePoint. You can also see this in the tooltip that is on the profile picture in the card.
https://user-images.githubusercontent.com/57751598/214329651-73843caf-168c-48f6-9c68-10fdd37ce8e2.mp4
This feature is useful because it allows you to show all the information that doesn't find a place in the card.
We will probably not be able to trigger this extended profile layer in MGT. But it would be very helpful if we could register a click event on the profile picture (and the lines) in the person card to trigger a custom function there, for example to link to a custom profile page.
I'm not sure what you mean exactly with your second suggestion. To open the card immediately in the expanded state? It opens very quickly when hovering. I consider this behavior ok.
Many greetings Tobias
Thanks for clarifying @nmtoblum
Regarding the opening the card in the expanded state:
Here is the default state of the card when it opens via a hover or click:
While the getting to the expanded state requires an extra click:
It's reasonably straightforward to add an extra emitted clicked event to the mgt-person
and expose the click events on the mgt-person-card
, but this raises a UX question for me.
The current model for click events is a loosely coupled one in that the component emits and event that a developer may subscribe to, this means that the component is unaware of the existence of any event listeners.
The challenge here is the UI affordance for these elements that emit clicked events which a developer may or may not handle.
It's even worse in React as the lose coupling is and event-based nature of the components is abstracted in the shim such that looks like the component should know what events have listeners, which is not the case.
We could add attributes to pass in a custom tool tip string for each of these clickable items and rely on the existence of this attribute to control the UI affordance with labels and cursor states.
@sebastienlevert I'd love your thoughts on this.
So the challenge is to show the "clickable option" on the profile picture in the mgt-person-card
based on a potential listener of this event. As we are using some sort of composition (card within a person component), we need to "pollute" the parent attributes to control the child. Though, it seems we have another option.
mgt-person
has a template named person-card
(https://learn.microsoft.com/en-us/graph/toolkit/components/person#templates). Could we only add the event on the card and let the developers "redefine" the card to use (in this case, the native one). Something like this : https://stackblitz.com/edit/mgt-1998?file=index.html
How's that? We would add a specific event on the person-card without impacting the entire tree.
@gavinbarron I think I have understood your points now.
Regarding the opening of the card in the extended state: This would in principle be a useful option, but is not connected with the requirement because of which I have opened the issue.
I understand the UI problem in terms of events and labels arising from the fact that the mgt-person card again contains an mgt-person component in the header. As for solving this issue and @sebastienlevert suggestion, I'm having a hard time contributing because I don't know the internals of the implementation well enough.
Greetings Tobias
Hi @sebastienlevert @gavinbarron,
I just wanted to follow-up to see if we could revisit the discussion. I am still interested in finding a solution. My main concern is to be able to link the profile picture within the person card.
Many greetings Tobias
@sebastienlevert I think that the composed templates approach is probably the best option we have at present.