# When to ❤ something?

**URL:** <https://discourse.sourcecred.io/t/when-to-something/635>\
**Category:** Uncategorized\
**Created:** [February 10, 2020, 7:19pm UTC](https://discourse.sourcecred.io/t/when-to-something/635 "2020-02-10T19:19:43Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![wchargin](https://yyz2.discourse-cdn.com/flex032/user_avatar/discourse.sourcecred.io/wchargin/32/1397_2.png) [@wchargin](https://discourse.sourcecred.io/u/wchargin)\
**Post date:** [February 11, 2020, 5:51am UTC](https://discourse.sourcecred.io/t/when-to-something/635/3 "2020-02-11T05:51:51Z")

</div>

Three people, three practices!

I use ❤s very sparingly on persistent platforms like Discourse. Without looking at my profile, I can tell you with high confidence that I have ❤ed exactly three posts. I can tell you which posts they were (and in what order), and why I chose to ❤ each one: the reasons are all different.

Off the top of my head, I didn’t know what my stats for GitHub were. But I wrote a simple query to find out\*, and it looks like I’ve ❤ed five posts, which seems proportionally commensurate.

On Discord, my reactions flow more freely, precisely because they are more ephemeral.

I think that it’s important to recognize that there is such a diversity of practice here. This thread hasn’t come close to covering everyone’s usage patterns, and already we see a bunch of variance. It will be tricky to try to find a “one size fits all” semantics for the interpretation of ❤ reactions, yet I suspect that it’s important that we meet people where they are. If we design our own platform for SourceCred, we can tweak the UX endlessly, but as long as the button is labeled “❤”, people are going to come in with preconceptions, and they will use the button how they please.

So—

> [@1GLENCo](#):
>
> Sorry that I haven’t learned the ropes around here yet

—don’t apologize! Your opinion is valid.

> **\* The way to my :heart:**
>
> The expressiveness of the GraphQL-to-SQL mirror really shines here—you can’t express this in a GraphQL query because it needs to traverse edges backward, but it’s trivial in SQL:
> 
> ```sql
> -- What GitHub posts has @wchargin :heart:ed?
> SELECT reactable_url.value AS url
> FROM objects AS reactions
> JOIN primitives AS reaction_primitives
> ON reactions.id = reaction_primitives.object_id
> AND reactions.typename = 'Reaction'
> AND reaction_primitives.fieldname = 'content'
> AND reaction_primitives.value = '"HEART"'
> JOIN links AS reaction_user
> ON reactions.id = reaction_user.parent_id
> AND reaction_user.fieldname = 'user'
> JOIN primitives AS user_primitives
> ON reaction_user.child_id = user_primitives.object_id
> AND user_primitives.fieldname = 'login'
> AND user_primitives.value = '"wchargin"'
> JOIN connection_entries AS reaction_parent_entry
> ON reaction_parent_entry.child_id = reactions.id
> JOIN connections AS reactable_cxn
> ON reactable_cxn.rowid = reaction_parent_entry.connection_id
> JOIN primitives AS reactable_url
> ON reactable_cxn.object_id = reactable_url.object_id
> AND reactable_url.fieldname = 'url'
> ;
> 
> ```
> 
> I think that at last I may have gotten the SQL schema right. I also think that I may have gotten the indices right: the query plan here users only indexed searches except for the `reaction_parent_id` lookup, which is reasonable because reverse-edge searches aren’t something that we actually care about in production SourceCred.

---

_[View the full topic](https://discourse.sourcecred.io/t/when-to-something/635)._