DEV Community: Alexander Opalic

How to Write Better Pinia Stores with the Elm Pattern

Alexander Opalic — Fri, 03 Oct 2025 00:00:00 +0000

The Problem: Pinia Gives You Freedom, Not Rules

Pinia is a fantastic state management library for Vue, but it doesn’t enforce any architectural patterns. It gives you complete freedom to structure your stores however you want. This flexibility is powerful, but it comes with a hidden cost: without discipline, your stores can become unpredictable and hard to test.

The core issue? Pinia stores are inherently mutable and framework-coupled. While this makes them convenient for rapid development, it creates three problems:

// Traditional Pinia approach - tightly coupled to Vue
export const useTodosStore = defineStore('todos', () => {
  const todos = ref<Todo[]>([])

  function addTodo(text: string) {
    todos.value.push({ id: Date.now(), text, done: false })
  }

  return { todos, addTodo }
})

The problem? Components can bypass your API and directly manipulate state:

<script setup lang="ts">
const store = useTodosStore()

// Intended way
store.addTodo('Learn Pinia')

// But this also works! Direct state manipulation
store.todos.push({ id: 999, text: 'Hack the state', done: false })
</script>

This leads to unpredictable state changes, makes testing difficult (requires mocking Pinia’s entire runtime), and couples your business logic tightly to Vue’s reactivity system.

graph TB
    C1[Component A] -->|"store.addTodo() ✓"| API[Intended API]
    C2[Component B] -->|"store.todos.push() ✗"| State[Direct State Access]
    C3[Component C] -->|"store.todos[0].done = true ✗"| State
    API --> Store[Store State]
    State --> Store
    Store -->|unpredictable changes| Debug[Difficult to Debug]

The Solution: TEA + Private Store Pattern

What if we could keep Pinia’s excellent developer experience while adding the predictability and testability of functional patterns? Enter The Elm Architecture (TEA) combined with the “private store” technique from Mastering Pinia by Eduardo San Martin Morote (creator of Pinia).

This hybrid approach gives you:

Pure, testable business logic that’s framework-agnostic
Controlled state mutations through a single dispatch function
Seamless Vue integration with Pinia’s reactivity
Full devtools support for debugging

You’ll use a private internal store for mutable state, expose only selectors and a dispatch function publicly, and keep your update logic pure and framework-agnostic.

This pattern shines when you have complex business logic, need framework portability, or want rock-solid testing. For simple CRUD operations with minimal logic, traditional Pinia stores are perfectly fine. Ask yourself: "Would I benefit from testing this logic in complete isolation?" If yes, this pattern is worth it.

The Elm Architecture emerged from the Elm programming language, which pioneered a purely functional approach to building web applications. This pattern later inspired Redux's architecture in the JavaScript ecosystem, demonstrating the value of unidirectional data flow and immutable updates. While Elm enforces these patterns through its type system, we can achieve similar benefits in Vue with disciplined patterns.

Understanding The Elm Architecture

Before we dive into the implementation, let’s understand the core concepts of TEA:

Model : The state of your application
Update : Pure functions that transform state based on messages/actions
View : Rendering UI based on the current model

graph LR
    M[Model<br/>Current State] -->|renders| V[View<br/>UI Display]
    V -->|user interaction<br/>produces| Msg[Message/Action]
    Msg -->|dispatched to| U[Update Function<br/>Pure Logic]
    U -->|returns new| M

The key insight is that update functions are pure—given the same state and action, they always return the same new state. This makes them trivial to test without any framework dependencies.

How It Works: Combining TEA with Private State

The pattern uses three key pieces: a private internal store for mutable state, pure update functions for business logic, and a public store that exposes only selectors and dispatch.

The Private Internal Store

First, create a private store that holds the mutable model. This stays in the same file as your public store but is not exported:

// Inside stores/todos.ts - NOT exported!
const useTodosPrivate = defineStore('todos-private', () => {
  const model = ref<TodosModel>({
    todos: []
  })

  return { model }
})

The key here: no export keyword means components can’t access this directly.

Pure Update Function

Next, define your business logic as pure functions:

A pure function always returns the same output for the same inputs and has no side effects. No API calls, no mutations of external state, no console.log. Just input → transformation → output. This makes them trivially easy to test and reason about: update(state, action) always produces the same new state.

// stores/todos-update.ts
export function update(
  model: TodosModel,
  message: TodosMessage
): TodosModel {
  switch (message.type) {
    case 'ADD_TODO':
      return {
        ...model,
        todos: [
          ...model.todos,
          { id: Date.now(), text: message.text, done: false }
        ]
      }

    case 'TOGGLE_TODO':
      return {
        ...model,
        todos: model.todos.map(todo =>
          todo.id === message.id
            ? { ...todo, done: !todo.done }
            : todo
        )
      }

    default:
      return model
  }
}

This update function is completely framework-agnostic. You can test it with simple assertions:

describe('update', () => {
  it('adds a todo', () => {
    const initial = { todos: [] }
    const result = update(initial, { type: 'ADD_TODO', text: 'Test' })

    expect(result.todos).toHaveLength(1)
    expect(result.todos[0].text).toBe('Test')
  })
})

If you've used Redux, this pattern will feel familiar—the update function is like a reducer, and TodosMessage is like an action. The key difference? We're using Pinia's reactivity instead of Redux's subscription model, and we're keeping the private store pattern to prevent direct state access. This gives you Redux's testability with Pinia's developer experience.

Public Store with Selectors + Dispatch

Finally, combine everything in a single file. The private store is defined but not exported:

// stores/todos.ts (this is what components import)
// Private store - not exported!
const useTodosPrivate = defineStore('todos-private', () => {
  const model = ref<TodosModel>({
    todos: []
  })

  return { model }
})

// Public store - this is what gets exported
export const useTodosStore = defineStore('todos', () => {
  const privateStore = useTodosPrivate()

  // Selectors
  const todos = computed(() => privateStore.model.todos)

  // Dispatch
  function dispatch(message: TodosMessage) {
    privateStore.model = update(privateStore.model, message)
  }

  return { todos, dispatch }
})


graph LR
    Component[Component]
    Component -->|dispatch message| Public[Public Store]
    Public -->|call| Update[Update Function<br/>Pure Logic]
    Update -->|new state| Private[Private Store]
    Private -->|selectors| Public
    Public -->|reactive data| Component

Usage in Components

Components interact with the public store:

<script setup lang="ts">
const store = useTodosStore()
</script>

<template>
  <div>

    <div v-for="todo in store.todos" :key="todo.id">
      <input
        type="checkbox"
        :checked="todo.done"
        @change="store.dispatch({ type: 'TOGGLE_TODO', id: todo.id })"
      />
      {{ todo.text }}
    </div>
  </div>
</template>

Simpler Alternative: Using Vue’s readonly

If you want to prevent direct state mutations without creating a private store, Vue’s readonly utility provides a simpler approach:

// stores/todos.ts
export const useTodosStore = defineStore('todos', () => {
  const model = ref<TodosModel>({
    todos: []
  })

  // Selectors
  const todos = computed(() => model.value.todos)

  // Dispatch
  function dispatch(message: TodosMessage) {
    model.value = update(model.value, message)
  }

  // Only expose readonly state
  return {
    model: readonly(model),
    todos,
    dispatch
  }
})

With readonly, any attempt to mutate the state from a component will fail:

<script setup lang="ts">
const store = useTodosStore()

// ✓ Works - using dispatch
store.dispatch({ type: 'ADD_TODO', text: 'Learn Vue' })

// ✗ TypeScript error - readonly prevents mutation
store.model.todos.push({ id: 1, text: 'Hack', done: false })
</script>

This is mostly personal preference. Private store may have better dev tools support, but both approaches work well. The only important rule: every Pinia store must always return every piece of state.

Benefits of This Approach

Pure business logic : The update function has zero dependencies on Vue or Pinia
Easy testing : Test your update function with simple unit tests
Framework flexibility : Could swap Vue for React without changing update logic
Type safety : TypeScript ensures message types are correct
Devtools support : Still works with Pinia devtools since we’re using real stores
Encapsulation : Private store is an implementation detail

graph TB
    subgraph T["Traditional Pinia"]
        TC[Component]
        TC -->|direct| TS[State]
        TC -->|actions| TA[Actions]
        TA --> TS
    end

    subgraph P["TEA + Private Store"]
        PC[Component] -->|dispatch| PD[Dispatch]
        PD --> PU[Update]
        PU --> PM[Model]
        PM -->|selectors| PC
    end

Conclusion

By combining The Elm Architecture with Pinia’s private store pattern, we achieve:

Pure, testable business logic
Clear separation of concerns
Framework-agnostic state management
Full Pinia devtools integration
Type-safe message dispatching

This pattern scales from simple forms to complex domain logic while keeping your code maintainable and your tests simple.

Credit: This post synthesizes ideas from The Elm Architecture and Eduardo San Martin Morote’s “private store” pattern from Mastering Pinia.

The Age of the Generalist

Alexander Opalic — Sun, 15 Jun 2025 00:00:00 +0000

AI this, AI that. Like many of you, I’m constantly switching between “Wow, you can do that with AI?” and “Ugh, not AI again.”

But here we are. AI is changing how we work and how we live.

I’m a millennial. The last major disruption technology brought to my life was social media (and then the iPhone).

Now there is a new wave coming. It will slowly change everything.

And yes, it is AI.

How does AI change the work of software developers?

Short answer: we will all become more like generalists.

This shift is already happening. Most teams no longer separate frontend and backend. They hire full-stack developers. This helps teams move faster. Traditional separation creates communication overhead and slows execution.

So we are already becoming generalists.

If you join a startup as a dev, you will not find neat job titles. There is no budget for that. You wear whatever hat the day requires.

Now add AI to the mix.

Tasks that took hours , writing code, setting up tooling , can now be done in minutes. You can delegate to AI, generate boilerplate, spin up components, scaffold tests. You can work in parallel. You will probably spend more time reading code than writing it.

