Lab - Build Customer Registration
Lab - Build Customer Registration
Lab - Build Customer Registration
The final essential workflow to implement in your basic Next.js storefront is customer login. While you’ll track a customer’s authenticated state within your own application, BigCommerce will be used for the authentication itself.
This exercise builds on the basic Next.js application begun in previous labs and has the same technical requirements.
Customer account registration will not be part of this lab, so you will need a pre-existing customer in your store.
To observe the full functionality of your customer session logic, your store should contain a customer group matching the following:
Then make sure your store contains a customer matching the following:
This exercise continues where you left off previously in your basic Next.js project. Simply start the dev server from the project root if it’s not currently running:
If you need a fresh start, you can follow the instructions below to set up a new project complete with previous exercise code.
.env.example as .env.local and modify .env.local with configuration details for your store.pnpm output and verify your catalog pages and cart load successfully.You may choose to download or clone the completed version of this lab in a separate location to serve as a reference for the final state.
You’ll be encoding an authenticated customer’s information in a JWT to securely track their session. The library jsonwebtoken is pre-installed in the codebase and is used to manage JWTs. This library requires a secret value in order to sign JWTs.
.env.local file.app/register/page.tsx, which defines the register page component. Update the component as follows.We’re not doing much in this page component. The reason is that basically the entire contents of the page are contained within a form, and as you’ve previously seen with the Add to Cart button, interacction requires a client component!
RegisterForm is currently empty. Let’s fill it in next.
components/account/register-form.tsx and modify the component as follows.We’re using some simple state here to capture the form values, as well as tracking a “loading” state when the form is submitted.
submitRegister function with the request logic.registerCustomer is another server function, which doesn’t currently accept the right parameters.
components/account/_actions/register-customer.ts and update the function to accept the proper parameters and return a generic error for the time being.http://localhost:3000/register (or the correct port for your own local server). You can try submitting the form for a successful HTTP response, but you’ll currently receive the “Registration. is not implemented” error.components/account/_actions/register-customer.ts and add the GraphQL and type definitions related to the registration mutation.registerCustomer function to perform the mutation.http://localhost:3000/register (or the correct port for your own local server)./login (which is currently a blank page)./register again and try out a registration with the same email address you used before. Verify that you receive appropriate error feedback.The focus of the next sections will be to provide a login form, perform authentication with BigCommerce, and store a JWT in a cookie to represent the customer’s session.
app/login/page.tsx, which defines the login page component. Update the component as follows.Similar to the registration page, most of what’s going on here is delegated to a client form component.
components/account/login-form.tsx and modify the component as follows.submitLogin function with the request logic.Once again, we’re relying on a server function that must be modified to accept the right parameters.
components/account/_actions/login-customer.ts and modify the function as follows.http://localhost:3000/login (or the correct port for your own local server). You can try submitting the form for a successful HTTP response. You’ll currently see the “not implemented” message.components/account/_actions/login-customer.ts and add the GraphQL and type definitions related to the login mutation.loginCustomer function to perform the mutation.http://localhost:3000/login (or the correct port for your own local server).customer cookie being set.Your next step will be to add contextual login/logout links in the store header, which will require awareness of a customer’s logged-in status.
lib/getCurrentCustomer.ts. The helper function here will be used by any component that needs to retrieve the details tracked in the “customer” cookie. Fill in the function as follows.components/account-links/index.tsx. Update the component as follows.Notice that while “Register” and “Log in” are simple links, while a separate component is included for logging out. The logout link, rather than simply linking the user to a destination, is a dynamic interaction, and so it calls for yet another client component. Let’s fill out that component’s initial content now.
components/account-links/logout-button.tsx and modify the component as follows.This button doesn’t do anything yet but already has a simple loading state ready to go.
components/header/index.tsx to place AccountLinks.If you retry a valid login on the login page, you should be able to observe the links in the header immediately update accordingly.
components/account-links/logout-button.tsx and modify the component to implement a submit event calling a server function.components/account-links/_actions/logout.ts and add the appropriate query and response types.logout to perform the appropriate mutation and destroy the customer cookie.Your storefront will now handle authenticating and tracking a customer, but this has little actual effect except to then give the customer the chance to log out again. Let’s put the customer context to use in one of the most important ways: Passing this context in the storefront’s various GraphQL queries, which will affect the data returned.
Support for a customerToken is already built into the bcGqlFetch function, which passes this parameter in the X-Bc-Customer-Access-Token header. Each of the catalog queries you’ve built also supports a customerToken parameter. All that’s needed is to update the contexts where these queries are used to obtain and pass in the current customer’s token.
In a truly complete storefront, cart-related queries and mutations should be affected as well, but we’re not tackling the extra complexity (such as reassigning an existing guest cart to a logged-in customer) in this exercise.
components/header/index.tsx to get the current customer using the helper function you created and pass the token into the GraphQL function.app/category/[...catPath]/page.tsx to perform the same customer context logic.app/product/[...productPath]/page.tsx to perform the same customer context logic.If you try adding a product to the cart while logged in as a customer with pricing discounts, you will NOT see the same price difference in the cart. This is because the cart queries and mutations, including the initial createCart request, still lack the customer context, so cart pricing is not affected by it.
Provide the token from the current customer for cart requests as well, and verify that a logged-in customer session is maintained when redirecting to checkout.