Forem: Datravous Odds

Loading Seller Dashboard Data

Datravous Odds — Fri, 04 Apr 2025 23:36:40 +0000

This weekend I continued to work on my e-commerce all-in-one platform that essentially allows users to do all the things that a reseller does, with some additional features and services. Here are some things that I have completed over the past weekend:

Loaded overview data to front end
Created schema for trades, products, and product drafts
Loaded products and product detail data from backend to front end using Firebase functions

Loading the Overview Data

After finishing up on the payment information tab function for the user's profile, I started working on connecting the backend schema data for the overview tab to the Firebase database which holds all my user information. I had the UI set up pretty much how I wanted; I just needed to connect the backend.

I started by accessing the user's data, which gets loaded when the user is logged in, from the checkUserStatus function that's located in the auth.js file. That holds all the authentication checking methods. Once this was done, I console.log'd the data which showed the user information.

Once this was done, all I needed to do was access each object which contained the information that I needed. You can access information from an object similar to how you do in JavaScript by using the dot notation. So to access the seller overview information we would use userData.sellerOverview, which would give us access to the overview data. Afterwards I stored the data into a variable called data, then updated the UI with the corresponding data pulled from the backend (Firebase's Database).

async function loadOverviewTabInfo(userData) {
  if (!userData) return null;

  // create reference
  const data = userData.sellerOverview;

  // update UI display
  document.getElementById("total-revenue-value").textContent =
    data.totalRevenue;
  document.getElementById("active-listing-value").textContent =
    data.activeListing;
  document.getElementById("product-sold-value").textContent = data.productsSold;
  document.getElementById("active-listing-value").textContent =
    data.activeListing;
  document.getElementById("product-sold-value").textContent = data.productsSold;
  document.getElementById("selling-rate-value").textContent =
    userData.sellerOverview.sellerRating;

  loadProducts(userData);
}

Creating the Trades, Products, and ProductDrafts Schema in Firebase Database

After loading the overview data, we needed to load the products to each of the corresponding tables in the UI. Each table corresponds to the following headers: all, active, for trade, pending trades, etc.

The following is the structure of each collection in the Firebase database. A collection of data is just a collection of data fields that correspond to the current documents. In this context, it corresponds to the product ID, which is the ID of each product.

Since trades, products, and productDrafts are documents that hold a collection of data, the following describes the fields needed for each document.

Trades

lastUpdated: when the item was last updated
requestItems: what items the user requested for the trade to happen (stored in an array)
requestingUserId: ID of the user requesting the trade
status: current status of the item for the trade (pending, reserved, expired, under review, etc.)
storeCredit: amount of store credit that can be given for the trade
submitted: date the trade was submitted or requested
tradeBalance: current balance the user has after every trade
tradingItems: items that the current user is trying to trade for the requesting items
tradingUserId: ID of the owner who initiated the trade

Products

analytics: analytical data corresponding to views, conversion rate, timestamps, etc.
basicInfo: item's general information
demand: level of priority of this item, percentage change, and whether the item is trending
images: images for the items, alt tag, src of the item
inventory: detailed information used for authentication and tracking product quantity
pricing: all information about cost of the product, retail price, etc.
sellBack: information about the item's worth if sold back to us
seo: information used for search parameters to help identify through keywords
shipping: all shipping information for the product and associated fees
specifications: dimensions used for shipping and to determine object size
supplier: vendor which originally provided the item before resale
variants: different colors and styles of the product
waitlist: number of people waiting for item restock or reservation
status: whether the item is currently available, pending, out-of-stock, etc.

ProductDrafts

basicInfo: all basic information for the item (same as products)
completedSections: completed parts of the draft so far
completionProgress: percentage amount of the product information completed
createdAt: timestamp when the item was created and drafted
draftId: unique ID of the draft item for easy identification
images: images for the draft item
isCompleted: whether the draft is completed
lastEdited: timestamp when user last edited the draft
missingInfo: missing information needed to complete the listing
originalProductId: ID of the original product
price: price of the draft item
publishBlockers: items or sections required for listing
requiredSections: sections needed to be completed for listing
status: status of the item
userId: ID of the owner making the current changes

Summary

These are the changes and adjustments that I have made so far on the journey of building an all-in-one e-commerce platform. I have learned a lot, like data indexing, querying data, connecting backend data with the front-end structure, and displaying information to the client. Please stay tuned next week as I continue working on completing the profile implementation and front-end/backend construction.

UX Improvement: Solving the "No Data" Problem in Financial Document Interfaces

Datravous Odds — Sun, 23 Mar 2025 16:35:50 +0000

As developers, we often focus on the happy path—when everything works perfectly and data loads as expected. But what about when there's no data to display? In our recent update, we tackled this common but often overlooked UX challenge by implementing modal notifications for missing financial documents.

The Problem: The Dreaded "No Data" Scenario

Users need to be able to access their financial documents, for this case it would be their statements and tax documents that would need to be readily available. But what happens when there is no data available? What do we show the user then? Previously before this implementation, it would just show an empty table or nothing at all—confusing users and likely causing more problems once live in production. This would probably lead to users asking, "Where are my documents and statements?"

The Solution: Informative Modal Notifications

Our solution was clear: implement modals for both the statements and the 1099-K form when none are available. We also implemented the functionality to allow users to download their statements and 1099-K forms when available:

Statements that aren't available yet
Form 1099-k documents that haven't been generated
Statements and 1099k document be downloadable

Instead of leaving users wondering why they can't see their documents or download them, this implementation provides:

Clear explanation of the current status
Information about when documents might become available
A way to download the document when available

<div
                class="no-statement-modal"
                id="no-statement-modal"
                role="dialog"
                aria-labelledby="no-statement-title"
                aria-describedby="no-statement-description"
              >
                <div class="no-statement-modal-content">
                  <div class="no-statement-icon">
                    <i class="far fa-file-alt" aria-hidden="true"></i>
                  </div>
                  <h3 class="no-statement-title">No statements available</h3>
                  <p class="no-statement-description">
                    There are currently no statements for this period.
                    Statements will appear here once they become available.
                  </p>
                </div>
              </div>

The code above shows the basic structure for the no statements modal, and we also use this modal for other UI displays. This starts with the parent container with the class of no-statement-modal, followed by the box modal structure capturing the content which will be displayed when there is no content or statements available. When using this modal for other implementations such as no tax documents available, or no 1099-K forms, or other similar situations, you can simply replace the h3 header and p element accordingly. This creates a basic error modal or no-data-available notification that simply lets the user know what data is not available—informing them there is not any data available and not leaving them assuming something is broken.

The Javascript

async function loadStatements(userData, statementId = "2025-01") {
  const statementList = document.querySelector(".statement-list");

  // clear existing content
  statementList.innerHTML = "";

  if (!userData || !statementId) return null;

  try {
    const statementDocRef = doc(
      db,
      "userProfiles",
      userData.email,
      "statements",
      statementId
    );

    const statementSnapshot = await getDoc(statementDocRef);



    if (statementSnapshot.empty) {
      // show no statements modal
      showNoStatementsModal(statementList);
      return;
    }

    statementSnapshot.forEach((doc) => {
      // get data from each document
      const statement = doc.data();

      // create html structure
      const statementItem = document.createElement("div");

      // download url
      const downloadUrl = statement.downloadUrl || "#";

      statementItem.innerHTML = `
      <div class="statement-info">
        <div class="icon-container">
          <i class="far fa-file-alt"></i>
        </div>
        <div class="statement-text">
          <p class="title">${statementItem.title}</p>
          <p class="subtitle">${statementItem.year}</p>
        </div>
      </div>
      <a href="${downloadUrl}" class="statement-action">
        <i class="fas fa-download"></i>
        <span>View Details</span>
      </a>
      `;

      statementList.appendChild(statementItem);
    });
  } catch (error) {
    console.log("Error occurred loading data: ", error);
  }
}

// helper function
function showNoStatementsModal(container) {
  container.innerHTML = `
  <div
                class="no-statement-modal"
                id="no-statement-modal"
                role="dialog"
                aria-labelledby="no-statement-title"
                aria-describedby="no-statement-description"
              >
                <div class="no-statement-modal-content">
                  <div class="no-statement-icon">
                    <i class="far fa-file-alt" aria-hidden="true"></i>
                  </div>
                  <h3 class="no-statement-title">No statements available</h3>
                  <p class="no-statement-description">
                    There are currently no statements for this period.
                    Statements will appear here once they become available.
                  </p>
                </div>
              </div>
  `;
}

Adding CSS for Polished Look

.no-statement-modal-content {



  display: none; /* until testing is done */
  flex-direction: column;
  align-items: center;
  justify-content: center;
  gap: 0.5rem;
  padding: 0.5rem;
}

.no-statement-modal-content .no-statement-icon,
.no-form-1099k-icon {
  padding: 10px 16px;
  background-color: #f3f4f6;
  border-radius: 25px;
}

.no-statement-icon i,
.no-form-1099k-icon i {
  color: #9ca3af;
}

.no-statement-description,
.no-form-1099k-description {
  font-weight: 500;
  text-align: center;
  margin: 0;
}

Conclusion

By implementing these modal notifications, we've significantly improved our application's user experience. Instead of leaving users confused when data is missing, we now provide clear, helpful information about the status of their documents.
This approach can be applied to any situation where data might not be available yet, helping users understand what's happening and when they might expect to see their data. Remember, handling the "no data" scenario is just as important as handling the happy path!
What strategies do you use to handle missing data in your applications? Share your thoughts in the comments below.

Launching Head-To-Toes: My First E-commerce Landing Page

Datravous Odds — Sun, 16 Mar 2025 17:18:00 +0000

The Journey of Building a Modern Web Experience

As a developer, there's nothing quite like the moment you deploy your first full-featured web application. Today, I'm excited to share the launch of Head-To-Toes, an e-commerce landing page that represents countless hours of design, development, and passion.

Tech Stack Breakdown

Frontend: HTML5, CSS3, JavaScript
Libraries: Bootstrap, Font Awesome
Hosting: Firebase

Key Features

Responsive product grid
Authentic product curation
Sleek, modern design
Mobile-first approach

Challenges Overcome

Building this landing page wasn't just about writing code—it was about creating an intuitive shopping experience. From implementing responsive design to creating a smooth user interface, each line of code was a step towards a more engaging platform.

What's Next

This is just the beginning. Future iterations will include:

Enhanced product filtering
User authentication
Shopping cart functionality

Live Now

Check out the live site: https://h2t-landing-page.web.app

Excited to hear your feedback and continue growing as a developer!

Implementing loadPaymentMethods(): Loading Credit Card and Bank Account Information

Datravous Odds — Wed, 05 Mar 2025 17:37:46 +0000

This weekend, I finished implementing the loadPaymentMethods() function to load credit card and bank account information. Below, I'll walk you through the steps I used to solve problems and break down the solution.

Full Implementation

async function loadPaymentMethods(userData) {
  if (!userData) return null;
  try {
    // user profile reference
    const userProfileRef = doc(db, "userProfiles", userData.email);

    // references to bank and credit card documents
    const bankAccountsRef = collection(userProfileRef, "bankAccounts");
    const creditCardsRef = collection(userProfileRef, "creditCards");

    // fetch bank and credit card information at the same time
    const [bankAccountSnapshot, creditCardsSnapshot] = await Promise.all([
      getDocs(bankAccountsRef),
      getDocs(creditCardsRef)
    ]);

    // map bank information to an object
    const bankAccounts = bankAccountSnapshot.docs.map((doc) => ({
      id: doc.id,
      ...doc.data()
    }));

    // map credit card information to an object
    const creditCardAccounts = creditCardsSnapshot.docs.map((doc) => ({
      id: doc.id, // credit card id
      ...doc.data()
    }));

    // load credit card transactions
    const transactionPromises = creditCardAccounts.map(async (card) => {
      const cardId = card.id;
      // console.log("Card id:", cardId);
      const transactions = await loadCreditCardTransactions(userData, cardId);
      // console.log("transactions: ", transactions);
      return { cardId, transactions };
    });

    // load bank transactions
    const bankTransactionsPromise = bankAccounts.map(async (acc) => {
      const bankId = acc.id;
      // console.log("bank id: ", bankId);
      const transactions = await loadBankTransactions(userData, bankId);
      console.log("Bank Account transactions: ", transactions);
      return { bankId, transactions };
    });

    const allBankActivity = await Promise.all(bankTransactionsPromise);
    // console.log(allBankActivity);

    const allTransactions = await Promise.all(transactionPromises);
    // console.log(allTransactions);

    const activityElements = allBankActivity.flatMap((bankData) => {
      // Return the map array
      return bankData.transactions.map((act) => {
        const activityItem = document.createElement("div");
        activityItem.className = "activity-item";
        if (act.type === "Deposit") {
          activityItem.innerHTML = `
                   <div class="activity-item-wrapper">
                    <label class="details-label font-500">${act.type}</label>
                    <p class="detail-date">${formatFirebaseDate(act.date)}</p>
                    </div>
                    <div class="activity-item-wrapper">
                    <label class="detail-value font-500 deposit">
                       +$${act.amount} ${act.currency}
                      </label>
                      <p class="status-indicator ${getStatusClass(
                        act.status
                      )}" >${act.status}</p>
                    </div>`;
        } else {
          activityItem.className = "activity-item";
          activityItem.innerHTML = `
                  <div class="activity-item-wrapper">
                    <label class="details-label font-500">${act.type}</label>
                    <p class="detail-date">${formatFirebaseDate(act.date)}</p>

                  </div>
                  <div class="activity-item-wrapper">
                    <label class="detail-value font-500 withdraw">$${
                      act.amount
                    } ${act.currency}</label>
                    <p class="status-indicator ${getStatusClass(act.status)}">${
            act.status
          }</p>
                  </div>`;
        }
        return activityItem; // Return the element
      });
    });
    const recentActivity = document.querySelector("#recent-activity");
    recentActivity.innerHTML = "";
    // add all elements
    activityElements.forEach((element) => {
      recentActivity.appendChild(element);
    });

    // credit cards transactions
    const transactionElements = allTransactions.flatMap((cardData) =>
      cardData.transactions.map((tran) => {
        const transDiv = document.createElement("div");
        transDiv.className = "trans";
        transDiv.innerHTML = `
            <p>${tran.itemName}</p>
            <p>$${tran.amount}</p>
            `;
        return transDiv;
      })
    );
    const recentTransactions = document.querySelector("#r-trans");
    // clear existing content
    recentTransactions.innerHTML = "";
    // add all transaction elements
    transactionElements.forEach((element) => {
      recentTransactions.appendChild(element);
    });

    return { bankAccounts, creditCardAccounts };
  } catch (error) {
    console.error("Error happened when fetching payment information");
    throw error; // Propagate error to caller
  }
}

Breaking Down the Implementation

Mapping Bank and Credit Card Information:

Here's how we map the data to objects containing the ID and the best rest of the data from Firebase:

const bankAccounts = bankAccountSnapshot.docs.map((doc) => ({
  id: doc.id,
  ...doc.data()
}));
const creditCardAccounts = creditCardsSnapshot.docs.map((doc) => ({
  id: doc.id,
  ...doc.data()
}));

This helps in better formatting and using the data.

Loading Transactions

We create promises to load all transactions:

const transactionPromises = creditCardAccounts.map(async (card) => {
  const cardId = card.id;
  const transactions = await loadCreditCardTransactions(userData, cardId);
  return { cardId, transactions };
});
const bankTransactionsPromise = bankAccounts.map(async (acc) => {
  const bankId = acc.id;
  const transactions = await loadBankTransactions(userData, bankId);
  return { bankId, transactions };
});

We use async before the callback function because these are API calls. We wait for all transactions to be loaded and then map them to their respective accounts.

Handling Promises:

const allBankActivity = await Promise.all(bankTransactionsPromise);
const allTransactions = await Promise.all(transactionPromises);

We use Promise.all() to wait for all promises to resolve, retrieving transactions from both credit cards and bank accounts.

Creating Activity Elements:

const activityElements = allBankActivity.flatMap((bankData) => {
  return bankData.transactions.map((act) => {
    const activityItem = document.createElement("div");
    activityItem.className = "activity-item";
    activityItem.innerHTML = `
      <div class="activity-item-wrapper">
        <label class="details-label font-500">${act.type}</label>
        <p class="detail-date">${formatFirebaseDate(act.date)}</p>
      </div>
      <div class="activity-item-wrapper">
        <label class="detail-value font-500 ${act.type === "Deposit" ? "deposit" : "withdraw"}">
          ${act.type === "Deposit" ? "+" : ""}$${act.amount} ${act.currency}
        </label>
        <p class="status-indicator ${getStatusClass(act.status)}">${act.status}</p>
      </div>`;
    return activityItem;
  });
});

We create elements to display recent activity for both bank accounts and credit cards, handling different types of transactions (deposits vs. withdrawals) with appropriate styling.

Stay tuned for the next post where we'll discuss the view detail UI!

Implementing Firebase Payment Methods Loading

Datravous Odds — Fri, 21 Feb 2025 18:47:44 +0000

This weekend, I implemented the payment methods loading functionality for the payment information tab in my e-commerce website. The main task was to create an asynchronous function that loads payment method information, including bank accounts and credit card accounts, from Firebase.

The Implementation

The core of this implementation is the loadPaymentMethods function that retrieves payment information from Firebase. Here's a detailed breakdown of how it works:

async function loadPaymentMethods(userData) {
  if (!userData) return null;
  try {
    // user profile reference
    const userProfileRef = doc(db, "userProfiles", userData.email);

    // references to bank and credit card documents
    const bankAccountsRef = collection(userProfileRef, "bankAccounts");
    const creditCardsRef = collection(userProfileRef, "creditCards");

    // fetch bank and credit card information at the same time
    const [bankAccountSnapshot, creditCardsSnapshot] = await Promise.all([
      getDocs(bankAccountsRef),
      getDocs(creditCardsRef)
    ]);

    // map bank information to an object
    const bankAccounts = bankAccountSnapshot.docs.map((doc) => ({
      id: doc.id,
      ...doc.data()
    }));

    // map credit card information to an object
    const creditCardAccounts = creditCardsSnapshot.docs.map((doc) => ({
      id: doc.id,
      ...doc.data()
    }));

    return { bankAccounts, creditCardAccounts };
  } catch (error) {
    console.error("Error happened when fetching payment information");
    throw error;
  }
}

Key Components Explained

User Data Validation
The function starts with a simple but important check:

if (!userData) return null;

This ensures we have valid user data before proceeding. In a production environment, we could enhance this by returning a UI component to inform users when no data is available.

Firebase Document References

The function creates necessary references to access the Firebase documents:

User Profile Reference:

const userProfileRef = doc(db, "userProfiles", userData.email);

This creates a reference to the user's profile document using their email as the identifier.

Payment Method References:

const bankAccountsRef = collection(userProfileRef, "bankAccounts");
const creditCardsRef = collection(userProfileRef, "creditCards");

These references point to the subcollections containing bank and credit card information.

Parallel Data Fetching
One of the key optimizations is the use of Promise.all() to fetch both bank and credit card data simultaneously:

const [bankAccountSnapshot, creditCardsSnapshot] = await Promise.all([
  getDocs(bankAccountsRef),
  getDocs(creditCardsRef)
]);

This approach is more efficient than sequential fetching as both requests are processed in parallel.

Data Mapping
The retrieved snapshots are then mapped to more usable objects:

const bankAccounts = bankAccountSnapshot.docs.map((doc) => ({
  id: doc.id,
  ...doc.data()
}));

This transformation makes the data easier to work with in the rest of the application, combining the document ID with its data.

Error Handling

The entire operation is wrapped in a try-catch block to handle potential errors gracefully:

try {
  // ... implementation
} catch (error) {
  console.error("Error happened when fetching payment information");
  throw error;
}

Next Steps

In upcoming implementations, I'll be adding functionality to:

Handle credit card and bank account transactions
Update the UI to display payment method information
Implement error states and loading indicators

Stay tuned for the next post where I'll cover the transaction implementation details!

Building My Startup: Implementing User Payouts with Firebase

Datravous Odds — Sun, 09 Feb 2025 19:09:58 +0000

Overview

Today, I completed the implementation of user profile data loading, including profile pictures, stats, personal information, and shipping details. The next phase focused on updating the client-side payment tab and integrating it with Firebase to manage payout history. Here's how I tackled the challenge.

Firebase Structure

The existing database structure handled wallet balances and upcoming payouts but lacked functionality for viewing complete payout history. Users needed the ability to view and filter their payout history, including:

Payment status
Transaction amount
Order ID
Processing date

To address this, I created a subcollection within the userProfiles collection. This approach ensures users can access their payment methods, activity, reviews, and payout history through a single authenticated route.

Creating the Payouts Subcollection

To organize payout data, I:

Added a new subcollection named /payouts to the userProfiles collection.
Implemented Firebase's auto-generated unique IDs for each payout record.
Defined the following fields for each payout:

amount: Transaction value
date: Deposit date
orderId: Unique order identifier
processingDate: Transaction processing timestamp
status: Current state ("pending", "completed", "processing")
type: Payment method (credit card, debit card, online payment)

Firebase Rules Update

With the subcollection in place, I needed to update Firebase rules to grant users access to their payout data. Here's the updated rules configuration:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /userProfiles/{email} {
     allow read: if request.auth != null && request.auth.token.email == email;
     allow write: if request.auth != null && request.auth.token.email == email;


     match /{subcollection}/{document=**} {
            allow read, write: if request.auth != null && request.auth.token.email == email;

        }      
    }
  }
}

