This NuxtDojo edition covers WebSockets, Nitro, and the power of Nuxt's prefixes, suffixes and lazies. Reflecting on the Nitro chapters in my book, I realise there’s so much depth to Nitro that I could fill several newsletters with it—a single book chapter won’t do it justice! I’ve also grouped all the info on Nuxt’s prefixes, suffixes, and lazy loading into one spot to help you think methodically when you are structuring your Nuxt projects.

In Author’s Corner, we explore Ruby extensions to create a two-column TOC layout in Asciidoctor, inspired by Packt books.

Bonus items include a Floating Dock Menu in Vue with VueUse Motion and Pariksha.io’s fun flashcards on coding jargon!

Happy reading!

Nuxter’s Corner

As Nitro keeps evolving, it’s only getting stronger. Writing a chapter on Nitro, though, has been a bit overwhelming—juggling ideas and sometimes feeling torn between covering the essentials or diving deeper into what it can offer for full-stack Nuxt.

Some recipes I’m considering:

• Recipe 1: Build Serverless API Endpoints

• Recipe 2: Implement Custom Middleware

• Recipe 3: Deploy to Multiple Platforms

• Recipe 4: Edge Rendering

• Recipe 5: Data Fetching and Server-Side Rendering

• Recipe 6: Use WebSockets for Real-Time Communication

• Recipe 7: Handle File Uploads

For a fresh start, I chose Recipe 6: Adding WebSockets in Nuxt for real-time functionality. Despite being an experimental feature, the implementation was surprisingly smooth and so much fun!

Nuxt and WebSocket

We’re all familiar with Nitro’s `defineEventHandler`, but have you come across `defineWebSocketHandler`? I hadn’t either, and in my opinion, it’s a game-changer!

I’m still laying the groundwork with WebSockets in Nuxt and haven’t tackled databases or deployment just yet. For now, I’ve adapted an example from UnJs’s CrossWS library and customised it as a communication layer for a two-player (board) game.

After setting up the WebSocket example below, `XState` immediately came to mind—adding it could make for a great Game Engine example. It might just be the perfect addition to my book! How about two players can play this type of quiz, but in real-time?

Here’s an example I put together where Chrome and Firefox chat with each other in real-time. Feel free to clone the repo (link below) and experiment with the various WebSocket hooks to see how everything connects and functions.

• Check out the Github Repo of my experiment with Nuxt and WebSockets

• Read full article on how I integrated WebSockets in Nuxt 3 project: Real-Time with Nuxt 3: A Guide to WebSocket Integration

Suffixes, Prefixes and Nuxt Magic

I haven’t yet decided where this will fit into my book, but it’s essential to have a high-level understanding of the prefixes and suffixes available in Nuxt. While working with WebSockets, I coincidentally needed to create a client-only Vue component, making the topic of suffixes and prefixes especially relevant to my project. It was perfect timing for my use case!

So, I documented the impact of prefixes and suffixes in Nuxt, highlighting how strategic naming—like `.global`, `.server`, and `Lazy`—enhances functionality, improves performance, and optimises component behaviour for server-side and/or client-side rendering. This detailed breakdown illustrates the power of conventions in organising code, controlling loading processes, and handling middleware. For developers seeking to streamline and elevate their Nuxt projects, mastering these naming conventions offers both clarity and efficiency.

• Read full article: Suffixes, Prefixes, and Nuxt Magic

Author’s Corner

Custom Table Of Content

This little side project started when I was browsing through some of the Packt Publishing books. I loved how each section is neatly organised, which inspired me to explore how to achieve a similar style in my own book using Asciidoctor.

So, I took a deeper dive into using Asciidoctor with Ruby and the Prawn library to create professional, customised PDFs, focusing on designing a tailored Table of Contents (TOC). By leveraging Asciidoctor’s API and methods, like `convert_document`, I was able to structure TOCs with interactive links, a two-column layout, and dynamic page management. These techniques offer a polished PDF layout, ideal for projects needing a well-organised TOC and flexible content formatting.

• Read full article where I wrote about how I achieved the two-column TOC layout using custom Ruby extension for Asciidoctor: Building Professional PDFs with Asciidoctor: Advanced Techniques for TOCs and Layouts

• Check out the quick Ruby implementation Gist

Bonus

Floating Dock Menu with VueUse Motion

While browsing through the latest component libraries, I stumbled upon Aceternity UI. They had recently implemented a new Floating Dock component. Naturally, I had to try it with Vue!

My first instinct was to use GSAP to create that magnifying icons effect. Since Aceternity UI achieved their transitions with Framer Motion, I decided to go for a similar approach in Vue and picked VueUse Motion to recreate the effect.

• Check out the Github Repo of Floating Dock Menu

I haven’t mapped out my chapter on transitions yet, but exploring VueUse Motion has been a real eye-opener. Many developers might assume that animations and transitions are strictly client-side, so rendering them on the server might seem unnecessary. However, VueUse Motion offers both module and SSR support, making it a perfect fit for Nuxt projects because SSR (Server-Side Rendering) support for animations is essential in Nuxt for several reasons:

1. SEO Benefits: SSR ensures that content, including animations, is available for search engines, improving SEO by making animated elements fully crawlable.

2. Initial Load Experience: With SSR, animations can be pre-rendered, ensuring a smoother experience on the first load, especially on slower devices or networks.

3. Accessibility: By rendering transitions server-side, you maintain an accessible, static fallback for users with JavaScript disabled or limited browser capabilities.

Interactive Flashcards

I’ve been experimenting with ways to present listicle-style articles, and it hit me—pariksha.io, which started as a flashcard quiz platform, would be great for quick, informative flashcards too. You can read listicle-style content as interactive flashcards on pariksha.io!

• Learn about backstories of programming jargons that we (developers) use in our daily lives.

Thank you for joining me on this adventure, and I hope you find inspiration and enlightenment within these pages.

🚀 How You Can Participate:

• 📚 Read Along: Subscribe to the newsletter to receive updates, diagrams, and behind-the-scenes content.

• 🤝 Community Interaction: Share topic suggestions for the book, questions, and insights here on NuxtDojo Substack.

• 🚀 Spread the Word: Let others know about NuxtDojo – share on social media and among your developer circles.

Warm regards,
Krutie @ NuxtDojo 🚀📚

If we were to break down Nuxt’s features into broad categories, I’d say they mostly fall into two: Performance Optimisation and Developer Experience (DX).

In this edition of NuxtDojo, we'll dive into some performance-focused features like Nuxt aliases, auto-imports, different caching methods (both server-side and client-side), and even touch on Server Components. What ties all these features together is their ability to boost your app's performance in one way or another. Whether it's trimming down the bundle size, cutting out unnecessary JavaScript, or speeding up page loads, Nuxt has your back!

So, let’s dive in.

Nuxter’s Corner

1️⃣ Nuxt Aliases and Auto-Imports

Managing imports in Nuxt can greatly affect the structure, performance, and maintainability of your application. Nuxt offers several features, such as auto-imports, aliases, and manual imports, to help streamline and optimise the way imports are handled.

Here are the key concepts in managing imports in Nuxt:

• Aliases: Aliases allow you to define shorthand paths to directories or files, reducing the use of long relative paths in your imports.

• Auto-Imports: Nuxt can automatically import commonly used utilities, components, and composables, reducing the need for manual import statements.

