Next.js production: CANNOT READ DATA FROM FIRESTORE

Question

I have a next.js application in which I have a real-time chat feature.

A get() request is supposed to be sent to firestore to check if chat between user A and user B already exists. If it does not already exist, a new chat between A and B is created

Problem:

The get() request to firestore always returns an empty value. So a new chat room between user A and user B is always created.

Since a new chat room is created successfully, I can write to firestore but cannot read data.

the code:

import { useEffect, useState } from "react";
import { dbs } from "../utils/firebase";

function Test() {
  const [chats, setChats] = useState([]);
  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await dbs
          .collection("chats")
          .where("users", "array-contains", "some@email")
          .get();
        setChats(response);
      } catch (err) {
        console.log(err);
      }
    };
    fetchData();
  }, []);
  console.log("chat is", chats);

  return <div></div>;
}

export default Test;

What I have attempted and discovered:

• I deployed an entirely new next.js app (let's call it app B) and tried to get data from the same firestore project with the same code above and it works. So my firestore configuration is fine, the code is fine, and there's nothing wrong with the deployment server.
• Since there's nothing wrong with firestore or the deployment server or the code, I think something is wrong with the next.js app itself and the dependencies surrounding it. I don't know why it works in app B and not in app A.

Note, in App A:

• Everything works fine in development mode, I can get the data.
• I'm also using mongoDB and other third-party APIs in this app and I can successfully read and write data to these APIs. Only the get() request to firestore is not working. which made me think the problem must be with my firestore config but app B proves that's not the case.
• I'm using google OAuth with mongoDB and next-auth to authenticate my users in app A. In app B I'm only using google OAuth without the DB.

I could show the code for both app A and app B but they are exactly the same. The code under the _app.js file is the same, the way I structure it is also the same. In both app A and app B, I called the get() request to firestore from a Test.js component in a test.js page but the get() request only returns value in app B and always returns null in app A.

So basically the only difference is app A is an actual app with plenty of dependencies, libraries, and files. app B is just a test app.

My question now is:

• Could the read operation to firestore be affected by other dependencies or npm libraries in the project? or could it be affected by using another DB to get the auth session context?
• Why is the write operation successful but not the read?
• Why does it work in dev mode but not in prod mode? is there any difference between retrieving data from firestore in dev mode vs prod mode?

Answer 1

As explained yesterday, you aren't paying close enough attention to the intermediate states properly and it is likely that NextJS is tripping up because of it.

On the first render of your current code, chats is an empty array. Even so, once the promise fulfills, you update chats to a QuerySnapshot object, not an array.

import { useEffect, useState } from "react";
import { dbs } from "../utils/firebase";

function Test() {
  const currentUserEmail = "some@email"; // get from wherever

  const [chatsInfo, setChatsInfo] = useState({ status: "loading", data: null, error: null });

  useEffect(() => {
    let unsubscribed = false;

    const fetchData = async () => {
      return dbs
        .collection("chats")
        .where("users", "array-contains", currentUserEmail)
        .get();
    };

    fetchData()
      .then(() => {
        if (unsubscribed) return; // do nothing
        setChatsInfo({
          status: "loaded",
          data: response.docs, // QueryDocumentSnapshot[]
          error: null
        });
      })
      .catch((err) => {
        if (unsubscribed) return; // do nothing
        setChatsInfo({
          status: "error",
          data: null,
          error: err
        });
      });
    };
    // return a unsubcribe callback that makes sure setChatsInfo
    // isn't called when the component is unmounted or is out of date    ​
    ​return () => unsubscribed = true; 
 ​ }, [currentUserEmail]); // rerun if user email changes
​ 
​  const { status, data: chats, error } = chatsInfo;
  console.log(JSON.parse(JSON.stringify({ status, chats, error }))); // crude object copy

  switch (status) {
    case "loading":
      return (<div>Loading...</div>);
    case "error":
      return (
        <div class="error">
          Failed to load data: {error.code || error.message}
        </div>
      );
  }

  // if here, status is "loaded"

  if (chats.length === 0) {
    // You could also show a "Message Someone" call-to-action button here
    return (
      <div class="error">
        No chat groups found.
      </div>
    );
  }

  // stamp out list of chats
  return (<>
    {chats.map((chatDoc) => {
      return (
        <div key={chatDoc.id}>
          {JSON.stringify(chatDoc.data())}
        </div>
      );
    })}
  </>);
}

export default Test;

Notes:

• A decent chunk of the above code can be eliminated by using an implementation of useAsyncEffect like @react-hook/async and use-async-effect. These will handle the intermediate states for you like loading, improper authentication, unmounting before finishing, and other errors (which are all not covered in the above snippet). This thread contains more details on this topic.
• I highly recommend not using email addresses in their raw form for user IDs. With the current structure of your database, anyone can come along and rip all the emails out and start spamming them.
• Each user should have some private identifier that doesn't reveal sensitive information about that user. This could be a Firebase Authentication User ID, the user's email address hashed using md5 (which also allows you to use Gravatar for user profile pictures) or some other ID like a username. Once you have such a user ID, you can use the approach outlined in this thread for handling messages between users.