Key Points:

match /{subcollection}/{document=**}: Grants access to all documents within the subcollection.
allow read, write: Ensures only authenticated users can access their data.
Email Verification: Confirms the user's email matches the userProfiles document.

These rules ensure:

Users can only access their own data.
Subcollections (like payment information) are protected.
Unauthorized access attempts are blocked.

Loading Firebase Data To Client-side

After setting the rules correctly, now it was time to test, create the code to load the data from the backend to the frontend. I decide create async functon to call whenever the userData is loaded from the checkUserStatus(), once the data is loaded, then the function would run to have the data loaded, below is the code I implemented to do so.

async function loadProfileData() {
  try {
    const userData = await checkUserStatus();
    console.log("User Data imported:", userData);
    if (userData) {
      loadPaymentInfoData(userData);
    }
  } catch (error) {
    console.error("Error happened when loading userData from auth.js", error);
    throw error;
  }
}

Implementing loadPaymentInfoData

The loadPaymentInfoData function handles loading and displaying payout information. Here's the breakdown:

async function loadPaymentInfoData(userData, filter = "all") {
  if (userData) {
    const walletData = userData.wallet;
    // load wallet info
    document.querySelector(
      "#act-wallet-balance"
    ).textContent = `$${walletData.balance.toFixed(2)}`;
    // ... rest of wallet data loading ...  
 try {
  const payoutsRef = collection(
        db,
        "userProfiles",
        userData.email,
        "payouts"
      );
      let baseQuery = payoutsRef;

      if (["pending", "completed", "processing"].includes(filter)) {
        baseQuery = query(payoutsRef, where("status", "==", filter));
      }

      const querySnapShot = await getDocs(baseQuery);
      const payoutDocs = Array.from(querySnapshot.docs);

      let completedPayouts = 0;
      let processingPayouts = 0;
      let pendingPayouts = 0;
      let totalPayoutAmount = 0;

      // filters by today, this-week, or this-month
      if (["today", "this-week", "this-month"].includes(filter)) {
      }

      const payoutItems = document.querySelectorAll(".payouts-item");
      payoutDocs.forEach((doc) => {
        if (doc.data().status == "completed") {
          completedPayouts++;
        } else if (doc.data().status == "pending") {
          pendingPayouts++;
        } else if (doc.data().status == "processing") {
          processingPayouts++;
        }

        totalPayoutAmount += doc.data().amount;
      });



      payoutDocs.forEach((doc, index) => {
        const currentItem = payoutItems[index];
        const data = doc.data();

        console.log("current index", currentItem);
        currentItem.querySelector(".payout-id").textContent = data.payoutId;
        // ... rest of payout data fields ...


      document.querySelector(
        "#totalPayoutAmount"
      ).textContent = `$${totalPayoutAmount}`;
      // ... rest of pending, complete, and processing payouts ...
    } catch (error) {
      console.error("Error occured when fetching payouts:", error);
    }
  }
}

How It Works:

Fetching Data: The function queries the /payouts subcollection based on the user's email and optional filters.
Counting Payouts: It iterates through the payout documents to count completed, pending, and processing payouts.
Updating the DOM: The function populates the client-side elements with the fetched data.

Challenges and Next Steps

While the implementation works, there are still a few areas to improve:

Filtering by Date: Implementing filters for "today," "this-week," and "this-month."
Dynamic Payout Loading: Generating payout items dynamically instead of relying on static elements.
Error Handling: Enhancing error handling for a smoother user experience.
I'll cover these updates in my next post, so stay tuned!

Conclusion

Building the payout history feature was a challenging but rewarding experience. By leveraging Firebase's powerful tools and structuring the data effectively, I was able to create a seamless experience for users to track their transactions. As I continue to refine this feature, I'm excited to see how it enhances the overall user experience for my startup.

For Linux users

Datravous Odds — Tue, 04 Feb 2025 08:46:45 +0000

I Chose Ubuntu for 2025. What's Changed so far? 👀

Juliana Costa ・ Jan 23

#webdev #productivity #linux #ubuntu

Fetching and Loading User Profiles Using Firebase in My eCommerce Project 🔐🗃

Datravous Odds — Tue, 04 Feb 2025 05:01:42 +0000

This morning, I spent time refactoring and implementing a couple of key features in my eCommerce project. In this blog post, I’ll walk you through the process of fetching and loading user profiles from Firebase, including the challenges I faced and how I solved them. I’ll also share code snippets and explanations to help you understand the implementation.

Fetching User Profiles

After debugging some errors and adding error-checking logic to the handleTabs()function, I shifted my focus to fetching user data from Firebase for my eCommerce project. This project is designed to cater to sneaker and vintage sellers, offering essential features like trading, buying, listing, and selling. Additionally, it includes some unique services tailored to this niche market.

For the backend, I’m using Firebase, while the frontend is built with basic web technologies like HTML/CSS, JavaScript, Node.js, and Express.js. Firebase’s real-time database and authentication capabilities make it an excellent choice for managing user profiles and product data.

Firebase Structure Implementation

In my Firebase setup, I’ve structured the database to store three main types of data:

Products: Items listed by users.
User Profiles: Information about each user.
Users: Authentication and access control data.

Each user has specific rules governing access to their documents, which store individual user information. Think of these documents as files in a file cabinet—each file contains specific data, and only authorized users can access them.

I’ll provide resource links at the end of this post for those who want to learn more about Firebase documents and collections. For now, let’s focus on the problem-solving aspect of fetching and loading user information.

What Are Documents in Firebase?

In Firebase, documents are used to store user information and other project-related data. They are essentially key-value pairs (similar to JavaScript objects) that follow your application’s logic.

Here’s how it works:

You start by creating a collection, which is a group of related data.
Each collection has a unique ID and contains one or more documents.
Documents can store fields (key-value pairs) and can even have nested collections within them.

For example, in my project, the userProfiles collection contains documents for each user, with fields like email, username, and ratings.

Firebase also allows you to set rules to control access to collections and documents. For instance, you can restrict access so that only authenticated users can read or write their own data.

Fetching User Profile Information: Implementation

Since this implementation doesn’t involve modifying the client-side UI yet, my goal was to establish a connection to Firebase and retrieve the user data object.

I decided to place the code in the auth.js file because the user profile information should only be fetched after the user is authenticated. Here’s how I approached it:

Firebase Rules Setup:

I started by setting up Firebase rules to allow read and write access to the userProfiles collection. These rules ensure that only authenticated users can access their own data.

Here’s the rule I implemented:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /userProfiles/{email} {
     allow read: if request.auth != null && request.auth.token.email == email;

    }
  }
}