• Manual Imports: Despite the convenience of auto-imports, manual imports are sometimes preferred for better control over code bundling and performance.

• Third-Party Package Imports: Nuxt can automatically or manually import utilities from third-party libraries, streamlining external dependencies management.

To scope out these topics for my Nuxt book, I have written these two articles detailing types of aliases, and ways to use auto-imports in Nuxt.

1. Understanding Aliases in Nuxt: A Detailed Breakdown

2. Understanding Auto-Imports in Nuxt

By combining auto-imports, aliases, and manual imports, you can strike the right balance between convenience and control, leading to a clean, performant, and scalable Nuxt application.

2️⃣ Caching Strategies in Nuxt.js

Caching is an essential aspect of optimising performance in Nuxt.js applications. Both server-side and client-side caching mechanisms are available in Nuxt, and they can be used in combination to significantly improve load times, reduce server load, and enhance the overall user experience.

While diving into the Nuxt documentation to explore caching strategies, I learned that there was a lot more to it than I initially expected. What started out as a single article ended up splitting into two—one focused on server-side caching and the other on client-side caching. The really cool part is that these two approaches aren’t mutually exclusive; in fact, they complement each other beautifully.

3. Server-Side Caching Strategies in Nuxt

4. Optimise API Caching: Balancing RouteRules with CacheEventHandler

5. Client-side Caching Strategies in Nuxt.js

By combining these server-side and client-side caching strategies, you can significantly improve the performance of your Nuxt.js applications.

As I worked through to explore different approaches to caching, it got me thinking about how I should structure the chapters of my book. For certain features or concepts, like types of Nuxt Routes or Layouts, project-based chapters make sense, as they allow readers to follow along step-by-step and see the feature in action within the context of a full project.

On the other hand, for topics that are more about exploring multiple techniques or options, like caching, a listicle or recipe-style format might be more appropriate, because it is impossible to include all caching techniques into a single project-based chapter. I am thinking these recipe-style chapters could be bite-sized and offer actionable solutions for common problems, making it easier for readers to pick and choose strategies depending on their needs.

3️⃣ Server Components in Nuxt.js

When I started writing this book, a lot of Nuxt features felt fresh—like that 'just released in Nuxt 3' kind of new. But now, those features have become part of my everyday Nuxt projects, except for Server Components. Due to time constraints, I used the popular markdown component as an example to show how they work.

6. Server Components in Nuxt.js

Yet, I still find myself searching for more situations where Server Components truly stand out. So, I did what anyone would do in my place these days. I asked ChatGPT, and it gave me some interesting ideas that I think I will explore next and see how I go.

• Generating graphs or charts using libraries that are heavy or not suitable for client-side rendering.

• Incorporating legacy code or libraries that aren't compatible with client-side rendering.

• Creating PDFs on the server for reports, invoices, or other documents.

• Generating email templates that need to be sent directly from the server.

• Implementing feature flags or A/B testing on the server side allows for dynamic rendering without client-side logic. (This could be super interesting to implement!)

If these chapter ideas have piqued your interest and left you eager for more, I invite you to subscribe to NuxtDojo newsletter. By subscribing, you'll gain access to exclusive updates about the progress of my book, as well as the opportunity to be among the first to receive the early release of each chapter.

Subscribe now

Author’s Corner

It's been a while since I last updated my Asciidoctor project. One thing I love about working with Asciidoctor is that when you're deep in writing mode, it feels just like writing in Markdown—you almost forget you're working in an Asciidoctor project at all.

For the future edition, I'm planning to share a starter Asciidoctor project template, so anyone can clone it and jump right into writing technical books without any hassle. With that idea in mind, I quickly found myself diving back into book themes and Ruby again!

Here’s how you can customise the default page layout using the basic Ruby extension.

Ruby Script to customise the page layout

To customise the page layout for title pages, part-title, and chapter-title in Asciidoctor PDF using a Ruby script, you will extend the functionality of Asciidoctor PDF. Asciidoctor PDF allows limited customisation through themes, but for more complex layout modifications, you can write a custom Ruby extension.

Step-by-Step Guide: Here’s how you can build a custom Ruby script to customise the layout of specific page elements like the title page, part-title, and chapter-title.

• Step 1: Install Required Gems
  Make sure you have Asciidoctor PDF installed by running:

  gem install asciidoctor-pdf

• Step 2: Create a Ruby Extension

  This script will modify how the title page, part-title, and chapter-title are rendered. Save this Ruby script as custom_page_layout.rb.

  require 'asciidoctor-pdf'
  
  class CustomPdfConverter < Asciidoctor::PDF::Converter
    register_for 'pdf'
  
    # Customise the title page layout
    def layout_title_page(doc)
      start_new_page
      font 'Helvetica', size: 48, style: :bold
      # ... 
    end
  
    # Customise the part-title layout
    def layout_part_title(part)
      start_new_page
      font 'Helvetica', size: 36, style: :bold
      text part.title, align: :center, valign: :center
      # ...
    end
  
    # Customise the chapter-title layout
    def layout_chapter_title(chapter, opts = {})
      # Start new chapter page
      # ...
    end
  end

• Step 3: Use the Custom Ruby Script

  Once you have saved the script, you can pass it to the `asciidoctor-pdf` command to generate the PDF with custom page layouts. Run the following command:

  asciidoctor-pdf -r ./custom_page_layout.rb my_document.adoc

This custom Ruby script modifies the page layout for title pages, part-title, and chapter-title in Asciidoctor PDF. You can tweak the design to fit your needs, such as adding logos, custom fonts, or different page orientations. The combination of a Ruby script and an Asciidoctor PDF theme gives you comprehensive control over the document layout.

Keep an eye on my future newsletter to get the Github Repo of the Asciidoctor starter project.

Thank you for joining me on this adventure, and I hope you find inspiration and enlightenment within these pages.

🚀 How You Can Participate:

• 📚 Read Along: Subscribe to the newsletter to receive updates, diagrams, and behind-the-scenes content.

• 🤝 Community Interaction: Share topic suggestions for the book, questions, and insights here on NuxtDojo Substack.

• 🚀 Spread the Word: Let others know about NuxtDojo – share on social media and among your developer circles.

Warm regards,
Krutie @ NuxtDojo 🚀📚

It’s been a while since my last update. I've been reading several books by other authors in the JavaScript community, and a few side projects have popped up while my Nuxt book project continues to progress slowly but surely in the background.

For the Nuxt book, I've been developing ideas for the Vue Components and Authentication chapters, and I'm also exploring other book authoring software in addition to AsciiDoc.

So, let’s dive in. Happy reading!

Nuxter’s Corner

Vue side of Nuxt

Vue components are the backbone of Nuxt applications, so I'm planning to draft a chapter that takes a deep dive into everything related to Vue components.

We'll explore:

• Single File Components

• Render Function Components

• And two additional Vue component design patterns to enhance the performance of Vue/Nuxt applications:

  • Functional Components

  • Renderless (aka Headless) Components

This chapter will provide a comprehensive look at these essential building blocks of Vue and Nuxt development.

The key idea here is to take a single Vue component and re-create it using the various design patterns available in Vue.js. You can visit this landing page to get a clearer view of the bigger picture, showcasing all the different variants of the same Numeric Input component in one place, along with their respective articles for further learning.

