Next.js应用中Firebase订单数据获取为空的解决方案

本文旨在解决Next.js应用中，结合`next-auth`和Firebase获取用户订单数据时，即使查询成功但数据数组却为空的问题。核心在于确保`getSession`正确获取到包含用户邮箱的会话信息，并对会话对象进行健壮性检查，以避免因`session.user.email`缺失导致Firebase查询路径不正确。

在构建现代Web应用时，Next.js因其卓越的性能和开发者体验而广受欢迎。当结合Firebase作为后端数据库和next-auth进行身份验证时，开发者可能会遇到一个常见问题：尝试从Firebase获取用户特定数据（如订单历史）时，即使看似查询成功，返回的数据数组却为空。这通常指向会话（session）信息处理不当，特别是用户邮箱（session.user.email）在构建Firebase查询路径时缺失或不正确。

问题分析

在Next.js的getServerSideProps函数中，通常会使用next-auth的getSession方法来获取当前用户的会话信息。随后，这些会话信息（特别是用户邮箱）被用于构建Firebase Firestore的文档路径，例如db.collection("users").doc(session.user.email).collection("orders")。

如果getSession未能返回一个有效的会话对象，或者返回的会话对象中缺少user属性，或者user属性中缺少email，那么后续的Firebase查询将指向一个不存在的路径，从而导致stripeOrders.docs为空，最终导致前端页面显示空订单列表。尽管Firebase查询本身可能不会抛出错误（因为它成功地“查询”了一个空路径），但结果却不符合预期。

AppMall应用商店

AI应用商店，提供即时交付、按需付费的人工智能应用服务

56

查看详情

解决方案

解决此问题的关键在于确保getSession正确返回会话，并且在构建Firebase查询路径之前，对会话对象及其关键属性（如session.user.email）进行严格的有效性检查。此外，有时TypeScript的类型推断可能导致编译时错误或运行时不确定性，此时可以考虑显式指定类型。

1. 确保getSession的正确使用和类型安全

首先，确保getSession被正确地await。其次，为了避免潜在的类型推断问题，可以显式地将session变量声明为any类型，尽管这通常作为一种临时解决方案，更推荐的做法是根据next-auth的类型定义来处理。

import { getSession } from "next-auth/react";
import db from "../../firebase"; // 确保Firebase实例已正确导入和初始化
import moment from "moment"; // 确保moment已正确导入

// ... 其他导入

export async function getServerSideProps(context) {
  const stripe = require("stripe")(process.env.STRIPE_SECRET_KEY);

  // 确保getSession被正确await，并可选择性地使用any类型以避免类型推断问题
  const session: any = await getSession(context);

  // 关键：在进行Firebase查询前，对会话和用户邮箱进行严格检查
  if (!session || !session.user || !session.user.email) {
    console.warn("会话或用户邮箱缺失，无法获取订单数据。");
    return {
      props: {
        orders: [], // 返回一个空数组，避免客户端渲染错误
      },
    };
  }

  // Firebase DB 查询
  const stripeOrders = await db
    .collection("users")
    .doc(session.user.email) // 此时 session.user.email 保证存在
    .collection("orders")
    .orderBy("timestamp", "desc")
    .get();

  // 将Firebase文档转换为可序列化的JavaScript对象
  const orders = await Promise.all(
    stripeOrders.docs.map(async (order) => ({
      id: order.id,
      amount: order.data().amount,
      images: order.data().images,
      timestamp: moment(order.data().timestamp.toDate()).unix(),
      items: (
        await stripe.checkout.sessions.listLineItems(order.id, {
          limit: 100,
        })
      ).data,
    }))
  );

  return {
    props: {
      orders,
    },
  };
}

2. 详细解释与注意事项

• const session: any = await getSession(context);: 这里的any类型是一种快速解决TypeScript类型推断问题的手段。如果next-auth的类型定义未能正确地将session.user.email识别为字符串，或者在某些情况下session.user可能为null或undefined，使用any可以绕过编译时的类型检查。然而，更推荐的做法是配置好next-auth的类型模块，以便TypeScript能够正确推断Session对象的结构。
• 健壮性检查: if (!session || !session.user || !session.user.email)这一行至关重要。它确保了在尝试访问session.user.email之前，session对象本身、session.user属性以及session.user.email属性都存在且非空。如果这些条件不满足，函数会立即返回一个空orders数组，从而避免运行时错误并向用户提供一个优雅的空状态。
• Firebase路径: Firebase Firestore的文档路径是严格的。如果doc()方法接收到一个null、undefined或空字符串作为参数，它将无法定位到正确的文档，导致查询结果为空。
• 错误处理: 除了上述检查，还应考虑在Firebase查询和Stripe API调用中添加try-catch块，以捕获潜在的网络错误或API响应错误，进一步增强应用的健壮性。
• Firebase初始化: 确保firebase.js文件中的Firebase应用已正确初始化，并且db实例被正确导出和导入。

// firebase.js 示例
import firebase from "firebase/compat/app";
import "firebase/compat/firestore";

const firebaseConfig = {
  apiKey: "YOUR_API_KEY", // 替换为你的API密钥
  authDomain: "YOUR_AUTH_DOMAIN",
  projectId: "YOUR_PROJECT_ID",
  storageBucket: "YOUR_STORAGE_BUCKET",
  messagingSenderId: "YOUR_MESSAGING_SENDER_ID",
  appId: "YOUR_APP_ID",
};

// 避免重复初始化Firebase应用
const app = !firebase.apps.length
  ? firebase.initializeApp(firebaseConfig)
  : firebase.app();

const db = app.firestore();
export default db;

总结

当在Next.js应用中使用next-auth和Firebase时，获取数据为空的问题通常源于getSession返回的会话信息不完整或未被充分验证。通过对getServerSideProps函数中的session对象进行严格的空值和属性存在性检查，并确保session.user.email在构建Firebase查询路径时始终有效，可以有效地解决此问题。虽然使用any类型可以快速解决TypeScript的类型推断问题，但更专业的做法是配置好类型定义并结合健壮的运行时检查，以确保代码的稳定性和可维护性。

以上就是Next.js应用中Firebase订单数据获取为空的解决方案的详细内容，更多请关注php中文网其它相关文章！