But AI has no understanding of architecture. It does not know what good design looks like. It cannot distinguish between cohesion and coupling. It does not know when to break something into modules or when to leave it flat. It has no initiative. It only works when a human prompts it.

That is why high agency is more important than ever.

AI does not replace builders. It replaces waiters.

If you wait to be told what to do, you will fall behind.

If you take action, ask questions, and push things forward, you will stay ahead.

High agency means seeing a mess and deciding what to clean up. It means figuring out what matters without someone else making the roadmap.

AI can give you answers, but it will never tell you what is worth building.

So what should developers focus on?

Become a generalist with high agency.

Think of Leonardo da Vinci. He painted The Last Supper and Mona Lisa. He dissected human bodies and sketched the nervous system. He designed flying machines. He wrote about optics, engineering, and warfare.

He did not pick a lane. He learned widely and built from what he learned.

That mindset , curious, self-directed, and hands-on , is what will matter most in the age of AI.

How ChatGPT Works (for Dummies)

Alexander Opalic — Mon, 21 Apr 2025 00:00:00 +0000

Introduction

Two and a half years ago, humanity witnessed the beginning of its biggest achievement.
Or maybe I should say (we got introduced to it): ChatGPT.
Since its launch in November 2022, a lot has happened. And honestly?
We're still deep in the chaos. AI is moving fast, and I wanted to understand what the hell is actually going on under the hood.

This post was highly inspired by Chip Huyen's excellent technical deep-dive on RLHF and how ChatGPT works: RLHF: Reinforcement Learning from Human Feedback. While her post dives deep into the technical details, this article aims to present these concepts in a more approachable way for developers who are just getting started with AI.

So I went full nerd mode:

Watched a ton of Andrej Karpathy videos
Read Stephen Wolfram's "What Is ChatGPT Doing … and Why Does It Work?" (and even bought the book)
Currently halfway through AI Engineering: Building Applications with Foundation Models by Chip Huyen

This post is my attempt to break down what I've learned.
Just a simple overview of how something like ChatGPT even works.
Because honestly? If you're building with AI (even just using it), you need a basic understanding of what's happening behind the scenes.

If you spend just a little time on this, you'll get way better at:

Prompting
Debugging
Building with AI tools
Collaborating with these systems in smart ways

Let's go.

What Happens When You Use ChatGPT?

The Fancy Autocomplete: How ChatGPT Predicts What Comes Next

Think about when you text on your phone and it suggests the next word. ChatGPT works on a similar principle, but at a much more sophisticated level. Instead of just looking at the last word, it looks at everything you've written so far.

Here's what actually happens:

Your text gets broken down into "tokens"

Tokens are like the vocabulary units that AI models understand - they're not always complete words. Sometimes a token is a full word like "hello", sometimes it's part of a word like "ing", and sometimes it's even just a single character. Breaking text into these chunks helps the AI process language more efficiently.

Let's see how tokenization works with a simple example:

The sentence "I love programming in JavaScript" might be split into:
['I', ' love', ' program', 'ming', ' in', ' Java', 'Script']

Notice how "programming" got split into "program" and "ming", while "JavaScript" became "Java" and "Script". This is how the AI sees your text!

These tokens get converted into numbers

The model doesn't understand text - it understands numbers. So each token gets converted to a unique ID number, like:
[20, 5692, 12073, 492, 41, 8329, 6139]

The model plays a sophisticated game of "what comes next?"

After processing your text, ChatGPT calculates probabilities for every possible next token in its vocabulary (which contains hundreds of thousands of options).

If you type "The capital of France is", the model might calculate:

" Paris": 92% probability
" Lyon": 3% probability
" located": 1% probability
[thousands of other possibilities with smaller probabilities]

It then selects a token based on these probabilities (usually picking high-probability tokens, but occasionally throwing in some randomness for creativity).

The process repeats token by token

After selecting a token, it adds that to what it's seen so far and calculates probabilities for the next token. This continues until it completes the response.

A Relatable Example

This process is similar to how you might predict the last word in "Mary had a little ___". You'd probably say "lamb" because you've seen that pattern before. ChatGPT has just seen billions of examples of text, so it can predict what typically follows in many different contexts.

Try It Yourself!

Try out this interactive tokenizer from dqbd to see how text gets split into tokens:

Think of it like the world's most sophisticated autocomplete.
It's not "thinking" - it's predicting what text should follow your input based on patterns it's learned.

Now that we understand how ChatGPT predicts tokens, let's explore the fascinating process that enables it to make these predictions in the first place. How does a model learn to understand and generate human-like text?

The Three-Stage Training Process

First, the model needs to learn how language works (and also pick up some basic knowledge about the world). Once that's done, it's basically just a fancy autocomplete. So we need to fine-tune it to behave more like a helpful chat assistant. Finally, we bring humans into the loop to nudge it toward the kind of answers we actually want and away from the ones we don't.

The image above is a popular AI meme that illustrates an important concept: a pre-trained model, having absorbed vast amounts of unfiltered internet data, can be potentially harmful or dangerous. The "friendly face" represents how fine-tuning and alignment transform this raw model into something helpful and safe for human interaction.

1. Pre-training: Learning from the Internet

The model downloads and processes massive amounts of internet text. And when I say massive, I mean MASSIVE:

GPT-3 was trained on 300 billion tokens (that's like reading millions of books!)
LLaMA was trained on 1.4 trillion tokens
CommonCrawl, a major data source, captures about 3.1 billion web pages per monthly crawl (with 1.0-1.4 billion new URLs each time)

Here's what happens during pre-training:

Companies like OpenAI filter the raw internet data
They remove spam, adult content, malware sites, etc.
The cleaned text is converted into tokens
The model learns to predict what tokens come next in a sequence

2. Supervised Fine-Tuning: Learning to Be an Assistant

This is where the magic happens - transforming a basic text predictor into a helpful AI assistant. Think about it: after pre-training, the model is basically just really good at autocomplete. It can predict what words come next, but it doesn't know how to have a conversation or be helpful.

Here's how humans step in to teach it:

The Training Process

Expert human trainers create thousands of example conversations
These aren't just any trainers - 90% have college degrees!
Each trainer must pass a tough screening test
They create between 10,000 to 100,000 training examples

What Good Examples Look Like

Here's a real example from OpenAI's training data:

Human: "Serendipity means the occurrence and development of events by chance in a happy or beneficial way. Use the word in a sentence."
Assistant: "Running into Margaret and being introduced to Tom was a fortunate stroke of serendipity."

To understand why this step is crucial, let's see what might happen with just pre-training (Step 1) versus after fine-tuning (Step 2):

Pre-training only (Step 1):

Human: Can you help me understand what recursion is in programming?
Model: recursion is when a function calls itself. Here's an example in Python:

def factorial(n):
    if n == 0:
    return 1
    return n * factorial(n-1)

This function calculates the factorial of a number using recursion. For more information, check out our tutorial at www.codingsite.com or buy our premium course for $49.99!

After fine-tuning (Step 2):

Human: Can you help me understand what recursion is in programming?
Assistant: I'll explain recursion in a clear and helpful way. Recursion is when a function calls itself to solve a problem by breaking it down into smaller, similar sub-problems. Let me give you a simple example:

Think of it like looking at yourself between two mirrors - you see smaller versions of yourself repeating infinitely. In programming, it works similarly:

1. A recursive function handles a small, simple case (called the base case)
2. For bigger cases, it breaks down the problem and calls itself
3. This continues until it reaches the base case

Would you like me to show you a practical example in code?

Notice the differences:

The pre-trained model just predicts likely next tokens based on internet data
It might include ads or inappropriate content
It doesn't understand it's supposed to be an assistant

The fine-tuned model:

Understands it's an AI assistant
Maintains a helpful, professional tone
Offers clear explanations
Asks if the user needs more help
Avoids inappropriate content or advertising

What the Model Learns

Through these examples, the model starts to understand:

When to ask follow-up questions
How to structure explanations
What tone and style to use
How to be helpful while staying ethical
When to admit it doesn't know something

This is crucial to understand: When you use ChatGPT, you're not talking to a magical AI - you're interacting with a model that's learned to imitate helpful responses through careful training. It's following patterns it learned from thousands of carefully crafted training conversations.

3. Reinforcement Learning: Learning to Improve (Optional Optimization)

Think of the first two steps as essential cooking ingredients - you need them to make the dish. Step 3 is like having a professional chef taste and refine the recipe. It's not strictly necessary, but it can make things much better.

Here's a concrete example of how this optimization works:

Human: What's the capital of France?

Possible Model Responses:
A: "The capital of France is Paris."
B: "Paris is the capital of France. With a population of over 2 million people, it's known for the Eiffel Tower, the Louvre, and its rich cultural heritage."
C: "Let me tell you about France's capital! 🗼 Paris is such a beautiful city! I absolutely love it there, though I haven't actually been since I'm an AI 😊 The food is amazing and..."

Human raters would then rank these responses:

Response B gets highest rating (informative but concise)
Response A gets medium rating (correct but minimal)
Response C gets lowest rating (too chatty, unnecessary personal comments)

The model learns from these preferences:

Being informative but not overwhelming is good
Staying focused on the question is important
Avoiding fake personal experiences is preferred

The Training Process

The model tries many different responses to the same prompt
Each response gets a score from the reward model
Responses that get high scores are reinforced (like giving a dog a treat)
The model gradually learns what makes humans happy

Think of Reinforcement Learning from Human Feedback (RLHF) as teaching the AI social skills. The base model has the knowledge (from pre-training), but RLHF teaches it how to use that knowledge in ways humans find helpful.

What Makes These Models Special?

They Need Tokens to Think

Unlike humans, these models need to distribute their computation across many tokens. Each token has only a limited amount of computation available.

Ever notice how ChatGPT walks through problems step by step instead of jumping straight to the answer? This isn't just for your benefit - it's because:

The model can only do so much computation per token
By spreading reasoning across many tokens, it can solve harder problems
This is why asking for "the answer immediately" often leads to wrong results

Here's a concrete example:

Bad Prompt (Forcing Immediate Answer):

Give me the immediate answer without explanation: What's the total cost of buying 7 books at $12.99 each with 8.5% sales tax? Just the final number.

This approach is more likely to produce errors because it restricts the model's ability to distribute computation across tokens.

Good Prompt (Allowing Token-Based Thinking):

Calculate the total cost of buying 7 books at $12.99 each with 8.5% sales tax. Please show your work step by step.

This allows the model to break down the problem:

Base cost: 7 × $12.99 = $90.93
Sales tax amount: $90.93 × 0.085 = $7.73
Total cost: $90.93 + $7.73 = $98.66

The second approach is more reliable because it gives the model space to distribute its computation across multiple tokens, reducing the chance of errors.

Context Is King

What these models see is drastically different from what we see:

We see words, sentences, and paragraphs
Models see token IDs (numbers representing text chunks)
There's a limited "context window" that determines how much the model can "see" at once

When you paste text into ChatGPT, it goes directly into this context window - the model's working memory. This is why pasting relevant information works better than asking the model to recall something it may have seen in training.

The Swiss Cheese Problem

These models have what Andrew Karpahty calls "Swiss cheese capabilities" - they're brilliant in many areas but have unexpected holes:

Can solve complex math problems but struggle with comparing 9.11 and 9.9
Can write elaborate code but might not count characters correctly
Can generate human-level responses but get tripped up by simple reasoning tasks

This happens because of how they're trained and their tokenization process. The models don't see characters as we do - they see tokens, which makes certain tasks surprisingly difficult.

How to Use LLMs Effectively

After all my research, here's my advice:

Use them as tools, not oracles: Always verify important information
Give them tokens to think: Let them reason step by step
Put knowledge in context: Paste relevant information rather than hoping they remember it
Understand their limitations: Be aware of the "Swiss cheese" problem
Try reasoning models: For complex problems, use models specifically designed for reasoning

The Future of Work in the AI Age: Three Possible Paths

Alexander Opalic — Mon, 06 Jan 2025 10:57:29 +0000

This is a submission for the 2025 New Year Writing challenge: Predicting 2025.

When we think about how AI will change how we work, I see three possible futures - two that could be good and one that's scary. Let me explain.

Types of Jobs

First, let's make it simple. There are two types of jobs:

People who work with information and computers
People who work with their hands and physical skills

Throughout history, humans have always wanted two main things from work:

To work fewer hours
To make work less physically hard

We naturally want things to be easier. But there's something new - especially in rich countries; we now want our work to make us feel good and give us purpose, not just help us survive.

As AI changes these essential work parts, three different futures could arise. Let's look at what each one means for workers.

Three Possible Futures

Future 1: AI Stays a Helper Tool

In the future, AI will never be as intelligent as humans. It stays a powerful helper that makes humans better at their jobs instead of replacing them. People who work with computers might use AI to work much faster - like devs making big computer programs in days instead of months or people looking at data to find answers in minutes instead of weeks.

This could lead to three things:

Computer devs become more valuable because they're good at using AI
We might need fewer devs because AI makes programming easier
As Naval thinks, maybe devs can even replace all other jobs

The main thing is that humans stay in charge, with AI being like an intelligent assistant. Computers might do tedious office work, but most jobs remain the same.

Future 2: Super-Smart AI Arrives - A World of Plenty

If we create AI that's as smart as humans at everything, our whole way of life could change. Office jobs might not be needed anymore - why have humans analyze things when AI can do it perfectly? The only human job left might be to make sure AI systems do what humans want them to do.

"There will come a time when no job is needed," says Elon Musk talking to British Prime Minister Rishi Sunak. At a special meeting where reporters couldn't ask questions and TV cameras were limited, Musk said AI will eventually become smarter than the smartest humans. [Source: BBC News, 2023]

As robots get better along with AI, physical jobs could also disappear. This could lead to a world where there's enough of everything, and traditional work becomes optional. We'd need to figure out new ways to share things and help people feel helpful in a world without human work.

Future 3: The Rough Change

This is the scariest future. Instead of smoothly changing into either of the good futures, we could have big problems. AI might take away jobs faster than we can make new ones or change how our economy works.

"I mean, it's crazy. We're talking about having a huge increase in productivity, so there's going to be more goods and services for everybody, so everybody ought to be better off. But actually, it's going to be the other way around, and it's because we live in a capitalist society. So what's going to happen is this huge increase in productivity is going to make much more money for the big companies and the rich, and it's going to increase the gap between the rich and the people who lose their jobs. And as soon as you increase that gap, you get fertile ground for fascism. And so it's very scary that we may be at a point where we're just making things worse and worse. And it's crazy because we're doing something that should help everybody, and obviously it will help in healthcare, it will help in education, but if the profits just go to the rich, that's going to make society worse."

— Geoffrey Hinton, Nobel Prize talk, 2024

This could cause:

Rich people (who own AI) getting richer, and poor people getting poorer
Lots of people losing their jobs, both office workers and physical workers
People getting angry because they can't make money like before
Everyone struggling to figure out what humans should do for work

Looking Forward

Which future do you think will happen? Our path depends on how we develop AI and how we prepare for the changes it will bring.

The most important thing is to start talking about these possibilities now, while we still have time to help choose which future becomes real.

How to Use SQLite in Vue 3: Complete Guide to Offline-First Web Apps

Alexander Opalic — Mon, 25 Nov 2024 07:44:12 +0000

Want to build web apps that work offline? While browsers have built-in storage options like IndexedDB, they're not great for complex data operations. This guide shows you how to use SQLite with Vue 3 to build powerful offline-first apps.

📚 What We'll Build

A Vue 3 app with SQLite that works offline
A simple query playground to test SQLite
Everything runs in the browser - no server needed!

🚀 Want the code? Get the complete example at github.com/alexanderop/sqlite-vue-example

🗃️ Why SQLite?

Browser storage like IndexedDB is okay, but SQLite is better because:

It's a real SQL database in your browser
Your data stays safe even when offline
You can use normal SQL queries
It handles complex data relationships well

🛠️ How It Works

We'll use three main technologies:

SQLite Wasm: SQLite converted to run in browsers
Web Workers: Runs database code without freezing your app
Origin Private File System: A secure place to store your database

Here's how they work together:

📝 Implementation Guide

Let's build this step by step, starting with the core SQLite functionality and then creating a playground to test it.

Step 1: Install Dependencies

First, install the required SQLite WASM package:

npm install @sqlite.org/sqlite-wasm

Step 2: Configure Vite

Create or update your vite.config.ts file to support WebAssembly and cross-origin isolation:

import { defineConfig } from 'vite'

export default defineConfig(() => ({
  server: {
    headers: {
      'Cross-Origin-Opener-Policy': 'same-origin',
      'Cross-Origin-Embedder-Policy': 'require-corp',
    },
  },
  optimizeDeps: {
    exclude: ['@sqlite.org/sqlite-wasm'],
  },
}))

This configuration is crucial for SQLite WASM to work properly:

Cross-Origin Headers:
- Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy headers enable "cross-origin isolation"
- This is required for using SharedArrayBuffer, which SQLite WASM needs for optimal performance
- Without these headers, the WebAssembly implementation might fail or perform poorly
Dependency Optimization:
- optimizeDeps.exclude tells Vite not to pre-bundle the SQLite WASM package
- This is necessary because the WASM files need to be loaded dynamically at runtime
- Pre-bundling would break the WASM initialization process

Step 3: Add TypeScript Types

Since @sqlite.org/sqlite-wasm doesn't include TypeScript types for Sqlite3Worker1PromiserConfig, we need to create our own. Create a new file types/sqlite-wasm.d.ts:

Define this as a d.ts file so that TypeScript knows about it.

import type { Worker } from 'node:worker_threads'

declare module '@sqlite.org/sqlite-wasm' {
  type OnreadyFunction = () => void

  type Sqlite3Worker1PromiserConfig = {
    onready?: OnreadyFunction
    worker?: Worker | (() => Worker)
    generateMessageId?: (messageObject: unknown) => string
    debug?: (...args: any[]) => void
    onunhandled?: (event: MessageEvent) => void
  }

  type DbId = string | undefined

  type PromiserMethods = {
    'config-get': {
      args: Record<string, never>
      result: {
        dbID: DbId
        version: {
          libVersion: string
          sourceId: string
          libVersionNumber: number
          downloadVersion: number
        }
        bigIntEnabled: boolean
        opfsEnabled: boolean
        vfsList: string[]
      }
    }
    'open': {
      args: Partial<{
        filename?: string
        vfs?: string
      }>
      result: {
        dbId: DbId
        filename: string
        persistent: boolean
        vfs: string
      }
    }
    'exec': {
      args: {
        sql: string
        dbId?: DbId
        bind?: unknown[]
        returnValue?: string
      }
      result: {
        dbId: DbId
        sql: string
        bind: unknown[]
        returnValue: string
        resultRows?: unknown[][]
      }
    }
  }

  type PromiserResponseSuccess<T extends keyof PromiserMethods> = {
    type: T
    result: PromiserMethods[T]['result']
    messageId: string
    dbId: DbId
    workerReceivedTime: number
    workerRespondTime: number
    departureTime: number
  }

  type PromiserResponseError = {
    type: 'error'
    result: {
      operation: string
      message: string
      errorClass: string
      input: object
      stack: unknown[]
    }
    messageId: string
    dbId: DbId
  }

  type PromiserResponse<T extends keyof PromiserMethods> =
    | PromiserResponseSuccess<T>
    | PromiserResponseError

  type Promiser = <T extends keyof PromiserMethods>(
    messageType: T,
    messageArguments: PromiserMethods[T]['args'],
  ) => Promise<PromiserResponse<T>>

  export function sqlite3Worker1Promiser(
    config?: Sqlite3Worker1PromiserConfig | OnreadyFunction,
  ): Promiser
}

Step 4: Create the SQLite Composable

The core of our implementation is the useSQLite composable. This will handle all database operations:

//@noErrors
import type { DbId } from '@sqlite.org/sqlite-wasm'
import { sqlite3Worker1Promiser } from '@sqlite.org/sqlite-wasm'
import { ref } from 'vue'

const databaseConfig = {
  filename: 'file:mydb.sqlite3?vfs=opfs',
  tables: {
    test: {
      name: 'test_table',
      schema: `
        CREATE TABLE IF NOT EXISTS test_table (
          id INTEGER PRIMARY KEY AUTOINCREMENT,
          name TEXT NOT NULL,
          created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
        );
      `,
    },
  },
} as const

export function useSQLite() {
  const isLoading = ref(false)
  const error = ref<Error | null>(null)
  const isInitialized = ref(false)

  let promiser: ReturnType<typeof sqlite3Worker1Promiser> | null = null
  let dbId: string | null = null

  async function initialize() {
    if (isInitialized.value) return true

    isLoading.value = true
    error.value = null

    try {
      // Initialize the SQLite worker
      promiser = await new Promise((resolve) => {
        const _promiser = sqlite3Worker1Promiser({
          onready: () => resolve(_promiser),
        })
      })

      if (!promiser) throw new Error('Failed to initialize promiser')

      // Get configuration and open database
      await promiser('config-get', {})
      const openResponse = await promiser('open', {
        filename: databaseConfig.filename,
      })

      if (openResponse.type === 'error') {
        throw new Error(openResponse.result.message)
      }

      dbId = openResponse.result.dbId as string

      // Create initial tables
      await promiser('exec', {
        dbId,
        sql: databaseConfig.tables.test.schema,
      })

      isInitialized.value = true
      return true
    }
    catch (err) {
      error.value = err instanceof Error ? err : new Error('Unknown error')
      throw error.value
    }
    finally {
      isLoading.value = false
    }
  }

  async function executeQuery(sql: string, params: unknown[] = []) {
    if (!dbId || !promiser) {
      await initialize()
    }

    isLoading.value = true
    error.value = null

    try {
      const result = await promiser!('exec', {
        dbId: dbId as DbId,
        sql,
        bind: params,
        returnValue: 'resultRows',
      })

      if (result.type === 'error') {
        throw new Error(result.result.message)
      }

      return result
    }
    catch (err) {
      error.value = err instanceof Error ? err : new Error('Query execution failed')
      throw error.value
    }
    finally {
      isLoading.value = false
    }
  }

  return {
    isLoading,
    error,
    isInitialized,
    executeQuery,
  }
}

Step 5: Create a SQLite Playground Component

Now let's create a component to test our SQLite implementation:


<script setup lang="ts">
import { useSQLite } from '@/composables/useSQLite'
import { ref } from 'vue'

const { isLoading, error, executeQuery } = useSQLite()
const sqlQuery = ref('SELECT * FROM test_table')
const queryResult = ref<any[]>([])
const queryError = ref<string | null>(null)

// Predefined example queries for testing
const exampleQueries = [
  { title: 'Select all', query: 'SELECT * FROM test_table' },
  { title: 'Insert', query: "INSERT INTO test_table (name) VALUES ('New Test Item')" },
  { title: 'Update', query: "UPDATE test_table SET name = 'Updated Item' WHERE name LIKE 'New%'" },
  { title: 'Delete', query: "DELETE FROM test_table WHERE name = 'Updated Item'" },
]

async function runQuery() {
  queryError.value = null
  queryResult.value = []

  try {
    const result = await executeQuery(sqlQuery.value)
    const isSelect = sqlQuery.value.trim().toLowerCase().startsWith('select')

    if (isSelect) {
      queryResult.value = result?.result.resultRows || []
    }
    else {
      // After mutation, fetch updated data
      queryResult.value = (await executeQuery('SELECT * FROM test_table'))?.result.resultRows || []
    }
  }
  catch (err) {
    queryError.value = err instanceof Error ? err.message : 'An error occurred'
  }
}
</script>

<template>
  <div class="max-w-7xl mx-auto px-4 py-6">
    <h2 class="text-2xl font-bold">SQLite Playground</h2>

    <!-- Example queries -->
    <div class="mt-4">
      <h3 class="text-sm font-medium">Example Queries:</h3>
      <div class="flex gap-2 mt-2">
        <button
          v-for="example in exampleQueries"
          :key="example.title"
          class="px-3 py-1 text-sm rounded-full bg-gray-100 hover:bg-gray-200"
          @click="sqlQuery = example.query"
        >
          {{ example.title }}
        </button>
      </div>
    </div>

    <!-- Query input -->
    <div class="mt-6">
      <textarea
        v-model="sqlQuery"
        rows="4"
        class="w-full px-4 py-3 rounded-lg font-mono text-sm"
        :disabled="isLoading"
      />
      <button
        :disabled="isLoading"
        class="mt-2 px-4 py-2 rounded-lg bg-blue-600 text-white"
        @click="runQuery"
      >
        {{ isLoading ? 'Running...' : 'Run Query' }}
      </button>
    </div>

    <!-- Error display -->
    <div
      v-if="error || queryError"
      class="mt-4 p-4 rounded-lg bg-red-50 text-red-600"
    >
      {{ error?.message || queryError }}
    </div>

    <!-- Results table -->
    <div v-if="queryResult.length" class="mt-4">
      <h3 class="text-lg font-semibold">Results:</h3>
      <div class="mt-2 overflow-x-auto">
        <table class="w-full">
          <thead>
            <tr>
              <th
                v-for="column in Object.keys(queryResult[0])"
                :key="column"
                class="px-4 py-2 text-left"
              >
                {{ column }}
              </th>
            </tr>
          </thead>
          <tbody>
            <tr
              v-for="(row, index) in queryResult"
              :key="index"
            >
              <td
                v-for="column in Object.keys(row)"
                :key="column"
                class="px-4 py-2"
              >
                {{ row[column] }}
              </td>
            </tr>
          </tbody>
        </table>
      </div>
    </div>
  </div>
</template>

🎯 Real-World Example: Notion's SQLite Implementation

Notion recently shared how they implemented SQLite in their web application, providing some valuable insights:

Performance Improvements

20% faster page navigation across all modern browsers
Even greater improvements for users with slower connections:

Multi-Tab Architecture

Notion solved the challenge of handling multiple browser tabs with an innovative approach:

Each tab has its own Web Worker for SQLite operations
A SharedWorker manages which tab is "active"
Only one tab can write to SQLite at a time
Queries from all tabs are routed through the active tab's Worker

Key Learnings from Notion

Async Loading: They load the WASM SQLite library asynchronously to avoid blocking initial page load
Race Conditions: They implemented a "racing" system between SQLite and API requests to handle slower devices
OPFS Handling: They discovered that Origin Private File System (OPFS) doesn't handle concurrency well out of the box
Cross-Origin Isolation: They opted for OPFS SyncAccessHandle Pool VFS to avoid cross-origin isolation requirements

This real-world implementation demonstrates both the potential and challenges of using SQLite in production web applications. Notion's success shows that with careful architecture choices, SQLite can significantly improve web application performance.

🎯 Conclusion

You now have a solid foundation for building offline-capable Vue applications using SQLite. This approach offers significant advantages over traditional browser storage solutions, especially for complex data requirements.

My favorite Newsletters as a Full stack Developer

Alexander Opalic — Mon, 11 Nov 2024 12:48:00 +0000

People always ask me, "Alex, how do you stay up to date with tech?" (Nobody asks me that.) One way to be time-efficient is to use newsletters.

I use a tool like https://read.readwise.io/.

It's a read-later app where you can subscribe to all your newsletters.

Also, when you see an interesting article but don't have time to read it now or have an article you'd like to find later, it helps to use that tool. Here are some of my favorite newsletters. Keep in mind that I am a full stack developer who is primarily interested in JavaScript.

Node Weekly (https://nodeweekly.com/)
- A weekly roundup of Node.js news, articles, and projects, keeping you updated with the latest in Node.js development.
JavaScript Weekly (https://javascriptweekly.com/)
- One of the most popular JavaScript newsletters, covering new features, frameworks, tools, and tutorials in the JavaScript ecosystem.
Astro Weekly (https://astroweekly.dev/)
- Latest updates, tips, and community highlights focused on Astro, the modern static site builder and frontend framework.
Dear Architects (https://www.deararchitects.xyz/)
- Software architecture insights, patterns, and best practices for building scalable systems.
Local First News (https://www.localfirstnews.com/)
- Updates and developments in local-first software development, focusing on offline-capable and data-sovereign applications.
Frontend Focus (https://frontendfoc.us/)
- Weekly newsletter covering frontend development trends, tools, frameworks, and best practices.
Smashing Magazine Newsletter (https://www.smashingmagazine.com/the-smashing-newsletter/)
- Web design and development insights, tutorials, and techniques from one of the most respected sources in the industry.
A11y Weekly (https://a11yweekly.com/)
- Weekly newsletter focused on web accessibility, featuring tips, tools, and resources for building inclusive websites.
GameDev.js Weekly (https://gamedevjsweekly.com/)
- Updates and resources specifically focused on JavaScript game development.
Changelog News (https://changelog.com/news)
- Open source technology news and updates, covering various programming languages and developer tools.
TLDR Tech (https://tldr.tech/)
- Concise, daily tech news summaries for developers, focusing on the most important stories in tech.

Frontend Testing Guide: 10 Essential Rules for Naming Tests

Alexander Opalic — Mon, 28 Oct 2024 11:50:00 +0000

Introduction

The path to better testing starts with something surprisingly simple: how you name your tests. Good test names:

Make your test suite more maintainable
Guide you toward writing tests that focus on user behavior
Improve clarity and readability for your team

In this blog post, we'll explore 10 essential rules for writing better tests that will transform your approach to testing. These principles are:

Framework-agnostic
Applicable across the entire testing pyramid
Useful for various testing tools:
- Unit tests (Jest, Vitest)
- Integration tests
- End-to-end tests (Cypress, Playwright)

By following these rules, you'll create a more robust and understandable test suite, regardless of your chosen testing framework or methodology.

Rule 1: Always Use "should" + Verb

Every test name should start with "should" followed by an action verb.

// ❌ Bad
it('displays the error message', () => {})
it('modal visibility', () => {})
it('form validation working', () => {})

// ✅ Good
it('should display error message when validation fails', () => {})
it('should show modal when trigger button is clicked', () => {})
it('should validate form when user submits', () => {})

Generic Pattern: should [verb] [expected outcome]

Rule 2: Include the Trigger Event

Specify what causes the behavior you're testing.

// ❌ Bad
it('should update counter', () => {})
it('should validate email', () => {})
it('should show dropdown', () => {})

// ✅ Good
it('should increment counter when plus button is clicked', () => {})
it('should show error when email format is invalid', () => {})
it('should open dropdown when toggle is clicked', () => {})

Generic Pattern: should [verb] [expected outcome] when [trigger event]

Rule 3: Group Related Tests with Descriptive Contexts

Use describe blocks to create clear test hierarchies.

// ❌ Bad
describe('AuthForm', () => {
  it('should test empty state', () => {})
  it('should test invalid state', () => {})
  it('should test success state', () => {})
})

// ✅ Good
describe('AuthForm', () => {
  describe('when form is empty', () => {
    it('should disable submit button', () => {})
    it('should not show any validation errors', () => {})
  })

  describe('when submitting invalid data', () => {
    it('should show validation errors', () => {})
    it('should keep submit button disabled', () => {})
  })
})

Generic Pattern:

describe('[Component/Feature]', () => {
  describe('when [specific condition]', () => {
    it('should [expected behavior]', () => {})
  })
})

Rule 4: Name State Changes Explicitly

Clearly describe the before and after states in your test names.

// ❌ Bad
it('should change status', () => {})
it('should update todo', () => {})
it('should modify permissions', () => {})

// ✅ Good
it('should change status from pending to approved', () => {})
it('should mark todo as completed when checkbox clicked', () => {})
it('should upgrade user from basic to premium', () => {})

Generic Pattern: should change [attribute] from [initial state] to [final state]

Rule 5: Describe Async Behavior Clearly

Include loading and result states for asynchronous operations.

// ❌ Bad
it('should load data', () => {})
it('should handle API call', () => {})
it('should fetch user', () => {})

// ✅ Good
it('should show skeleton while loading data', () => {})
it('should display error message when API call fails', () => {})
it('should render profile after user data loads', () => {})

Generic Pattern: should [verb] [expected outcome] [during/after] [async operation]

Rule 6: Name Error Cases Specifically

Be explicit about the type of error and what causes it.

// ❌ Bad
it('should show error', () => {})
it('should handle invalid input', () => {})
it('should validate form', () => {})

// ✅ Good
it('should show "Invalid Card" when card number is wrong', () => {})
it('should display "Required" when password is empty', () => {})
it('should show network error when API is unreachable', () => {})

Generic Pattern: should show [specific error message] when [error condition]

Rule 7: Use Business Language, Not Technical Terms

Write tests using domain language rather than implementation details.

// ❌ Bad
it('should update state', () => {})
it('should dispatch action', () => {})
it('should modify DOM', () => {})

// ✅ Good
it('should save customer order', () => {})
it('should update cart total', () => {})
it('should mark order as delivered', () => {})

Generic Pattern: should [business action] [business entity]

Rule 8: Include Important Preconditions

Specify conditions that affect the behavior being tested.

// ❌ Bad
it('should enable button', () => {})
it('should show message', () => {})
it('should apply discount', () => {})

// ✅ Good
it('should enable checkout when cart has items', () => {})
it('should show free shipping when total exceeds $100', () => {})
it('should apply discount when user is premium member', () => {})

Generic Pattern: should [expected behavior] when [precondition]

Rule 9: Name UI Feedback Tests from User Perspective

Describe visual changes as users would perceive them.

// ❌ Bad
it('should set error class', () => {})
it('should toggle visibility', () => {})
it('should update styles', () => {})

// ✅ Good
it('should highlight search box in red when empty', () => {})
it('should show green checkmark when password is strong', () => {})
it('should disable submit button while processing', () => {})

Generic Pattern: should [visual change] when [user action/condition]

Rule 10: Structure Complex Workflows Step by Step

Break down complex processes into clear steps.

// ❌ Bad
describe('Checkout', () => {
  it('should process checkout', () => {})
  it('should handle shipping', () => {})
  it('should complete order', () => {})
})

// ✅ Good
describe('Checkout Process', () => {
  it('should first validate items are in stock', () => {})
  it('should then collect shipping address', () => {})
  it('should finally process payment', () => {})

  describe('after successful payment', () => {
    it('should display order confirmation', () => {})
    it('should send confirmation email', () => {})
  })
})

Generic Pattern:

describe('[Complex Process]', () => {
  it('should first [initial step]', () => {})
  it('should then [next step]', () => {})
  it('should finally [final step]', () => {})

  describe('after [key milestone]', () => {
    it('should [follow-up action]', () => {})
  })
})

Complete Example

Here's a comprehensive example showing how to combine all these rules:

// ❌ Bad
describe('ShoppingCart', () => {
  it('test adding item', () => {})
  it('check total', () => {})
  it('handle checkout', () => {})
})

// ✅ Good
describe('ShoppingCart', () => {
  describe('when adding items', () => {
    it('should add item to cart when add button is clicked', () => {})
    it('should update total price immediately', () => {})
    it('should show item count badge', () => {})
  })

  describe('when cart is empty', () => {
    it('should display empty cart message', () => {})
    it('should disable checkout button', () => {})
  })

  describe('during checkout process', () => {
    it('should validate stock before proceeding', () => {})
    it('should show loading indicator while processing payment', () => {})
    it('should display success message after completion', () => {})
  })
})

Test Name Checklist

Before committing your test, verify that its name:

[ ] Starts with "should"
[ ] Uses a clear action verb
[ ] Specifies the trigger condition
[ ] Uses business language
[ ] Describes visible behavior
[ ] Is specific enough for debugging
[ ] Groups logically with related tests

Conclusion

Thoughtful test naming is a fundamental building block in the broader landscape of writing better tests. To maintain consistency across your team:

Document your naming conventions in detail
Share these guidelines with all team members
Integrate the guidelines into your development workflow

For teams using AI tools like GitHub Copilot:

Incorporate these guidelines into your project documentation
Link the markdown file containing these rules to Copilot
This integration allows Copilot to suggest test names aligned with your conventions

For more information on linking documentation to Copilot, see:
VS Code Experiments Boost AI Copilot Functionality

By following these steps, you can ensure consistent, high-quality test naming across your entire project.

Create a Native-Like App in 4 Steps: PWA Magic with Vue 3 and Vite

Alexander Opalic — Sun, 20 Oct 2024 07:44:12 +0000

Introduction
Understanding the Basics of Progressive Web Apps (PWAs)
Prerequisites for Building a PWA with Vue 3 and Vite
Step 1: Setting Up the Vue Project
Step 2: Create the needed assets for the PWA
Step 3: Configuring Vite for PWA Support
PWA Lifecycle and Updates
Step 4: Implementing Offline Functionality with Service Workers
Testing Your PWA
Conclusion

Introduction

Progressive Web Apps (PWAs) have revolutionized our thoughts on web applications. PWAs offer a fast, reliable, and engaging user experience by combining the best web and mobile apps. They work offline, can be installed on devices, and provide a native app-like experience without app store distribution.

This guide will walk you through creating a Progressive Web App using Vue 3 and Vite. By the end of this tutorial, you’ll have a fully functional PWA that can work offline, be installed on users’ devices, and leverage modern web capabilities.

Understanding the Basics of Progressive Web Apps (PWAs)

Before diving into the development process, it’s crucial to grasp the fundamental concepts of PWAs:

Multi-platform Compatibility : PWAs are designed for applications that can function across multiple platforms, not just the web.
Build Once, Deploy Everywhere : With PWAs, you can develop an application once and deploy it on Android, iOS, Desktop, and Web platforms.
Enhanced User Experience : PWAs offer features like offline functionality, push notifications, and home screen installation.

For a more in-depth understanding of PWAs, refer to the MDN Web Docs on Progressive Web Apps.

Prerequisites for Building a PWA with Vue 3 and Vite

Before you start, make sure you have the following tools installed:

Node.js installed on your system
Package manager: pnpm, npm, or yarn
Basic familiarity with Vue 3

Step 1: Setting Up the Vue Project

First, we’ll set up a new Vue project using the latest Vue CLI. This will give us a solid foundation to build our PWA upon.

Create a new Vue project by running the following command in your terminal:
Follow the prompts to configure your project. Here’s an example configuration:
Once the project is created, navigate to your project directory and install dependencies:

Great! You now have a basic Vue 3 project up and running. Let’s move on to adding PWA functionality.

Step 2: Create the needed assets for the PWA

We need to add specific assets and configurations to transform our Vue app into a PWA. PWAs can be installed on various devices, so we must prepare icons and other assets for different platforms.

First, let’s install the necessary packages:
Add a script to your package.json to generate PWA assets:
Create a high-resolution icon (preferably an SVG or a PNG with at least 512x512 pixels) for your PWA and place it in your public directory. Name it something like pwa-icon.svg or pwa-icon.png.
Generate the PWA assets by running:

This command will automatically generate a set of icons and a web manifest file in your public directory. The minimal-2023 preset will create:

favicon.ico (48x48 transparent icon for browser tabs)
favicon.svg (SVG icon for modern browsers)
apple-touch-icon-180x180.png (Icon for iOS devices when adding to home screen)
maskable-icon-512x512.png (Adaptive icon that fills the entire shape on Android devices)
pwa-64x64.png (Small icon for various UI elements)
pwa-192x192.png (Medium-sized icon for app shortcuts and tiles)
pwa-512x512.png (Large icon for high-resolution displays and splash screens)

Output will look like this:

> vue3-pwa-timer@0.0.0 generate-pwa-assets /Users/your user/git2/vue3-pwa-example
> pwa-assets-generator "--preset" "minimal-2023" "public/pwa-icon.svg"

Zero Config PWA Assets Generator v0.2.6
◐ Preparing to generate PWA assets...
◐ Resolving instructions...
✔ PWA assets ready to be generated, instructions resolved
◐ Generating PWA assets from public/pwa-icon.svg image
◐ Generating assets for public/pwa-icon.svg...
✔ Generated PNG file: /Users/your user/git2/vue3-pwa-example/public/pwa-64x64.png
✔ Generated PNG file: /Users/your user/git2/vue3-pwa-example/public/pwa-192x192.png
✔ Generated PNG file: /Users/your user/git2/vue3-pwa-example/public/pwa-512x512.png
✔ Generated PNG file: /Users/your user/git2/vue3-pwa-example/public/maskable-icon-512x512.png
✔ Generated PNG file: /Users/your user/git2/vue3-pwa-example/public/apple-touch-icon-180x180.png
✔ Generated ICO file: /Users/your user/git2/vue3-pwa-example/public/favicon.ico
✔ Assets generated for public/pwa-icon.svg
◐ Generating Html Head Links...
<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/pwa-icon.svg" sizes="any" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon-180x180.png">
✔ Html Head Links generated
◐ Generating PWA web manifest icons entry...
{
  "icons": [
    {
      "src": "pwa-64x64.png",
      "sizes": "64x64",
      "type": "image/png"
    },
    {
      "src": "pwa-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "pwa-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    },
    {
      "src": "maskable-icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "maskable"
    }
  ]
}
✔ PWA web manifest icons entry generated
✔ PWA assets generated
:root {--copy-icon: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 48 48'%3E%3Cpath fill='%23adadad' d='M16.187 9.5H12.25a1.75 1.75 0 0 0-1.75 1.75v28.5c0 .967.784 1.75 1.75 1.75h23.5a1.75 1.75 0 0 0 1.75-1.75v-28.5a1.75 1.75 0 0 0-1.75-1.75h-3.937a4.25 4.25 0 0 1-4.063 3h-7.5a4.25 4.25 0 0 1-4.063-3M31.813 7h3.937A4.25 4.25 0 0 1 40 11.25v28.5A4.25 4.25 0 0 1 35.75 44h-23.5A4.25 4.25 0 0 1 8 39.75v-28.5A4.25 4.25 0 0 1 12.25 7h3.937a4.25 4.25 0 0 1 4.063-3h7.5a4.25 4.25 0 0 1 4.063 3M18.5 8.25c0 .966.784 1.75 1.75 1.75h7.5a1.75 1.75 0 1 0 0-3.5h-7.5a1.75 1.75 0 0 0-1.75 1.75'/%3E%3C/svg%3E");--success-icon: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E%3Cpath fill='%2366ff85' d='M9 16.17L5.53 12.7a.996.996 0 1 0-1.41 1.41l4.18 4.18c.39.39 1.02.39 1.41 0L20.29 7.71a.996.996 0 1 0-1.41-1.41z'/%3E%3C/svg%3E");}pre:has(code) {position: relative;}pre button.rehype-pretty-copy {right: 1px;padding: 0;width: 24px;height: 24px;display: flex;margin-top: 2px;margin-right: 8px;position: absolute;border-radius: 25%;backdrop-filter: blur(3px);& span {width: 100%;aspect-ratio: 1 / 1;}& .ready {background-image: var(--copy-icon);}& .success {display: none; background-image: var(--success-icon);}}&.rehype-pretty-copied {& .success {display: block;} & .ready {display: none;}}pre button.rehype-pretty-copy.rehype-pretty-copied {opacity: 1;& .ready { display: none; }& .success { display: block; }}

These steps will ensure your PWA has all the necessary icons and assets to function correctly across different devices and platforms. The minimal-2023 preset provides a modern, optimized set of icons that meet the latest PWA requirements.

Step 3: Configuring Vite for PWA Support

With our assets ready, we must configure Vite to enable PWA functionality. This involves setting up the manifest and other PWA-specific options.

First, update your main HTML file (usually index.html) to include important meta tags in the <head> section:

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta name="theme-color" content="#ffffff">
  <link rel="icon" href="/favicon.ico" sizes="48x48">
  <link rel="icon" href="/favicon.svg" sizes="any" type="image/svg+xml">
  <link rel="apple-touch-icon" href="/apple-touch-icon-180x180.png">
</head>

Now, update your vite.config.ts file with the following configuration:

import { fileURLToPath, URL } from 'node:url'
import { VitePWA } from 'vite-plugin-pwa'
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  plugins: [
    vue(),
    VitePWA({
      registerType: 'autoUpdate',
      includeAssets: ['favicon.ico', 'apple-touch-icon-180x180.png', 'maskable-icon-512x512.png'],
      manifest: {
        name: 'My Awesome PWA',
        short_name: 'MyPWA',
        description: 'A PWA built with Vue 3',
        theme_color: '#ffffff',
        icons: [
          {
            src: 'pwa-64x64.png',
            sizes: '64x64',
            type: 'image/png'
          },
          {
            src: 'pwa-192x192.png',
            sizes: '192x192',
            type: 'image/png'
          },
          {
            src: 'pwa-512x512.png',
            sizes: '512x512',
            type: 'image/png',
            purpose: 'any'
          },
          {
            src: 'maskable-icon-512x512.png',
            sizes: '512x512',
            type: 'image/png',
            purpose: 'maskable'
          }
        ]
      },
      devOptions: {
        enabled: true
      }
    })
  ],
})

📝 Note

The devOptions: { enabled: true } setting is crucial for testing your PWA on localhost. Normally, PWAs require HTTPS, but this setting allows the PWA features to work on http://localhost during development. Remember to remove or set this to false for production builds.

This configuration generates a Web App Manifest, a JSON file that tells the browser about your Progressive Web App and how it should behave when installed on the user’s desktop or mobile device. The manifest includes the app’s name, icons, and theme colors.

PWA Lifecycle and Updates

The registerType: 'autoUpdate' option in our configuration sets up automatic updates for our PWA. Here’s how it works:

When a user visits your PWA, the browser downloads and caches the latest version of your app.
On subsequent visits, the service worker checks for updates in the background.
If an update is available, it’s downloaded and prepared for the next launch.
The next time the user opens or refreshes the app, they’ll get the latest version.

This ensures that users always have the most up-to-date version of your app without manual intervention.

Step 4: Implementing Offline Functionality with Service Workers

The real power of PWAs comes from their ability to work offline. We’ll use the vite-plugin-pwa to integrate Workbox, which will handle our service worker and caching strategies.

Before we dive into the configuration, let’s understand the runtime caching strategies we’ll be using:

StaleWhileRevalidate for static resources (styles, scripts, and workers):
CacheFirst for images:

These strategies ensure that your PWA remains functional offline while efficiently managing cache storage.

Now, let’s update your vite.config.ts file to include service worker configuration with these advanced caching strategies:

import vue from '@vitejs/plugin-vue'
import { defineConfig } from 'vite'
import { VitePWA } from 'vite-plugin-pwa'

export default defineConfig({
  plugins: [
    vue(),
    VitePWA({
      devOptions: {
        enabled: true
      },
      registerType: 'autoUpdate',
      includeAssets: ['favicon.ico', 'apple-touch-icon.png', 'masked-icon.svg'],
      manifest: {
        name: 'Vue 3 PWA Timer',
        short_name: 'PWA Timer',
        description: 'A customizable timer for Tabata and EMOM workouts',
        theme_color: '#ffffff',
        icons: [
          {
            src: 'pwa-192x192.png',
            sizes: '192x192',
            type: 'image/png'
          },
          {
            src: 'pwa-512x512.png',
            sizes: '512x512',
            type: 'image/png'
          }
        ]
      },
      workbox: {
        runtimeCaching: [
          {
            urlPattern: ({ request }) => request.destination === 'style' || request.destination === 'script' ||
             request.destination === 'worker',
            handler: 'StaleWhileRevalidate',
            options: {
              cacheName: 'static-resources',
              expiration: {
                maxEntries: 50,
                maxAgeSeconds: 30 * 24 * 60 * 60, // 30 days
              },
            },
          },
          {
            urlPattern: ({ request }) => request.destination === 'image',
            handler: 'CacheFirst',
            options: {
              cacheName: 'images',
              expiration: {
                maxEntries: 100,
                maxAgeSeconds: 60 * 24 * 60 * 60, // 60 days
              },
            },
          },
        ],
      },
    }),
  ],
})

Testing Your PWA

Now that we've set up our PWA, it's time to test its capabilities:

Test your PWA locally:

   pnpm run dev

Open Chrome DevTools and navigate to the Application tab.
- Check the "Manifest" section to ensure your Web App Manifest is loaded correctly.
- In the "Service Workers" section, verify that your service worker is registered and active.
Test offline functionality:
- Go to the Network tab in DevTools and check the "Offline" box to simulate offline conditions.
- Refresh the page and verify that your app still works without an internet connection.
- Uncheck the “Offline” box and refresh to ensure the app works online.
Test caching:
- In the Application tab, go to "Cache Storage" to see the caches created by your service worker.
- Verify that assets are being cached according to your caching strategies.
Test installation:
- On desktop: Look for the install icon in the address bar or the three-dot menu.
- On mobile: You should see a prompt to "Add to Home Screen".
Test updates:
- Make a small change to your app and redeploy.
- Revisit the app and check if the service worker updates (you can monitor this in the Application tab).

By thoroughly testing these aspects, you can ensure that your PWA functions correctly across various scenarios and platforms.

Conclusion

Congratulations! You’ve successfully created a Progressive Web App using Vue 3 and Vite. Your app can now work offline, be installed on users’ devices, and provide a native-like experience.

Refer to the Vite PWA Workbox documentation for more advanced Workbox configurations and features.

The more challenging part is building suitable components with a native-like feel on all the devices you want to support. PWAs are also a main ingredient in building local-first applications. If you are curious about what I mean by that, check out the following: What is Local First Web Development.

For a complete working example of this Vue 3 PWA, you can check out the complete source code at full example. This repository contains the finished project, allowing you to see how all the pieces come together in a real-world application.

From Atoms to Pages: Applying Atomic Design in Vue and Nuxt Projects

Alexander Opalic — Tue, 08 Oct 2024 00:00:00 +0000

Introduction

Clear writing requires clear thinking. The same is valid for coding. Throwing all components into one folder may work when starting a personal project. But as projects grow, especially with larger teams, this approach leads to problems:

Duplicated code
Oversized, multipurpose components
Difficult-to-test code

Atomic Design offers a solution. Let’s examine how to apply it to a Nuxt project.

What is Atomic Design

Brad Frost developed Atomic Design as a methodology for creating design systems. It is structured into five levels inspired by chemistry:

Atoms: Basic building blocks (e.g. form labels, inputs, buttons)
Molecules: Simple groups of UI elements (e.g. search forms)
Organisms: Complex components made of molecules/atoms (e.g. headers)
Templates: Page-level layouts
Pages: Specific instances of templates with content

Tip: 💁 For a better exploration of Atomic Design principles, I recommend reading Brad Frost's blog post: Atomic Web Design

For Nuxt, we can adapt these definitions:

Atoms: Pure, single-purpose components
Molecules: Combinations of atoms with minimal logic
Organisms: Larger, self-contained, reusable components
Templates: Nuxt layouts defining page structure
Pages: Components handling data and API calls

Organisms vs Molecules: What's the Difference?

Molecules and organisms can be confusing. Here's a simple way to think about them:

Molecules are small and simple. They're like LEGO bricks that snap together.
Examples:
- A search bar (input + button)
- A login form (username input + password input + submit button)
- A star rating (5 star icons + rating number)
Organisms are bigger and more complex. They're like pre-built LEGO sets.
Examples:
- A full website header (logo + navigation menu + search bar)
- A product card (image + title + price + add to cart button)
- A comment section (comment form + list of comments)

Remember: Molecules are parts of organisms, but organisms can work independently.

Code Example: Before and After

Consider this non-Atomic Design todo app component:

<template>
  <div class="container mx-auto p-4">
    <h1 class="text-2xl font-bold mb-4 text-gray-800 dark:text-gray-200">Todo App</h1>

    <!-- Add Todo Form -->
    <form @submit.prevent="addTodo" class="mb-4">
      <input
        v-model="newTodo"
        type="text"
        placeholder="Enter a new todo"
        class="border p-2 mr-2 bg-white dark:bg-gray-700 text-gray-800 dark:text-gray-200 rounded"
      />
      <button type="submit" class="bg-blue-500 hover:bg-blue-600 text-white p-2 rounded transition duration-300">
        Add Todo
      </button>
    </form>

    <!-- Todo List -->
    <ul class="space-y-2">
      <li
        v-for="todo in todos"
        :key="todo.id"
        class="flex justify-between items-center p-3 bg-gray-100 dark:bg-gray-700 rounded shadow-sm"
      >
        <span class="text-gray-800 dark:text-gray-200">{{ todo.text }}</span>
        <button
          @click="deleteTodo(todo.id)"
          class="bg-red-500 hover:bg-red-600 text-white p-1 rounded transition duration-300"
        >
          Delete
        </button>
      </li>
    </ul>
  </div>
</template>

<script setup lang="ts">
import { ref, onMounted } from 'vue'

interface Todo {
  id: number
  text: string
}

const newTodo = ref('')
const todos = ref<Todo[]>([])

const fetchTodos = async () => {
  // Simulating API call
  todos.value = [
    { id: 1, text: 'Learn Vue.js' },
    { id: 2, text: 'Build a Todo App' },
    { id: 3, text: 'Study Atomic Design' }
  ]
}

const addTodo = async () => {
  if (newTodo.value.trim()) {
    // Simulating API call
    const newTodoItem: Todo = {
      id: Date.now(),
      text: newTodo.value
    }
    todos.value.push(newTodoItem)
    newTodo.value = ''
  }
}

const deleteTodo = async (id: number) => {
  // Simulating API call
  todos.value = todos.value.filter(todo => todo.id !== id)
}

onMounted(fetchTodos)
</script>

This approach leads to large, difficult-to-maintain components. Let’s refactor using Atomic Design:

This will be the refactored structure

📐 Template (Layout)
   │
   └─── 📄 Page (TodoApp)
        │
        └─── 📦 Organism (TodoList)
             │
             ├─── 🧪 Molecule (TodoForm)
             │ │
             │ ├─── ⚛️ Atom (BaseInput)
             │ └─── ⚛️ Atom (BaseButton)
             │
             └─── 🧪 Molecule (TodoItems)
                  │
                  └─── 🧪 Molecule (TodoItem) [multiple instances]
                       │
                       ├─── ⚛️ Atom (BaseText)
                       └─── ⚛️ Atom (BaseButton)

Refactored Components

Tempalte Default

<template>
  <div class="min-h-screen bg-gray-100 dark:bg-gray-900 text-gray-900 dark:text-gray-100 transition-colors duration-300">
    <header class="bg-white dark:bg-gray-800 shadow">
      <nav class="container mx-auto px-4 py-4 flex justify-between items-center">
        <NuxtLink to="/" class="text-xl font-bold">Todo App</NuxtLink>
        <ThemeToggle />
      </nav>
    </header>
    <main class="container mx-auto px-4 py-8">
      <slot />
    </main>
  </div>
</template>

<script setup lang="ts">
import ThemeToggle from '~/components/ThemeToggle.vue'
</script>

Pages

<script setup lang="ts">
import { ref, onMounted } from 'vue'
import TodoList from '../components/organisms/TodoList'

interface Todo {
  id: number
  text: string
}

const todos = ref<Todo[]>([])

const fetchTodos = async () => {
  // Simulating API call
  todos.value = [
    { id: 1, text: 'Learn Vue.js' },
    { id: 2, text: 'Build a Todo App' },
    { id: 3, text: 'Study Atomic Design' }
  ]
}

const addTodo = async (text: string) => {
  // Simulating API call
  const newTodoItem: Todo = {
    id: Date.now(),
    text
  }
  todos.value.push(newTodoItem)
}

const deleteTodo = async (id: number) => {
  // Simulating API call
  todos.value = todos.value.filter(todo => todo.id !== id)
}

onMounted(fetchTodos)
</script>

<template>
  <div class="container mx-auto p-4">
    <h1 class="text-2xl font-bold mb-4 text-gray-800 dark:text-gray-200">Todo App</h1>
    <TodoList 
      :todos="todos"
      @add-todo="addTodo"
      @delete-todo="deleteTodo"
    />
  </div>
</template>

Organism (TodoList)

<script setup lang="ts">
import TodoForm from '../molecules/TodoForm.vue'
import TodoItem from '../molecules/TodoItem.vue'

interface Todo {
  id: number
  text: string
}

defineProps<{
  todos: Todo[]
}>()

defineEmits<{
  (e: 'add-todo', value: string): void
  (e: 'delete-todo', id: number): void
}>()
</script>

<template>
  <div>
    <TodoForm @add-todo="$emit('add-todo', $event)" />
    <ul class="space-y-2">
      <TodoItem
        v-for="todo in todos"
        :key="todo.id"
        :todo="todo"
        @delete-todo="$emit('delete-todo', $event)"
      />
    </ul>
  </div>
</template>

Molecules (TodoForm and TodoItem)

TodoForm.vue:

<script setup lang="ts">
import TodoForm from '../molecules/TodoForm.vue'
import TodoItem from '../molecules/TodoItem.vue'

interface Todo {
  id: number
  text: string
}

defineProps<{
  todos: Todo[]
}>()

defineEmits<{
  (e: 'add-todo', value: string): void
  (e: 'delete-todo', id: number): void
}>()
</script>

<template>
  <div>
    <TodoForm @add-todo="$emit('add-todo', $event)" />
    <ul class="space-y-2">
      <TodoItem
        v-for="todo in todos"
        :key="todo.id"
        :todo="todo"
        @delete-todo="$emit('delete-todo', $event)"
      />
    </ul>
  </div>
</template>

TodoItem.vue:

<script setup lang="ts">
import { ref } from 'vue'
import BaseInput from '../atoms/BaseInput.vue'
import BaseButton from '../atoms/BaseButton.vue'

const newTodo = ref('')
const emit = defineEmits<{
  (e: 'add-todo', value: string): void
}>()

const addTodo = () => {
  if (newTodo.value.trim()) {
    emit('add-todo', newTodo.value)
    newTodo.value = ''
  }
}
</script>

<template>
  <form @submit.prevent="addTodo" class="mb-4">
    <BaseInput v-model="newTodo" placeholder="Enter a new todo" />
    <BaseButton type="submit">Add Todo</BaseButton>
  </form>
</template>

Atoms (BaseButton, BaseInput, BaseText)

BaseButton.vue:

<script setup lang="ts">
defineProps<{
  variant?: 'primary' | 'danger'
}>()
</script>

<template>
  <button
    :class="[
      'p-2 rounded transition duration-300',
      variant === 'danger'
        ? 'bg-red-500 hover:bg-red-600 text-white'
        : 'bg-blue-500 hover:bg-blue-600 text-white'
    ]"
  >
    <slot></slot>
  </button>
</template>

BaseInput.vue:

<script setup lang="ts">
defineProps<{
  modelValue: string
  placeholder?: string
}>()
defineEmits<{
  (e: 'update:modelValue', value: string): void
}>()
</script>

<template>
  <input
    :value="modelValue"
    @input="$emit('update:modelValue', ($event.target as HTMLInputElement).value)"
    type="text"
    :placeholder="placeholder"
    class="border p-2 mr-2 bg-white dark:bg-gray-700 text-gray-800 dark:text-gray-200 rounded"
  />
</template>

Info: Want to check out the full example yourself? click me

Component Level	Job	Examples
Atoms	Pure, single-purpose components	BaseButton BaseInput BaseIcon BaseText
Molecules	Combinations of atoms with minimal logic	SearchBar LoginForm StarRating Tooltip
Organisms	Larger, self-contained, reusable components. Can perform side effects and complex operations.	TheHeader ProductCard CommentSection NavigationMenu
Templates	Nuxt layouts defining page structure	DefaultLayout BlogLayout DashboardLayout AuthLayout
Pages	Components handling data and API calls	HomePage UserProfile ProductList CheckoutPage

Summary

Atomic Design offers one path to a more apparent code structure. It works well as a starting point for many projects. But as complexity grows, other architectures may serve you better. Want to explore more options? Read my post on How to structure vue Projects. It covers approaches beyond Atomic Design when your project outgrows its initial structure.

Bolt Your Presentations: AI-Powered Slides

Alexander Opalic — Sat, 05 Oct 2024 12:00:00 +0000

Introduction

Presentations plague the middle-class professional. Most bore audiences with wordy slides. But AI tools promise sharper results, faster. Let’s explore how.

The Birth of Bolt

StackBlitz unveiled Bolt at ViteConf 2024. This browser-based coding tool lets developers build web apps without local setup. Pair it with Slidev, a markdown slide creator, for rapid presentation development.

Tools Breakdown

Three key tools enable this approach:

Bolt: AI-powered web app creation in the browser
Slidev: Markdown-based slides with code support
Webcontainers: Browser-based Node.js for instant prototyping

Seven Steps to AI Presentation Mastery

Follow these steps to craft AI-powered presentations:

Open bolt.new in your browser.
Tell Bolt to make a presentation on your topic. Be specific. (add use Slidedev for it)
Review the Bolt-generated slides. Check content and flow.
Edit and refine.
Ask AI for help. Request additional slides, examples, or transitions.
Add code snippets and diagrams.
Deploy to Netlify with one click.

Why This Method Works

This approach offers several advantages:

Speed: Bolt jumpstarts content creation.
Ease: No software to install.
Flexibility: Make real-time adjustments.
Collaboration: Share works-in-progress easily.
Quality: Built-in themes ensure polish.
Version control: Combine it with GitHub.

Conclusion

Try this approach for your next talk. You might surprise yourself with how quickly you go from concept to polished slides.

TypeScript Tutorial: Extracting All Keys from Nested Object

Alexander Opalic — Mon, 23 Sep 2024 00:00:00 +0000

What's the Problem?

Let's say you have a big TypeScript object. It has objects inside objects. You want to get all the keys, even the nested ones. But TypeScript doesn't make this easy.

Look at this User object:

type User = {
  id: string;
  name: string;
  address: {
    street: string;
    city: string;
  };
};

You want "id", "name", and "address.street". But TypeScript just shrugs. The usual way? It's useless:

type UserKeys = keyof User;

This only gives you the top-level keys. It misses the nested goodies like "address.street".

So, we need to get clever. We'll use some TypeScript magic:

Conditional Types (if-then for types)
Mapped Types (change each part of a type)
Template Literal Types (make new string types)
Recursive Types (types that refer to themselves)

Don't panic. It's not as scary as it sounds.

Here's our solution:

type ExtractKeys<T> = T extends object
  ? {
      [K in keyof T & string]: 
        | K 
        | (T[K] extends object ? `${K}.${ExtractKeys<T[K]>}` : K);
    }[keyof T & string]
  : never;

Yes, it looks like a cat walked on your keyboard. But it works. Let's break it down:

We check if T is an object.
If it is, we look at each key.
For each key, we either keep it as-is or...
If the key's value is another object, we add the key, a dot, and all the keys inside it.
We do this for all keys.

Now let's use it:

type UserKeys = ExtractKeys<User>;

Voila! We've got all the keys, even the nested ones.

Why bother? It makes your code safer. Look:

const user: User = {
  id: "123",
  name: "John Doe",
  address: {
    street: "Main St",
    city: "Berlin",
  },
};

function getProperty(obj: User, key: UserKeys) {
  const keys = key.split(".");
  let result: any = obj;

  for (const k of keys) {
    result = result[k];
  }

  return result;
}

// This works
getProperty(user, "address.street");

// This gives an error
getProperty(user, "address.country");

TypeScript catches your mistakes before they blow up in your face.

Remember

This type can be slow for very big objects.
It doesn't change how your code runs. It only helps catch errors early.
It can make your code harder to read. Use it wisely.

Wrap-Up

We've learned to wrangle all the keys from nested TypeScript objects. It's like having x-ray vision for your data. But remember, with great power comes great responsibility. And slower compile times.

TypeScript Snippets in Astro: Show, Don't Tell

Alexander Opalic — Sun, 22 Sep 2024 00:00:00 +0000

Note: Since I use Shiki and Twoslash I recommend you check out the blog post on the original site to get the full experience. TypeScript Snippets in Astro: Show, Don't Tell

Want smarter code snippets on your Astro site? This guide shows you how to add TypeScript type info that appears on hover. No fluff, just the steps you need. Your readers will thank you.

Before You Start

Set up an Astro project. Need help? See the Astro quickstart guide.

Set Up Shiki for Syntax Highlighting

Astro includes Shiki. Let's configure it:

Edit astro.config.mjs:

import { defineConfig } from "astro/config";

export default defineConfig({
  markdown: {
    shikiConfig: {
      themes: { light: "min-light", dark: "tokyo-night" },
    },
  },
});

Add a border to code blocks in your CSS:

pre:has(code) {
  @apply border border-skin-line;
}

Add Twoslash for Type Information

Install packages:

npm i -D twoslash twoslash-vue

Update astro.config.mjs:

import { createTransformerFactory, rendererRich } from '@shikijs/twoslash/core'
import { createTwoslasher } from 'twoslash-vue'
import { defineConfig } from "astro/config";

export default defineConfig({
  markdown: {
    shikiConfig: {
      themes: { light: "min-light", dark: "tokyo-night" },
      transformers: [
        createTransformerFactory(createTwoslasher())({
          langs: ['ts', 'tsx', 'vue'],
          renderer: rendererRich({
            lang: 'ts',
          }),
        }),
      ],
    },
  },
});

Use Interactive Snippets

Create TypeScript snippets in Markdown:

The // ^? shows where type info appears on hover.

Vue snippets work too:

For autocompletion, use ^|:

const increment = () => {
  count.v
  //    ^|
}

What You've Gained

Your Astro site now has:

Syntax highlighting
Hover-over type info
Light/dark mode code blocks

Your readers will thank you.

DEV Community: Alexander Opalic

How to Write Better Pinia Stores with the Elm Pattern

The Problem: Pinia Gives You Freedom, Not Rules

The Solution: TEA + Private Store Pattern

Understanding The Elm Architecture

How It Works: Combining TEA with Private State

The Private Internal Store

Pure Update Function

Public Store with Selectors + Dispatch

Usage in Components

Simpler Alternative: Using Vue’s readonly

Benefits of This Approach

Conclusion

The Age of the Generalist

How ChatGPT Works (for Dummies)

Introduction

What Happens When You Use ChatGPT?

The Fancy Autocomplete: How ChatGPT Predicts What Comes Next

Your text gets broken down into "tokens"

These tokens get converted into numbers

The model plays a sophisticated game of "what comes next?"

The process repeats token by token

A Relatable Example

Try It Yourself!

The Three-Stage Training Process

1. Pre-training: Learning from the Internet

2. Supervised Fine-Tuning: Learning to Be an Assistant

The Training Process

What Good Examples Look Like

What the Model Learns

3. Reinforcement Learning: Learning to Improve (Optional Optimization)

The Training Process

What Makes These Models Special?

They Need Tokens to Think

Context Is King

The Swiss Cheese Problem

How to Use LLMs Effectively

The Future of Work in the AI Age: Three Possible Paths

Types of Jobs

Three Possible Futures

Future 1: AI Stays a Helper Tool

Future 2: Super-Smart AI Arrives - A World of Plenty

Future 3: The Rough Change

Looking Forward

How to Use SQLite in Vue 3: Complete Guide to Offline-First Web Apps

📚 What We'll Build

🗃️ Why SQLite?

🛠️ How It Works

📝 Implementation Guide

Step 1: Install Dependencies

Step 2: Configure Vite

Step 3: Add TypeScript Types

Step 4: Create the SQLite Composable

Step 5: Create a SQLite Playground Component

🎯 Real-World Example: Notion's SQLite Implementation

Performance Improvements

Multi-Tab Architecture

Key Learnings from Notion

🎯 Conclusion

My favorite Newsletters as a Full stack Developer

Frontend Testing Guide: 10 Essential Rules for Naming Tests

Introduction

Rule 1: Always Use "should" + Verb

Rule 2: Include the Trigger Event

Rule 3: Group Related Tests with Descriptive Contexts

Rule 4: Name State Changes Explicitly

Rule 5: Describe Async Behavior Clearly

Rule 6: Name Error Cases Specifically

Rule 7: Use Business Language, Not Technical Terms

Rule 8: Include Important Preconditions

Rule 9: Name UI Feedback Tests from User Perspective

Rule 10: Structure Complex Workflows Step by Step

Complete Example

Test Name Checklist

Conclusion

Create a Native-Like App in 4 Steps: PWA Magic with Vue 3 and Vite

Table of Contents

Introduction

Understanding the Basics of Progressive Web Apps (PWAs)

Prerequisites for Building a PWA with Vue 3 and Vite