Additionally, feel free to explore the GitHub repository where I am extending these components into my blog as a Nuxt Layer.

I see this chapter as a smooth transition into the Nuxt side of Vue, where Vue components are taken to the next level. In Nuxt, we have page components that drive the file-based routing system, and now we can even separate server and client components. And that's not even touching on dynamic and async components in Vue.js. It only makes sense to thoroughly understand everything about Vue components when we talk about Nuxt.

While writing this guide on Vue components, I've come up with a lot of ideas that I haven't been able to include just yet, but I believe they could be super useful. These could include sections like:

• Vue Components Gotchas: covering potential pitfalls with each design pattern

• Vue Components Best Practices

• How to debug Vue components in Nuxt using Nuxt DevTools, and more.

The more I think about these topics, the more I can see this turning into a mini-book of its own. However, I’ll wait to see how the final version of the chapter shapes up before deciding whether to go down that route.

Firebase Authentication as a Nuxt Layer

I've been exploring different use cases for Nuxt Layers with the goal of reusing them across multiple Nuxt projects. Beyond the obvious UI and data layers, the authentication layer is another key area that could be reused without modification in various Nuxt projects. For authentication, there's the nuxt-auth-utils library created by Atinux, which works well but requires your Nuxt app to be server-rendered.

In one of my personal projects, I decided to test how Firebase performs as an authentication solution. Interestingly, it turns out that you can implement Firebase authentication with Nuxt entirely on the client-side, offering a flexible alternative to traditional server-rendered approaches.

I’ve documented my approach in a concept diagram that illustrates the structure of the Nuxt Firebase Layer, which includes plugins, pages, composables, and components. While Nuxt Layers don’t currently support named route middleware, you can still implement inline middleware on Nuxt pages within the layer.

At the moment, I have this Firebase Auth layer set up as a local layer, so I’m unable to share it with you all just yet. My initial plan was to create a GitHub Repo layer that anyone could use. Stay tuned for future updates on this project!

If you're interested in learning more about architecting your Nuxt applications using Nuxt Layers, you might want to check out an article I wrote a while ago: "Nuxt Layers Unwrapped."

Author’s Corner

Michael Thiessen’s book

Michael's book, "Nuxt Tips Collection," is packed with a treasure trove of tips and tricks that might otherwise be overlooked in the Nuxt documentation. Despite using Nuxt for over 6 years, I discovered new insights in this book that I had no idea of.

The book is an easy read, one that you can likely finish in a single sitting. However, it's also the kind of resource you'll find yourself returning to repeatedly when working on Nuxt projects, making it an invaluable companion for both new and experienced developers.

In this tweeter thread, Michael gives a sneak peek into his book, sharing a glimpse of content you'll find in this book.

Markus Oberlehner’s book

Markus wrote a book on writing tests for Vue applications, and in this tweet, he shares his journey of creating it. What I really like about his book is its focus on a single, niche topic - testing - allowing readers to dive deep and master one aspect thoroughly. It reminds me of a similar book written by Lachlan Miller about a test driven approach to maintainable applications. This kind of focused exploration can be super useful to truly understanding a framework.

While it's a bit late for me to shift the trajectory of my current book project, writing my Vue components guide has made me realise the value of honing in on one specific area of a framework. If you're interested, here’s the link to Markus’s book—it’s definitely worth checking out.

WriteBook

The team at 37Signals has just launched a brand new software called WriteBook, designed for writing and instantly publishing your own books on the web for free, without the need for a traditional publisher.

I've been eagerly following this project through their newsletter and was excited to see it finally come to life. Despite missing the traditional book feel of AsciiDoc, WriteBook is straightforward and easy to use once you have purchased and hosted (yes, hosted as in on DigitalOcean or Hetzner) your free copy of the software.

Thank you for joining me on this adventure, and I hope you find inspiration and enlightenment within these pages.

🚀 How You Can Participate:

• 📚 Read Along: Subscribe to the newsletter to receive updates, diagrams, and behind-the-scenes content.

• 🤝 Community Interaction: Share topic suggestions for the book, questions, and insights here on NuxtDojo Substack.

• 🚀 Spread the Word: Let others know about NuxtDojo – share on social media and among your developer circles.

Warm regards,
Krutie @ NuxtDojo 🚀📚

A heartfelt thank you to everyone who joined NuxtDojo since my last newsletter! Your support is invaluable to my book-writing journey. 🙏

It's been a while since I provided updates on my book. I've been busy writing and working on a side project that I'll share in this edition. In the Author's Corner, I've recommended a couple of great reads about writing and the use of AI in writing.

Happy reading!

Nuxter’s Corner

Personal blogs are the ultimate middle child of the digital world, striking that perfect balance between performant landing pages and content-heavy CMS like applications.

While designing an exploratory chapter on Why Nuxt Js is perfect framework for your next landing page? for my Nuxt book, I took a little detour. I went on a little decluttering spree on my personal website.

It was time! Nuxt 4 is already on the horizon and my personal website has been pending an upgrade from Nuxt 2 for a while now. It felt like a big chunk of work because I was using way too many plugins and libraries. Here’s how my old website looked 👇 before I revamped it over the past few weeks.

It started as an example project for my book chapter. One feature led to another, and suddenly I had a new repository for the second version of my blog.

In this article From Nuxt 2 to Nuxt 3: Enhancing Performance and Flexibility I wrote about the nitty-gritty of the little things I implemented in my blog 👆.

Working on this side project actually shed a lot of light on several aspects of my book chapter. Landing pages aren’t exclusive to digital products. They are essential for a wide variety of offerings. Even individuals like you and me can benefit from landing pages to effectively promote ourselves.

Although creating landing pages might seem like a smaller project compared to developing full-blown, data-heavy dynamic applications, they can actually become quite intricate as we dive deeper into their complexities. Each landing page requires meticulous attention to detail where each element is strategically designed to optimise user engagement and conversion rates. The best landing pages seamlessly integrate with the product experience that creates a cohesive user journey.

For example, think of a landing page for an online car finance application where the first step of the multi-step form is embedded directly on the homepage. In dynamic landing pages such as this, the design approach needs to maintain user identity and even authentication from the start. This effectively blurs the lines between the landing page and the application process. By doing so, it provides a smooth transition and consistent experience that enhance user engagement and reduce friction in the conversion process - which all are the key deliverables of any landing page project.

From frontend development perspective, landing page projects can be divided into 1) Interactive Elements, 2) Responsive Design, 3) Accessibility, 4) SEO Best Practices and 5) Performance Optimisation. My book will cover the first three parts into Nuxt Layers chapters, as I will use Nuxt Layers to abstract away the UI library that is reusable across multiple Nuxt projects, while the remaining two parts - SEO & Performance - is what I want to cover in this chapter followed by rendering modes and deployment.

From SEO optimisation to mobile responsiveness to performance, accessibility and best practices, the creation of a landing page involves many factors proving that even the most straightforward projects like Landing Pages, can demand a significant level of expertise and creativity. That’s why I want my chapter on creating landing pages to be wholesome and packed with insights and actionable tips.

While I write my chapter, below are some SEO tips you can implement right now for your public facing Nuxt project and improve the Lighthouse score in minutes.

