Wp-calypso: Gravatar: Support avatars based on email address

[brandonpayton]

Calypso's <Gravatar /> component currently renders based on a user object specified via the user prop. For the Share a Draft feature (#16002), we need to support Gravatars based on email addresses of the people we've shared with.

We've discussed updating the component to take a URL string instead of a user object, but I'm not sure this is the correct course because it externalizes knowledge of what a Gravatar URL is. Would it be better to encapsulate that knowledge in the Gravatar component by supporting an email prop and generating the URL internally?

Initially, I don't love supporting both an email and a user prop, but I'm not sure it is a problem in practice. We can give the user prop precedence and warn when both are specified. In addition, this keeps existing <Gravatar /> consumers from having to consider image URLs.

I am both happy to do the work and happy to receive help on this but want to discuss the right direction first.

What do you think?

cc @nb, @dmsnell, @v18

[v18]

Initially, I don't love supporting both an email and a user prop

I'd prefer to see the component take only the props it needs, instead of relying on the user object prop. For reference, here are the props that user currently has:

• display_name
• avatar_URL
• ID

supporting an email prop and generating the URL internally

Btw, I found one case where changing to use an email address isn't straightforward - showing the Gravatars of happiness engineers (https://github.com/Automattic/wp-calypso/blob/master/client/me/help/help-happiness-engineers/index.jsx#L34). We're relying on an API response that contains the avatar URLs, and that response does not currently contain email addresses. I could also see us wanting to continue to rely on URLs in case we want to display specific non-Gravatar avatars for each HE.

[nb]

I also agree that sending (or requiring) the whole user object is far from idea. To quote the old OOP mantra, at the store we give the cashier only our credit card, not our wallet :)

Is there a problem the component supporting various ways to identify the gravatar: e-mail, username, full URL? Ideally those will be separate props to communicate the intent and data type/source better.

[dmsnell]

To quote the old OOP mantra, at the store we give the cashier only our credit card, not our wallet :)

love it

[brandonpayton]

Thank you for your feedback, @v18 and @nb.

I agree that user objects should not be the primary data source for avatars and don't like that supporting a user object obscures the data dependencies of an avatar component by allowing it to privately reference the fields it needs rather than taking them explicitly as props. But there may be value in encapsulating knowledge of how avatars are rendered from user objects, at least if you desire consistency.

Btw, I found one case where changing to use an email address isn't straightforward

I didn't mean to propose that all avatars should be driven by email address, but my comments may have sounded that way. Thank you for looking.

Is there a problem the component supporting various ways to identify the gravatar: e-mail, username, full URL? Ideally those will be separate props to communicate the intent and data type/source better.

It's funny... after I proposed supporting multiple ways to identify an avatar in a single component, my first reaction to your comment was that we should avoid it. I noticed my inconsistency but still considered the thought. I took time sketching separate components like <Avatar url=""/>, <Gravatar email="" />, and even <UserAvatar user={} />. I was going to discuss the possibility of separate components, but after writing them out, I returned to believing a single component is better because:

1. It's not reasonable to expect developers to remember a variety of component flavors. The flavors will be inconsistently used because people will miss or forget them.
2. A component can still be focused on doing one thing well, even if it supports multiple, mutually exclusive data sources.

It seems we may be close to agreeing <Gravatar /> can support mutually exclusive url and email props. Is that the case?

Personally, I am not averse to supporting a user prop as one of the data sources, assuming it is useful and provides some consistency among those who render user avatars, but we can convert to using the url prop if needed.

[nb]

It seems we may be close to agreeing <Gravatar /> can support mutually exclusive url and email props. Is that the case?

Yes.

[stale[bot]]

This issue has been marked as stale and will be closed in seven days. This happened because:

• It has been inactive in the past 9 months.
• It isn't a project or a milestone, and hasn’t been labeled `[Pri] Blocker`, `[Pri] High`, `[Status] Keep Open`, or `OSS Citizen`.

You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation.