The Base Store (Next.js) starter now supports instant VTEX Headless CMS previews.

Use the Preview option while writing a draft on VTEX Headless CMS to preview content changes immediately and whenever you want.

What needs to be done?​

These changes are available in Base Store (Next.js) version 22.38.3 or greater. If you have already started a FastStore project with the Base Store (Next.js) starter, remember to keep it up to date with its latest version.

Also, notice that __next_preview_data cookies are set on the browser whenever you generate a CMS preview. Hence, after using the VTEX Headless CMS, make sure to clear the cookies from your browser so you can see your production website once again.

Gift, OrderSummary, SkuSelector, and CartItem components are now available in the FastStore UI. Also, updates to the FastStore API improve the shopping cart UX and allow adding user's session information to the orderForm.

FastStore UI​

Gift​

• 🎉 New component - #1443

  Use the Gift component to display promotional gift items.

  

OrderSummary​

• 🎉 New component - #1456

  Use the OrderSummary component to provide a summary of the items in the cart, including the total price, related shipping tax, and discounts.

  

SkuSelector​

• 🎉 New component - #1462

  Use the SkuSelector component on Product Details Pages (PDPs) to display all SKUs available for a given product.

  

CartItem​

• 🎉 New component - #1461

  Use the CartItem component to display summarized data about an item placed in the shopping cart.

  

FastStore API​

• 🐛 Fixed "Buy 2 get 3" promotions - #1434

  Cart UX issues related to promotions, such as "Buy 2 get 3," have been fixed. Now, items and gifts are correctly combined when necessary.

  

• ✨ Product releaseDate now available - #1438

  The StoreProduct entity can now return the releaseDate of an item.

• ✨ Session info now available as an argument of validateCart - #1444

  The validateCart mutation now accepts the session argument. This allows adding the user's session information to the orderForm, making the shopping flow consistent between storefront and checkout, and allowing for regionalized prices.

Documentation​

• 🎉 New documentation feedback feature - #1448

  

New and improved docs​

• FastStore, WebOps & Headless CMS Beta Program - #1446
  • Program overview and timeline - #1446
  • Feedback and issue tracking - #1446
  • Customer invitation - #1446
  • Features and capabilities - #1446
  • Changes from Store Framework - #1446

• Performance Overivew - #1452

  • Getting started with Lighthouse - #1458
  • Analyzing a project's bundle size - #1453
  • Testing the server-side rendering - #1458

• FastStore API

  • Extending the GraphQL schema - #1436 / #1445
  • Using a GraphQL IDE to explore the FastStore API - #1445 / #1428
  • Fetching API data on the storefront - #1445

• Analytics - #1449

  • sendAnalyticsEvent - #1449
  • useAnalyticsEvent - #1449
  • Extending and customizing native types - #1449
  • Sending custom events - #1449
  • Analytics on FastStore - #1449
  • Analytics on official starters - #1449
  • Analytics on Store Framework and FastStore comparison - #1449

• Glossary - #1452

The USE_FRAMEWORK_CACHE and USE_NODE_MODULES_CACHE environment flags were deprecated in favor of USE_BUILD_CACHE. The new flag improves the build time by reusing cache from previous commits in newer deploy previews of the same Pull Request.

What has changed?​

The new USE_BUILD_CACHE flag replaces the previously used USE_FRAMEWORK_CACHE and USE_NODE_MODULES_CACHE flags.

To exemplify the improvement, consider the git example below.

master: commit-sha-1
PR 233:
       - commit-sha-2
       - commit-sha-3

Previously, the build correponding to commit-sha-3 would use commit-sha-1 cache. Now it uses the cache generated for commit-sha-2. In case the commit-sha-2 does not exist, the build would use the commit-sha-1 cache.

What needs to be done?​

To use this new improvement, set the USE_BUILD_CACHE flag to true in the vtex.env file of your FastStore project.

The automatic previews of your FastStore + WebOps project Pull Requests are now deployed with GitHub environments.

What has changed?​

Previously, if you committed code to a branch with an open pull request, the vtex-sites bot would add a comment with the link to the PR's corresponding deploy preview. For example:

Now, this comment is no longer provided. Instead, you should check the GitHub environments section. You should see something like this in your pull request:

You can see the available environments on your repository's home page, on the right side of the screen. As of now, there are two environments: FastStore Preview and FastStore Production.

What needs to be done?​

This feature is already active for all projects. There is no action required.

There are new and improved FastStore API guides available on our documentation portal:

• Using a GraphQL IDE to explore the FastStore API
• Fetching API data on the storefront
• Extending the GraphQL schema

What has changed?​

Previously, the GraphQL IDE guide focused on GraphiQL. However, GraphiQL is not natively supported by the Base Store starters anymore.

Now, you can still run your FastStore project locally and, although the new guide contains specific instructions for using graphql-playground, you may use your preferred GraphQL IDE.

In addition, now you can find more precise instructions and code examples of how to use the FastStore API in your storefront with the guides Fetching API data on the storefront and Extending the GraphQL schema.

In this article, we share our vision for the future of analytics on FastStore and invite you to share your thoughts.

Before we start, it's important to highlight that this is not a commitment to any of the following topics, and we have not yet planned when they will be implemented or even if they'll come to be. That being said, we envision an ever-evolving analytics solution for FastStore, and we count on you to build it together with us.

Universal Analytics​

We want to make it easy to migrate to FastStore, regardless of where you are coming from. To address that, we intend to support Universal Analytics on our official starters. We still plan to recommend and enforce Google Analytics 4 whenever possible. Still, we want to give our users and developers the time they need to fully understand and migrate to the new version of Google Analytics.

dataLayer completeness​

To create rich reports about ecommerce operations, collecting rich data is necessary. In Google Analytics and Google Tag Manager, this is done by pushing data to the dataLayer.

Currently, our official starters support only GA4 Enhanced Ecommerce capabilities. This is not enough for most stores, which need more data powering their reports. We want to address this issue.

There's no definitive answer for which properties we should include in our official starters' dataLayer by default, and that's why we want to hear from you.

Analytics libraries for store segments​

Grocery, fashion, and appliances are all store segments with specific needs regarding design, functionality, and, of course, analytics.

We believe it makes sense to have custom-built events targeted to specific store segments so these stores can fully understand the shoppers' behavior. For grocery, for example, we believe it would be helpful to know how many users try to enter their address, but there's no store near them or the most popular stores in a given area.

These libraries would be accompanied by extensive documentation explaining the meaning behind each event, when to fire them, which information is required, autocomplete, how to integrate it with Google Analytics, etc. Also, using these libraries would be optional.

Zooming out​

The Analytics SDK module, Partytown, and the built-in integration offered by our official starters make us really excited about our analytics solutions and what's to come. We have a great opportunity to offer our clients a delightful experience while still allowing them to explore options other than the ones we've established by default. The future can also look bright, and we want to hear from you: what would you like to see from the FastStore team regarding analytics?

Continue learning​

To continue learning, check our advanced guide about Analytics on FastStore.

The search query has been enhanced to allow cross-selling and upselling of products. Also, the new subscribeToNewsletter mutation is now available in the FastStore API. In the FastStore UI, the Slider and PriceRange components now allow ref forwarding.

To go live, FastStore projects developed with Gatsby 4 and Next.js require a new environment variable. This new setting relates to improving and automating the hosting flow in WebOps.

What has changed?​

Setting up the SITE_HOST environment variable is now necessary in order to deploy new FastStore websites, developed with Gatsby 4 and Next.js, to production.

Why did we make these changes?​

To improve the hosting flow in WebOps, the WebOps team built a new automation related to this new environment variable.

What needs to be done?​

Open the vtex.env file and add the SITE_HOST key with the main domain specified in VTEX Account Management as the value. For more information, please refer to Configuring external DNS for a custom domain.

+ SITE_HOST= {hostDomain}

PLPs now support price range filtering, and nonexistent PDPs can now handle 404 errors. Also, more components have been updated to conform to the new Base Store Theming architecture.

The FastStore UI now includes the Hero and Dropdown components. Also, the FastStore API was enhanced to better support page error handling. Global changes were also implemented to enable price range filtering on PLPs.