Learn how to get started with Nuxt 3 and Prismic and enjoy a comprehensive development experience when building your very own page builder.

Nuxt 3 and Prismic: Get Up and Running Now!

Nuxt is one of the frameworks we work on to offer first-class support at Prismic. From an excellent TypeScript integration and impressive performances to auto-imports and flexible rendering modes, the meta-framework for Vue.js, Nuxt 3, packs in a lot.

Conscious of the great experience Nuxt provides you with. We, at Prismic, want to carry this it forward. Over the last few months, we released quite a lot of things toward this goal:

In April, we released Slice Machine 1.0.0 with official support for Nuxt 3 featuring a new automatic TypeScript integration

Later, in May, we released an updated Vue.js SDK, `@prismicio/vue` v4, integrating with our refreshed client

This was closely followed in early June by `@nuxtjs/prismic` v3 release out of RC, Prismic module for Nuxt 3

Finally, we made last week all our Nuxt 3 starters available for you to start working with Prismic and Nuxt 3 seamlessly

We’re eager to show you how all of these work together and how you can quickly get started with Nuxt 3 and Prismic, so let’s get to it!

And in case you prefer videos, we also made one about all of that; you can watch it over on YouTube →

Check out the crash course first to learn more about our key concepts →

To get started, we first need a project. In this case, you have three options.

You can get started from scratch by creating a brand new Nuxt project using `nuxi`, the Nuxt 3 CLI.

We offer a few starters that can get you up and running fast with various kinds of websites. If you want a minimal starter with some example code but no extra noise, pick our new minimal starter.

If you prefer a more elaborate starter with a few pages, slices, and TailwindCSS already configured, then our multi-page starter is here for you.

You already have a Nuxt project up and running? Great! Just get inside it and follow along.

Once we have our project ready at hand, it’s time to initialize Prismic and Slice Machine inside it. This is best done using Slice Machine init command with `npx` from inside our project.

This guided process will walk you through pairing your project to a new or existing Prismic repository, while installing and configuring Prismic and Slice Machine in the background.

Once it’s done, you’re done! And we’re ready to start developing with Prismic and Slice Machine.

Two notes, however, in case you started from scratch or from an existing project (i.e. not from a starter):

In the event you have a default `App.vue` at the root of your project. Just move it to the new pages directory: `mv App.vue pages/index.vue`, or delete it.

Finish configuring Slice Simulator inside your `slicemachine.config.json`, by adding its URL, we’ll make use of it later.

During this Summer, we’ll be working on automating these two extra steps for you so you won’t have to worry about them anymore in the future 🚀

Now that our project is set up, let’s get down straight to building a first slice together. This will also be the opportunity to explain what the init command did for us and what it means to have Prismic installed on our Nuxt project!

To run our project we want to start two things: Nuxt’s development server and Slice Machine.

Slice Machine is our main developer tool. It’s a UI you run locally to manage your Prismic project, create and develop custom types and slices to build your very own page build. It is configured through a mandatory `slicemachine.config.json` file that you can find at the root of your project.

Slice Machine was installed for us during the init command, through two extra dependencies: `slice-machine-ui` the UI itself, and `@slicemachine/adapter-nuxt`, Slice Machine’s adapter for it to work with Nuxt projects.

If you started with a starter, you can do so with a single command thanks to `concurrently`.

For other cases, you’ll need to spin up two terminals, one for Nuxt, and one for Slice Machine.

Once the servers are running, you should be able to access Nuxt on localhost:3000 and Slice Machine UI on localhost:9999.

While this post is not exactly about how to develop with slices, let’s still create a slice together to highlight some of the new things coming with Nuxt 3 and Prismic.

To do so, we head to the “Slices” page on Slice Machine, and we create a new slice, let’s name it “SimpleHero”. Inside, we can add a few fields, a title, a description, and an image. Then we can save it.

Now, if we head to our code, we can see Slice Machine created for us a new “SimpleHero” component inside our “slices” directory. It contains the minimum scaffolding for the new website section we’ll be developing.