In Nuxt 3, useHead composable allows you to manage the meta tags and attributes of your web pages dynamically. It's crucial for enhancing SEO by enabling precise control over the document head. useHead comes packaged with Nuxt 3. However, you can use Nuxt modules to help take your landing page to the next level.

Google Analytics - The Nuxt GTM module integrates Google Tag Manager into your Nuxt 3 application, enabling efficient management and deployment of Google Analytics and other marketing tags without modifying your Nuxt codebase.

Nuxt Image - Nuxt Image optimises images for performance and SEO by providing lazy loading, responsive images, and automatic format selection. This ensures your Nuxt website loads faster and ranks better in search engine results.

Sitemap - The Nuxt Sitemap module helps you generate a sitemap for your Nuxt 3 website, making it easier for search engines to index your pages and improving your website's SEO.

Open Graph Images - The Nuxt OG Image module allows you to generate dynamic Open Graph images for your Nuxt 3 application, enhancing how your content appears when shared on social media platforms.

Structured Data - The Nuxt Schema Org module helps you insert structured data into your Nuxt 3 website, improving search engine understanding and visibility of your content by providing context through schema markup.

robots.txt - The Nuxt Robots module lets you easily manage your robots.txt file in a Nuxt 3 application, controlling how search engines crawl and index your website.

Google Fonts - The Nuxt Google Fonts module simplifies integrating Google Fonts into your Nuxt 3 project, allowing easy configuration of prefetch, pre-connect, and preload attributes to enhance performance.

Complete Suite of SEO Modules - The Nuxt SEO module bundles a comprehensive suite of SEO tools for Nuxt 3, including meta tags management, sitemaps, structured data, and more, ensuring robust SEO capabilities for your application.

Nuxt 3 modules listed above will help you optimise your website’s images and overall performance, leading to faster load times and better visibility on search engines. Modules for sitemaps, structured data, and robots.txt improve SEO by enhancing search engine indexing and making sure search engines understand your content better. Collectively, these enhancements will ensure higher Lighthouse scores in performance, SEO, and best practices as well.

Author’s Corner

When I sit down to write a chapter, an article or a documentation for a project, I get my best ideas for new contents and side projects! I even get more clarity to explain difficult concepts better. The article Cultures of writing captures exactly how I feel. This article explores how writing culture at workplaces can foster creativity, discipline, and high-quality output. This article outlines how New York Times, Dropbox and Anthropic uses writing to drive innovations and engagement.

I have been thinking a lot about the best way to use AI to speed up the writing process. ChatGPT is great at aggregating information but the resulting content does not sound like me. It just doesn’t feel true to myself. The article "Future-proof Tech Blogging: Understanding AI's Core Traits" discusses the impact of AI on tech blogging and how AI should enhance rather than replace human creativity. To stay relevant, tech writers should focus on creating unique, insightful content, leveraging personal experiences, and engaging narratives. The article also highlights the importance of quality over quantity, as AI-generated content raises the bar for human writers to produce more valuable and engaging content.

Before I finish, here’s the latest Gameboy Card 👇 from my Tailwind UI Cards project. I wrote a little about this Codepen project in my last newsletter. Check out the Gameboy Card Codepen here.

Thank you for joining me on this adventure, and I hope you find inspiration and enlightenment within these pages.

🚀 How You Can Participate:

• 📚 Read Along: Subscribe to the newsletter to receive updates, diagrams, and behind-the-scenes content.

• 🤝 Community Interaction: Share topic suggestions for the book, questions, and insights here on NuxtDojo Substack.

• 🚀 Spread the Word: Let others know about NuxtDojo – share on social media and among your developer circles.

Warm regards,
Krutie @ NuxtDojo 🚀📚

In our last newsletter, we looked at Nuxt Routes. We wrapped up with a sneak peek at all those cool built-in components provided by Nuxt.

<NuxtLoadingIndicator/> is one the built-in component provided by Nuxt. So, in our Nuxt Fundamentals segment today, we're diving into the basics of Loading Indicators, exploring their design principles, and showing you how to build a custom one for your Nuxt project.

Happy reading!

Nuxter’s Corner

Let’s set Nuxt aside for a moment, zoom out and look at Loading Indicators from a broader frontend perspective. Loading indicators serve as a bridge of communication between the application and its users during times of waiting, be it for data to load, content to be fetched, or transactions to be processed. Their presence, or lack thereof, can drastically affect the user experience, potentially turning moments of waiting into a frustrating pause of inactivity.

Check out the diagram below. It shows you all the different loading indicators you can use in your web application, when to use them, and high-level implementation details to make them tick.

Loading indicators come in various forms, each suited to different scenarios and user expectations. From the classic spinner that symbolises ongoing activity to progress bars that provide a visual cue of how much work has been completed. These indicators show how careful design meets with focusing on the user's needs.

• Spinner: It's best used in scenarios where the wait time is unpredictable or relatively short. The spinner, often represented as a circular animation that rotates infinitely, is the quintessential symbol of something "in the process."

• Progress Bar: They are most effective when the system can predict the time to completion with reasonable accuracy. Progress bars are linear indicators that fill up as a task progresses.

• Skeleton Component: Instead of showing a blank screen or a loading sign, skeleton screens give a preview of what's to come, which can psychologically make the wait feel shorter because users see evidence of work being done. Skeleton Components are a relatively modern approach compared to the spinner and progress bar. Skeleton components are placeholders that outline the basic structure of your content before it loads.

• Custom Animations: These are particularly effective for branding purposes, creating a memorable experience even in the wait times. Custom animations are unique, brand-specific loading indicators that can range from simple geometric transformations to complex scenes or characters that tell a story.

Each type of loading indicator serves a specific purpose and can influence the user experience in different ways. The choice of indicator should be driven by the:

• context of the wait time,

• expected duration, and

• overall design language of the application.

Returning our focus back to Nuxt, the framework offers a variety of methods to manage loading indicators, enriching the user experience during navigation and data retrieval.

For instance, when transitioning between pages, the <NuxtLoadingIndicator /> component comes into play that elegantly renders a progress bar and visually informs the user of the ongoing process.

<NuxtLoadingIndicator /> falls into the Progress Bar category of the loading indicator, since it predicts the estimated time to load the content of the page.

This component can be customised by overriding color, height, duration and throttle values. You can also provide custom calculation for how estimatedProgress is calculated. However, this is the extent of customisation you can perform on this built-in component.

Digging deeper into the implementation of <NuxtLoadingIndicator /> component, we can see that it uses useLoadingIndicator composable under the hood. useLoadingIndicator uses page:loading:start and page:loading:end hooks to update its state.

useLoadingIndicator composable accepts duration, throttle and estimatedProgress as props. You can calculate estimatedProgress using a similar calculation used in <NuxtLoadingIndicator /> component. In return, useLoadingIndicator provides us with:

• two variables: progress, isLoading and

• three methods: start(), finish() and clear().

const { progress, isLoading, start, finish, clear } = useLoadingIndicator({
   duration: props.duration,
   throttle: props.throttle,
   estimatedProgress: props.estimatedProgress
})

progress and isLoading variables are sufficient to create a custom loading indicator. You can show/hide your custom loading component using isLoading variable, and animate your HTML or SVG element using the progress value which changes from 0 to 100.

start() and finish() methods come in handy while designing and developing a custom loading component, as they let you start and finish the transition respectively, on demand with a click of a button. You can review a quick example of a custom loader example here on Stackblitz.