Let’s break this down:

match /userProfiles/{email}: This rule applies to the userProfiles collection, where each document is identified by the user’s email.
allow read: A user can only read their document if they are authenticated (request.auth != null) and their email matches the document’s email (request.auth.token.email == email).

Authentication Flow:

I chose to authenticate users via email verification. Once the user’s email is verified, they gain access to their profile data in the userProfiles collection. While some developers might use the document’s unique ID for this purpose, I opted for email-based authentication to save time, as I had already implemented it in an earlier stage of the project.

Code implementation

After setting up the rules for the database, I was ready to write the code to retrieve the user data object from Firebase. I started by importing the necessary modules: db, doc, getDoc, and onAuthStateChanged.

db: Provides access to the Firebase database.

doc: Allows interaction with documents in collections.

getDoc: Retrieves documents from the database.

onAuthStateChanged: Tracks the user’s authentication status, which is crucial because we can’t fetch user data without authentication.

Most of these modules are imported from the /.firebase-client.js file.

Here’s the code I wrote to fetch the user profile:

// Fetch user profile
const fetchUserProfile = async (user) => {
  try {
    const docRef = doc(db, "userProfiles", user.email);
    console.log("Fetching user profile for email:", user.email);
    const docSnap = await getDoc(docRef);

    // Fetching user profile
    if (docSnap.exists()) {
      const userData = {
        uid: user.uid,
        email: user.email,
        ...docSnap.data()
      };
      console.log("User profile found:", userData);
      return userData;
    } else {
      console.log("No profile document exists for user:", user.email);
      return null;
    }
  } catch (error) {
    console.error("Error fetching user profile:", error);
    throw error; // Throw error to be caught by caller
  }
};