What’s exciting here is that Slice Machine is now able to generate exact types for your slices and documents. These types play nicely with Nuxt’s TypeScript integration and allow you to template data quickly and safely with your auto-imported components, as you can see in the IntelliSense example below:

This is all possible thanks to a third, and last, dependency installed and configured by the init command: `@nuxtjs/prismic`, our Prismic module for Nuxt. It provides you with everything you need to develop your website with Prismic.

Under its hood, it makes use of `@prismicio/vue`. It’s a Vue plugin exposing many Vue components and helpers we can make use of seamlessly inside our project now thanks to Nuxt auto-imports.

Similarly, `@prismicio/vue` also uses under its hood `@prismicio/client` to inject inside your Vue application a client instance ready to be used for querying content with Nuxt data fetching composables. That client is also all wired up and ready to preview content out of the box so that setup is kept minimal on your end.

Heading back to Slice Machine, we can now click the “Simulate Slice” button. This will bring us to the Simulator. On this page, we can develop slices in isolation, à-la-Storybook. We can edit mock data to display through an editor, and take screenshots of our slices.

The Simulator is a page of Slice Machine UI that makes use of the `~/pages/slice-simulator.vue` page which was created during the init process.

This page is currently used by Slice Machine to allow us to develop slices in isolation with mocked content we can edit. Soon it will also be used by our editor, letting you preview slices as you're writing them!

And that’s the gist of it, you’re now ready to roll with Nuxt 3 and Prismic! As this was just an intro, here are some links for things you might want to explore next:

Fetch Prismic data on your pages and components →

Template any kind of content with components and helpers →

Route documents to correct pages using the Route Resolver →

Lots of releases happened over the last few months at Prismic allowing us to offer first-class support and quick setup to Nuxt 3 users.

Iterate on your models and develop pages and slices within Slice Machine UI to create your very own page builder

Enjoy Nuxt 3 latest and greatest with Prismic: auto-imports for everything and comprehensive TypeScript integration with our updated SDKs: `@prismicio/vue` v4 and `@nuxtjs/prismic` v3

Get started quickly with our updated starters and updated Slice Machine init command

We’re not stopping there as more things are to come for Nuxt and Prismic! Currently, we’re exploring opportunities to integrate Prismic within Nuxt DevTools, and it’s looking pretty promising!

In the meantime, feel free to give a start to Nuxt 3 and Prismic, following the above or directly from the UI. You can join the discussion and share your questions and feedback:

👨‍👩‍👧‍👦 On the community forum

💾 Or, if you stumble upon any issue or want to submit a new feature idea, we welcome you as a contributor over on GitHub.

We’re excited to announce the release of @prismicio/client v7, a new major version of our JavaScript client library which simplifies things for you.

@prismicio/client v7: Our New, Unified, Core Library

At Prismic, we try to build SDKs that integrate deeply with the framework you use to provide you with the best experience.

But whether you’re using React, Vue, Astro, or something else, at the heart of these integrations resides `@prismicio/client`: It’s the core Prismic package for querying and templating Prismic data with JavaScript, and we just released a new major version of it, let’s talk about it!

The main highlight of this version is that `@prismicio/client` v7 now combines `@prismicio/client`, `@prismicio/helpers`, and `@prismicio/types` into one package, offering a leaner API with a smaller footprint on your project.

Being a new major version, this also means it comes with a few breaking changes, mainly removed deprecated APIs. But no worries! We have you covered with a comprehensive migration guide that you can go check out here if you want to dive straight into upgrading your project.

Want to learn more about what has changed and the new things we added before updating? Well, let’s get to it!

We cannot talk about this version without talking about the libraries we merged. Previously, our core packages to develop web apps with Prismic and JavaScript were a collection of three:

`@prismicio/client`, holding code to query our API

`@prismicio/helpers`, providing helpers to template and render Prismic data

`@prismicio/types`, defining TypeScript types for all Prismic data structures

In most cases, you had to install the three of them, and even if you didn’t, our dedicated framework integrations, like `@prismicio/vue`, were doing it for you anyway.

On top of that, having three packages to perform basic things also created confusion. From where do I need to import that? Where do I find this type? Enough!