Break down this tiny example and you will see that we are using,

• <NuxtLink> component to switch between pages

• <NuxtPage> component to display page content

• useLoadingIndicator composable to create custom loader

• CSS transition to apply app wide page transition

• <Transition> component (from Vue) to add fade effect

Moreover, Nuxt extends its functionality to data fetching scenarios, including asynchronous operations, by returning a pending variable when you use useFetch or useAsyncData composable.

const { data, pending, error, refresh } = await useFetch('/api/modules')

const { data, pending, error, refresh } = await useAsyncData(
  'mountains',
  () => $fetch('https://api.nuxtjs.dev/mountains')
)

In the template section of your page or Vue component, you can check the value of the pending variable and render the skeleton component while the data is being loaded. If you are familiar with Nuxt UI, you can check out the <USkeleton> component which lets you show a placeholder skeleton while content is loading.

This versatile utility enables Nuxt developers to either display a spinner or a skeleton component, and help maintain a smooth and informative interaction as data loads.

Creating effective loading indicators involves more than just choosing between a spinner or a progress bar. We should be mindful of basic design principles while incorporating loading indicators in our web applications, such as:

Visibility: Loading indicators must be clearly visible without overwhelming the user interface.

Informative: An effective loading indicator provides users with information about what is happening behind the scenes. Whenever possible, it should offer more than just an indication that something is loading; it should convey progress or estimated wait times.

Minimalism: Loading indicators should not distract users from their primary objectives or clutter the interface. The design should be simple and clean that integrates seamlessly with the overall design language of the application.

Branding: Loading indicators offer a unique opportunity to reinforce brand identity, even in moments of waiting. Custom animations or brand-specific designs can turn a generic wait time into a branded experience. However, this should be balanced with the principles of visibility and minimalism to ensure that the branding effort does not compromise the indicator's functionality or the user experience.

I'm really putting in the work to push these contents past the usual tutorials, aiming for something that reads more like a deep-dive chapter. The goal? To boost your know-how in a way that goes beyond just frameworks. Master one, and you'll have the skills to tackle any of them.

Keeping that in mind, it's not just about the basics and design principles. I'm also keen on weaving in some best practices and a guide to making your loading indicators not only responsive but accessible too, for all kinds of web apps.

If the roadmap of my Nuxt book appeals to you and you're keen on the direction it's heading, I'd love to invite you to subscribe to the NuxtDojo newsletter. By subscribing, you'll gain access to exclusive updates about the progress of my book, as well as the opportunity to be among the first to receive the early release of each chapter.

Subscribe now

Designer’s Corner

What's your go-to move when work starts to feel like a bit of a drag and you're itching for a breather to reset your brain?

For me, when the whole Vue and React scene starts to get a bit too much, I like to kick it old school with some HTML and CSS. It's kind of like my chill pill. It does wonders for me, and by the time I circle back to the heavy stuff, I'm all refreshed and pumped to dive back in.

Alright, let me fill you in on this little project I've got going on Codepen, kind of a side-side hustle of mine. I've been keeping it super simple, sticking to just plain HTML and spicing things up with Tailwind CSS. It's my little sandbox where I get to play around, experiment, and just have some fun away from all the serious stuff.

I've got this plan to keep up with this small yet fulfilling routine: crafting cards on the side as I work on writing my Nuxt book. I'm curious to see how these two projects can inspire and energise each other. They could serve as practical examples or visual aids when I'm explaining concepts in the book. It's like having two creative paths that, while distinct, complement each other beautifully, making the journey of writing the book not just more informative but also more engaging.

Thank you for reading this far! I really hope you’ve found some inspiration and enlightenment within these pages.

🚀 How You Can Participate:

• 📚 Read Along: Subscribe to the newsletter to receive updates, diagrams, and behind-the-scenes content.

• 🤝 Community Interaction: Share topic suggestions for the book, questions, and insights here on NuxtDojo Substack.

• 🚀 Spread the Word: Let others know about NuxtDojo – share on social media and among your developer circles.

Warm regards,
Krutie @ NuxtDojo 🚀📚

Nuxt Routes may initially appear straightforward—simply create Vue files in the ~/pages directory, and the file-based routing system will automatically generate pages. However, as you delve deeper into the subject, Nuxt Routes becomes a more intricate and interesting topic to learn!

Let's dive into Nuxt Routes at Nuxter's Corner and take a brief look at my Lucidchart Dashboard over at the Author's Corner.

Happy reading!

Nuxter’s Corner

The Nuxt Routes chapter will be included in the Nuxt Fundamentals part of the book. Understanding the types of routes will help you organise your Nuxt 3 application effectively and handle various URL patterns efficiently.

Let's break down the different types of routes in Nuxt 3:

1. Index Route: Index route is represented by the index.vue file in the root of the ~/pages directory.

2. Static Routes: Static routes are straightforward routes that map directly to a single file. They are ideal for pages that don't need to fetch any data from an API or database.

3. Dynamic Routes: Dynamic routes allow you to match dynamic segments in the URL and pass them as parameters to your page components. They are defined in the file name with a pair of square brackets and name of the parameter, i.e. [slug].vue

4. Catch-all Routes: Catch-all routes are used to match any URL that hasn't been matched by other routes. They are defined by using three dots in the file name enclosed within a pair of square brackets, i.e. […slug].vue

5. Nested Routes: Nested routes allow you to create a hierarchy of routes by organising them into nested directories. In Nuxt, parent-child relationship between routes is indicated by a file and directory with the same name.

Nuxt 3 introduces a new feature that allows for a flexible mix of rendering methods across individual pages. This is made possible through the implementation of Route Rules, which can be specified within the Nuxt configuration settings.

Essentially, this feature grants developers the flexibility to define how each page should be rendered, whether it be server-side, statically, or via client-side rendering, on a case-by-case basis. The addition of Route Rules enhances the control over the rendering process, enabling a tailored approach to how content is delivered and displayed based on the specific needs of each page.

The diagram provided below offers a high-level overview of the available route types and the new route rules, illustrating how they interact and how they can be applied within a Nuxt 3 application to optimise performance and user experience.

Route middleware in Nuxt is a powerful feature that allows you to execute code before rendering a page or a group of pages (routes). This functionality is tightly integrated with Nuxt's routing system, providing a mechanism to perform tasks such as authentication checks, data prefetching, or conditionally redirecting users based on specific criteria before a route is fully resolved and its components are rendered. Middleware can be applied globally or to individual pages.

Nuxt provides a built-in collection of utility functions to be used with route middleware. These utilities are part of Nuxt's rich ecosystem, designed to simplify tasks, including navigation, manipulating layouts or even setting route middleware at build-time and more.

The diagram below illustrates some of the key utility functions provided by Nuxt that are particularly useful when working with route middleware along with where to use them and when (runtime or build-time) to use them.

And lastly, Nuxt 3 also comes equipped with a collection of essential Vue components that are available for immediate use right from the start. These components are automatically imported and ready to use on Nuxt pages.

In considering the content for my book, I am planning to use examples from e-commerce platforms or headless Content Management Systems (CMS) to explain the variety of route types and help you think in terms of Nuxt routes and surrounding features. These examples are well-suited for such a demonstration because they leverage the full spectrum of routing and rendering techniques available. E-commerce sites and headless CMS platforms often require a dynamic mix of server-side, client-side, and static rendering methods to efficiently handle the diverse needs of their web pages.

