feat: integrate Request API with Easy Invoice #2
Conversation
aimensahnoun
force-pushed
the
1-request-api---integrate-request-api-into-easyinvoice
branch
from
098755c to
1256700
Compare
aimensahnoun
force-pushed
the
1-request-api---integrate-request-api-into-easyinvoice
branch
from
09855ca to
4417d1c
Compare
…request-api---integrate-request-api-into-easyinvoice
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
package.json (1)
27-28:⚠️ Potential issueUpdate @reown/appkit to a valid stable version.
The specified version
^1.6.8for both@reown/appkitand@reown/appkit-adapter-ethers5appears to be invalid. The latest stable version is 1.3.0.Apply this diff to update to the latest stable version:
- "@reown/appkit": "^1.6.8", - "@reown/appkit-adapter-ethers5": "^1.6.8", + "@reown/appkit": "^1.3.0", + "@reown/appkit-adapter-ethers5": "^1.3.0",
🧹 Nitpick comments (28)
src/components/invoice-creator.tsx (3)
19-35: Well-structured success callback with dynamic routing.
The conditional check fordata.invoicefollowed by toast and setTimeout-based navigation is functional. As a small improvement, consider providing a direct link to the newly created invoice instead of an enforced 3-second delay for enhanced user control.
46-47: Revised default values for currency.
Using"USD"forinvoiceCurrencyand an empty string forpaymentCurrencysynchronizes with your updated schema. If you expect consistent usage of a default payment currency, consider assigning a default here as well, to prevent potential empty string edge cases.
53-62: Enhanced error handling with try/catch.
Wrapping the mutation call in try/catch and displaying error details improves user feedback. Logging or sending error data to an error-tracking service could further aid debugging in production.src/server/db/schema.ts (2)
6-6: JSON column usage is valid.
Storing line items in a JSON column is flexible for variable data structures. Keep in mind indexing or performance concerns if queries on this field become more complex.
49-68: Added fields and references inrequestTable.
The broad set of text fields for amounts, IDs, and references is understandable. However, consider the following refinements:
- Use numeric or decimal types for financial fields (e.g.,
amount) to avoid parsing overhead and potential string conversion bugs.- Add uniqueness constraints or indexes for fields like
invoiceNumberorrequestIdif they must be unique or frequently queried.src/app/dashboard/page.tsx (2)
19-20: Dynamic data retrieval fromapi.invoice.getAll.query().
Fetching real invoice data aligns the dashboard with live backend data. Consider adding error handling or fallback UI if the request fails or returns an empty result.
77-83: RenderingInvoiceTablewith initial data.
Passinginvoices,totalPayments, andoutstandingInvoicesas props is a clear approach to unify and display invoice data. For large data sets, consider lazy loading or pagination.src/server/routers/invoice.ts (2)
10-58: Consider applying transactional logic when creating invoices.Within the
createmutation, if the external request is successful but the subsequent database insertion fails (or vice versa), partial inconsistencies may occur (e.g., an invoice is created externally but not reflected in the local DB). Consider using a transaction or compensating actions to handle failures atomically.
88-109: Guard against repeated payments or attempts on already-paid invoices.In the
payRequestmutation, there's no explicit check to ensure the status isn't already "paid." Malicious or accidental repeated payment attempts might lead to confusion or undesired behaviors. Consider adding a guard to verify that the invoice’s status is still "pending" before proceeding.// ... if (invoice.status === "paid") { + return { success: false, message: "Invoice already paid" }; } const response = await apiClient.get( `/v1/request/${invoice.paymentReference}/pay`, ); // ...src/components/invoice-form.tsx (2)
195-220: Provide a fallback or explanation if payment currency selection is needed for other invoice currencies.You currently show the payment currency selector only if
invoiceCurrencyis "USD." If future requirements allow a different payment currency for non-USD invoices, consider offering a similar selector.
239-245: Allow creating subsequent invoices without reloading the form.Disabling the submit button after a successful submission (because
isSubmitSuccessfulis true) may force users to refresh the page to create another invoice. Consider providing a “New Invoice” button or resetting the form after submission for better UX.src/components/invoice-table.tsx (1)
70-111: Ensure displayed currency matches data currency.The "Total Payments" field is prefixed with a
$sign, which implies USD, yet your app supports multiple currencies. Consider formatting this total consistently with the selected invoice/payment currency or providing an explicit currency label.src/components/payment-section.tsx (3)
23-28: Consider extracting state into a custom hook.The component maintains multiple pieces of local state (e.g.,
paymentStatus,paymentProgress,currentStep,isAppKitReady) which results in a fairly large and complex component. Extracting payment logic and state transitions into a custom hook (e.g.,usePaymentFlow) can reduce complexity, promote reusability, and improve testability.
114-115: Update invoice status in real-time.After setting
paymentStatusto"paid", consider refetching the invoice data from the server or performing other updates (e.g., invalidating TRPC queries) to keep the UI in sync with your backend’s record of paid invoices. This helps ensure the displayed invoice details and status are consistent across the application.
127-137: Provide a fallback or partial discount status for “processing” or “pending” states.If the user’s payment is still pending or processing, consider explaining that partial or final amounts may still be deducted. This ensures clarity regarding the financial and UI state while the user transaction is not fully settled.
src/lib/axios.ts (1)
3-8: Validate environment variable availability.If
REQUEST_API_URLorREQUEST_API_KEYare undefined, axios calls will fail or lack authentication. Consider adding a fallback or an explicit error if these environment variables are not set to avoid silent misconfigurations.drizzle.config.ts (1)
9-9: Allow configurable table filtering if possible.Changing
tablesFilterfrom["invoicepro_*"]to["easyinvoice_*"]is aligned with the new naming convention. If you anticipate future renaming or multi-project usage, consider making this property configurable via environment variables for improved maintainability.src/app/api/trpc/[trpc]/route.ts (1)
17-32: Fix the type error instead of using ts-expect-error.Replace the ts-expect-error comment with proper type assertions or fix the underlying type issue.
- // @ts-expect-error: This works , no need to fix - createContext: () => createContext(req), + createContext: async () => await createContext(req),src/app/api/webhook/payment/route.ts (1)
31-37: Enhance error handling with specific error types.The catch block should handle different types of errors (validation, database, etc.) separately for better error reporting.
- } catch (error) { + } catch (error) { + if (error instanceof Error) { + console.error("Payment webhook error:", error.message); + if (error.message.includes("No request found")) { + return NextResponse.json( + { error: "Payment reference not found" }, + { status: 404 } + ); + } + } console.error("Payment webhook error:", error); return NextResponse.json( { error: "Internal server error" }, { status: 500 } ); }src/lib/currencies.ts (1)
1-8: Add JSDoc documentation for better code clarity.The currency constants and types would benefit from documentation explaining their purpose and usage.
+/** + * List of supported invoice currencies. + * Includes both fiat (USD) and Sepolia testnet tokens. + */ export const INVOICE_CURRENCIES = [ 'USD', 'ETH-sepolia-sepolia', 'FAU-sepolia', 'fUSDC-sepolia', 'fUSDT-sepolia' ] as const; + +/** Type representing valid invoice currencies */ export type InvoiceCurrency = (typeof INVOICE_CURRENCIES)[number];src/components/invoice-preview.tsx (3)
17-23: Consider adding date validation.While the date formatting function works well, it might throw an error if an invalid date string is provided.
Consider adding validation:
const formatDate = (date: string) => { + if (!date || isNaN(new Date(date).getTime())) { + return "Invalid date"; + } return new Date(date).toLocaleDateString("en-GB", { year: "2-digit", month: "2-digit", day: "2-digit", }); };
93-111: Consider adding type safety for items array.The default item structure could benefit from type safety to ensure consistent data shape.
Consider defining an interface:
interface InvoiceItem { description: string; quantity: number; price: number; } const defaultItem: InvoiceItem = { description: "Description", quantity: 1, price: 0, };
141-149: Simplify currency display logic.The nested ternary and multiple fallbacks make the code harder to read.
Consider simplifying:
- {!data.paymentCurrency - ? "Choose payment currency" - : formatCurrencyLabel( - data.paymentCurrency || - data.invoiceCurrency || - "Select currency", - )} + {formatCurrencyLabel(data.paymentCurrency || data.invoiceCurrency) || "Choose payment currency"}src/app/invoices/[ID]/page.tsx (2)
31-37: Consider moving date formatting to a utility file and add error handling.The date formatting function could be:
- Moved to a separate utility file for reusability
- Enhanced with error handling for invalid dates
+// src/utils/date.ts +export const formatDate = (date: string) => { + try { + return new Date(date).toLocaleDateString("en-GB", { + year: "2-digit", + month: "2-digit", + day: "2-digit", + }); + } catch (error) { + console.error('Error formatting date:', error); + return 'Invalid date'; + } +};
160-175: Consider improving type safety for invoice items.While invalid items are prevented at creation, the type casting could be improved for better type safety.
-{(invoice.items as InvoiceItem[]).map((item, index) => ( +{(invoice.items as readonly InvoiceItem[]).map((item, index) => (.env.example (1)
6-9: Add documentation for new environment variables.Please add comments explaining:
- Required format for each variable
- Whether these variables are required or optional
- Example values where applicable
+# Request API configuration (required) +# Example: https://api.request.network/v1 REQUEST_API_URL="" +# API key from Request Network dashboard REQUEST_API_KEY="" +# Project ID from Reown dashboard NEXT_PUBLIC_REOWN_PROJECT_ID="" +# Secret for webhook validation (min 32 characters) WEBHOOK_SECRET=""package.json (1)
65-65: Remove unused dependency.The
dotenv-clipackage is added as a dev dependency but is no longer used in any scripts.Apply this diff to remove the unused dependency:
- "dotenv-cli": "^7.3.0",README.md (1)
39-44: Enhance environment variables documentation.Consider adding brief explanations for the purpose and format of each environment variable, especially:
REQUEST_API_KEY: How to obtain it and its purposeNEXT_PUBLIC_REOWN_PROJECT_ID: Where to get it and why it's needed🧰 Tools
🪛 LanguageTool
[uncategorized] ~39-~39: Loose punctuation mark.
Context: ...t variables in.env: -DATABASE_URL: Your PostgreSQL connection string - `GO...(UNLIKELY_OPENING_PUNCTUATION)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (28)
.env.example(1 hunks)LICENSE(1 hunks)README.md(1 hunks)dev/docker-compose.yml(1 hunks)drizzle.config.ts(1 hunks)package.json(3 hunks)src/app/api/trpc/[trpc]/route.ts(1 hunks)src/app/api/webhook/payment/route.ts(1 hunks)src/app/dashboard/page.tsx(3 hunks)src/app/invoices/[ID]/page.tsx(1 hunks)src/app/invoices/[requestID]/page.tsx(0 hunks)src/app/invoices/create/page.tsx(2 hunks)src/app/layout.tsx(1 hunks)src/app/page.tsx(3 hunks)src/components/app-kit.tsx(1 hunks)src/components/invoice-creator.tsx(2 hunks)src/components/invoice-form.tsx(3 hunks)src/components/invoice-preview.tsx(2 hunks)src/components/invoice-table.tsx(1 hunks)src/components/payment-section.tsx(1 hunks)src/components/ui/sonner.tsx(1 hunks)src/components/user-menu.tsx(1 hunks)src/lib/axios.ts(1 hunks)src/lib/currencies.ts(1 hunks)src/lib/schemas/invoice.ts(2 hunks)src/middleware.ts(1 hunks)src/server/db/schema.ts(3 hunks)src/server/routers/invoice.ts(1 hunks)
💤 Files with no reviewable changes (1)
- src/app/invoices/[requestID]/page.tsx
🧰 Additional context used
🧠 Learnings (1)
src/server/routers/invoice.ts (1)
Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
🪛 LanguageTool
README.md
[uncategorized] ~39-~39: Loose punctuation mark.
Context: ...t variables in .env: - DATABASE_URL: Your PostgreSQL connection string - `GO...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~95-~95: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ...ontributing Contributions are welcome! Please feel free to submit a Pull Request. ## 📝 License ...
(FEEL_FREE_TO_STYLE_ME)
🔇 Additional comments (46)
src/components/invoice-creator.tsx (4)
6-9: Use of type-only import is a best practice.
ImportingInvoiceFormValuesas a type is a clean approach that helps keep bundle size small and code organization clear.
12-12: Appropriate usage ofuseRouter.
Bringing inuseRouterfromnext/navigationaligns with Next.js 13 conventions. No issues here.
14-14: Toast import is valid.
Usingsonnerfor toast notifications is straightforward and fits well into the current architecture.
17-17: Router instance usage.
Initializingconst router = useRouter()is correct. Consider verifying that the environment is client-side before relying on router-based navigation in other contexts, but in this case, theuse clientdirective at the top ensures a client component.src/server/db/schema.ts (2)
3-3: Type-based import strategy is appropriate.
Includingtype InferSelectModelandrelationsfromdrizzle-ormclarifies usage in both schema definitions and relationships.
83-102: New table relations.
Mapping one-to-many relationships betweenuserTable,requestTable, andsessionTableis clearly defined. This approach keeps DB constraints explicit and consistent.src/app/dashboard/page.tsx (5)
1-2: New imports for invoice display and user menu.
Fetching theInvoiceTableandUserMenucomponents modularizes the dashboard logic, improving clarity.
4-6: Additional imports for data fetching, icons, and navigation.
Usingapifrom the tRPC server, importingPlusCircle, and leveragingredirectfrom Next.js are aligned with the framework’s best practices.Also applies to: 8-8
10-14: SEO-friendly metadata.
Including theMetadataexport improves the page’s SEO and helps clarify the page’s intent for visitors.
53-53: Use of "EI" branding.
Renaming from "IP" to "EI" aligns with the “EasyInvoice” brand. Consistent use of branding across components is advisable for a cohesive experience.
68-74: Navigational link for invoice creation.
Replacing a button with a Link styled as a button is a recommended pattern for Next.js to preserve client-side transitions.src/server/routers/invoice.ts (1)
81-87: Verify that makinggetByIdpublic matches your data-privacy expectations.Currently,
getByIdis apublicProcedure, which means anyone with a valid invoice ID can retrieve its data. If sharing invoices publicly is your intended design (similar to a public invoice link), this is fine. Otherwise, consider scoping access to authorized users.src/components/invoice-form.tsx (1)
165-174: Confirm that auto-syncing payment currency for non-USD invoices aligns with user expectations.When
invoiceCurrencyis not "USD," thepaymentCurrencyis automatically set to the same value. This may reduce flexibility if users want to define different invoice and payment currencies. If the current logic is intentional, please disregard this comment.src/components/invoice-table.tsx (2)
31-31: Refine the type of theitemsfield.Using
unknownbypasses type safety and can lead to runtime errors. If you have a known shape for invoice items, replaceunknownwith a dedicated interface or type.- items: unknown; + items: InvoiceItem[];
153-185: Check time-zone sensitivity in overdue logic.Currently, isOverdue is computed by checking whether
statusis"pending"anddueDateis in the past. Time zone differences might cause unexpected overdue statuses if users in different locales access the system. If you need robust date-handling, consider storing times/offsets or using a standardized approach (e.g., UTC) for consistent behavior.src/components/app-kit.tsx (3)
14-24: Add validation for required environment variables.The project ID is cast as string without validation, which could cause runtime errors if the environment variable is missing.
26-28: LGTM!The component is correctly implemented as a client-side wrapper component with proper TypeScript types.
7-12: Verify the icon path accessibility.The icon path
./assets/logo.svgis relative and might not be accessible. Ensure that the icon is available at the correct path relative to the application's root.❌ Verification inconclusive
🏁 Script executed:
#!/bin/bash # Description: Check if the logo file exists at the specified path. fd -t f "logo.svg" -x echo "Found logo at: {}"Length of output: 46
Icon Accessibility Check
The initial FD command did not return any results for “logo.svg”. This outcome suggests that the file might not be present at the expected location relative to the application’s root. To gather more evidence, let’s run an alternative file search using the standardfindcommand.Please execute this script and share the output. If no matching file is found, manually verify whether the icon file exists in your repository and update the metadata icon path accordingly.
🏁 Script executed:
#!/bin/bash # Search the repository for any file named "logo.svg" (case-insensitive) find . -type f | grep -i "logo.svg"Length of output: 35
Icon file missing from the repository
The search using both
fdandfindreturned no results for "logo.svg", indicating that the file is not present at the expected location. Please verify whether the icon file exists, or update the metadata to point to the correct file path if it has been moved or renamed.src/components/ui/sonner.tsx (2)
31-31: LGTM!The component is correctly exported.
8-29: Verify the CSS classes are defined.The component uses several CSS classes for styling the toast notifications. Please ensure that these classes are defined in your CSS files:
toastergrouptoastbg-backgroundtext-foregroundborder-bordershadow-lgtext-muted-foregroundbg-primarytext-primary-foregroundbg-mutedtext-muted-foreground❌ Verification inconclusive
🏁 Script executed:
#!/bin/bash # Description: Search for CSS class definitions in the codebase. rg -t css -t scss "(\.|@apply).*?(\btoaster\b|\bgroup\b|\btoast\b|\bbg-background\b|\btext-foreground\b|\bborder-border\b|\bshadow-lg\b|\btext-muted-foreground\b|\bbg-primary\b|\btext-primary-foreground\b|\bbg-muted\b)"Length of output: 250
🏁 Script executed:
#!/bin/bash echo "Searching CSS files for class definitions:" rg -g "*.css" -e "(\.|@apply).*?\b(toaster|group|toast|bg-background|text-foreground|border-border|shadow-lg|text-muted-foreground|bg-primary|text-primary-foreground|bg-muted)\b" . echo "Searching SCSS files for class definitions:" rg -g "*.scss" -e "(\.|@apply).*?\b(toaster|group|toast|bg-background|text-foreground|border-border|shadow-lg|text-muted-foreground|bg-primary|text-primary-foreground|bg-muted)\b" .Length of output: 670
CSS Classes Definition Verification
After searching for class definitions in CSS, we found that some classes (e.g.,
border-border,bg-background, andtext-foreground) are defined in the global CSS file via@applyinsrc/app/globals.css. The remaining classes used in the component—such astoaster,group,toast,shadow-lg,text-muted-foreground,bg-primary,text-primary-foreground, andbg-muted—are standard Tailwind CSS utilities (e.g.,groupandshadow-lg) or likely defined via your Tailwind configuration or additional CSS layers.Please verify that these additional classes (if they are custom tokens rather than default Tailwind utilities) are either defined in your Tailwind configuration (or in other CSS files) or intentionally rely on Tailwind's built-in classes.
src/lib/schemas/invoice.ts (2)
4-24: LGTM!The invoice form schema is well-structured with comprehensive validation rules for all fields:
- Required fields have appropriate error messages
- Email format is validated
- Numeric fields have appropriate minimum values
- Array fields require at least one item
- Currency fields use predefined values or minimum length validation
- Optional fields are correctly marked
26-26: LGTM!The type is correctly inferred from the schema using zod's type inference.
src/app/api/trpc/[trpc]/route.ts (3)
1-5: LGTM!The imports are correctly implemented with type-only import for NextRequest.
11-15: LGTM!The context creation is correctly implemented using request headers.
34-34: LGTM!The handler is correctly exported for both GET and POST methods.
src/app/layout.tsx (2)
20-23: Update metadata with actual application information.The metadata still contains default Next.js values.
export const metadata: Metadata = { - title: "Create Next App", - description: "Generated by create next app", + title: "Easy Invoice - Simple and Secure Invoice Payment Platform", + description: "Easy Invoice is a simple and secure invoice payment platform powered by Request Network.", };
30-42: LGTM! Well-structured layout with proper component hierarchy.The integration of AppKit and Toaster components is well-implemented, providing a solid foundation for wallet connection and user notifications.
src/app/api/webhook/payment/route.ts (2)
12-15: Validate webhook secret environment variable.The webhook secret is crucial for security but lacks validation.
+ const webhookSecret = process.env.WEBHOOK_SECRET; + if (!webhookSecret) { + console.error("WEBHOOK_SECRET is not configured"); + return NextResponse.json( + { error: "Server configuration error" }, + { status: 500 } + ); + } const expectedSignature = crypto - .createHmac("sha256", process.env.WEBHOOK_SECRET as string) + .createHmac("sha256", webhookSecret) .update(JSON.stringify(body)) .digest("hex");
21-29: Add transaction safety for database update.The database update should be wrapped in a transaction to ensure atomicity.
const { paymentReference } = body; + await db.transaction(async (tx) => { + const result = await tx + .update(requestTable) + .set({ + status: "paid", + updatedAt: new Date(), + }) + .where(eq(requestTable.paymentReference, paymentReference)) + .returning({ id: requestTable.id }); + + if (!result.length) { + throw new Error(`No request found with payment reference: ${paymentReference}`); + } + }); - await db - .update(requestTable) - .set({ - status: "paid", - }) - .where(eq(requestTable.paymentReference, paymentReference));src/lib/currencies.ts (2)
10-22: LGTM! Well-structured currency mapping with type safety.The payment currencies mapping is well-implemented with proper type constraints and const assertions.
24-39: LGTM! Clear and maintainable currency formatting.The currency formatting function is well-structured with comprehensive coverage of all currency types.
src/middleware.ts (1)
23-26: LGTM! Webhook bypass implementation is appropriate.The broad path matching for webhook endpoints is intentional as confirmed in the learnings, and the implementation is correct.
src/components/user-menu.tsx (1)
12-12: LGTM! Type-only import improves bundle optimization.The change to a type-only import is a good practice as it helps with tree-shaking and potentially reduces bundle size.
src/app/invoices/create/page.tsx (2)
8-11: LGTM! Added SEO metadata.The metadata addition improves SEO by providing clear title and description for the create invoice page.
47-47: LGTM! Updated branding.The logo text update from "IP" to "EI" aligns with the rebranding to "EasyInvoice".
src/app/page.tsx (3)
7-10: LGTM! Added SEO metadata.The metadata addition improves SEO by providing clear title and description for the landing page.
45-45: LGTM! Updated branding.The logo text update from "IP" to "EI" aligns with the rebranding to "EasyInvoice".
86-93: LGTM! Updated footer layout and year.The footer updates improve layout with centered content and display the current year.
src/components/invoice-preview.tsx (1)
29-50: LGTM! Improved header section layout.The grid-based layout with clear labels and consistent spacing improves readability. Default values prevent UI breaking with missing data.
src/app/invoices/[ID]/page.tsx (3)
1-18: LGTM! Well-structured imports and type definitions.The imports are appropriate for the functionality, metadata is well-defined for SEO, and the InvoiceItem type is properly structured.
20-29: LGTM! Proper error handling and API integration.The component properly handles the case of non-existent invoices and makes good use of TypeScript types.
104-104: Use invoice creation date instead of current date.The issue date is using the current date instead of the invoice's creation date.
dev/docker-compose.yml (1)
6-6: LGTM! Good practice using specific version and Alpine variant.Using
postgres:16-alpineinstead oflatestprovides better version control and reduces image size.LICENSE (1)
1-21: LGTM! Proper MIT License implementation.The MIT License is appropriately implemented with current year and correct copyright holder.
README.md (2)
1-10: LGTM!The introduction and features section is well-written, providing a clear overview of the application and its key features.
74-100: LGTM!The tech stack and documentation sections are comprehensive and well-organized, providing valuable information for users and contributors.
🧰 Tools
🪛 LanguageTool
[style] ~95-~95: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ...ontributing Contributions are welcome! Please feel free to submit a Pull Request. ## 📝 License ...(FEEL_FREE_TO_STYLE_ME)
Check was required when we were forwarding to the invoice page, which is not the case anymore
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (11)
src/components/invoice-table.tsx (3)
13-13: Avoid naming collisions with the built-in Request typeBecause the type
Requestis also used by Next.js and the DOM, consider renaming this model (e.g.,PaymentRequestorDbRequest) to avoid confusion or overshadowing built-in objects.- import type { Request } from "@/server/db/schema"; + import type { PaymentRequest as BaseRequest } from "@/server/db/schema";
35-40: Add loading and error state handlingCurrently, there's no user feedback for loading or error states. Consider including them for a better user experience.
- const { data: invoices } = api.invoice.getAll.useQuery(undefined, { + const { data: invoices, isLoading, isError } = api.invoice.getAll.useQuery(undefined, { initialData: initialInvoices, refetchOnWindowFocus: true, refetchOnMount: true, refetchOnReconnect: true, }); + if (isLoading) { + return <div>Loading invoices...</div>; + } + if (isError) { + return <div>Failed to load invoices. Please try again later.</div>; + }
42-48: Consider server-side pagination for scalabilityPaginating on the client might become slower for large datasets since all invoices are fetched at once. Moving pagination logic to the server can improve performance and scalability.
src/app/api/webhook/payment/route.ts (3)
7-25: Add null check for the incoming signatureAlthough an empty or null signature will fail the comparison, explicitly returning a 400 error if the signature header is missing can improve clarity.
const signature = req.headers.get("x-request-network-signature"); + if (!signature) { + return NextResponse.json( + { error: "Missing signature" }, + { status: 400 } + ); + }
27-43: Validate presence of paymentReferenceIf
body.paymentReferenceis missing or empty, the transaction will not properly identify the invoice. Adding a check can prevent unexpected issues.const { paymentReference } = body; + if (!paymentReference) { + return NextResponse.json( + { error: "Missing paymentReference" }, + { status: 400 } + ); + }
45-53: Enhance error loggingUsing
console.erroris a good start, but you could adopt a full-featured logging library (e.g., winston, pino) for better log management and structured output.src/server/db/schema.ts (1)
49-69: Use domain-appropriate column types and reduce reliance on text fieldsStoring dates and amounts as text may hamper queries and cause parsing issues. Consider using timestamp columns (e.g.,
timestamp()ordate()) for dates and numeric columns for money amounts to enforce data integrity.src/server/routers/invoice.ts (2)
57-60: Enhance error handling with specific error messages.The current error handling only logs the error and returns a generic failure response. Consider providing more specific error messages to help with debugging and user feedback.
} catch (error) { console.log("Error: ", error); - return { success: false }; + return { + success: false, + error: error instanceof Error ? error.message : "An unexpected error occurred", + }; }
62-83: Consider pagination for better performance.The current implementation fetches all invoices at once, which could impact performance with large datasets. Consider implementing pagination.
- getAll: protectedProcedure.query(async ({ ctx }) => { + getAll: protectedProcedure + .input( + z.object({ + page: z.number().min(1).default(1), + limit: z.number().min(1).max(100).default(10), + }) + ) + .query(async ({ ctx, input }) => { const { db } = ctx; + const offset = (input.page - 1) * input.limit; const invoices = await db.query.requestTable.findMany({ where: eq(requestTable.userId, ctx.user?.id as string), orderBy: desc(requestTable.createdAt), + limit: input.limit, + offset, });src/app/invoices/[ID]/page.tsx (2)
25-29: Add error boundary for better error handling.Consider wrapping the component with an error boundary to gracefully handle runtime errors.
+ import { ErrorBoundary } from '@/components/error-boundary'; export default async function PaymentPage({ params, }: { params: { ID: string }; }) { const invoice = await api.invoice.getById.query(params.ID); if (!invoice) { notFound(); } + return ( + <ErrorBoundary fallback={<div>Something went wrong</div>}> {/* existing component JSX */} + </ErrorBoundary> + ); }
186-188: Use a consistent approach for number formatting.Consider using a dedicated currency formatting utility for consistent number formatting across the application.
- <span className="text-sm"> - {Number(invoice.amount).toFixed(2)} - </span> + <span className="text-sm"> + {formatCurrencyAmount(invoice.amount, invoice.invoiceCurrency)} + </span>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
src/app/api/webhook/payment/route.ts(1 hunks)src/app/invoices/[ID]/page.tsx(1 hunks)src/app/layout.tsx(3 hunks)src/components/app-kit.tsx(1 hunks)src/components/invoice-table.tsx(1 hunks)src/components/payment-section.tsx(1 hunks)src/server/db/schema.ts(3 hunks)src/server/routers/invoice.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- src/components/payment-section.tsx
- src/components/app-kit.tsx
🧰 Additional context used
🧠 Learnings (2)
src/app/invoices/[ID]/page.tsx (1)
Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#2
File: src/app/invoices/[ID]/page.tsx:160-175
Timestamp: 2025-02-12T12:42:40.076Z
Learning: Invoice items are validated at creation time through the schema validation in src/lib/schemas/invoice.ts, ensuring that items array is non-empty and each item has required description, quantity, and price fields. Runtime validation in display components is not necessary.
src/server/routers/invoice.ts (1)
Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
🔇 Additional comments (8)
src/app/layout.tsx (3)
4-5: LGTM! Imports are well-organized and necessary.The new imports support the PR objectives by adding wallet connection capabilities (AppKit) and toast notifications (Toaster).
Also applies to: 7-7
20-23: Update metadata with more descriptive information.The metadata could be more descriptive to better reflect the application's features and integration with Request Network.
Apply this diff to enhance the metadata:
export const metadata: Metadata = { - title: "Easy Invoice", - description: "Easy Invoice is a simple and secure invoice payment platform.", + title: "Easy Invoice - Simple and Secure Invoice Payment Platform", + description: "Easy Invoice is a simple and secure invoice payment platform powered by Request Network.", };
35-40: Verify AppKit configuration for Sepolia network.The layout structure looks good with proper component hierarchy. However, let's verify that AppKit is configured correctly for the Sepolia network as mentioned in the PR objectives.
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Description: Check AppKit configuration in the component file # Search for Sepolia network configuration in AppKit component rg -A 5 'Sepolia|chainId|networkId' src/components/app-kit.tsxLength of output: 64
Let's get more context on the AppKit configuration. The previous search for keywords (“Sepolia”, “chainId”, “networkId”) in
src/components/app-kit.tsxreturned no matches. This might mean that the network configuration is injected indirectly or defined elsewhere.To be sure, please run a script to output the initial section of
src/components/app-kit.tsxso we can inspect its configuration details. We can then determine if any Sepolia-specific setup exists or if additional manual verification is needed.Please provide the output from this script for further analysis.
🏁 Script executed:
#!/bin/bash # Dump the first 200 lines of the AppKit component to inspect its configuration details. head -n 200 src/components/app-kit.tsxLength of output: 852
AppKit configuration correctly includes Sepolia network settings.
The AppKit component’s initialization via the
createAppKitfunction clearly setsnetworks: [sepolia], confirming that the Sepolia network configuration is in place. This meets the intended configuration requirements.src/components/invoice-table.tsx (1)
144-145: Verify that invoice amounts are always numericThe code assumes
invoice.amountis numeric, but it's stored as text in the DB. Ensure strict validation or consider using a numeric type.✅ Verification successful
🏁 Script executed:
#!/bin/bash # Searching the codebase for references to 'amount' rg -A 2 $'amount:'Length of output: 667
Invoice amounts are derived from numeric values and are safely converted at display time.
- The DB schema defines
amountas text (seesrc/server/db/schema.ts), but insrc/server/routers/invoice.tsthe value is generated from a numerictotalAmountand explicitly converted to a string using.toString().- Because of this controlled conversion, the front-end’s conversion using
Number(invoice.amount)will function correctly, as the underlying value is always numeric in nature.- While storing the value as text can be acceptable, you might consider using a numeric type or adding additional validation to enforce strict typing at the database level.
src/server/db/schema.ts (1)
84-104: Relationships look consistentThese newly defined relationships provide clarity and cohesion between the tables, enabling straightforward joins and references.
src/server/routers/invoice.ts (1)
84-90: LGTM!The implementation is clean and straightforward.
src/app/invoices/[ID]/page.tsx (2)
9-12: LGTM!The metadata is well-defined with appropriate title and description.
160-175: LGTM!The invoice items rendering is correct. As per the learnings, the items are validated at creation time through the schema validation, so no additional runtime validation is needed here.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/components/invoice-creator.tsx (2)
17-28: Consider improving the navigation pattern.While the success notification and automatic navigation are good additions, a fixed 3-second delay might not be optimal for user experience. Consider these alternatives:
- Add a manual "Go to Dashboard" button in the success toast
- Use a loading state transition instead of a fixed delay
Example implementation with a button:
const { mutate: createInvoice, isLoading } = api.invoice.create.useMutation({ onSuccess: () => { toast.success("Invoice created successfully", { - description: "Redirecting to dashboard in 3 seconds", + description: "Your invoice has been created", + action: { + label: "Go to Dashboard", + onClick: () => router.push("/dashboard") + }, }); - setTimeout(() => { - router.push("/dashboard"); - }, 3000); }, });
45-56: Consider enhancing error handling with specific error types.While the current error handling is good, it could be more specific to help users understand and resolve issues better.
Example implementation with specific error types:
const onSubmit = async (data: InvoiceFormValues) => { try { await createInvoice(data); } catch (error) { + if (error instanceof TRPCClientError) { + toast.error("Validation Error", { + description: error.message, + }); + return; + } + if (error instanceof NetworkError) { + toast.error("Network Error", { + description: "Please check your connection and try again", + }); + return; + } toast.error("Failed to create invoice", { description: - error instanceof Error - ? error.message - : "An unexpected error occurred", + "An unexpected error occurred. Please try again later.", }); } };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/components/invoice-creator.tsx(2 hunks)
🔇 Additional comments (2)
src/components/invoice-creator.tsx (2)
6-14: LGTM! Import changes improve type safety and functionality.The changes properly separate type imports and add necessary dependencies for navigation and toast notifications.
32-43: Verify currency handling across the application.The form configuration has been updated to support multiple currencies with
invoiceCurrencydefaulting to "USD" andpaymentCurrencyas required. Please ensure:
- These changes align with the supported currencies in the Request API
- The currency conversion logic handles these fields correctly
✅ Verification successful
🏁 Script executed:
#!/bin/bash # Search for currency-related configurations and validations rg -A 5 "Currency|currency" --type typescriptLength of output: 82
I'll re-run the search using file globbing for TypeScript files instead of the unrecognized file type. Let's run a new script to search for occurrences of the currency fields and logic in the codebase:
🏁 Script executed:
#!/bin/bash # Searching for explicit usage of the new currency form fields in TypeScript files echo "Searching for 'invoiceCurrency' and 'paymentCurrency' references:" rg -A 5 "(invoiceCurrency|paymentCurrency)" -g "*.ts" -g "*.tsx" echo "Searching for general currency occurrences:" rg -A 5 "currency" -g "*.ts" -g "*.tsx"Length of output: 15144
Currency Handling Consistency Verified
The changes are consistently applied across the application. Specifically:
- The invoice form in
src/components/invoice-form.tsxupdates the currency fields correctly, auto-settingpaymentCurrencywhen the selected invoice currency is not "USD" and providing a selector when it is "USD".- The invoice schema (
src/lib/schemas/invoice.ts) validates bothinvoiceCurrencyandpaymentCurrencyas required, aligning with the API requirements.- Currency display and conversion logic using
formatCurrencyLabeland the handling insrc/components/invoice-preview.tsx,src/components/invoice-table.tsx, andsrc/components/payment-section.tsxconfirm that the updated fields flow through the presentation and transaction processes correctly.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
src/server/routers/invoice.ts (4)
17-20: Consider using a more precise number type for financial calculations.Using floating-point arithmetic for financial calculations can lead to precision issues.
Consider using a decimal type library like
decimal.js:-const totalAmount = input.items.reduce( - (acc, item) => acc + item.price * item.quantity, - 0, -); +import { Decimal } from 'decimal.js'; +const totalAmount = input.items.reduce( + (acc, item) => acc.plus(new Decimal(item.price).times(item.quantity)), + new Decimal(0) +).toString();
57-60: Enhance error handling with specific error types.The current error handling logs the error but returns a generic failure response.
Consider categorizing errors for better client-side handling:
} catch (error) { console.log("Error: ", error); - return { success: false }; + if (error instanceof ApiError) { + return { success: false, error: 'API_ERROR', message: error.message }; + } else if (error instanceof DatabaseError) { + return { success: false, error: 'DB_ERROR', message: 'Database operation failed' }; + } + return { success: false, error: 'UNKNOWN_ERROR', message: 'An unexpected error occurred' }; }
69-72: Use decimal arithmetic for payment totals.Similar to the create method, using floating-point arithmetic for financial calculations can lead to precision issues.
-const totalPayments = invoices.reduce( - (acc, invoice) => acc + Number(invoice.amount), - 0, -); +import { Decimal } from 'decimal.js'; +const totalPayments = invoices.reduce( + (acc, invoice) => acc.plus(new Decimal(invoice.amount)), + new Decimal(0) +).toString();
64-67: Consider implementing pagination for better performance.Fetching all invoices without pagination could lead to performance issues as the number of invoices grows.
-const invoices = await db.query.requestTable.findMany({ +const invoices = await db.query.requestTable.findMany({ + take: input.limit ?? 10, + skip: input.offset ?? 0, where: eq(requestTable.userId, ctx.user?.id as string), orderBy: desc(requestTable.createdAt), });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/server/routers/invoice.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
src/server/routers/invoice.ts (1)
Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
🔇 Additional comments (2)
src/server/routers/invoice.ts (2)
1-9: LGTM! Well-organized imports and router setup.All imports are properly utilized, and the router setup appropriately uses both protected and public procedures based on the requirements.
91-115: LGTM! Well-implemented payment request handler.The implementation correctly handles the retrieval of payment transactions calldata with appropriate error handling. The public access is intentional for invoice sharing capabilities.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/server/routers/invoice.ts (1)
63-84: Add pagination and safer number parsing to getAll procedure.The current implementation loads all invoices at once and uses unsafe number parsing.
Consider these improvements:
-getAll: protectedProcedure.query(async ({ ctx }) => { +getAll: protectedProcedure + .input( + z.object({ + limit: z.number().min(1).max(100).default(10), + offset: z.number().min(0).default(0), + }) + ) + .query(async ({ ctx, input }) => { const { db } = ctx; const invoices = await db.query.requestTable.findMany({ where: eq(requestTable.userId, ctx.user?.id as string), orderBy: desc(requestTable.createdAt), + limit: input.limit, + offset: input.offset, }); const totalPayments = invoices.reduce( - (acc, invoice) => acc + Number(invoice.amount), + (acc, invoice) => { + const amount = parseFloat(invoice.amount); + return acc + (Number.isFinite(amount) ? amount : 0); + }, 0, ); const outstandingInvoices = invoices.filter( (invoice) => invoice.status !== "paid", ); return { invoices, totalPayments, outstandingInvoices: outstandingInvoices.length, + hasMore: invoices.length === input.limit, }; }),
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/server/routers/invoice.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
src/server/routers/invoice.ts (1)
Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#2
File: src/server/routers/invoice.ts:88-109
Timestamp: 2025-02-12T12:40:14.742Z
Learning: The payRequest endpoint in src/server/routers/invoice.ts is intentionally kept public (using publicProcedure) to allow invoice sharing and payment by anyone with the payment reference, similar to how payment links work in other payment systems.
🔇 Additional comments (3)
src/server/routers/invoice.ts (3)
1-10: LGTM! Well-organized imports and router setup.The imports are properly organized and include all necessary dependencies for tRPC, database operations, and validation.
85-99: LGTM! Well-implemented getById procedure.The implementation includes proper error handling and follows the project's requirements for public invoice access.
100-124: LGTM! Well-designed payRequest procedure.The implementation correctly:
- Keeps the endpoint public to allow invoice sharing (as intended)
- Returns payment transactions calldata instead of processing payment
- Includes proper error handling
MantisClone
left a comment
MantisClone
left a comment
There was a problem hiding this comment.
Approved 👍 pending comment resolution 🚧
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (10)
src/app/invoices/[ID]/page.tsx (3)
14-18: Consider making the type properties readonly.Since these properties are only used for display and shouldn't be modified, consider making them readonly for better type safety.
type InvoiceItem = { - description: string; - quantity: number; - price: number; + readonly description: string; + readonly quantity: number; + readonly price: number; };
31-37: Move formatDate to utils for reusability.The date formatting function could be reused across components. Consider moving it to a utils file.
Create a new file
src/lib/utils/date.ts:export const formatDate = (date: string) => { return new Date(date).toLocaleDateString(undefined, { year: "2-digit", month: "2-digit", day: "2-digit", }); };
179-203: Simplify amount calculations.The subtotal and total sections show the same amount without any additional calculations. Consider combining them or clarifying why they're separate.
- <div className="flex justify-between py-2"> - <span className="text-sm text-neutral-600"> - Subtotal - </span> - <span className="text-sm"> - {Number(invoice.amount).toFixed(2)} - </span> - </div> <div className="flex justify-between py-2 border-t border-neutral-200"> <span className="text-sm font-medium">Total</span> <div>README.md (5)
5-11: Consider adding Request Network-specific features.Given that this PR focuses on Request API integration, consider adding features that highlight specific Request Network capabilities, such as:
- Multi-currency support
- Payment status tracking through Request Network
- Secure payment processing
14-21: Enhance prerequisites with version requirements and resource links.Consider adding:
- PostgreSQL version requirement
- Links to obtain Request Network API key and Reown Project ID
- Link to Google Cloud Console for OAuth credentials setup
37-44: Improve environment variables documentation.
- Fix the formatting of the list by adding proper line breaks.
- Add descriptions for:
REQUEST_API_URL: What's the default value?NEXT_PUBLIC_REOWN_PROJECT_ID: What is Reown and why is it needed?🧰 Tools
🪛 LanguageTool
[uncategorized] ~39-~39: Loose punctuation mark.
Context: ...t variables in.env: -DATABASE_URL: Your PostgreSQL connection string - `GO...(UNLIKELY_OPENING_PUNCTUATION)
82-100: Consider adding more Request Network resources.Given the focus on Request Network integration, consider adding links to:
- Request Network API reference
- Request Network integration guides
- Request Network payment flow documentation
101-108: Enhance contributing guidelines.Consider adding:
- Code of conduct reference
- Step-by-step contribution process
- Development workflow
- Testing requirements
Also, consider rewording "feel free to" to make it more professional, e.g., "We welcome contributions! Please submit a Pull Request."🧰 Tools
🪛 LanguageTool
[style] ~103-~103: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ...ontributing Contributions are welcome! Please feel free to submit a Pull Request. ## 📝 License ...(FEEL_FREE_TO_STYLE_ME)
drizzle/0000_chunky_albert_cleary.sql (1)
14-14: Add status field validation.The
statusfield should be constrained to valid values using an enum or check constraint to prevent invalid states.+ CONSTRAINT "easyinvoice_request_status_check" CHECK (status IN ('draft', 'pending', 'paid', 'cancelled')),package.json (1)
10-14: Consider organizing scripts by category.The scripts could be better organized by grouping them into categories (e.g., development, database, linting).
Consider this organization:
- "lint": "biome lint --write", - "db:push": "drizzle-kit push", - "db:studio": "drizzle-kit studio", - "db:generate": "drizzle-kit generate", - "db:migrate": "drizzle-kit migrate", + // Database scripts + "db:push": "drizzle-kit push", + "db:studio": "drizzle-kit studio", + "db:generate": "drizzle-kit generate", + "db:migrate": "drizzle-kit migrate", + // Linting and formatting + "lint": "biome lint --write",
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
README.md(1 hunks)drizzle/0000_chunky_albert_cleary.sql(1 hunks)drizzle/meta/0000_snapshot.json(1 hunks)drizzle/meta/_journal.json(1 hunks)package.json(3 hunks)src/app/invoices/[ID]/page.tsx(1 hunks)src/lib/currencies.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- drizzle/meta/_journal.json
🚧 Files skipped from review as they are similar to previous changes (1)
- src/lib/currencies.ts
🧰 Additional context used
🧠 Learnings (1)
src/app/invoices/[ID]/page.tsx (1)
Learnt from: aimensahnoun
PR: RequestNetwork/easy-invoice#2
File: src/app/invoices/[ID]/page.tsx:160-175
Timestamp: 2025-02-12T12:42:40.076Z
Learning: Invoice items are validated at creation time through the schema validation in src/lib/schemas/invoice.ts, ensuring that items array is non-empty and each item has required description, quantity, and price fields. Runtime validation in display components is not necessary.
🪛 LanguageTool
README.md
[uncategorized] ~39-~39: Loose punctuation mark.
Context: ...t variables in .env: - DATABASE_URL: Your PostgreSQL connection string - `GO...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~103-~103: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ...ontributing Contributions are welcome! Please feel free to submit a Pull Request. ## 📝 License ...
(FEEL_FREE_TO_STYLE_ME)
🔇 Additional comments (8)
src/app/invoices/[ID]/page.tsx (2)
1-12: LGTM! Clean imports and well-structured metadata.The imports are properly organized and the metadata follows Next.js conventions.
160-175: LGTM! Type casting is safe due to schema validation.Based on the retrieved learnings, invoice items are validated at creation time through schema validation, making the type casting safe.
README.md (2)
1-4: LGTM! Clear and informative introduction.The title and introduction effectively communicate the project's purpose and technology stack.
46-81: LGTM! Clear and comprehensive installation instructions.The instructions clearly differentiate between development and production setups, and provide commands for both npm and yarn.
drizzle/0000_chunky_albert_cleary.sql (2)
22-26: LGTM!The session table schema is well-designed with appropriate data types and constraints.
28-33: LGTM!The user table schema is well-designed for Google OAuth integration with appropriate constraints.
drizzle/meta/0000_snapshot.json (1)
1-229: LGTM!The JSON snapshot accurately reflects the SQL schema definition.
package.json (1)
61-61: LGTM!The version changes look good:
- Using caret range for Biome allows for minor updates
- dotenv-cli version is appropriate
Also applies to: 67-67
aimensahnoun
deleted the
1-request-api---integrate-request-api-into-easyinvoice
branch
Resolves #1
Added EasyInvoice payment platform with Request API :
Easy.Invoice_.Streamlining.Payments.with.Tella.mp4
Summary by CodeRabbit
New Features
LICENSEfile specifying MIT License terms.InvoiceTablecomponent for displaying invoices with pagination.PaymentSectioncomponent for managing invoice payments.DashboardPageto dynamically fetch invoice data.PaymentPagecomponent for processing invoice payments.InvoiceFormcomponent.Toastercomponent for notifications.RootLayoutcomponent with new metadata and layout structure.AppKitcomponent for application initialization.Bug Fixes
Documentation
Chores