Those two reasons, among others more subtle, motivated us to simplify our foundations. We merged code from `@prismicio/helpers` and `@prismicio/types` into the new `@prismicio/client` v7. All functionalities from these - newly deprecated - packages are now available through `@prismicio/client`. This allows you to only install a single library moving forward to work with Prismic when you don’t also need to integrate with a specific framework.

We are on a constant quest to make Prismic more natural and easier to understand. Working towards that goal, we’ve simplified the names of some of our concepts to make them more intuitive.

`@prismicio/client` v7 includes these updated names. Here’s an overview of these changes:

“Integration Fields” fields are now referred to as “integration” fields (one less “fields”).

"Predicates," used to filter queries to the API, are now called "filters"

“HTML Serializer," a function or map used to serialize our rich text fields, is now called a “rich text serializer”

References to these old names are still exposed by the client to simplify upgrading but are marked as deprecated. They will be removed in the next major of `@prismicio/client`.

Another highlight of this new version is that we developed new helpers: small functions to help you manipulate Prismic data, previously available through `@prismicio/helpers`. With `@prismicio/client` v7, on top of classic helpers like `asText()` and `asDate()`, you now have access to:

`asLinkAttrs()`, an advanced version of `asLink()` to work with Prismic links

`getToolbarSrc()`, a safe way to programmatically compute Prismic toolbar source URL for a given repository name

And we will continue our work here as more helpers are already on their way, so stay tuned for future releases! In the meantime, you can find a list of all available helpers, as of today, in `@prismicio/client` technical references.

Performances are always top-of-mind when working on libraries like `@prismicio/client`: we monitor package sizes on every pull request and keep an eye out for runtime performances.

In that regard, `@prismicio/client` v7 integrates some new optimizations:

When querying our API, the client will now deduplicate requests when they happen concurrently, allowing pages to be rendered more quickly, in fewer network calls.

A new `fetchOptions` is now available when creating a client instance and/or on a per-query method basis. You can use it to provide additional parameters, like specific caching headers, to the client’s `fetch()` function that will be merged with internally required options.

For more complex use-case, the client’s `fetch` option still allows you to provide your own fetching method, library, or `fetch()` wrapper.

As we develop our packages, we sometimes find ourselves unhappy with the names or functionalities we came up with and shipped. Maybe we figured out better alternatives or those features are just not considered useful anymore.

When this happens, because we follow Semantic Versioning standards, we cannot remove them immediately; that would break your projects. So instead, we mark them as deprecated, which, depending on your editor, removes them from IntelliSense and/or crosses them out in your code if you were using them.

You can think of it as a warning: “This API will be removed in a later version,” which, most of the time, is followed by instructions on how to migrate when you hover the deprecated piece of code.

Major versions allow us to clean up our codebase from these, often long-time, deprecated APIs. With `@prismicio/client` v7, we did just that. Deprecated APIs from `@prismicio/client` v6 were removed. You can find a list of them and the required changes in the migration guide, if you were still relying on them.

The upgrade should be quick. For most projects, you’re likely a few search-and-replaces away from being done. Get started by updating your dependencies in your `package.json`.

package.json

From here, after an `npm install`, you can start handling breaking changes following our migration guide. This process primarily involves updating imports from `@prismicio/helpers` and `@prismicio/types` to `@prismicio/client`.

If you experience any trouble upgrading, feel free to reach out to us on the community forum. If it all went smoothly, congratulations! You can start embracing new features and enjoying simplified code.

We’re happy with this new release and hope you’ll enjoy it too. `@prismicio/client` v7 significantly streamlines our core SDK usage, simplifying your code. If you have any questions about it or require some help, our community forum is the best place to reach out to us!

Regarding `@prismicio/client` v6, `@prismicio/helpers`, and `@prismicio/types`, while we’ll keep maintaining them for a year, we don’t plan on adding new features to them anymore. With that in mind, we recommend you update your projects to use `@prismicio/client` v7 as soon as your maintenance schedule allows. The migration guide is here to guide you in this endeavor.

More features are ahead for `@prismicio/client` v7 and we’re already working on some of them! If you’d like to voice your ideas to us, or if you stumble across any bug, feel free to contribute an issue on GitHub. For now, all new features of `@prismicio/client` v7 are documented in its refreshed technical references.

We look forward to seeing what you’ll build using the new `@prismicio/client` 🚀

Next & Nuxt are JavaScript meta-frameworks that embrace Jamstack. Next builds on React, Nuxt on Vue. See how they compare and which is right for you!

Nuxt vs. Next: Which Should You Choose for Your Project?

In The Matrix, Morpheus asks Neo to choose between the red pill and the blue pill. To build a website, you have to choose between a wide range of pills, two of them being the Next and Nuxt pills. When facing this choice for your next project, which one should you pick?

Nowadays, incorporating some facets of the Jamstack into your workflow might be something you’re after. Perhaps you want to move on from WordPress maintenance, improve your apps’ performance and reliability, or just enjoy some new tech. In any case, now you need to choose the best solution for your needs.

Next and Nuxt are two flagship JavaScript meta-frameworks that embrace Jamstack architecture. Next is built on React. Nuxt is built on Vue. How do they compare? While we believe there’s no wrong pill to take here, there are definitely some considerations worth having in mind when picking a framework to ensure you’re successful with your choice. Let’s go through them in this post, from basic comparisons to considerations about their ecosystems and developer onboarding.

Next and Nuxt are both built on top of the latest JavaScript technologies. Since their first releases in 2016, they have shared a similar goal of enabling you to build fast websites in an efficient and reliable way. Long story short, Next and Nuxt have a similar scope for their features, but let’s add some more detail to that.

With Next and Nuxt you can pretty much build any type of site and scale it. This is made possible thanks to concepts from the Jamstack. More precisely, “hybrid rendering” is a feature both frameworks have. It allows you to fine-tune which pages are getting statically built and served over a CDN for faster page loads, which aren’t and should be served through a server of any kind, and more!

However, rendering pages is only part of the story: you might still need a backend to run your application. Whether it’s a small one to handle form submissions, or a more complex one dealing with user accounts and authentication, once again, Next and Nuxt have got you covered. Need an API on top of your site? They both allow you to work with API folders of their own, which are deeply integrated with the rest of your application.

Now that you have an application, you’ll need to host it. In that regard, both frameworks come with a lot of flexibility and can be deployed through a variety of hosts: a server of your own, platforms like Netlify or Vercel, CDNs like Cloudflare, or cloud platforms of your choice.

However, hosting a website only gets you so far if it ends up slow. Next and Nuxt are really sensible about that and provide you with dozens of built-in improvements you don’t have to worry about anymore. Among them are smart bundling, in-lined critical CSS, and image optimization. They are built to enable you.

Talking about enablement, they also enable you, as developers, with a deep focus on developer experience. This starts with the standard folder structures each framework adopted, allowing you to jump between or pick up projects from them easily. Next and Nuxt now also come with native TypeScript support, allowing you to get stronger IntelliSense and typing on your projects. One last example is their build engines, respectively relying on Rust and Go, which makes for fast development server and build processes.

I admit, so far, this post looks more like an advertisement praising both frameworks than an apple-to-apple comparison. But hey, part of a comparison is also about acknowledging similarities. Our point here is that while things might not always be named the same, from a feature perspective Next and Nuxt have a lot in common. But let’s see some real differences now and talk about each framework’s ecosystem.

One thing that made WordPress successful was not WordPress itself, but its ecosystem. Want to add some functionality to your WordPress site? There’s a plugin for that. Nuxt went down the same path, except it’s not called a plugin but a module. With Nuxt, you want to add something to your app? There’s a module for that.

Nuxt modules are meant to ease your developer experience by making the integration of new technologies on your website painless and quick: just install a package, register it, and configure it. If you’re curious about the integrations you could add to a Nuxt website, head over to nuxt.com/modules. This site references all publicly available modules, ranging from CSS frameworks like Tailwind or Bootstrap to payment systems like Stripe. There’s even a CMS category, with — just saying — our own Prismic module.