E-commerce platforms, for example, utilise server-side rendering for product pages to ensure SEO effectiveness and client-side rendering for user dashboards for a more interactive experience. Static rendering might be used for help pages or blog posts that do not often change. Similarly, headless CMS platforms need to serve content-rich pages that are SEO friendly, while also managing dynamic user interactions that benefit from client-side rendering.

Secondly, these platforms often require sophisticated access control mechanisms to differentiate between various user roles—be it customers, content editors, or administrators. Route middleware becomes a critical tool in managing these distinctions, ensuring that users only access the content and functionalities relevant and permitted to their roles. This middleware can help us enforce authentication, authorise specific actions, and redirect users based on their login status or permissions, which shows the necessity of middleware in routing and power of Nuxt 3 in handling complex web development scenarios.

By using these examples, I aim to provide a practical context that illustrates how different types of routes can be used to address specific requirements of web applications. This way, I hope my chapter will look less like documentation and more relatable to real-world scenarios.

Author’s Corner

Concept diagrams are visual treats among technicalities - your reference points or gateway to more abstract technical concepts that might be difficult to convey with text alone. Ultimate goal of diagrams in my Nuxt book will be to facilitate deeper understanding of the Nuxt framework.

If you have been following my work for a while now, then you’d know that these diagrams can play a crucial role in breaking down complex concepts, making them more accessible and easier to understand for readers. Making these diagrams has become a major part of creating this Nuxt book. For those who don’t know, I use Lucidchart to make these diagrams. Here’s a little sneak peek of my Lucidchart dashboard.

I hope to incorporate engaging and aesthetically pleasing diagrams throughout the book to make the technical journey through Nuxt much more enjoyable and effective.

You can find more Nuxt diagrams like these on my website, and if you're interested in making diagrams like these on your own, take a look at the resources I've written on Medium:

• How to Create Technical Conceptual Diagrams - Read on Medium

• Conceptual Technical Diagrams: How to Think in Terms of Shapes, Icons, and Legend - Read on Medium

Thank you for joining me on this adventure, and I hope you find inspiration and enlightenment within these pages.

🚀 How You Can Participate:

• 📚 Read Along: Subscribe to the newsletter to receive updates, diagrams, and behind-the-scenes content.

• 🤝 Community Interaction: Share topic suggestions for the book, questions, and insights here on NuxtDojo Substack.

• 🚀 Spread the Word: Let others know about NuxtDojo – share on social media and among your developer circles.

Warm regards,
Krutie @ NuxtDojo 🚀📚

In this edition, I want to share some ideas I have on the Error Handling chapter of my book. In the ever-evolving landscape of SSR frameworks like Nuxt, error handling transcends the basic six types provided by JavaScript, extending them further so that they align with the unique needs and philosophies of the Nuxt framework.

In the Author's corner, I'll share insights on leveraging Asciidoctor—a powerful tool for organising and structuring long-form content—to divide the book into cohesive parts, each housing chapters thoughtfully grouped together to provide a seamless and comprehensive learning experience.

Happy reading!

Nuxter’s Corner

The Error Handling chapter will be included in the Nuxt Fundamentals part of the book. Given the full-stack nature of Nuxt, this topic will flow from server-side errors to client-side errors. Nuxt provides powerful utilities to tackle an array of potential errors from HTTP errors (4xx, 5xx), data fetching errors, authentication errors to server-side errors originating from the Nitro server.

At the center of Error Handling in Nuxt, we have in-built createError and showError utilities that work on both client-side and server-side.

Basic idea is that we show or create errors using these utilities, then we either redirect users on full-screen, custom error page or display specific error information on the same page while providing a call-to-action for users to recover from the error. We can also catch these errors in either server-side or client-side hooks available to us in Nuxt and further report them in Error Reporting & Monitoring tools.

I have prepared this initial diagram to capture the error handling landscape in Nuxt.

Custom Error Page

Both createError and showError helps us return appropriate error responses to clients, including status codes, error messages, and error payloads.

When we throw an error using createError or showError utilities, we can send users on a custom, generic error page. And when Nuxt redirect users on a custom error page, we can use useError composable to flesh out error details on ~/error.vue.

And finally, we can use clearError utility to get the user unstuck from the error page and redirect them on a working page, for example a home page, i.e. clearError({ redirect: '/homepage' })

Error Handling on Server-side

We can throw Nitro server-side errors using the same createError utility that we can use on the client-side as well, and display the custom error page. On server-side, by default, createError redirects users to the custom error page - while on client-side, createError provides a bit more, fine-grained control over whether to redirect or not.

// server/route/test.ts

export default eventHandler((event) => {

  const id = getRouterParam(event, 'id')  
  if (!id)
    throw createError({ message: 'Invalid id', statusCode: 422 })
})

Error Handling on Client-side

There’ll be use cases when we do not want to redirect users over to a generic error page, and rather show them specific error messages on the client-side itself. That’s when we can leverage the in-built component <NuxtErrorBoundary> provided by Nuxt.

<NuxtErrorBoundary> component emits @error event for us to handle if needed, and also provides #error slot to access error details that we can use within the <NuxtErrorBoundary> component.

//~/pages/topics.vue 
//parent page catches errors from child-routes: ~/pages/topics/index.vue

<template>

  <NuxtErrorBoundary @error="logError">

    <template #error="{ error, clearError }">
      You can display the error locally here: {{ error }}
      <button @click="clearError">
        This will clear the error.
      </button>
    </template>

    <NuxtPage />

  </NuxtErrorBoundary>
</template>

In cases where we do want the redirection to happen even on the client-side, we can pass the fatal: true option while creating error and createError will behave exactly the same way as it does on the server-side. We do not need to use <NuxtErrorBoundary> in that case.

Data Fetching and Error Handling

Nuxt doesn’t have any hooks to catch errors while using useFetch or useAsyncData to fetch data. However, both of these composable returns { error } ref that we can check to see if an error has occurred.

In case the error ref comes truthy, we can fall back to showError or createError utilities to handle data fetching errors.

// ~/pages/items.vue

const { error } = await useAsyncData('home', () => queryContent('/items').findOne())

if (error) {
  throw createError({
     statusCode: 404,
     message: 'Content not found',
     fatal: true
  })
}

Error Handling in Route Middleware

Apart from above options, there is a slightly less known option to catch errors using abortNavigation(err) utility function.

This option works exclusively within Route Middleware.

When abortNavigation is used with an error string passed into it, it redirects users to the error page on every http request made to that page where this route-middleware is applied.

abortNavigation utility uses createError under the hood. This would mean that if needed, we can use createError or showError utility directly inside route middleware as well.

// ~/middleware/test.ts

export default defineNuxtRouteMiddleware((to, from) => {
  // ...
  
  if (!user.value.isAuthorized) {
    return abortNavigation('Insufficient permissions.')
  }
})

This was a high-level, broad outlook of error handling in Nuxt. In the book however, I see a bigger scope for this chapter and I am hoping to include:

• the importance of logging and monitoring in error handling,

• best practices for error logging and tracking client-side errors for debugging purposes,

• the significance of testing error scenarios to ensure robust error handling,

• strategies for writing unit tests, integration tests, and end-to-end tests to cover error cases,