Explanation of the Code

Asynchronous Function:
The fetchUserProfile function is asynchronous because it interacts with Firebase, which involves network requests.
Document Reference:
The docRef variable creates a reference to the document in the userProfiles collection using the user’s email as the identifier.
Fetching Data:
The getDoc function retrieves the document snapshot (docSnap). If the document exists, the user’s data is combined with their uid and email into a userData object.
Error Handling:
If an error occurs, it’s logged using console.error to distinguish it from regular logs. The error is also thrown to ensure it’s handled by the caller.

Testing and Results

After implementing the code, I tested it to ensure it worked as expected. Here’s a screenshot of the console output:

Summary

I really enjoyed working on this feature, as I learned a lot about structuring Firebase databases, capturing user information (such as passwords, auth tokens, and emails), and implementing authentication rules. It was challenging at first, but resources like The Net Ninja’s Firebase tutorial and the Firebase documentation were incredibly helpful.

If you’re working on a similar project, I hope this post provides some useful insights. Feel free to reach out if you have any questions or suggestions!

Firebase Auth vs Manual Auth: A Developer's Journey 🤔😣🤗

Datravous Odds — Mon, 27 Jan 2025 20:48:09 +0000

Recently, I've been working on an exciting e-commerce platform that combines features from StockX and eBay. As this is my first major project, I was particularly motivated to build everything from scratch. However, my journey with implementing user authentication taught me some valuable lessons about choosing between manual authentication and Firebase Auth.