While modules are what make Nuxt’s ecosystem strong and capable of supporting you, Next doesn't have modules of its own. However, that doesn’t mean Next is not capable of supporting you.

Next is a React framework. Because of that, Next inherits from the wide ecosystem of libraries built on top of React itself that you can use (most of the time) directly within Next. Indeed, because those libraries are not as tightly integrated as they could have been with modules, you sometimes have to roll out some boilerplate code to get them running. But no worries, Next’s team likely has an example for that. Jokes aside, they’ve got you covered with tons of great and comprehensive examples that you can browse here.

All things considered, having to roll some boilerplate code is not necessarily a bad thing, since it gives you more control over the tools you integrate and an easier debugging workflow, which some might prefer over Nuxt’s module approach.

So Next is built on top of React and benefits from its ecosystem. But Nuxt is also built on top of Vue, another JavaScript framework. Let’s discuss that obvious difference!

The main difference to consider: React vs. Vue

Probably the most obvious difference between Next and Nuxt is that Next builds on React while Nuxt builds on Vue. We think this difference is the main one you should have in mind while picking one or the other.

React and Vue are two different JavaScript frameworks that allow you to build interactive websites with reusable components. From a performance standpoint they are pretty comparable (see this benchmark for reference, but bear in mind it’s showcasing extreme use-cases). They also both come with great TypeScript support, so if you’re into it, you’re covered! From here, which one to prefer? Here are some considerations:

You and your team might already be experienced with these JavaScript frameworks. If so, just pick between Next and Nuxt according to your preference!

Next relying on React will have a React-styled codebase with some abstractions and patterns you might already be familiar with if you’ve been using React.

On the other hand, Nuxt relying on Vue will have a Vue-themed codebase with intuitive syntax patterns that should be straightforward to pick up.

All in all, if you’ve been learning React or Vue and things felt weird or didn’t click for you yet, feel free to give the other one a quick try also, since you may find that its code style suits you better, and then you’ll also enjoy Next or Nuxt more, too.

If you and your team are new to JavaScript frameworks, no worries! Here are some more insights:

Overall, Vue tends to be easier to pick up for those who never worked with a JavaScript framework. Indeed, because Vue relies on vanilla HTML, CSS, and JavaScript for its templating and logic, that makes its learning curve smoother for beginners. If you’re a team of WordPress and PHP veterans, you should feel at home pretty quickly with Vue.

However, this doesn’t rule out React straight away. Using JSX (an extended version of JavaScript that supports à-la-HTML syntax) for its templates, React might appeal to you more if you’re JavaScript and/or TypeScript enthusiasts, so feel free to give it also a try if you have any doubt.

Put in a more visual way, here’s a quick code-style comparison with a component displaying a counter with some styling in Vue and React, so you can see for yourself:

React

Finally, when picking between Next or Nuxt for your business, it’s also worth giving some consideration to the job market. Are you growing? Planning on hiring developers to strengthen your team or relying on contractors often? While React and Vue both boast large communities, developers’ availability for one or the other might vary depending on your location. If that’s a concern of yours, feel free to give LinkedIn, or other websites, a quick search before you make a decision.

Open-source technologies are made by people, and sometimes even by companies. In that regard, it can be useful to know a bit about each of the companies and people making Next and Nuxt. This can help you understand what to expect regarding support, who to look after for updates and the future of these frameworks, and more.

Vercel is the company behind Next. You might know about them because of their powerful hosting platform that, obviously, is a great choice to host your Next websites.

Beyond the platform, Vercel also backs other open-source projects including SWC, a super fast Rust-based JavaScript/TypeScript compiler and bundler, and Svelte, another JavaScript framework with its own approach to UI building.

To build Next, Vercel can count on some amazing people like Tim Neutkens, Next’s lead developer and creator of the MDX format, JJ Kasper, tireless maintainer, and Lee Robinson, who’s great to follow for updates. Vercel is also closely working with the team behind React, with React Server Components being one of the joined efforts of the two teams.