• best practices and recommendations for effective error handling in full-stack applications and

• real-life examples and/or case-studies to illustrate concepts and techniques discussed in the chapter.

If the outline of this chapter has piqued your interest and left you eager for more, I invite you to subscribe to NuxtDojo newsletter. By subscribing, you'll gain access to exclusive updates about the progress of my book, as well as the opportunity to be among the first to receive the early release of each chapter.

Subscribe now

Author’s Corner

In the Author’s corner, we will see how to divide a book into parts. There are three steps to divide your book into parts using Asciidoctor. Make sure your .adoc document:

1. is set to :doctype: book,

2. has at at least one section with Heading 1

3. has a theme applied to it.

Content Structure

A part is designated by a level 0 section title indicated by single equal sign =, equivalent of Heading 1 in Markdown. Chapter title comes second in a hierarchy that is indicated by double equal sign ==. Asciidoctor will use this exact hierarchy to generate the table of content.

// index.adoc

= Nuxt Fundamentals

== Error Handling in Nuxt

image::images/error-handling-in-nuxt-v2.jpeg[]

Heading Font Style

Create a new .yml file in the theme folder, book-theme.yml where we will define the theme for our book.

Under the heading, we add h1 style that is applied to the Part headings, while the h2 styling is applied to the chapter headings.

// theme/book-theme.yml

heading:
  h1:
    align: center
    padding: [4in, 0, 2in, 0]
    font-size: 40
    font-color: #05995d
    font-weight: bold
    top: 45%
  h2:
    font-size: 28
    padding: [0.25in, 0, 0.5in, 0]
    font-color: #18171c

Base Paragraph and Page Style

We can assign margins for all the pages and paragraphs, as well as base font attributes for overall book fonts - excluding heading fonts.

// theme/book-theme.yml

prose_margin_top: 0
prose_margin_bottom: 14
page:
  margin: [1in, 1in, 1in, 1in]
base:
  font-size: 15
  font-color: #18171C
  font-style: normal
  line_height: 1.25

Title Page

In the same theme file, we can add title_page styling to format the second page of the book after the front cover page.

// theme/book-theme.yml

title_page:
  align: center
  title:
    font-size: 40
    font-color: #18171C
    font-style: black
    line_height: 1.5
    top: 45%

Update Book Settings

Since Parts can only be used when the document type is a book, make sure :doctype: book is set along with :sectnums: and :partnums:, so that Asciidoctor can automatically number the parts and chapters in our book.

Make sure to use :toc: key here to help Asciidoctor generate the table of content at the beginning of the book.

In case, you want to call book parts something else other than Part, you can use :part-signifier: key.

// index.adoc

= Nuxt Your Everyday Vue.js
Krutie Patel <doc@example.com>
:toc:
:description: Book description goes Here
:doctype: book
:front-cover-image: image:images/isometric-nuxt-101.jpg[fit=fill]
:sectnums:
:partnums:
// :part-signifier: Module

We have a basic theme file ready. Now finally, update your script to accept this theme file path - theme/book-theme.yml and run yarn pdf to generate the PDF file of your book.

{
  "name": "asciidoc-test",
  "version": "0.0.1",
  "main": "index.adoc",
  "scripts": {
    "pdf": "asciidoctor-pdf -a pdf-theme=book -a pdf-themesdir=theme/ index.adoc"
  }
}

Thank you for joining me on this adventure, and I hope you find inspiration and enlightenment within these pages.

🚀 How You Can Participate:

• 📚 Read Along: Subscribe to the newsletter to receive updates, diagrams, and behind-the-scenes content.

• 🤝 Community Interaction: Share topic suggestions for the book, questions, and insights here on NuxtDojo Substack.

• 🚀 Spread the Word: Let others know about NuxtDojo – share on social media and among your developer circles.

Warm regards,
Krutie @ NuxtDojo 🚀📚

A heartfelt thank you to everyone who joined NuxtDojo Substack last week! Your support fuels my book writing journey. 🙏

In this edition, I'm excited to share with you a sneak peek of a chapter I've been crafting: an in-depth exploration of the various Lifecycles in Nuxt.js. Get ready to dive deeper into the intricacies of Nuxt's lifecycle hooks and discover how they can enhance your Nuxt projects.

In the Author's Corner, we'll also embark on a brief journey into getting started with Asciidoctor. Whether you're a seasoned writer or just dipping your toes into the world of technical authoring, this guide will equip you with little extra information you might just need to express your ideas effectively.

Happy reading, and thank you for being a part of my journey.

Nuxter’s Corner

Lifecycle hooks have been one of my favourite topics ever since I picked up Vue.js back in 2017. So obviously, I am very excited to write this chapter in my book.

We never end up using all of the lifecycle hooks in a single project - ever! However, learning about them increases our understanding of the framework and teaches us how the framework was intended to be used. Whether we are writing Nuxt plugins or Nitro plugins, Nuxt modules or even Vue Composable in Nuxt - lifecycle hooks are everywhere if you look closely.

Lifecycle hooks provide insight into various stages of your Nuxt application - from setting up Nuxt configuration to creating, rendering and mounting the Nuxt app that leads us to access Nuxt page and Vue components. I can see three key reasons to learn lifecycle hooks in Nuxt.

• Understanding these lifecycle hooks helps us write more efficient and predictable code in our Nuxt application.

• Lifecycle hooks open up wide ranging possibilities to extend default Nuxt as it allows us to tap into specific stages of Nuxt application - either at runtime or build-time or on client-side or server-side.

• Understanding these lifecycles can be invaluable when debugging and troubleshooting your Nuxt application. By logging lifecycle hook events and understanding their sequence, we can pinpoint issues and identify potential solutions more effectively.

We have three sets of lifecycle hooks in the Nuxt framework - 1) Nuxt, 2) Nitro and 3) App - that we should learn about. Since Nuxt is built on top of Vue, we should be familiar with Vue Component Lifecycle and Vue Transition Lifecycle as well.

• Nuxt Lifecycle Hooks - allow us to extend Nuxt at build-time, and we can use them in Nuxt modules or a Nuxt Config file.

• App Lifecycle Hooks - allow us to manage the state of the Nuxt app and help us extend Nuxt at runtime, that we can do through Nuxt plugins. I have created this initial diagram to illustrate the App Lifecycle Hooks where you can see a high-level journey of app:*, vue:* and Nuxt page:* hooks.

• Nitro Lifecycle Hooks - allow us to tap into the runtime behaviour of the Nitro server where we can intercept request and response lifecycle including errors.

  

• Vue Lifecycle Hooks - provide insight into the various stages a Vue component goes through, from initialisation to destruction.

• Vue Transition Lifecycle

• Nuxt Page Lifecycle

This last one - Nuxt Page Lifecycle - is not an officially documented lifecycle as such. It is however, something I created to understand what happens when someone accesses a Nuxt page. Nuxt page lifecycle has evolved over time, and it was absolutely amazing to see how each new Nuxt version has brought new improvements each time. Here’s the very first version from the old days.

By understanding when (build-time or runtime) and where (client-side or server-side) certain tasks should be performed within the application, we can write more efficient, maintainable, and performant code, while also gaining valuable insights into the inner workings of Nuxt framework.