The Manual Authentication Approach

Initially, I attempted to implement authentication manually while still planning to use Firebase for data storage. My original implementation looked something like this:

Create a signup process that would:

Collect user data from a form
Generate a JWT token
Store user data in Firebase

Implement a login process that would:

Verify user credentials against the database
Authenticate with the JWT token
Redirect to the home page upon success

Here's what the initial implementation looked like:

const submitFormData = async (path, data) => {
  // Store JWT token
  localStorage.setItem("token", responseData.data.token);

  console.log("Redirecting to home page");
  location.replace("/");
};

subBtn.addEventListener("click", () => {
  // Form validation
  if (!tac.checked) {
    showAlert("you must agree to our terms and conditions");
  } else {
    loader.style.display = "block";
    submitFormData("/signup", {
      name: name.value,
      email: email.value,
      password: password.value,
      number: number.value,
      tac: tac.checked,
      notification: notification.checked,
      seller: false
    });
  }
});

The Challenge

While this code worked initially, I hit a significant roadblock when trying to fetch user data from Firebase. The user object consistently returned null, indicating that the user wasn't found. After an hour of troubleshooting and research, I discovered that Firebase Auth offered a more streamlined solution.

The Firebase Auth Solution

Switching to Firebase Auth simplified the process considerably. Here's how the improved implementation works:

Signup Process

const auth = getAuth();

createUserWithEmailAndPassword(auth, email.value, password.value)
  .then((userCredential) => {
    const user = userCredential.user;
    loader.style.display = "block";
    return submitFormData("/signup", {
      name: name.value,
      email: email.value,
      password: password.value,
      number: number.value,
      tac: tac.checked,
      notification: notification.checked,
      seller: false
    });
  })
  .catch((error) => {
    showAlert(error.message);
  });

Login Process

signInWithEmailAndPassword(auth, email.value, password.value)
  .then((userCredential) => {
    const user = userCredential.user;
    loader.style.display = "block";
    return submitFormData("/login", {
      email: email.value,
      password: password.value
    });
  })
  .catch((error) => {
    showAlert(error.message);
  });

Key Components Explained

Authentication Setup: The getAuth() method initializes Firebase Authentication, handling the complex security mechanisms behind the scenes.

User Creation: createUserWithEmailAndPassword() manages the entire signup process, including:

Email validation
Password security
User creation in Firebase Auth
Automatic session management

User Sign-in: signInWithEmailAndPassword() provides:

Secure credential verification
Session management
Error handling for invalid credentials

Lessons Learned

While building authentication from scratch can be educational, Firebase Auth provides a robust, tested solution that handles many edge cases and security concerns automatically.
Firebase Auth integrates seamlessly with Firestore, making it easier to manage user data and authentication state in sync.
The built-in error handling and security features of Firebase Auth save significant development time and reduce potential security risks.

Remember, when building a production application, it's often better to use battle-tested authentication solutions like Firebase Auth rather than implementing everything from scratch. This allows you to focus on building your application's unique features while ensuring security best practices are followed.

First Project E-commerce

Datravous Odds — Thu, 01 Aug 2024 14:57:46 +0000

So this is my first project, I’ve been coding for about 4 years while in college and i decided not to wait for a job. Why don’t I just create my own, so that’s why I’m here. I’ve followed some tutorials and made some progress on the project as far creating the pages that’s needed. I think my overall goal is to create an all in one marketplace for shoes, apparel, and accessories. Also allow them to sell us or others the products, sort of like a stock-x but for used products as well not just new products. I’m using firebase for the authentication and user information holding because I feel it’s more simple, since it’s my first project. My expectation for v1 of this project is to allow users to sell to us, list their products, and buy from us. Their so many other features I want to add but I feel this is the best option right if I want to have it done before spring semester 2025