On the other side, NuxtLabs is the company supporting Nuxt (who would have guessed?), and while this might sound counter-intuitive, NuxtLabs has Vercel as one of its partners. So yes, while addressing similar needs, the two frameworks aren’t at war, and Vercel is also a platform of choice for hosting Nuxt-powered websites.

On its end, NuxtLabs actively contributes to the open-source ecosystem through unjs, an extensive collection of modern JavaScript tools you could make use of on your next Node project.

Finally, Nuxt also has some amazing contributors creating the framework like Pooya Parsa and Daniel Roe, working days and nights on new features and improvements, or Anthony Fu, creator of Vitest, and many more. Like Vercel, NuxtLabs also has a close relationship with the Vue Core Team, collaborating together to make the JavaScript framework and its ecosystem better every day.

At the end of the day, you can succeed with Next or Nuxt

Before we close, and just to clear any doubt: you can succeed with either option. With React or Vue, Next or Nuxt. To prove it here’s the work from two agencies that use them:

Skyward worked with Next on Pigeon Loans’s website, a platform to ease the process of lending money to people you know.

With Next they built a multi-page marketing website to better highlight the Pigeon Loans’ value proposition and refresh its brand. They also used Prismic as the CMS, easing content creation and SEO work for their editors.

On the other side, Thinkingbox worked with Nuxt to build Arc Worldwide, an e-commerce style site where you can shop (bookmark) content and get it delivered to your email.

Nuxt allowed them to build that clever marketing website experience, and enables Arc to showcase how uniquely they service their brands.

Great! Morpheus is happy. If not, here’s a quick run-through of everything we discussed in this post:

Next and Nuxt are two popular frameworks embracing the Jamstack architecture. They enable you to build fast, modern, websites in an efficient and reliable way.

And if after that you still don’t know. Well. Just pick Nuxt. I joined their core team in 2023. It’s a cool framework. I contribute to it regularly and notably made its new link components. (But no worries, my React colleagues still reviewed this post to make sure it wasn’t too biased.)

While working on these Prismic snippets, I also had the opportunity to create Schnipsel, an open-source tool that allows you to write snippets in a markdown file and have them rendered into the proper formats for multiple IDEs.

Schnipsel, a Tool to Render Snippets for Multiple IDEs

This spring, I tasked myself with exploring the possible integrations Prismic could offer with Integrated Development Environments (IDEs, a.k.a. code editors). This was a topic I was interested in and aligned with our current goal of providing you with the best integration and experience. I also felt like it could come with the opportunity for me to learn more about the anatomy of IDE extensions.

“Who knows?” I thought, “Might be helpful for a hypothetic Philips Hue (yes, the light bulbs) integration… Nevermind! Someone beat me to it.”

This Prismic extension project led to Prismic Snippets being released for VS Code, as well as Vim, Sublime Text, and IntelliJ, hopefully providing most of you with snippets to template content quickly. But that’s not all! While working on these 4 extensions I also had the opportunity to create Schnipsel, an open-source tool I created to solve a multiple extensions problem…

One of the first questions I asked myself when starting this project was: which IDE should we target? I suspected VS Code to be the one, but doing some research is always great to get rid of biases, right? While there are no precise data on IDE market shares, surveys are regularly run by third parties asking about IDE usage (e.g. Stack Overflow’s Developer Survey).

Long story short, numbers fluctuate, but IDE usage among web developers in 2022 can “roughly” be summed up like so:

So VS Code is the winner, yay! But 70% is only about two-thirds of developers, so there are clearly opportunities with other IDEs, too. In that regard, each IDE comes with its own extension framework or even language: VS Code wants its extensions to be written in TypeScript, so does Vim (via Coc), but IntelliJ is all about Java and Sublime Text whistles Python, and… as we now wanted to cover multiple IDEs, that was our problem!

Each IDE requires extensions to be written very differently (they all have their own reasons for that). This kills any opportunity to share code if we were to write an extension for each of them. It would be all about duplication, or would it be?

As I was doing research for this project and learning about extensions’ capabilities, I stumbled across Snippet Generator:

Snippet Generator is an application developed by Pawel Grzybek. It allows you to write a snippet in a simple format (the left section of the GIF above) and convert it to different IDE snippet formats (the right section with the cryptic syntax).

This clicked for me! I could just define a convenient format for writing snippets like Pawel did, and then have some kind of process to render that snippet to different IDE formats. All that would remain would be to figure out some boilerplate for each IDE to load those snippets through an extension. Then it would be Winner Winner, Chicken Dinner!

I started working on that idea and that idea eventually got a name: Schnipsel.

Schnipsel — German for “fragment or snippet” — is available for anyone to use on GitHub. It is a CLI tool that reads some input snippet files, then renders them to desired IDE formats. Let’s highlight how it works by first talking about snippet files!

Snippet files are what I came up with for an easy-to-write, read, and parse format to write snippets in. Basically, they’re Markdown files with some front matter and a code block. The code block can be highlighted with any language you fancy, just like regular Markdown, and tab stops with placeholders can be declared inside it with an à-la-VS Code syntax. Considering all of that, a snippet file can look like this for example:

What I find extra cool about it is that it even displays nicely over on GitHub.

Snippet files are what we used and what potential Schnipsel users would use to define their snippets before rendering them through the available renderers …

To render snippets, Schnipsel works with an array of renderers. I wrote one for each IDE we decided to target for now (namely, VS Code, Vim, Sublime Text, and IntelliJ), but we can always add more should we want to.

The role of a renderer is to take in parsed snippet files, some metadata, and the code inside the code block, and render them to the desired format at a specific location.

Schnipsel is able to work thanks to these first two notions. A CLI then allows you to render your snippet files once or in watch mode.

From my experience, building a CLI is always quite fun and refreshing compared to my usual projects. This time it was also for me the opportunity to work with some cool (new) tools:

For example, Schnipsel CLI works by reading its configuration from the user’s `schnipsel.config.ts` file. Reading a TypeScript file from a CLI is not trivial (because the CLI by design is a Node.js script). For that purpose, this was the perfect opportunity to use c12. It’s a smart configuration loader developed by the Nuxt team that handles TypeScript configuration files.

Another great tool I had the opportunity to use again for this project is CAC. It’s a simple CLI framework that I find pleasant to use. It is nicely typed, and its output is minimal but well-formatted.

One of the things I cherish about working at Prismic is that we get time to work on open-source projects like Schnipsel. This comes with a lot of learning opportunities while also allowing us to give back to the community.

In fact, earlier this year I had the chance to work on another open-source project as I implemented `<NuxtLink>`, the new link component for Nuxt 3. You can read more about this experience right here!

Finally, if you’re a Prismic user feel free to give Prismic Snippets a try! Find how to install it on your IDE and what you can do with it on GitHub!

See other ways Prismic works to improve your developer experience:

Pinia is the default state management library for Vue 3. Explore it with us as we build a fun confetti clicker app called "Pinia's Party" to learn the basics!

Give Pinia a Try: Build a Confetti Clicker Game with Us

For this month's Optimized Dev coding challenge, we learned about Pinia, a state management library for Vue. We'll start with a recap for new readers, but Optimizers, feel free to use the Table of Contents to find solutions to your challenge!

A state management library provides you with a framework for managing state that is global to your application (not belonging to a specific component) through what we call stores. For example, this could be the cart on an e-commerce website: with a state management library, you can define the cart as a store (the cart store), read its content (on the navbar and the cart page), and update it (with “Add to cart” buttons or the cart page directly).

If you’re a Vue user you might already be familiar with VueX, so why learn about Pinia?

New to Vue? Have a glance at our introduction to Vue to pick up the basics so you can follow the tutorial smoothly →

Pinia started as an experiment and exploration for Vue 3 store options. Recently, it has been decided that Pinia will be the default state management library for Vue 3 over VueX. The simpler, composition-styled API Pinia offers and strong TypeScript integration are two of the main reasons that motivated this decision.

Way to go on those solutions @trostcodes and @helge_eight! Love the creativity we're seeing from the community. 🚀