I see so many possibilities for this chapter that is filled with examples from real-world use cases. This chapter is likely to have critical teaching-points for the beginners as well. I will have similar diagrams as above for all Lifecycles mentioned here. Going forward, these diagrams will become reference points to dive deeper into other areas of Nuxt.

Author’s Corner

A talented tech writer is worth as much as a talented developer. Good prose is no more or less complex to write than good code. - Dan Allen

Dan Allen is the creator of Asciidoctor - an open source implementation of Asciidoc. Before I sat my heart on Asciidoctor, I did trial Google Docs, Notion, Scrivener and even Apple Pages. While they only partially fulfilled my requirements, Asciidoctor did everything I needed - pretty code blocks, markdown support, version control, multiple export file formats and more!

Unlike other tools I mentioned here, Asciidoc is not just a writing tool, it’s rather a tool for writing tech books. If you read its documentation, you will see lots of book related terminologies - such as recto, verso, abstract, colophon, index catalog, front matter, back matter, admonitions to name a few - that you may never see in a generic software. In case you are wondering, here’s a quick definition of each:

• Front Matter: The introductory section of a book that includes elements like the title page, copyright page, dedication, preface, and table of contents.

• Back Matter: The concluding section of a book that includes elements like the index, glossary, bibliography, appendices, and acknowledgments.

• Recto: The right-hand page of an open book with an odd-numbered page.

• Verso: The left-hand page of an open book with an even-numbered page.

• Abstract: A concise summary of a larger work that provides an overview of its key points and findings.

• Colophon: A section at the end of the book that contains information about the publication, such as the publisher's name, printer, and date of publication.

• Index Catalog: A comprehensive list of topics, names, or terms found within a book, typically arranged alphabetically and providing page references.

• Admonitions: Brief notes or warnings typically included in technical or instructional texts to provide guidance, clarification, or cautionary information to the reader.

Asciidoctor provides a straightforward and human-readable, markdown-like syntax while offering powerful features for writing technical content. Here's a step-by-step guide on how to use AsciiDoc for writing a technical book:

• Install AsciiDoc on your Mac:

  Refer to the official AsciiDoctor website for installation instructions: AsciiDoctor Installation.

  $ brew install asciidoctor

• Basic Document Structure:

  Start your .adoc document in your favourite Code Editor with a title, author information, and other key metadata, such as :doctype: book - this is required when we want to generate a book. You can have a separate .adoc file for each of your book chapters, and then include them in your index.adoc file using include:: key. Here's a simple example:

  // index.adoc
  
  = Title of Your Book
  Author Name
  :doctype: book
  :lang: en
  
  include::chapter-1.adoc
  include::chapter-2.adoc

• Include front and back cover:

  Use the `image` directive to include images:

  // index.adoc
  :doctype: book
  // ...
  
  :front-cover-image: image:images/cover-front.jpg[fit=fill]
  :back-cover-image: image:images/cover-front.jpg[fit=fill]

• Sections and Chapters:

  Organise your content into sections and chapters using headings. For example:

  // chapter-1.adoc
  
  == Chapter 1: Introduction
  This is the content of the introduction.
  
  === Section 1.1: Overview
  This is an overview of the chapter.

• Code Blocks:

  Use code blocks for displaying code snippets:

  [source,js]
  ----
  export default {
    setup() {
      const count = ref(0)
      return { count }
    }
  }
  ----

• Generate PDF Output:

  Once your content is written, use the asciidoctor-pdf to generate the PDF output. You do not need to install any additional package to do this.

  
  Create a basic package.json in the root of your book project and add a script asciidoctor-pdf index.adoc to export the pdf file. Now, you can run yarn pdf from your terminal to export your book.

  // package.json
  {
  "name": "my-book",
  "version": "1.0.0",
  "main": "index.adoc",
  "scripts": {
    "pdf": "asciidoctor-pdf index.adoc"
   }
  }

  

• Review and Iterate:

  Review the generated output and iterate on your AsciiDoctor source as needed. Fine-tune formatting, fix errors, and enhance the content and most importantly now you can use a version control system to track changes and even collaborate with others.

By following these steps, you can leverage AsciiDoctor's simplicity and power to author a technical book with ease. We will see more intricate elements of the book authoring process in coming weeks.

🚀 How You Can Participate:

• 📚 Read Along: Subscribe to the newsletter to receive updates, diagrams, and behind-the-scenes content.

• 🤝 Community Interaction: Share topic suggestions for the book, questions, and insights here on NuxtDojo Substack.

• 🚀 Spread the Word: Let others know about NuxtDojo – share on social media and among your developer circles.

Warm regards,
Krutie @ NuxtDojo Publication 🚀📚

Nuxter’s Corner

I want this Nuxt book to be what I wish I had when I started off with Nuxt back in 2017 and hope to cover topics that Nuxt beginners may encounter on the job - in the real world. So, if you are thinking about topics such as Headless CMS, E-commerce and Authentication alike - then yes, this book might be for you.

At the same time, I want to include the fundamentals of Nuxt.js - where we learn Nuxt basics in regards to what happens during runtime and build-time vs client-side and server-side, auto-imports and aliases, Vue vs Nuxt, Nuxt and TypeScript, app config vs environment variables to name a few.

I published this 👇 diagram a while ago and it has been a guiding light for me when I am planning the Nuxt Fundamentals part of this book.

With this in mind, here’s the high-level parts of the book that I am pondering over these days:

• Nuxt Fundamentals

• Nuxt Customisation Touchpoints

• Backend Nuxt (Nitro)

• Frontend Development - Common Parts

• Nuxt By Examples

• Deploying Nuxt

I think the most challenging part of writing Nuxt basics has been to make sure it does not read like a documentation! This applies to the book’s Table of Contents (TOC) as well. While I author the topics that I am sure of, I am also spending some time trying out different TOC structures to get the feel for this book - to see if it maintains a reader-friendly flow - to see if it makes sense in case readers skipped a few chapters in-between - to see what value it’ll add to the whole project.

Overtime, I will plan and share the detailed content structure of each part. Doing this will keep me accountable to complete this project as well.

Author’s Corner

This project isn’t just about Nuxt - it’s a journey into the world of technical book writing and self-publishing as well. Self-publishing aspect of this project makes it all the more exciting. At least for me 🤷‍♀️

I have chosen ASCII Doctor as a tool of my choice to author this book. As I am navigating the landscape of writing a technical book, I am learning a lot - from formatting book parts, chapters, pages to creating front and back book covers. Here’s the sneak peek of the initial cover designs I am tinkering with in Affinity Design.

ASCII Doctor is an open-source, Ruby-based text processor that parses the markdown and converts the output into a book-like PDF format. So I am also learning a bit of Ruby basics to customise certain aspects of the book.

I am starting this newsletter with a hope to share all that I am learning and the process of authoring a technical book. I am using Nuxt.js as the canvas for my exploration, hope this inspires you to write your own one day! When I have tangible results to share, I will share behind-the-scenes stories about how I achieved specific book features using ASCII Doctor.

🚀 How You Can Participate:

• 📚 Read Along: Subscribe to the newsletter to receive updates, diagrams, and behind-the-scenes content.

• 🤝 Community Interaction: Share topic suggestions for the book, questions, and insights here on NuxtDojo Substack.

• 🚀 Spread the Word: Let others know about NuxtDojo – share on social media and among your developer circles.

  

  ---