How can I structure Firestore relationship data to sort friends by username?

When you need to sort by the friend's name—which depends on which user is viewing the document—you’ll run into trouble if you store both names in the same document without a clear “friend name” field from the current user’s perspective. Firestore’s orderBy always acts on a specific field in each document. Here are some approaches to solve this:

---

1. Denormalize by Duplicating Friend Data

Because the “other user” in the relationship is not fixed from the document’s point of view (it depends on who is querying), one common solution is to create a field that directly represents the friend’s name relative to the logged-in user. For example, instead of a single document with both names, you can store a field like friendName (and friendUID) and even create one relationship document per user. For instance:

• Create a collection (or duplicate fields inside the same document) so that when user A adds user B as a friend, you store:

  JAVASCRIPTCopied
  // For user A's perspective
  firestore.collection("user_relationships").add({
    uid: "A",
    friendUID: "B",
    friendName: "User B",
    status: "friends",
    // ... other fields
  });

  And similarly for user B’s perspective:

  JAVASCRIPTCopied
  // For user B's perspective
  firestore.collection("user_relationships").add({
    uid: "B",
    friendUID: "A",
    friendName: "User A",
    status: "friends",
    // ... other fields
  });

• Then you can query as follows:

  JAVASCRIPTCopied
  firestore.collection("user_relationships")
    .where("uid", "==", myUID)
    .where("status", "==", "friends")
    .orderBy("friendName")
    .limit(10)
    .get()

This way, every relationship document is already oriented to the current user, and you can cleanly order by friendName.

---

2. Compute a Sort Field on Write

If you really need to keep a single document for both users, another approach is to compute two additional fields at write time (say, name1ForA, name1ForB or even a mapping object) that let you pick the correct friend name during the query. However, this generally leads to more complex data management. For example, you might have:

• nameForUid_A: the friend name from A’s perspective (if A is in the relationship)
• nameForUid_B: the friend name from B’s perspective

Then your client would have to know which field to order by (if myUID equals A’s id, order by nameForUid_A; else, nameForUid_B). Unfortunately, Firestore queries do not allow using a dynamic field name in orderBy, which is why this alternative is less straightforward.

---

Conclusion

The recommended solution is to denormalize your data by creating a document per user (or storing a field that always reflects the friend’s name relative to the current user). Although this means duplicating relationship data, it simplifies your queries and allows you to use the orderBy clause for pagination without complications.

Remember, Firestore queries order documents based on static fields. Precomputing and storing the friend’s name in a dedicated field is essential for achieving the required sorted order.