In today’s challenge, we’ll be building a clicker game: Pinia’s Party.

Maybe you’re already familiar with clicker games like Cookie Clicker. If you’re not, a clicker game is a game where you try to exponentially accumulate something (cookies in Cookie Clicker, confetti in Pinia’s Party) through manual actions (clicking) and automatic ones (ever more efficient — and pricy — “factories” you can acquire).

While building this challenge, we thought a clicker game might be a great candidate for learning about stores. In these games, the clicker state needs to be read at multiple places (to display the amount of confetti, owned factories, etc.) while also being updated at different locations (when clicking, acquiring factories, etc.).

Without further ado let’s dive into it!

To follow that tutorial we recommend you use Stackblitz. Kickstart your own instance of the project online by clicking here.

Alternatively, if like me you’re more of a local person, you can download the starter files here. Install dependencies with `npm install` and start the development server `npm run dev`.

Our project today is a Vite + Vue 3 application. We took care of the styling in `src/assets` and of most of the templating with 3 components in `src/components`:

`<PartyArea />` is the main section of Pinia’s party; it will display our number of confetti and allow us to gain more by clicking the central one.

`<FactoryList />` is the sidebar; it will display available factories and information about them.

`<FactoryListItem />`, following its name, will represent a factory displayed by `<FactoryList />`.

What’s left for us to do is to make all of that work together by adding a store to our application with Pinia, and to learn about that process 🚀

If you get lost, you can find stepped solutions here, which represent the state of the application at the beginning of each section of the tutorial. Right now, you’re in the same state as `01-piniaSetup`.

Like most things, we first need to set it up. We already installed Pinia for you as a project dependency (with `npm install --save pinia`), so our first task is to register Pinia in our Vue application. To do so we’ll edit `src/main.js`:

What we’re doing in the code above is importing the `createPinia()` helper and calling it to register Pinia as a Vue plugin in our application. This effectively makes the app aware that we’ll be using Pinia.

Now that our application is aware of Pinia, we can proceed to create our first store. As explained earlier, a store is an element of our application that is responsible for managing a piece of state and declaring methods to read and update it.

For Pinia’s Party, we’ll only need one store; let’s create it at `src/stores/clicker.js`:

Using the `stores` directory for storing application stores is a common pattern used by the community.

First, we import the `defineStore()` helper from Pinia.

We then use it to create a store with the ID “clicker.” In today’s challenge, we’ll only have one store, but if you were to have multiple inside an application, this ID needs to be unique.

Following the ID, we provide store options. For now, it only features a `state` method. This method returns the default state of the store, for now, an object with the property balance set to 0, as we’re starting the game with `0` confetti in our balance.

Finally, the whole store is exported as `useClicker`.

Great! So we’ve installed Pinia and set up our first store. Before moving to the next section let’s just see how to use this store in our application by displaying the balance we initialized in `src/components/PartyArea.vue`. To do so we first import our store and make it available in the component script section by calling it:

We can then update the template part of it, replacing the “TODO:BALANCE” comment with `{{ clicker.balance }}`:

And here we go! You should now see “0 confetti” instead of “confetti” in the party area ✨

💢 Having issues? Pick-up here on Stackblitz →

Well, the setup part is only so much fun, so let’s move on to implementing our first game mechanic: obtaining confetti by clicking the party area confetti.

Lucie Haberer

Nuxt 3 and Prismic: Get Up and Running Now!

@prismicio/client v7: Our New, Unified, Core Library

Nuxt vs. Next: Which Should You Choose for Your Project?

Schnipsel, a Tool to Render Snippets for Multiple IDEs

Give Pinia a Try: Build a Confetti Clicker Game with Us

How We Helped Bring You the New Nuxt 3 Link Component

Slice Simulator: An Alternative for Building Slices in Isolation

TypeScript Integration, Refreshed APIs & More

Nuxt Image Is Out, and So Is Its Prismic Integration!

#SliceContest: Fun Startup Edition

#SliceContest: Winner, Winner, Pizza Dinner

#SliceContest: Share Your Slice Library

Deliver a website with a visual Page Builder for your marketing team