Coder Legion - Recent posts tagged vue

Headless Vue + WordPress Boilerplate v2.0.0

Mon, 26 Oct 2026 01:04:13 +0000

Headless Vue + WordPress Boilerplate v2.0.0

Yes, Version 2.0.0 is here!!!

This boilerplate allows you to use Vue as the front-end for your WordPress theme in a headless architecture. WordPress handles the backend and REST API, while Vue powers the user interface using modern frontend tooling like Vite.

Key Features

Use Vue 3 with Vite for a fast and modern development experience
⚡ Hot Module Replacement inside WordPress: save a .vue file and see it instantly, no rebuild
One-line REST API routes in PHP and one-line calls in Vue (useApi, useWp)
WordPress pages, posts and menus work out of the box with Vue Router
Modular folder structure for components, pages, APIs, and stores
⚙️ Supports Vue Router and Pinia (Vue Store)
Style with Tailwind CSS, standard CSS or your preferred CSS preprocessor

Requirements

WordPress 6.7+ and PHP 8.1+
Node.js 20+
Pretty permalinks (Settings > Permalinks, anything except "Plain")

Folder Structure

themes/
└── vue-boilerplate/
    ├── functions/               # WordPress PHP functions
    │   ├── api.php              # Your REST API routes
    │   ├── api-helpers.php      # vue_theme_api_get(), vue_theme_api_post(), ...
    │   ├── vite.php             # Loads the Vue app (dev server or build)
    │   └── theme-settings.php   # Theme supports and menu locations
    ├── src/                     # Vue application root
    │   ├── api/                 # API client (index.js) and JS modules for API calls
    │   │   └── wp/
    │   ├── assets/              # Static assets like images and SVGs
    │   ├── components/          # Vue components (e.g., layout)
    │   ├── composables/         # useApi and useWp
    │   ├── page/                # Vue page views
    │   ├── router/              # Vue Router setup
    │   ├── stores/              # Pinia stores
    │   │   └── wp/
    │   ├── utils/               # HTML sanitizer and link helpers
    │   ├── App.vue              # Root Vue component
    │   ├── main.js              # Vue app entry point
    │   ├── settings.js          # Values passed from WordPress
    │   └── style.css            # Global styles
    ├── dist/                    # Production build (created by npm run build)
    ├── *.php                    # WordPress theme files (header.php, footer.php, etc.)
    ├── style.css                # Theme metadata
    └── vite.config.js           # Configuration file for Vite, a fast frontend build tool.

Getting Started

Download and put the files inside your themes folder, then activate the theme.
Download Latest Release
Install Dependencies
```
npm install
```
Run the Development Server
```
npm run dev
```
Open your WordPress site URL (e.g. http://mysite.local), not the Vite URL.

While npm run dev is running, WordPress loads the app from the Vite dev server. Vue and CSS changes show up instantly, and PHP changes reload the page. Stop the dev server and WordPress goes back to the production build.

Make sure WordPress is running locally (e.g., with LocalWP or Laragon) and that the theme is activated.

Build for Production

npm run build

This will compile and optimize your Vue app into dist/. Upload the theme with the dist folder, you don't need node_modules or src on the server.

Working with the API

Add a route (PHP)

Add it at the bottom of functions/api.php. Routes live under /wp-json/vue-theme/v1/.

vue_theme_api_get('/books', function () {
    return get_posts(['post_type' => 'book']);
});

// URL parameter
vue_theme_api_get('/books/{id}', function ($request) {
    $book = get_post((int) $request['id']);

    if (!$book) {
        return new WP_Error('not_found', 'Book not found.', ['status' => 404]);
    }

    return $book;
});

// JSON body
vue_theme_api_post('/contact', function ($request) {
    $email = sanitize_email($request['email']);

    return ['sent' => true];
});

// Logged in users only, or users with a capability
vue_theme_api_post('/notes', 'my_callback', ['permission' => true]);
vue_theme_api_delete('/notes/{id}', 'my_callback', ['permission' => 'edit_posts']);

Use it (Vue)

In a component, useApi and useWp are auto-imported and give you reactive state:

<script setup>
const { data: books, loading, error } = useApi('books')

// WordPress core API: posts, pages, categories, media, your custom post types...
const page = ref(1)
const { data: posts, totalPages } = useWp('posts', () => ({ per_page: 6, page: page.value }))
</script>

<template>
    <p v-if="loading">Loading...</p>
    <p v-else-if="error">{{ error }}</p>
    <ul v-else>
        <li v-for="book in books" :key="book.ID">{{ book.post_title }}</li>
    </ul>
</template>

Anywhere else (stores, event handlers), use the clients:

import { api, wp } from '@/api' // or a relative path like '../api'

const books = await api.get('books')
const result = await api.post('contact', { email, message })
const posts = await wp.get('posts', { per_page: 5, search: 'vue' })
const { data, total, totalPages } = await wp.paginate('posts', { page: 2 })

Failed requests throw an ApiError with message, status and code. The nonce for logged in users is sent automatically.

Routing

Add your own routes in src/router/index.js.
Any other URL is looked up in WordPress: src/page/Content.vue shows the page or post with that slug, or a "Page not found" message.
Menus assigned to Primary Menu and Footer Menu (Appearance > Menus) are rendered by Header.vue and Footer.vue.

Integration Tips

Site title, logo and menus are available without a request: useSiteStore()
Pass your own PHP data to Vue with the vue_theme_app_config filter, then read it from window.wpVueTheme
Always use sanitizeHtml() from src/utils/html.js before rendering WordPress content with v-html
Import images from src/assets so they get the right URL after the build
Set show_in_rest to true on your custom post types to load them with useWp('your-post-type')

❓ Troubleshooting

"The Vue app is not built yet": run npm install and npm run build, or start npm run dev.
Changes don't show up: check that npm run dev is still running and that you opened the WordPress URL.
Port 5173 is already in use: create .env.local with VITE_DEV_PORT=5174.
*Local domain is not localhost, `.local, .loc or .test**: add VITE_WP_ORIGIN=http://your-domain` to .env.local.
WordPress runs in Docker: PHP can't see the dev server on your machine, so add add_filter('vue_theme_check_dev_server', '__return_false'); to functions.php while developing.
Vue routes return a server 404: enable pretty permalinks in Settings > Permalinks.

⬆️ Upgrading from 1.x

See CHANGELOG.md for the breaking changes.

Github Repo

See Headless Vue + WordPress Boilerplate v2.0.0

License

See MIT License

Prepared by: Christopher Robin Chase

I remade Hamurabi, the game I used to play a lot as a kid

Tue, 22 Sep 2026 08:07:05 +0000

Back in the 90s, when I was in school, I had a game on my home PC called Gospodar. The idea was simple: you have 10 years to rule. You plant crops, buy land, feed your people, and wait for new settlers. I could play it for hours.

My dad was totally into it too. He quickly figured out the math and could sit there managing the kingdom for ages. We would often discuss how much grain to save for planting and how much to give to the people.

Years later, I found out it was actually the classic game Hamurabi. The code was written in BASIC back in 1973, and the original dates all the way back to 1968! The developers of the version I played just changed the name and the setting, but kept the original rules.

I always had warm memories about it and wanted to play it again. I tried finding modern versions online, but they just weren't fun. They were either pure text or had broken logic that made it way too easy to win.

I usually build websites and apps, but this time I thought, why not recreate this game from scratch exactly the way I want it?

I decided to stick to the original, keeping the Hamurabi name and the Babylon setting. I found the classic formulas online, built the engine, ran it, and realized something. My childhood memory was actually a pretty simple game. When you are an adult, those 10 years don't feel like a lifetime anymore, and the mechanics are too obvious.

I played it many times and figured out what needed to change. The original game was a bit repetitive and the math was too simple. You could get the highest score just by getting lucky in the final year.

So, I made the math a bit harder. Now, just saving up grain until year 10 is not enough for a good ending. The game tracks the stability of your rule over the whole period. It checks how population growth matches your land expansion, if there were any sudden crashes, and how well you handled crises. The cost of a mistake is much higher now.

Winning is not easy anymore. But it is possible, even if you accidentally starve a few dozen people along the way (tested it myself 😅).

Aside from the logic, I also updated the visuals. I generated some graphics and music, and added a few languages. It is a web app, so you can play it in any browser on your computer or phone. There are no registrations or accounts. Your progress is automatically saved right in your browser, so you can stop anytime and continue later.

I hope those who remember the classic Hamurabi get a nice feeling of nostalgia. And if you have never heard of it, this is a great chance to touch a piece of gaming history.

You can try your hand at ruling Babylon here: https://hammurabi.webixsoft.com

I Kept Rebuilding PDF Features in Vue 3, So I Built vue-pdf-export

Fri, 04 Sep 2026 00:10:12 +0000

Hey everyone 👋

I recently released vue-pdf-export, an open-source Vue 3 + TypeScript library for generating PDFs directly in the browser.

I built it after repeatedly needing the same PDF features across different Vue projects and wanting one reusable solution instead of rebuilding the same logic each time.

What it supports

Some of the main features include:

Canvas and selectable-text PDF rendering
Automatic and manual pagination
Preview, download, and browser print
Headers and footers
Watermarks and page targeting
Clickable PDF links
Password protection and permissions
PDF metadata and compression
Progress reporting and cancellation
Large-document rendering
Blob, ArrayBuffer, Base64, and PDF data URL outputs
data-pdf-ignore for excluding UI elements from exports
Export-only page and body styling
Nuxt 3 and Nuxt 4 SSR-safe package imports

The package also has compatibility coverage for npm, pnpm, Yarn, Yarn Plug'n'Play, and Bun.

Installation

npm install vue-pdf-export

Basic usage

<script setup lang="ts">
import { ref } from 'vue'
import { Html2Pdf } from 'vue3-pdf-export'
import 'vue3-pdf-export/style.css'

const pdf = ref<InstanceType<typeof Html2Pdf> | null>(null)

async function generate() {
  await pdf.value?.generatePdf()
}
</script>

<template>
  <button @click="generate">
    Generate PDF
  </button>

  <Html2Pdf
    ref="pdf"
    filename="example.pdf"
    :preview-modal="true"
  >
    <template #pdf-content>
      <main>
        <h1>Hello from Vue</h1>
        <p>This content will be exported to PDF.</p>
      </main>
    </template>
  </Html2Pdf>
</template>

Canvas or selectable text

Use Canvas rendering when HTML/CSS fidelity is the priority:

<Html2Pdf render-mode="canvas">

Or use selectable-text rendering when users need to select, search, and copy text from the generated PDF:

<Html2Pdf render-mode="text">

This makes the package useful for both highly visual layouts and text-heavy documents such as reports, invoices, statements, and documentation.

The idea is to let developers choose between maximum browser-style fidelity and real selectable PDF text depending on their use case.

Programmatic output

The generated PDF can also be used directly in your application:

const blob = await pdf.value?.generatePdf()
const buffer = await pdf.value?.generatePdfArrayBuffer()
const base64 = await pdf.value?.generatePdfBase64()

This is useful when you want to upload, store, preview, or pass the PDF to another API instead of immediately downloading it.

Nuxt support

The package is designed so importing it does not crash Nuxt SSR.

Actual PDF generation still happens in the browser, so a typical Nuxt integration can use ClientOnly or lazy client-side rendering when needed.

Pagination

The package supports both automatic and manual pagination.

For an explicit manual page break:

<div class="html2pdf__page-break"></div>

There are also options for keeping elements together and avoiding unwanted page breaks.

Large-document rendering

Large PDFs were one of the areas I wanted to improve significantly.

Canvas rendering can become expensive when a browser attempts to create one extremely tall canvas for an entire document.

vue3-pdf-export can now render paginated Canvas documents incrementally, page by page, instead of depending on one giant full-document capture.

In one benchmark fixture, the previous long-document capture surface was around:

99.96 million pixels

while incremental rendering kept the maximum capture surface around:

1.74 million pixels per page

That is approximately a 98.26% reduction in peak capture-surface geometry for that fixture.

This is specifically a rendering-surface measurement, not a claim that total browser memory always drops by the same percentage.

The current regression suite includes documents across:

10 / 25 / 40 / 50 / 60 / 75 / 100 pages

50-page and 100-page Canvas documents are part of the current verified test range.

100 pages is not a hard package limit. Practical limits still depend on the document, images, browser memory, rendering mode, security settings, and the device being used.

Cancellation

Long-running PDF generation can now be cancelled.

pdf.value?.cancelGeneration()

Cancellation is cooperative and works across the generation pipeline.

The library also tests recovery after cancellation, so a new PDF can be generated after an earlier operation was cancelled.

Some already-running synchronous browser operations cannot always be stopped immediately, but the pipeline checks for cancellation between major stages.

Page-aware progress

Progress reporting now includes more than a simple percentage.

The package can expose:

current progress
current page
total pages
current processing stage

Stages include:

pagination
images
preparing
rendering
watermark
header
footer
metadata
serializing
complete
error

This makes it possible to build UI such as:

Rendering page 18 of 50...

instead of showing an indefinite spinner.

Headers

Headers can contain:

plain text
trusted HTML
optional logos
custom backgrounds and text colors
configurable logo dimensions
selected-page targeting

A header can appear on:

all pages
the first page only
the last page only
every page except the first
explicit page numbers

Selective header targeting also uses page-aware spacing, so header space is reserved only where the header is actually rendered.

Footers

Footers support:

HTML mode
text mode
trusted HTML content
optional logos
configurable logo dimensions
background and text colors
page-number templates

For example:

Page {n} of {total}

Header and footer logos preserve their aspect ratio instead of being stretched into a fixed box.

Static HTML footers are now rendered once and reused across pages instead of being rasterized repeatedly.

In project benchmark fixtures:

HTML footer without logo
7.82s -> 1.43s

HTML footer with logo
11.81s -> 1.29s

Footer-heavy PDF size
~46.7 MB -> ~1.0 MB

These numbers are specific to the benchmark fixtures and should not be treated as universal performance guarantees.

Repeated image optimization

Selectable-text rendering now caches repeated images within a single generation.

If the same image is reused across many pages, the package can avoid repeatedly loading and encoding the same source.

The cache is scoped to one PDF generation and is cleared afterward.

This is especially useful for documents containing repeated logos, icons, product images, or other shared assets.

Resource cleanup

A lot of work also went into cleaning temporary resources earlier.

The generation pipeline now handles cleanup of things such as:

temporary cloned DOM nodes
temporary canvases
encoded image data
per-generation image caches
rendering state

Canvas backing stores are also released when possible after they are no longer needed.

Repeated-generation and isolation tests were added to help detect regressions in cleanup behavior.

Browser responsiveness

Large PDF generation is naturally expensive, especially in Canvas mode.

The pipeline now yields between selected expensive operations so the browser gets opportunities to process UI work while generation is running.

Combined with cancellation and page-aware progress, this makes long-running generation easier to integrate into real applications.

Watermarks

Watermarks can be:

text or image
foreground or background
single or repeated
rotated
positioned
configured with opacity
targeted to selected PDF pages

PDF security

You can optionally generate password-protected PDFs with:

user/open password
owner password
configurable permissions
password construction from multiple password parts

Supported permission controls include:

print
modify
copy
annot-forms

Metadata and compression

PDF metadata can include:

title
author
subject
keywords
creator

jsPDF stream compression can also be enabled when needed.

Clickable links

PDF link annotations are also supported, allowing links in generated documents to remain interactive instead of becoming plain visual text.

Safer filenames

Generated filenames are normalized before download.

This includes handling invalid filename characters, whitespace, reserved Windows names, trailing dots or spaces, and overly long filenames.

Unicode filenames are still preserved.

A note about encrypted raster PDFs

While profiling larger secured documents, I found that encrypted raster PDFs could retain significantly more browser memory than equivalent unencrypted PDFs.

I reproduced the behavior directly with jsPDF outside the main vue3-pdf-export rendering pipeline.

That means a substantial part of this behavior appears to come from the underlying PDF library rather than from the Vue component itself.

I opened an upstream jsPDF issue with the reproduction and benchmark details:

https://github.com/parallax/jsPDF/issues/4017

For large secured documents, selectable-text mode can sometimes be a useful alternative because text-based PDFs are generally much smaller than equivalent rasterized documents.

This is still workload-dependent, so applications generating large encrypted PDFs should test their own representative content.

Testing and performance work

The project now includes automated testing around:

unit behavior
Chromium
Firefox
WebKit
large documents
Canvas rendering
selectable-text rendering
cancellation and recovery
image-heavy documents
repeated images
footer optimization
browser cleanup
security behavior
memory measurements
repeated generation
stress testing

The current unit suite contains:

19 test files
106 tests

There are also dedicated benchmark and Playwright workflows for performance-heavy scenarios.

For heavy PDF tests, I intentionally run browser work sequentially where appropriate so multiple workers do not distort memory measurements.

Why I built a Vue layer instead of replacing the underlying libraries

The goal was never to pretend that html2pdf.js, html2canvas, or jsPDF do not exist.

Those libraries still provide important pieces of the Canvas rendering pipeline.

The goal of vue3-pdf-export is to provide a Vue-oriented layer around PDF generation so common production requirements do not need to be rebuilt for every application.

At the same time, developers can still pass advanced html2pdf.js and jsPDF options when the higher-level API is not enough.

The selectable-text renderer provides another option for cases where real PDF text matters more than exact Canvas-style browser rendering.

Current release

The current release is:

vue-pdf-export v1.0.0

The project has grown significantly since the original release, including:

Canvas and selectable-text rendering modes
incremental page-by-page Canvas generation
large-document regression coverage
cancellation and recovery
current-page / total-page progress
repeated-image caching
footer rendering optimization
earlier DOM and Canvas cleanup
browser responsiveness improvements
PDF security
metadata and compression
clickable links
trusted HTML headers and footers
logo support
watermarks
filename normalization
expanded unit, browser, stress, and performance testing

Try it

🧪 Live Playground
https://vue-pdf-export-playground.vercel.app/

📖 Documentation
https://vue-pdf-export-docs.vercel.app/

📦 npm
https://www.npmjs.com/package/vue-pdf-export

💬 Feature requests & feedback
https://vue3-pdf-export.canny.io/

I’d really appreciate feedback from Vue and Nuxt developers, especially around real-world PDF edge cases, API ergonomics, pagination, large documents, or features you would expect from a Vue PDF library.

If you are building a Vue application that needs client-side PDF generation, I would love to hear about the kinds of documents you are generating and the edge cases you run into.

The project is still evolving, and real-world feedback is one of the most useful inputs for deciding what to improve next. If you find a bug, performance cases, or have an idea for an API improvement, feel free to let me know.

Run Vue Component Tests Where Vue Runs: The Browser

Tue, 01 Sep 2026 07:35:19 +0000

A Vue component's job is to produce DOM in a browser. Most component tests ask it to do that somewhere else: in Node, against a DOM that jsdom simulates. That has been the default since npm create vue@latest started offering Vitest with jsdom, and for plenty of tests it is the right trade. It does set a ceiling on what a green test proves, though. Nothing is ever drawn. Your CSS never runs and nothing has a size or a position, so a component can pass every assertion in the file and still be broken on screen.

I co-maintain twd-js, which runs tests inside your actual dev server, in a sidebar, next to the app. It was built for flow testing: visit a route, click through the app, assert on what the user sees. Component testing was the thing it did not do.

Then I tried calling render() from @testing-library/vue inside a TWD test.

import { afterEach, describe, it } from "twd-js/runner";
import { twd, userEvent } from "twd-js";
import { render, screen, cleanup } from "@testing-library/vue";
import HomeView from "../../views/HomeView.vue";
import { componentHost, restorePage } from "../support/componentHost";

describe("HomeView component", () => {
  afterEach(() => {
    cleanup();
    restorePage();
  });

  it("increments the counter on click", async () => {
    // componentHost() is a blank div on an empty page. More on it below.
    render(HomeView, { container: componentHost() });

    const button = await screen.findByTestId("counter-button");
    twd.should(button, "contain.text", "Count is 0");

    await userEvent.click(button);
    twd.should(button, "contain.text", "Count is 1");
  });
});

Nothing broke. The component mounts into the page, the sidebar shows it running, and reactivity does what reactivity does, in a browser, against a DOM nobody had to simulate.

Why this works at all

Vue Testing Library is a thin layer. render() mounts your component with @vue/test-utils and binds @testing-library/dom queries to the result. Neither of those is tied to jsdom. jsdom is just the DOM most people hand them.

Give them a real one and the same code runs, except now the component is actually on a screen, with a real size, a real position, and your CSS applied to it. TWD already runs inside your app in the browser, so the real DOM is right there.

The setup

One helper, and no changes to your app.

render() appends its container to document.body, so the component lands after #app, a full viewport below your layout. The app is also still on the page, so screen matches its elements as well as the ones your test just rendered. Both of those are the same problem: the app is in the way.

const HOST_ID = "twd-component-host";
const APP_ROOT_ID = "app";

let appRoot: HTMLElement | null = null;
let placeholder: Comment | null = null;

export function componentHost(): HTMLElement {
  detachApp();

  let host = document.getElementById(HOST_ID);
  if (!host) {
    host = document.createElement("div");
    host.id = HOST_ID;
  }
  if (!host.isConnected) {
    document.body.prepend(host);
  }

  host.innerHTML = "";
  return host;
}

export function restorePage(): void {
  document.getElementById(HOST_ID)?.remove();
  attachApp();
}

function detachApp(): void {
  if (placeholder) return;

  const root = document.getElementById(APP_ROOT_ID);
  if (!root) return;

  appRoot = root;
  placeholder = document.createComment(" app detached by twd component test ");
  root.replaceWith(placeholder);
}

function attachApp(): void {
  if (!placeholder || !appRoot) return;

  placeholder.replaceWith(appRoot);
  placeholder = null;
  appRoot = null;
}

Detaching the app root is not the same as emptying it. app.innerHTML = "" pulls the DOM out from under Vue while its vnodes still point at those nodes, and the next router navigation patches elements that are no longer in the document. Moving the node out and putting it back leaves that correspondence intact, so restorePage() returns a live app.

prepend rather than append puts the component at the top of the page. It also keeps it in normal flow, which matters in a browser: the page is offset to make room for the TWD sidebar, and anything in normal flow inherits that offset for free.

One detail worth keeping: cleanup() and restorePage() belong in afterEach, not beforeEach. In jsdom the environment is torn down for you between files. In a real browser it is not, so renders stack up, and your flow tests need the app back before they run.

That is the whole setup. Your app does not change.

The part that changes how the test reads

Here is the same idea on a view that fetches on mount and posts a form.

it("posts the form values when a todo is created", async () => {
  await twd.mockRequest("getTodoList", {
    method: "GET",
    url: "/api/todos",
    response: [],
    status: 200,
  });
  await twd.mockRequest("createTodo", {
    method: "POST",
    url: "/api/todos",
    status: 201,
    response: { id: "1", title: "Write the Vue post", description: "In a real browser", date: "2026-09-01" },
  });

  render(TodosView, { container: componentHost() });
  await twd.waitForRequest("getTodoList");

  await userEvent.type(await screen.findByLabelText("Title"), "Write the Vue post");
  await userEvent.type(screen.getByLabelText("Description"), "In a real browser");
  await userEvent.type(screen.getByLabelText("Date"), "2026-09-01");

  await userEvent.click(screen.getByRole("button", { name: "Create Todo" }));

  const rule = await twd.waitForRequest("createTodo");
  expect(rule.request).to.deep.equal({
    title: "Write the Vue post",
    description: "In a real browser",
    date: "2026-09-01",
  });
});

Nothing here is stubbed except the network. The component's onMounted, its ref state, the v-model bindings and the axios call all run for real, and the assertion is on the request that actually left the browser. In jsdom that test usually starts with a vi.mock of the API module, and from then on you are asserting that your component calls your mock correctly.

userEvent here comes from twd-js, which re-exports @testing-library/user-event so there is nothing extra to install. It drives v-model the way a person does, one key event at a time, and in a real browser those are real key events.

Both kinds of test, one run

Component tests and flow tests are now the same kind of artifact. Files in the same project, listed in the same sidebar, running in the same browser session against the same bundle. There is no second runner, no second DOM, and no second config to keep in sync.

The one thing to configure is the other direction. If you also run Vitest in the same repo, exclude the browser tests from it, or Vitest will collect them, find no describe it recognises, and fail the run:

test: {
  exclude: [...configDefaults.exclude, "**/*.twd.test.*"],
},

Where each style fits

Rendering a component in isolation is the right move when the component is the subject: a form's validation states, a modal that opens and closes, a table that sorts. You skip the navigation, you skip the fixtures, and the test says exactly what it is about.

Flow tests stay the right move for anything that crosses a boundary. Routing, data loading, a sequence of screens, state that survives a navigation. Rendering a component in isolation to test those means rebuilding the app around it, which is how component test files end up longer than the components.

The useful change is not that one replaced the other. It is that choosing between them is now a decision about scope, made per test, instead of a decision about which runner and which DOM you are committing to.

Try it

If you already have Vue Testing Library tests, copy one, change the imports for describe and it to twd-js/runner, and hand render() the component host. The rest of the test stays as it is.

The example app is on GitHub, with the same component tested in jsdom and in the browser side by side: BRIKEV/twd-vue-example.

I wrote the React version of this first, if you want the same walkthrough with @testing-library/react: No More Fake DOM.

How to Convert Word to PDF in the Browser with Vue 3, mammoth, and html2pdf.js

Sat, 13 Jun 2026 13:24:06 +0000

Converting Word documents to PDFs on the server is the classic approach: upload the file, run LibreOffice or a cloud API, send the result back. But that means your users’ resumes, contracts, and reports touch your infrastructure.

I wanted something simpler for en.sotool.top: pick a .docx file in the browser, preview the parsed content, and download a PDF. No server involved.

Here is how I built it with Vue 3, mammoth, and html2pdf.js.

Why Client-Side?

The main reason is privacy. Resumes, contracts, tax documents — users do not want them on a stranger’s server. Client-side conversion also means:

No upload bandwidth limits
No file size caps from your server
No storage to clean up
Works offline after the page loads

The trade-off is that very complex documents are limited by the browser’s rendering capabilities. For typical office documents, that is fine.

The Stack

Vue 3 — UI, file handling, and reactive state
mammoth — Parse .docx files into clean HTML
html2pdf.js — Render the HTML into a PDF using html2canvas + jsPDF
Native File API — File selection

npm install mammoth html2pdf.js

Loading the Word Document

The first step is reading the uploaded .docx file into an ArrayBuffer, then converting it to HTML with mammoth.

import mammoth from 'mammoth';

async function convertDocxToHtml(file) {
  const arrayBuffer = await file.arrayBuffer();
  const result = await mammoth.convertToHtml({ arrayBuffer });
  return result.value;
}

mammoth intentionally produces simple, clean HTML. It ignores complex formatting like text boxes and embedded fonts, which makes the output predictable.

I keep the HTML in a reactive ref and render it in a preview panel:

<template>
  <div ref="previewRef" class="word-preview" v-html="htmlContent"></div>
</template>

<script setup>
import { ref } from 'vue';

const htmlContent = ref('');
const previewRef = ref(null);
</script>

Generating the PDF

Once the user is happy with the preview, html2pdf.js turns the preview element into a PDF. It uses html2canvas to rasterize the HTML and jsPDF to create the PDF file.

import html2pdf from 'html2pdf.js';

async function convertToPdf() {
  const element = previewRef.value;
  if (!element) return;

  await html2pdf()
    .from(element)
    .set({
      margin: [10, 10, 10, 10],
      filename: 'document.pdf',
      image: { type: 'jpeg', quality: 0.98 },
      html2canvas: { scale: 2, useCORS: true },
      jsPDF: { unit: 'mm', format: 'a4', orientation: 'portrait' },
    })
    .save();
}

The scale: 2 setting gives crisp text and images on high-DPI screens. useCORS: true helps if the preview contains external images.

Styling the Preview

html2pdf.js renders whatever is in the DOM, so the preview styles directly affect the output. I use scoped CSS with :deep() to style the converted HTML:

.word-preview :deep(h1) {
  font-size: 1.5rem;
  font-weight: 700;
  margin-bottom: 1rem;
}

.word-preview :deep(p) {
  margin-bottom: 0.75rem;
  line-height: 1.7;
}

.word-preview :deep(table) {
  width: 100%;
  border-collapse: collapse;
  margin-bottom: 1rem;
}

.word-preview :deep(td),
.word-preview :deep(th) {
  border: 1px solid #d1d5db;
  padding: 0.5rem;
}

Keep the preview background white. Dark mode UI is nice for the app, but a white page produces a clean PDF.

Handling Errors Gracefully

Not every file is a valid .docx. I wrap the conversion in a try/catch and reset the state on failure:

async function handleFile(file) {
  try {
    const arrayBuffer = await file.arrayBuffer();
    const result = await mammoth.convertToHtml({ arrayBuffer });
    htmlContent.value = result.value;
  } catch (e) {
    console.error(e);
    alert('Failed to parse the document. Please check the file format.');
  }
}

You can also surface mammoth warnings if you want to show the user which styles or elements were ignored.

Lessons Learned

1. Mammoth is opinionated by design
It strips complex Word features to produce clean HTML. If your users need pixel-perfect fidelity, a server-side converter is still a better fit.

2. Page size matters
If the document contains wide tables or landscape sections, A4 portrait may clip them. Consider letting users choose the output format.

3. html2canvas is heavy on large documents
Very long documents with many images can take several seconds and block the main thread. For heavy usage, consider chunking or using a Web Worker.

4. Keep the original file around
If users want to adjust settings and re-convert, you will need the original File object or ArrayBuffer because mammoth does not expose an editable model.

Try It

The Word to PDF tool is live at en.sotool.top/word-to-pdf.

Free, no signup, and nothing uploads to a server.

Full source code is on GitHub. The conversion logic lives in src/views/WordToPdf.vue.

Want More Advanced PDF Features?

If you need OCR, form editing, digital signatures, or batch processing beyond what a browser tool can do, Wondershare PDFelement is a solid desktop option. It keeps everything local and adds professional tools on top.

This post contains affiliate links.

Have you built client-side document converters? What did you use — mammoth, pdf-lib, or a server-side tool?

From Modal to Full Page: How We Refactored a Vue 3 Recipe Detail View (and Made It Faster)

Sun, 03 May 2026 19:43:07 +0000

From Modal to Full Page: How We Refactored a Vue 3 Recipe Detail View (and Made It Faster)

Demo:
https://recipe-finder.org/recipe/644488-german-rhubarb-cake-with-meringue

One of the longest-lived technical decisions in our recipe finder app was showing recipe details inside a dialog modal. It worked — until it didn't. Here's how we migrated from a bloated modal to a clean, SEO-friendly full page, what we cut along the way, and what the app looks like now.

The Old Approach: Everything in a Modal

The original setup opened a <v-dialog> when a user clicked a recipe card. The modal held the entire recipe detail UI: ingredients, nutrition, videos, AI chef, grocery import, recipe scaler — all of it. The logic for opening it, fetching the recipe, and handling deep-link slugs lived inside HomePage.vue.

<!-- Old: HomePage.vue controlled everything -->
<RecipeDetailsModal
  :is-open="isRecipeModalOpen"
  :recipe="selectedRecipeDetails"
  :loading="loadingRecipeDetails"
  @close="closeModal"
/>

The problem was that HomePage.vue had become a god component. It managed:

The search form and results
Cuisine carousel
Recipe of the day
Recent recipes
And the modal open/close state, slug parsing, and detail fetch

On top of that, because everything was in a modal, the URL never changed. Users couldn't share a link to a specific recipe, Google couldn't index the content, and the Back button did nothing useful.

The New Approach: Dedicated Route + Page

We created /recipe/:slug as a proper route and moved the recipe detail logic into a standalone RecipeDetailPage.vue.

// router/index.ts
{
  path: '/recipe/:slug',
  component: () => import('@/pages/RecipeDetailPage.vue'),
  meta: { title: 'Recipe' }
}

Slugs are derived from the recipe ID and title, making them human-readable and stable:

// utils/index.ts
export const toRecipeSlug = (id: number, title: string): string => {
  const slug = title
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/(^-|-$)/g, '');
  return `${id}-${slug}`;
};

export const extractRecipeIdFromSlug = (slug: string): number | null => {
  const id = parseInt(slug.split('-')[0]);
  return isNaN(id) ? null : id;
};

What We Cut From HomePage.vue

Once the page was independent, we stripped HomePage.vue of everything modal-related. Gone:

isRecipeModalOpen ref
selectedRecipeDetails and loadingRecipeDetails state
The openRecipeModal / closeModal handlers
The slug-watching watch that re-fetched on URL change
The <RecipeDetailsModal> import and component registration
The handleOpenRecipeDetails function passed down through three component layers

The result was HomePage.vue shrinking by roughly 40% in script size. It now does one thing: show the search form and results.

What the Page Layout Looks Like

The page uses a standard Vuetify two-column grid — main content on the left, sticky sidebar on the right (desktop only). On mobile, the sidebar collapses and the tools surface inline.

<v-row>
  <!-- Left: main content -->
  <v-col cols="12" lg="8">
    <v-img :src="recipe.image" cover rounded="lg" class="mb-6" />
    <h1 class="recipe-title">{{ recipe.title }}</h1>
    <!-- chips, rating, action buttons, summary, ingredients, instructions, nutrition -->
  </v-col>

  <!-- Right: sticky sidebar (desktop only) -->
  <v-col cols="12" lg="4" class="d-none d-lg-flex flex-column">
    <div class="sidebar-sticky">
      <!-- Recipe Tools card -->
      <!-- AI Cooking Chef card -->
      <!-- Nutrition Snapshot card -->
    </div>
  </v-col>
</v-row>

The sidebar cards use a glass morphism style that matches the rest of the app:

.glass-card {
  border: 1px solid rgba(255, 255, 255, 0.1);
  background:
    radial-gradient(circle at top right, rgba(255, 163, 92, 0.08), transparent 40%),
    linear-gradient(165deg, rgba(255, 255, 255, 0.07), rgba(255, 255, 255, 0.02));
  border-radius: 16px !important;
}

Mobile: Icon Buttons + Bottom Sheet AI

On mobile, the page can't show a sidebar. We solved this in two ways:

Action buttons become icon-only on small screens, matching how the modal used to look:

<!-- Mobile: icon-only -->
<div class="d-flex d-sm-none gap-2 mb-6 align-center">
  <v-btn icon variant="tonal" size="small" @click.stop="handleToggleFavoriteRecipe">
    <v-icon>{{ isFavorited ? 'mdi-heart' : 'mdi-heart-outline' }}</v-icon>
  </v-btn>
  <v-btn icon variant="tonal" size="small" @click="shareRecipe">
    <v-icon>{{ isCopied ? 'mdi-check' : 'mdi-share-variant' }}</v-icon>
  </v-btn>
  <v-btn icon variant="tonal" size="small" @click="printRecipe">
    <v-icon>mdi-printer</v-icon>
  </v-btn>
</div>

<!-- Desktop: text buttons -->
<div class="d-none d-sm-flex flex-wrap gap-2 mb-6">
  <v-btn prepend-icon="mdi-heart-outline" variant="tonal" class="page-action-btn">
    Add to Favorites
  </v-btn>
  <!-- ... -->
</div>

The AI chef becomes a bottom sheet triggered by a text button inline with the ingredient tools (no floating action button cluttering the screen):

<!-- Ingredient row: Scale / Analyze / Grocery / AI Chef -->
<v-btn color="primary" variant="text" size="small"
  prepend-icon="mdi-robot-excited" @click="showAiSheet = true">
  AI Chef
</v-btn>

<v-bottom-sheet v-model="showAiSheet">
  <!-- full AI interface -->
</v-bottom-sheet>

SEO + Meta Tags

Since the content is now on a real URL, we inject <title> and Open Graph meta tags dynamically on load:

const injectMetaTags = (title: string, summary: string, imageUrl: string) => {
  const pageTitle = `${title} | Recipe Finder`;
  document.title = pageTitle;

  const setMeta = (selector: string, attr: string, value: string) => {
    document.querySelector(selector)?.setAttribute(attr, value);
  };

  setMeta("meta[property='og:title']", 'content', pageTitle);
  setMeta("meta[name='twitter:title']", 'content', pageTitle);

  if (summary) {
    const clean = summary.replace(/<[^>]*>/g, '').trim().slice(0, 155);
    setMeta("meta[name='description']", 'content', clean);
    setMeta("meta[property='og:description']", 'content', clean);
  }

  if (imageUrl) {
    setMeta("meta[property='og:image']", 'content', imageUrl);
  }
};

This is called inside a watch on the recipe computed ref, so it fires on both initial load and when navigating between similar recipes.

Async Components Throughout

Every non-critical UI piece is lazy-loaded:

const ImportToGroceryList = defineAsyncComponent(
  () => import('@/components/ImportToGroceryList.vue')
);
const PremiumUpgradeDialog = defineAsyncComponent(
  () => import('@/components/PremiumUpgradeDialog.vue')
);
const RecipeScaler = defineAsyncComponent(
  () => import('@/components/RecipeScaler.vue')
);
const RecipeEmbedWatermark = defineAsyncComponent(
  () => import('@/components/RecipeEmbedWatermark.vue')
);

The main recipe content renders immediately. The grocery dialog, scaler, embed widget, and upgrade dialog only load if the user actually interacts with them.

Auth Guard on Grocery Import

One regression we caught: clicking "Send to Grocery List" while logged out was calling getAccessTokenSilently() and throwing an Auth0 missing refresh token error. Fixed by checking auth state before opening the dialog:

const onDialogToggle = (open: boolean) => {
  if (open) {
    if (!isAuthenticated.value) {
      dialogOpen.value = false;
      loginWithRedirect();
      return;
    }
    loadGroceryLists();
  }
};

The Result

HomePage.vue Script Size: Reduced from ~650 lines to ~390 lines

Recipe URL: Now fully shareable

Google Indexing: Now fully indexable

Mobile Layout: Upgraded from a fullscreen modal to a native page with a bottom sheet

Auth Crash on Grocery: Fixed

AI on Mobile: Moved from a floating button to an inline trigger

The modal still exists for the recipe list view (quick-peek without leaving the page), but the canonical experience is now a proper page. The code is cleaner, the app is faster to load, and every recipe finally has a real URL.

Built with Vue 3, Vuetify 3, TypeScript, and Tailwind CSS. Auth via Auth0.

Creative Ways to Leverage JavaScript Frameworks for Modern Development

Sat, 14 Feb 2026 07:33:52 +0000

Introduction

As a JavaScript developer, you know that libraries and frameworks provide powerful tools for building applications. However, tapping into their full potential often requires thinking outside the box. Let's explore some innovative ways to leverage frameworks like React, Vue, and Angular.

1. Component Reusability

Instead of building every new feature from scratch, focus on creating highly reusable components.

Example: Suppose you're developing an e-commerce site. Create a generic ProductCard component that can adapt to different product types by passing props, simplifying future updates and feature additions.

2. Custom Hooks in React

Custom hooks can significantly streamline your code and improve maintainability. You can encapsulate common logic into hooks.

Example: If multiple components need to fetch user data, develop a useFetchUser hook that handles fetching, loading, and error states. This keeps components clean and promotes logic reuse.

3. Vue Mixins for Shared Functionality

While Vue has a robust composition API, mixins are still a potent tool for sharing functionality across components.

Example: Create a mixin that includes validation methods. This can simplify form controls across various components, ensuring consistency and reducing duplication.

4. Angular Schematics

Angular's schematics allow you to automate the creation of components, services, and more. This feature improves efficiency by generating boilerplate code.

Example: Customize schematics for your app, so when you generate a new component, it automatically includes CSS styles, tests, and related files. This drastically reduces setup time.

5. State Management through Context API

For small to medium apps, you might not need a heavy state management library like Redux. Instead, consider using the Context API to manage state effectively without the overhead.

Example: Build a simple global store for user authentication status, which can be easily accessed across components without prop drilling.

6. Progressive Web Apps with Frameworks

Both React and Vue support PWA features enabling you to create fast, reliable apps.

Example: Use Create React App’s built-in PWA support to enhance your web app, making it installable and improving performance metrics.

Conclusion

By adopting these unconventional techniques in your JavaScript projects, you can streamline your workflow and develop high-quality applications more efficiently. Don’t hesitate to mix and match practices from different frameworks to find what works best for your needs.

Share your thoughts on these strategies or suggest other creative approaches you've implemented.

Vector: The easiest way to plug Vue in Blade

Tue, 03 Feb 2026 19:24:34 +0000

You know that feeling when you're building a Laravel app and you just need a tiny bit of reactivity? A counter. A toggle. Something that feels overkill for a full Vue component but too annoying for vanilla JavaScript?

I kept reaching for Alpine.js, which is great, but I wanted Vue's Composition API. The ref(), the computed(), the familiar syntax I already know. So I bu4ilt Vector.

What Even Is This?

Vector is a Laravel package that lets you write Vue directly in your Blade templates with zero ceremony:

<script setup>
    const i = ref(0);
</script>

<div>
    <button @click="i++">Click Me</button>
    <div>
        Count: @{{ i }}
    </div>
    <div v-if="i > 5">Success!</div>
</div>

That's the whole thing. No build step for your components. No separate .vue files. No special directives wrapping your code. Just a <script setup> tag and you're done.

How It Works

The <script setup> tag gets transformed at compile time. Vector treats the element immediately after the script tag as your Vue template. Everything inside that element becomes reactive, and anything outside it remains regular Blade.

Blade's precompiler finds your <script setup> blocks
Extracts your variable declarations
Mounts Vue on the next sibling element

The key part is the variable extraction. It parses const, let, and var declarations and auto-returns them to the template. You write normal code, it figures out the rest.

Escaping Blade Syntax

Since Blade also uses {{ }} for output, you need to prefix Vue's mustache syntax with @ to prevent Blade from processing it:

{{-- This is Blade --}}
{{ $phpVariable }}

{{-- This is Vue (note the @) --}}
@{{ vueVariable }}

Alternatively, use Vue directives like v-text which don't conflict with Blade:

<span v-text="count"></span>

Installation

composer require brunoabpinto/vector

Add Vector to your Vite entry points in vite.config.js:

plugins: [
    laravel({
        input: [
            "resources/css/app.css",
            "resources/js/app.js",
            "resources/js/vendor/vector.js",
        ],
        // ...
    }),
],
resolve: {
    alias: {
        'vue': 'vue/dist/vue.esm-bundler.js',
    },
},

Add @vectorJs before your closing </body> tag in your layout:

<body>
    {{ $slot }}

    @vectorJs
</body>

That's it. Vector auto-publishes its runtime, and @vectorJs loads it where you need it.

The Trade-offs

Let's be real about what this is:

Good for:

Quick interactive elements
Prototyping
When you want Vue's API without Vue's ceremony
Laravel apps that are mostly server-rendered with islands of reactivity

Not great for:

Complex component hierarchies
When you need proper SFC features (scoped styles, etc.)
Large-scale SPAs (just use Inertia at that point)

Try It

The package is available on GitHub. Star it, fork it, tell me it's an abomination. Whatever feels right.

composer require brunoabpinto/vector

Beyond the Framework Hype: What Really Matters in Modern Web Dev

Sat, 29 Nov 2025 19:01:43 +0000

Modern web development in 2025 is dominated by frameworks, but the real story is not React vs Vue vs Svelte, it is how well teams use these tools to ship fast, accessible, maintainable products. React remains the default choice for many companies because of its vast ecosystem, strong TypeScript support, and mature meta‑frameworks like Next.js and Remix, which handle routing, data fetching, and server‑side rendering out of the box. At the same time, lighter options such as Preact, Solid, and Svelte are gaining traction where performance and bundle size are critical, especially on mobile connections or embedded environments.

The biggest shift is architectural rather than syntactic: server components, streaming rendering, and edge functions are blurring the line between frontend and backend. Instead of shipping a monolithic single‑page app, developers increasingly compose UIs from server‑rendered shells with islands of interactivity, hydrated only where needed. React Server Components, Next.js App Router, and Qwik’s resumability are all attempts to solve the same problem—how to keep the developer experience of components while delivering near‑instant first paint for users. This mindset forces teams to think about data loading, caching, and latency as first‑class concerns rather than afterthoughts.

Another quiet revolution is happening around DX: tools like Vite, Turbopack, and esbuild make dev servers nearly instant, while component‑driven workflows with Storybook and design systems keep UI consistent across large teams. Yet the best results still come from fundamentals: semantic HTML, clean state management, predictable APIs, and performance budgets baked into CI. The question is no longer “Which framework should I learn first?” but “How do I design my app so that swapping frameworks in five years does not become a full rewrite?” In that world, good architecture.......clear boundaries, reusable domain logic, and API‑first thinking.....outlives any single JavaScript trend.

How I Started Writing Unit Tests for Vue Components - Part 2

Fri, 21 Nov 2025 09:41:46 +0000

So, it's been a year since the last article, and a lot has changed. In this one, we're going to talk about integrating with Mock Service Worker (MSW). I'll also describe what I tried to implement in my quest for system resilience - what worked out and what didn't.

So, did my tests actually help me?

I can't say the time investment paid off in spades, but one thing's for sure - it definitely wasn't a waste of time.

Here are the main areas where the tests really proved their worth:

When contracts were lost or changed;
Fixing the fallout from merge conflicts (given the quirks of our
processes, this is the most common scenario);
Refactoring (it's hard to be objective here since our project's test
coverage isn't huge, but before any refactoring, I try to at least
cover the code with local tests).

Then again, all those fancy things like Cursor with their powerful autocomplete freed up some time, so why not spend a bit of it on tests?

The Fight for Reliability, or Reality Strikes Back

Let me start with what didn't work out.The first thing I tried was implementing E2E tests with Playwright. You know, testing business logic in the browser by simulating real user actions.

In our existing project, this turned out to be really tough. The main problem was setting up the initial test data. In my case, that meant the database. It needed to be as small as possible, but still have all the necessary data for testing.

In theory, it sounds simple: take a database, tweak the data, create a Docker image, and boom - you're golden. Well, I got stuck at the very first step of preparing that database. It requires a firm decision and a coordinated effort, meaning help from the backend team and DevOps (who are always busy). In the end, on my project, we shelved the idea for the time being.

I also tried replacing actual backend interaction by mocking API requests directly within Playwright, but that felt like a dead end. Maintaining yet another set of mocks (on top of the MSW we already had) combined with the slow browser startup times just didn't seem rational, unless for some very specific tasks.

About Unit Tests and MSW

All in all, I decided to focus on unit tests (which, in the classic sense, are more like integration tests in our context). They're fast, isolated, simple, and reliable.

To mock network interactions, I set up MSW (Mock Service Worker). This later allowed us to practice contract-first programming and parallel development.

So, first you install MSW (the official guide is your best friend here).

Then, I moved the vite configuration for it into vitest.workspace.js (note: in new versions DEPRECATED). This isn't mandatory, but it's convenient if you need to separate node and browser environments.

import { defineWorkspace } from 'vitest/config';

export default defineWorkspace([
  'packages/*',
  {
    extends: './vite.config.js',
    test: {
      environment: 'jsdom',
      name: 'unit',
      include: ['src/**/*.spec.{ts,js}'],
      deps: {
        inline: ['element-plus'],
      },
      setupFiles: ['./src/mocks/setup.ts'], // path for the msw config
    },
  },
]);

Since it's an independent service, I put it in a mocks folder, so it's easy to cleanly remove if needed.

import { server } from './server.ts';
import { afterAll, afterEach, beforeAll } from 'vitest';

beforeAll(() =>  return server.listen({ onUnhandledRequest: 'warn' });
afterAll(() => server.close());
afterEach(() => server.resetHandlers());

user/handlers.ts

import { GET_USERS } from '@/api/constants/APIEndPoints.js';
import { HttpResponse, http } from 'msw';
import { USERS_FAKE_RESPONSE} from './fixtures.ts';

export const handlers = [
  http.get('*' + GET_USERS , () => {
    return HttpResponse.json(USERS_FAKE_RESPONSE);
  }),

];

Now, whenever a call is made to the URL defined in the GET_USER identifier, it will return the value stored in USER_FAKE_RESPONSE.

Interestingly, MSW, especially with its plugins, can generate handlers from an openApi.json file, which can cover all your API requests. It can also use faker.js to generate response data with fake values.

I'm not a big fan of that approach myself (it can complicate parallel work), so I prefer to create response fixtures and handlers manually, and then fill them in - even using AI helpers sometimes - which results in more human-readable responses.

export const USER_FAKE_RESPONSE = {
  items:[
    { firstName: 'John' , lastName: 'Smith'}
    { firstName: 'Willy' , lastName: 'Willson'}
  ]
}

Using it in Tests

For a clear example, let's imagine we have a component with a button to fetch users and a block to display the response. A traditional test might look something like this (a detailed test was in the previous article; this is just a schematic).

import * as USER_API from 'some api folder'
let wrapper

const createComponent = (params {}) => {
  wrapper = shallowMount(OurGetUsersComponent, {
    props: {
      ...params.props,
    },
    global: {
      renderStubDefaultSlot: true,
      stubs: {
        ...params.stubs,
      },
    },
  });
};

test('Handling user retrieval when the Find button is clicked', async () => {
const spyGetUsers =  vi.spyOn(USER_API, 'getUsersRequest').mockImplementation(() =>{  items:[
    { firstName: 'John' , lastName: 'Smith'}
    { firstName: 'Willy' , lastName: 'Willson'}
  ]}) 

  createComponent ()
  const buttonNode = wrapper.find('.button') //not a very good selector, but we only have 1 button
  await buttonNode.trigger('click');

  await flushPromises();
  expect(spyGetUsers).toHaveBeenCalled(); //here you can also check the parameters


  expect(wrapper.text()).toContain('Smith')
  expect(wrapper.text()).toContain('Willson')
 
});

That approach works, but what if we need to test the behavior when the server returns an error? For example, when a 500 error triggers a toast notification saying, "The server is temporarily unavailable, please try again later."

This is exactly where MSW comes to the rescue.

import { server } from '@/mocks/server';
import { http, HttpResponse } from 'msw';
import { USER_FAKE_RESPONSE } from '...fixtures'
import * as MESSAGE_MODULE from "utils"
import { GET_USERS } from '@/api/constants/APIEndPoints.js';

let wrapper

const createComponent = (params {}) => {
  wrapper = shallowMount(OurGetUsersComponent, {
    props: {
      ...params.props,
    },
    global: {
      renderStubDefaultSlot: true,
      stubs: {
        ...params.stubs,
      },
    },
  });
};

test('Handling user retrieval when the search button is clicked', async () => {
const spyGetUsers =  vi.spyOn(USER_API, 'getUsersRequest') // the implementation already exists in MSW and doesn't need to be duplicated here

  createComponent ()
  // it's better to search the same way as the user  
  const buttonNode = wrapper.findAll('.button').filter(item=>item.text()=="Search")[0] 
  await buttonNode.trigger('click');

  await flushPromises();
  expect(spyGetUsers).toHaveBeenCalled(); // This step might be redundant since the result is what matters to the user

  expect(wrapper.text()).toContain(USER_FAKE_RESPONSE.items[0].lastName)
  expect(wrapper.text()).toContain(USER_FAKE_RESPONSE.items[1].lastName)
 
});

test('Handling server errors when retrieving users', async ()=>{
spyMessage = vi.spyOn(MESSAGE_MODULE , 'showErrorMessage')

  server.use(
    http.get('*' + GET_USERS, () => {
      return new HttpResponse(null, { status: 500 });
    }),
  );
  createComponent ()
  const buttonNode = wrapper.findAll('.button').filter(item=>item.text()=="Search")[0] 
  await buttonNode.trigger('click');

expect(spyMessage ).toHaveBeenCalledWith({message: 'The server is temporarily unavailable, please try again later' });

})

This way, you can make your unit tests a little more honest and your team's capabilities a little broader.

Author: Dmitry Simonov

Why did I create vue-uform

Thu, 21 Aug 2025 02:07:44 +0000

In Vue, we already have the very convenient v-model syntax sugar. It handles two essential things for us:

When a JavaScript variable has a value, it fills the input field.
When the input changes, the new value is passed back to JavaScript.

That’s basically what v-model does under the hood.

So why redefine two-way binding?

The reason is that I’ve been exploring a new approach to form validation. I believe the next generation of Vue form validators should be:

Component-driven – the form behavior is powered by components, not configuration.
Style-agnostic – no built-in styling, leaving developers free to define layouts.
Flexible with UI libraries – should work seamlessly with input components from libraries like Naive UI, Element Plus, or even fully custom ones.

What existing validators do

When I looked at existing solutions, I found a common pattern: each form field usually comes with:

A label
An input
A help message
An error message (shown when validation fails)

Some libraries solve this by bundling their own input components and tightly integrating them with validation. While this works, it reduces flexibility.

I wanted something different: a validator that lets developers use their own UI components, while still handling value binding and validation logic cleanly.

The idea: u-field component

To achieve this, I introduced the idea of a u-field component.
You can put any input component into its slot.

The u-field exposes two key bindings to its slot:

value passes the form data down to the input.
update sends the new input value back up to the form.

This makes synchronization possible, and sets the stage for validation.

For example:

<template>
  <u-field v-slot="{ value, update }">
    <input :value="value" @input="($event) => update($event.target.value)" />
  </u-field>
</template>

Why not just v-model?

Looking at Vue’s official docs, this is exactly the kind of code v-model was meant to simplify.
But when binding with parent components (not just local state), we need another kind of syntax sugar.

So, inspired by vue-macros, I created a Vite plugin to introduce a new directive: f-model.

With f-model, the example above becomes:

<u-field v-slot="{ value, update }">
  <input f-model />
</u-field>

Beyond text inputs

Of course, text inputs are the simplest case.
For other components like radio buttons, checkboxes, or selects, special handling is still needed.

For third-party components, it’s straightforward:

With a regular input:

<input f-model />

With Naive UI’s n-input (which uses v-model:value):

<n-input f-model:value />

I built vue-uform – a unstyled, component-driven form validation library for Vue 3

Mon, 18 Aug 2025 20:25:28 +0000

Hey everyone

I’ve been working on a Vue 3 form library called vue-uform, and I think it might be useful for folks who want flexible, unstyled, component-driven form validation without the boilerplate.

Why I built it

Most form libraries either:

Come with a bunch of built-in styles that don’t match your design system, or
Require too much JS/TS setup for simple forms.

vue-uform takes a different approach:

No built-in styles – you have full control over HTML & CSS.
Treats components as first-class citizens – validation, data flow, and UI are all component-based.
Works with any UI library (Element Plus, Naive UI, etc.).
Supports built-in & custom validation rules (inspired by FormKit).

Quick Example

<script setup>
const formValues = { username: '', password: '' }

function doLogin(data) {
  console.log(data)
}
</script>
<template>
  <u-form :values="formValues" @submit="doLogin">
    <u-field name="username" label="Username" validation="required" v-slot="{ value, update }">
      <input f-model />
    </u-field>

    <u-field name="password" label="Password" validation="required|min:6" v-slot="{ value, update }">
      <input type="password" f-model />
    </u-field>

    <u-submit>Login</u-submit>
  </u-form>
</template>

That f-model directive is provided by a small Vite plugin – it’s like v-model but tailored for form fields.

✅ Built-in validation rules include:

required, number, email, between, starts_with, url, and more – you can also add your own custom rules with parameters

Example custom rule:

<script setup lang="ts">
function isfruit(node: FieldNode): boolean | string {
  const { value } = node;
  if (value.value != "apple" && value.value != "banana") {
    return "this value is not apple or banana";
  }
  return true;
}
</script>
<template>
    <u-field
      name="fruit"
      label="Fruit"
      help="please input a fruit"
      :rules="{ isfruit }"
      validation="required|isfruit"
      v-slot="{ value, update }"
    >
      <input f-model />
    </u-field>
</template>

Installation

pnpm install vue-uform
pnpm install @vue-uform/vite-plugin -D

Links

GitHub: https://github.com/tu6ge/vue-uform

StackBlitz: https://stackblitz.com/~/github.com/tu6ge/vue-uform-example

# Automated Anomaly Detection and Predictive Maintenance in Drone Motor Control Systems

Fri, 08 Aug 2025 07:06:32 +0000

Automated Anomaly Detection and Predictive Maintenance in Drone Motor Control Systems using Federated Learning and Gaussian Process Regression

Abstract: This research proposes a robust and scalable solution for anomaly detection and predictive maintenance in drone motor control systems utilizing a federated learning framework combined with Gaussian Process Regression (GPR). Traditional centralized approaches to anomaly detection suffer from data privacy concerns and struggle to adapt to the diverse operating conditions of individual drones. Federated learning allows for model training across decentralized datasets residing on the drones themselves, preserving data privacy while leveraging a global model. Integration with GPR provides uncertainty quantification and enables accurate prediction of motor degradation, facilitating proactive maintenance and minimizing downtime. This system is industrially viable, offering immediate improvements in drone fleet management with an estimated 15-20% reduction in maintenance costs and a 5-10% improvement in operational reliability.

Introduction

The drone industry continues to experience exponential growth across various sectors, including logistics, agriculture, surveillance, and infrastructure inspection. A critical component of drone operation is the motor control system, responsible for efficient and precise flight control. Unexpected motor failures pose significant risks, leading to operational downtime, potential damage, and safety hazards. Current anomaly detection methods often rely on centralized data collection, which raises data privacy concerns and hinders adaptability to varied flight conditions. This research addresses these limitations by introducing a federated learning and Gaussian Process Regression (GPR) based approach that distributes model training while providing accurate predictive maintenance capabilities.

Related Work & Novelty

Existing drone anomaly detection methods commonly employ machine learning algorithms like Support Vector Machines (SVMs) or Recurrent Neural Networks (RNNs), trained on centralized datasets. These methods, while effective, are vulnerable to single points of failure and privacy breaches. Federated learning has emerged as a promising alternative for distributed machine learning, protecting data privacy while aggregating knowledge. However, few existing applications integrate federated learning with accurate predictive models capable of quantifying uncertainty. This study uniquely combines federated learning with Gaussian Process Regression (GPR) to achieve both privacy preservation and robust predictive maintenance, exceeding the performance of traditional centralized methods and providing greater operational insight. The novel aspect lies in the adaptive weighting of each drone’s contribution during the federated learning process, dynamically adjusted based on the quality and variance of their local data.

Methodology

3.1 System Architecture: The system comprises three key components: the Drone Agent, the Federated Learning Server (FLS), and the Maintenance Management Interface (MMI).

Drone Agent: Each drone acts as a client in the federated learning process. It collects real-time data from motor control sensors (current, voltage, temperature, RPM, vibration frequency) and trains a local GPR model on this data.

Federated Learning Server (FLS): The FLS orchestrates the federated learning process. It distributes shared GPR model architectures to each drone agent and aggregates their locally trained model parameters using a secure aggregation protocol.

Maintenance Management Interface (MMI): The MMI presents a dashboard for visualizing model performance, anomaly scores, and predicted remaining useful life (RUL) of each motor.

3.2 Federated Learning Algorithm: The federated learning process follows the FedAvg algorithm, modified to incorporate adaptive weighting.

Initialization: Each drone receives an initialized GPR model with randomly generated hyperparameters.

Local Training: Each Drone Agent trains its local GPR model using data collected over a defined time window (T) using stochastic gradient descent.

Model Aggregation: The FLS aggregates the locally trained model parameters (weights, hyperparameters) from each drone using a weighted averaging scheme:

global_model_parameters = SUM (from i=1 to N) of (w_i * local_model_parameters_i)

Where:

global_model_parameters is the global GPR model parameters (denoted as theta_global).

N is the number of participating drones.

w_i is the weight assigned to the i-th drone.

local_model_parameters_i is the set of parameters from the i-th drone’s local GPR model (denoted as theta_i).

The weights (w_i) are dynamically adjusted based on a variance metric of each drone’s local training data:

w_i = 1 / (local_data_variance_i)

Where:

local_data_variance_i is the variance of the local training data for drone i (denoted as sigma_i^2).

Iteration: The process repeats for a fixed number of iterations.

3.3 Gaussian Process Regression (GPR): GPR is employed for anomaly detection and RUL prediction due to its ability to provide probabilistic predictions and quantify uncertainty.

Kernel Selection: The Matérn kernel is chosen due to its flexibility in capturing varying degrees of smoothness in the motor degradation process.

RUL Prediction: The RUL of each motor is predicted by fitting the GPR model to historical data and extrapolating the degradation trend.

Anomaly Detection: Anomalies are flagged when the observed sensor readings deviate significantly from the GPR’s predicted value, exceeding a pre-defined threshold based on the GPR’s predictive variance.

Experimental Design

4.1 Dataset: A simulated dataset of drone motor control data is generated using a physics-based motor model, incorporating various degradation mechanisms (wear, friction, corrosion). The dataset consists of 100 drones, each operating under diverse environmental conditions. The dataset contains 1 million data points per drone.

4.2 Baseline Comparison: The proposed federated learning + GPR system will be compared against the following baseline methods:

Centralized GPR: A standard GPR model trained on a centralized dataset of all drone data.

Independent GPR: Each drone trains its own GPR model independently without federated learning.

4.3 Evaluation Metrics: The following metrics will be used to evaluate system performance:

Anomaly Detection Accuracy: Precision, Recall, F1-score

RUL Prediction Error: Root Mean Squared Error (RMSE)

Communication Overhead: Average communication rounds required for convergence.

Privacy Preservation: Differential Privacy parameter (epsilon, delta). A higher value indicates stronger privacy guarantees.

Data Analysis and Results Prediction

We predict that the federated learning + GPR system will outperform both baseline methods in terms of anomaly detection accuracy and RUL prediction error while preserving data privacy. The adaptive weighting scheme is expected to improve convergence speed and overall model accuracy. The system is expected to achieve an F1-score of 0.95 for anomaly detection, an RMSE of 5% for RUL prediction, and a differential privacy parameter of (epsilon, delta) = (0.1, 1e-6). A communication overhead of roughly 15-20 rounds is expected for convergence.

Scalability Roadmap

Short-Term (6-12 months): Deploy the system on a fleet of 100 drones, validating performance in a real-world environment and refining model parameters. Optimize communication protocols for low-bandwidth environments.

Mid-Term (1-3 years): Scale the system to a fleet of 1000 drones, incorporating support for heterogeneous drone models and sensor configurations. Investigate using blockchain technology for secure and auditable data aggregation.

Long-Term (3-5 years): Integrate the system with a cloud-based maintenance planning platform, enabling automated scheduling of maintenance activities and optimizing drone fleet utilization. Explore advanced federated learning techniques like personalization and edge device intelligence.

Conclusion
This research introduces a novel framework for drone motor control system management, combining federated learning and Gaussian Process Regression for enhanced anomaly detection, accurate RUL prediction, and data privacy preservation. The proposed system offers significant advantages over existing methods and is poised to revolutionize drone fleet management, driving operational efficiency and reducing maintenance costs. This approach is immediately commercializable and provides a scalable foundation for future advancements in drone technology and predictive maintenance.
Mathematical Details & Appendices (Further detailing GPR equations, FedAvg algorithm pseudocode, and kernel parameter optimization) – Omitted for brevity, available upon request.

Commentary
Explanatory Commentary: Automated Drone Motor Maintenance with Federated Learning & Gaussian Processes

This research tackles a growing problem in the drone industry: ensuring reliable operation and minimizing costly motor failures. Drones are increasingly used in everything from package delivery to agricultural inspections, making their performance vital. Unexpected motor breakdowns lead to downtime, potential damage, and safety risks. This study proposes a smart system that uses advanced technology to predict when drone motors will need maintenance, before failures occur – a process known as predictive maintenance. It achieves this using a combination of federated learning and Gaussian Process Regression (GPR).

Research Topic Explanation and Analysis

The core challenge isn't just predicting failures; it’s doing so while protecting sensitive data. Traditional approaches collect all drone flight data in one central location. This raises privacy concerns and makes it difficult to adapt the system to the unique operating conditions of each drone. Imagine a drone working in a hot desert versus one operating in a cold, rainy environment; their motor wear patterns will be very different. Federated learning solves this data privacy dilemma and adaptability issue.

Federated Learning: Decentralized Intelligence. Think of it like this: instead of everyone sending their data to a central brain, each drone has its own small brain (a local model) that learns from its own experiences. These "brains" regularly communicate with a central coordinator (the Federated Learning Server or FLS), sharing only how they’ve learned (model updates, not the raw data itself). The coordinator then combines these updates to create an improved overall "brain" for the whole fleet. This protects individual drone data while still allowing the fleet to benefit from collective learning. It’s like a group discussing ideas without revealing their personal notes.

Gaussian Process Regression (GPR): Predicting the Future. GPR is a specialized tool for making predictions with uncertainty. Unlike simpler models that just give a single predicted value, GPR provides a range of possible values, along with an estimate of how confident it is in each prediction. In this context, GPR models the degradation process of a motor. It learns from the historical sensor data (current, voltage, temperature, RPM, vibration) and then uses this knowledge to predict how the motor's performance will change over time, effectively forecasting its RUL – Remaining Useful Life. The uncertainty information is crucial; if GPR is unsure, it flags the motor for inspection.

Key Question & Technical Advantages: The central question is: Can we accurately predict motor failure while keeping drone data private and adaptable to varied conditions? This research's advantage lies in this combined approach. Centralized methods are privacy-invasive, while independent GPR models on each drone lack the benefits of shared knowledge. Federated learning paired with GPR offers the best of both worlds: privacy and collective intelligence. A limitation is the computational burden on each drone for local GPR training and the communication overhead between drones and the FLS.

Mathematical Model and Algorithm Explanation

The algorithm at the heart of this system is a modified version of FedAvg (Federated Averaging). The goal is to find the best global GPR model.

Local Training: Each drone uses sensor data to train a GPR model. The GPR model uses a Matérn kernel, a mathematical function describing how data points relate to each other. Think of it like a recipe—the kernel defines the ingredients and mixing process for making predictions. The Matérn kernel is flexible, allowing it to capture varying levels of smoothness in the motor degradation process; some motors wear gradually, others more abruptly. The training uses stochastic gradient descent (SGD), a technique involving iteratively refining the GPR model’s parameters to better fit the sensor data. It’s like slowly adjusting a radio dial until you get a clear signal.

Weighted Averaging: The FLS combines model updates from each drone. Not all drones are created equal: some might experience more extreme conditions or have better sensors, so their data is given more weight in the aggregation process. The weight assigned to each drone's model is inversely proportional to the variance (spread) of its local data; drones with more consistent data have higher weights. This dynamic weighting is a key innovation. Mathematically, w_i = 1 / (local_data_variance_i), where w_i is the weight assigned to drone i and local_data_variance_i is the variance of its local data.

Iteration: The process repeats—local training, global aggregation—for a set number of rounds, gradually improving the global GPR model’s accuracy.

Experiment and Data Analysis Method

To test the system, the researchers created a simulated dataset—a "digital twin" of a drone motor. This means they built a computer model that accurately mimics a real motor’s behavior, including the gradual degradation caused by wear, friction, and corrosion. The dataset comprises 100 drones, each operating under various simulated environmental conditions.

Experimental Setup Description: The "physics-based motor model" simulates the factors affecting motor life. Advanced terminology like “wear, friction, and corrosion” are modeled through equations that describe how forces and material properties change over time. This ensures the data reflects realistic degradation patterns. The experiment involves running the federated learning algorithm with the simulated data and then comparing the results against two baseline methods: a traditional centralized GPR and individual GPR models on each drone.

Data Analysis Techniques: The researchers used several metrics to evaluate performance:

Anomaly Detection Accuracy: Measured by Precision, Recall, and F1-score—how well the system identifies true anomalies and avoids false alarms.

RUL Prediction Error: Measured by Root Mean Squared Error (RMSE)—how closely the predicted RUL matches the actual RUL. A lower RMSE indicates better prediction accuracy.

Communication Overhead: Number of communication rounds to reach convergence, vital for efficiency.

Privacy Preservation: Differential Privacy parameter (epsilon, delta)—lower values demonstrating stronger data protection. Statistical analysis compared models, and regression analysis identified the relationships between sensor readings and degradation patterns.

Research Results and Practicality Demonstration

The results showed that the federated learning + GPR system outperformed the baselines in both anomaly detection and RUL prediction. The adaptive weighting scheme helped the system converge faster (using fewer communication rounds) and achieve higher accuracy.

Results Explanation & Visual Representation: The researchers predict an F1-score of 0.95 for anomaly detection, meaning the system correctly identifies approximately 95% of the true motor anomalies. The RMSE for RUL prediction is 5%, indicating a respectable degree of accurate prediction.

Practicality Demonstration: The estimated reduction in maintenance costs (15-20%) and an improvement in operational reliability (5-10%) provide a strong business case. The immediate commercial value is enhanced fleet management. Imagine an airline using this system to predict maintenance needs for their drone fleet inspecting aircraft—reducing downtime and costs significantly.

Verification Elements and Technical Explanation

The researchers rigorously validated their system. The physics-based motor model ensures that the simulated data accurately replicates real-world conditions. The dynamic weighting scheme implemented in FedAvg was tested to specifically determine that less variance results in higher model accuracy than a system that does not weight the data accordingly. These weights prioritized drones exhibiting consistent degradation patterns.

Verification Process: By comparing the performance of the federated learning system with the centralized and independent GPR models, they demonstrated that federated learning consistently delivered superior results while protecting data privacy.

Technical Reliability: The FedAvg algorithm, while modified, is a well-established method in federated learning. The added adaptation ensures model accuracy and stability during forecasting.

Adding Technical Depth

This research builds on the existing body of work in federated learning and GPR, but specifically advances it by integrating these techniques in a targeted way for predictive maintenance. Previous federated learning applications often used simpler anomaly detection methods. The innovation lies in the combination of federated learning with the sophisticated and accurate predictive capabilities of GPR. The adaptive weighting scheme differentiates this study from standard FedAvg, which generally weights all drones equally. Further, it employs a Matérn Kernel, which accounts for variance during the training of the data.

Technical Contribution: The differentiation lies in contributing a novel federated learning approach coupled with GPR, specifically tailored to drone motor predictive maintenance. The adaptive weighting scheme directly addresses the challenges of data heterogeneity and varying data quality across drones within a fleet. This extends the reach of federated learning to more complex predictive tasks, proving its real-world application in time-critical fields like drone operations.

Conclusion:

This study presents a compelling solution for optimizing drone maintenance, balancing accuracy, privacy, and practicality. With real-world applications ranging from logistics to infrastructure inspection, this federated learning and GPR-powered system promises to revolutionize drone fleet management, paving the way for safer, more efficient, and cost-effective drone operations.

This document is a part of the Freederia Research Archive. Explore our complete collection of advanced research at en.freederia.com, or visit our main portal at freederia.com to learn more about our mission and other initiatives.

How to apply various postprocessing effects like Bloom, Motion Blur, and Pixelation inside a Vue

Mon, 07 Jul 2025 02:09:36 +0000

Want to bring cinematic 3D effects to your Vue app? Enter TresJS—a powerful, declarative wrapper around Three.js that plays beautifully with Vue 3's Composition API.

If you’ve ever dreamed of adding Bloom, Pixelation, Motion Blur, or even Glitch effects with just a few lines of code—TresJS makes it possible.

Setup

First, install TresJS and its core dependencies:

npm install @tresjs/core three @tresjs/post-processing

If you're using Vite, you're ready to go. Make sure you’re on Vue 3.

Example 1: Glowing Sphere with Bloom

<!-- GlowingSphere.vue -->
<template>
  <Canvas clear-color="#000">
    <TresPerspectiveCamera :position="[0, 0, 5]" />
    <TresAmbientLight />
    <TresPointLight :intensity="1.5" :position="[5, 5, 5]" />

    <TresMesh>
      <TresSphereGeometry :args="[1, 32, 32]" />
      <TresMeshStandardMaterial color="hotpink" emissive="hotpink" emissiveIntensity="1" />
    </TresMesh>

    <EffectComposer>
      <Bloom :intensity="1.5" :luminanceThreshold="0.4" />
    </EffectComposer>
  </Canvas>
</template>

Result: A smooth glowing neon sphere on a black background—great for sci-fi UIs.

Example 2: Motion Blur for Fast Movement

Motion blur works best with animation. Here’s a spinning cube with blur.

<!-- SpinningCube.vue -->
<template>
  <Canvas>
    <TresPerspectiveCamera :position="[0, 0, 6]" />
    <TresAmbientLight />

    <TresMesh ref="cube" :rotation="rotation">
      <TresBoxGeometry />
      <TresMeshStandardMaterial color="#00ffff" />
    </TresMesh>

    <EffectComposer>
      <MotionBlur :samples="32" />
    </EffectComposer>
  </Canvas>
</template>

<script setup>
import { ref, onMounted } from 'vue'
import { useRenderLoop } from '@tresjs/core'

const rotation = ref([0, 0, 0])

useRenderLoop(({ delta }) => {
  rotation.value[0] += delta
  rotation.value[1] += delta * 1.2
})
</script>

Result: A smoothly rotating cube with natural blur on edges—great for dynamic UIs.

Example 3: Pixelation Effect (Retro Style)

Perfect for game UIs or retro visuals.

<!-- PixelatedScene.vue -->
<template>
  <Canvas>
    <TresPerspectiveCamera :position="[0, 0, 5]" />
    <TresAmbientLight />
    
    <TresMesh>
      <TresTorusKnotGeometry :args="[1, 0.3, 100, 16]" />
      <TresMeshStandardMaterial color="limegreen" />
    </TresMesh>

    <EffectComposer>
      <Pixelation :granularity="5" />
    </EffectComposer>
  </Canvas>
</template>

Result: The entire scene appears in blocky, pixelated chunks—a nostalgic, game-like vibe.

Stacking Multiple Effects

Yes, you can combine them!

<EffectComposer>
  <Bloom :intensity="1.2" />
  <Noise opacity="0.05" />
  <Vignette eskil="false" offset="0.5" darkness="0.8" />
</EffectComposer>

This stack creates a subtle cinematic atmosphere: a glowing bloom, grainy texture, and dark edges—like a movie scene.

Dev Tips

Performance: Effects like bloom and motion blur can be GPU-heavy. Test on multiple devices.
Declarative FTW: TresJS uses Vue’s reactivity, so animating or toggling effects is dead simple.
Debug: Use <Stats /> from TresJS for FPS monitoring.

Final Thoughts

TresJS makes high-end visuals accessible to frontend devs without needing to dive deep into raw WebGL or complex shaders. Whether you're building a dashboard, a product showcase, or an immersive landing page, effects like bloom, blur, and pixelation can instantly make your app stand out.

If you're already in the Vue ecosystem and want cinematic 3D without the Three.js boilerplate—TresJS is your toolkit.

Clean Async State Management with Pinia Colada

Sat, 05 Jul 2025 08:33:04 +0000

Managing async state—think loading spinners, error handling, stale data—is notoriously messy. If you’ve wrestled with nested subscriptions or redundant fetch logic in Vue+Pinia apps, Pinia Colada might be the game-changer you need.

What Is Pinia Colada?

Pinia Colada is a powerful data-fetching layer built on top of Pinia. It eliminates boilerplate by providing:

Automatic caching and deduplication
Smart query invalidation
Declarative API for queries (data fetches) and mutations
Support for optimistic updates, SSR, and tree-shaken size of \~2 KB

Quick Start

npm install pinia @pinia/colada

Then in your Vue app setup:

import { createPinia } from 'pinia'
import { PiniaColada } from '@pinia/colada'

app.use(createPinia())
app.use(PiniaColada, {/* optional plugins */})

Now you’re ready to use useQuery and useMutation everywhere.

Example: Querying Data

Instead of manual loading flags, error state, and fetch logic:

const { data, error, isPending, isLoading, refresh } = useQuery({
  key: ['users'],
  query: fetchUsers,
})

Then in the template, you can declaratively handle the three states:

isPending — first fetch
isLoading — refreshes
error — if broken
data — once resolved

Mutations & Invalidation

const { mutate: addComment, isLoading } = useMutation({
  mutation: postComment,
  onSettled: async ({ id }) => {
    await queryCache.invalidateQueries({ key: ['comments', id], exact: true })
  }
})

This lets you optimistically update and ensure fresh data before closing modal dialogs or user notifications.

Why You’ll Love It

Minimal state boilerplate: No more juggling isLoading, isError, and data manually.
Built-in caching and deduplication for better UX and efficiency.
Fully typed, tree-shakeable, zero deps (besides Pinia), and SSR-ready.
Plugins like autoRefetch and delay help avoid flickers or stale data.

Real-World Feedback

Reddit users highlight Pinia Colada's advantage for API-driven state:

“This is what Pinia stores call service methods… API calls inside sweet local store. It’s perfect to avoid multiple fetches.”

Others note:

“Pinia is for global app state. For API caching use Tanstack Query… Pinia Colada consolidates the conundrum.”

TL;DR – When to Use It

Use Pinia Colada when:

You want clean, reusable logic for API calls
You care about efficient caching and UX consistency
You prefer declarative state over imperative patterns
You work with mutable server data and want stale-data control

Want to Go Further?

Explore optimistic updates, SSR support, and GraphQL usage
Combine with Vue Router Data Loaders and modular async handling
Try plugins like auto-refetch and delay to polish UX

Pinia Colada brings a modern, well-structured approach to async state in Vue apps—cutting boilerplate, reducing bugs, and improving developer happiness. Whether it's simple CRUD or complex dialogs or pagination, it's well worth a look.

Turn Your Vue Web App into a Mobile App (Android & iOS) in Just 5 Minutes

Mon, 23 Jun 2025 15:49:53 +0000

In this quick tutorial, I’ll show you how to use CapacitorJS to convert your existing Vue.js web app into a fully functional mobile app for Android and iOS — without rewriting your codebase.

▶️ Watch the full tutorial here

This method is the fastest way to bring your frontend skills to mobile platforms using tools you already know.

Commands Used in This Video:
Install the Capacitor CLI locally

npm install -D @capacitor/cli
Initialize Capacitor in your Vue project

npx cap init
Install the required packages

npm install @capacitor/core @capacitor/ios @capacitor/android
Add native platforms

npx cap add ios
npx cap add android
Build and sync your app

npm run build
npx cap sync
Open the native projects in your IDE

npx cap open ios
npx cap open android
What is CapacitorJS and Why Use It?
CapacitorJS is a modern open-source native runtime developed by the Ionic team. It allows developers to build cross-platform mobile apps using web technologies like HTML, CSS, and JavaScript — without needing to rewrite your app in native languages such as Swift or Kotlin.

With Capacitor, your web app runs inside a native WebView container, enabling it to function like a true mobile app. Beyond just wrapping your app, Capacitor provides easy access to native device features like the camera, filesystem, geolocation, push notifications, and more through a rich plugin ecosystem.

Cross-Framework Compatibility
One of Capacitor’s biggest strengths is that it works with any modern JavaScript framework. Whether you are using:

Vue.js (like in this tutorial)
React
Angular
Svelte
Or even plain vanilla JavaScript
Capacitor can seamlessly integrate with your existing project. This flexibility means you don’t need to change your frontend framework or rewrite your codebase to build mobile apps — just add Capacitor and you’re good to go.

Why Choose Capacitor Over Other Solutions?
Compared to alternatives like Cordova, Capacitor is:

More modern and lightweight, built with a focus on web standards and developer experience
Better integrated with native SDKs, giving you easier access to device APIs
Supports live reload and faster development cycles
Actively maintained and backed by the Ionic team, ensuring ongoing support and improvements
How Capacitor Works Under the Hood
Capacitor takes your built web app (the static files you generate when you run npm run build) and packages it inside a native project shell for iOS and Android. This native shell includes:

A WebView component that loads your web app
A bridge that connects JavaScript code to native device APIs
Native projects that you can open and customize in Xcode (for iOS) or Android Studio (for Android)
This means your app behaves just like a native app on mobile devices but allows you to write your entire UI and logic in web languages.

What You Need to Get Started
Your web app ready to build (Vue, React, Angular, or vanilla JS)
Node.js and npm installed on your system
Android Studio and/or Xcode installed for running native projects
Basic familiarity with command-line tools
Wrapping Up
Using CapacitorJS, you can quickly turn your existing web app into a mobile app without the overhead of learning native development. This is a huge advantage for web developers looking to expand their reach to mobile users efficiently.

If you’re comfortable building with Vue (or any JavaScript framework), adding Capacitor to your workflow will open up new possibilities for app distribution on mobile platforms — faster and easier than ever before.

How I Built a Smart Elevator Control System in Vue 3 and TypeScript

Fri, 20 Jun 2025 01:23:32 +0000

Have you ever wondered how elevator systems operate behind the scenes? I recently developed a real-time elevator control simulation using Vue 3, TypeScript, and Tailwind CSS a project that brings the complexity of multi-elevator coordination to life through a modern web interface.

In this post, I’ll walk you through the architecture, implementation details, and key lessons learned while building this interactive simulation from the ground up.

Project Overview
This simulation models a 10-floor building served by 4 independently operating elevators. Each elevator intelligently picks up passengers, navigates between floors, and drops them off at their destination all in real time with state updates every 10 seconds.

Live Demo Highlights
Four elevators running concurrently
Real-time passenger pickup & drop-off
Dynamic floor request generation
Visual floor indicators with request tracking
Scrollable, real-time activity logs
Modern, responsive user interface
Tech Stack
Frontend Framework: Vue 3 + Composition API
Language: TypeScript
Styling: Tailwind CSS
Build Tool: Vite
State Management: Vue’s built-in reactivity & composables
System Architecture
Core Data Structures
To ensure clarity and type safety, the system relies on three main TypeScript interfaces:

    src/
├── components/
│   ├── ElevatorCard.vue
│   └── elevator/
│       ├── ElevatorStatus.vue
│       ├── FloorDisplay.vue
│       ├── PassengerInfo.vue
│       └── ElevatorLogs.vue
├── composables/
│   └── useElevatorSystem.ts
├── utils/
│   └── elevatorUtils.ts
└── types/
    └── elevator.ts

Key Implementation Details

Elevator Movement Logic

A basic but effective algorithm handles direction reversal and floor progression:

    function moveElevator(elevator: Elevator) {
  if (elevator.direction === 'up') {
    if (elevator.currentFloor < elevator.flors.length) {
      elevator.currentFloor++
      log(elevator, `Moved up to floor ${elevator.currentFloor}`)
    } else {
      elevator.direction = 'down'
      elevator.currentFloor--
      log(elevator, `Reached top. Reversing to down → floor ${elevator.currentFloor}`)
    }
  } else {
    if (elevator.currentFloor > 1) {
      elevator.currentFloor--
      log(elevator, `Moved down to floor ${elevator.currentFloor}`)
    } else {
      elevator.direction = 'up'
      elevator.currentFloor++
      log(elevator, `Reached bottom. Reversing to up → floor ${elevator.currentFloor}`)
    }
  }
}

Passenger Pickup & Drop-Off

Passengers are generated and assigned direction-based destinations:

    function handlePickup(elevator: Elevator, floor: Floor) {
  const waitingPassengers = floor.up || floor.down ? 1 : 0
  if (waitingPassengers > 0) {
    const newPassenger: Passenger = {
      id: Date.now(),
      destinationFloor: Math.floor(Math.random() * 10) + 1,
      direction: floor.up ? 'up' : 'down'
    }

    if (floor.up) {
      while (newPassenger.destinationFloor <= elevator.currentFloor) {
        newPassenger.destinationFloor = Math.floor(Math.random() * 10) + 1
      }
    }

    elevator.passengers.push(newPassenger)
    log(elevator, `Picked up passenger going to floor ${newPassenger.destinationFloor}`)
    floor.up = false
    floor.down = false
  }
}

System Controller

The main composable manages the elevator system in real time:

    function useElevatorSystem(totalFloors: number = 10, maxPassengers: number = 5) {
  const elevators = ref<Elevator[]>([])
  let moveIntervalId: ReturnType<typeof setInterval> | null = null

  function startSystem() {
    moveIntervalId = setInterval(() => {
      elevators.value.forEach(elevator => {
        dropOffPassengers(elevator)
        moveElevator(elevator)

        const currentFloorObj = elevator.flors.find(f => f.id === elevator.currentFloor)
        if (currentFloorObj && (currentFloorObj.up || currentFloorObj.down)) {
          handlePickup(elevator, currentFloorObj)
        }

        dropOffPassengers(elevator)
      })

      elevators.value.forEach(generateRandomFloorRequest)
    }, 10000)
  }

  return { elevators, initializeElevators, startSystem, stopSystem }
}

User Interface Design

Floor Display

Floor number with a circular badge

Highlighted active floor

Up/down request indicators

Clear floor labeling

Real-Time Feedback

Live updates for each elevator

Passenger count & destinations

Scrollable log with timestamps

Animated visual cues for movement

Challenges & Solutions

State Management Complexity

Managing 4 elevators with independent logic and shared global state was no small feat.

Solution: Leveraged Vue 3’s Composition API and ref/reactive to create performant, scoped reactivity.

Real-Time Synchronization

Ensuring consistent updates while keeping elevator logic independent.

Solution: I used a centralized interval loop to orchestrate operations while preserving elevator autonomy.

Type Safety

Elevators, floors, and passengers required intricate interrelations.

Solution: Strongly typed interfaces allowed safe interaction across components and composables.

Performance Highlights

Reactive efficiency via scoped updates

Efficient log storage with unshift() for quick inserts

Resource cleanup with interval teardown on unmount

Optimized rendering through component isolation

What’s Next?

The system offers exciting possibilities for further development:

Passenger Priorities: VIP or emergency overrides

Energy Efficiency: Smarter routing logic

Multi-Building Support: Shared elevator infrastructure

Analytics: Real-time performance dashboards

Interactive Mode: Manual elevator control by users

Lessons Learned

Composables = Clean architecture

TypeScript = Fewer bugs

Timing systems demand precision

Visual feedback = Better UX

Logging simplifies debugging & UX clarity

Conclusion

This project was a rewarding challenge that merged real-time systems thinking with modern frontend development. Vue 3’s reactivity, TypeScript’s type assurance, and Tailwind’s rapid styling capabilities came together to create a clean, scalable, and visually engaging simulation.

If you're passionate about algorithms, state management, or interactive web interfaces, I highly encourage exploring or extending this project.

Source Code

The full code is available on GitHub. Feel free to fork it, experiment with new features, or optimize the algorithms!

Project Links:

Live Demo: View Project

GitHub Repository: Smart-Elevator-Control-System

How to create admin panel in a minutes

Wed, 14 May 2025 20:48:42 +0000

I will show you how to easily create an extendable admin panel using the open-source (and free!) AdminForth framework. The setup process is incredibly simple and takes just a few minutes.

Requirements

All you need is Node.js version 20 or later installed.

Let's get started

Run:

npx adminforth create-app

This will launch a small utility that will ask you to name your project.
Then, it will prompt you for your database URL in the field "Please specify the database URL to use >".

You can use SQLite, Postgres, MySQL, MongoDB, or ClickHouse URLs.
For testing purposes, we recommend SQLite, as it doesn't require a daemon and works out of the box.

Once the app is created, you should see:

Next steps: prepare and run the app

Run the suggested commands:

cd adminforth-app
npm run makemigration -- --name init && npm run migrate:local
npm run dev

That's it! Open http://localhost:3500/ in your browser and you should see:

⚠️ In production, be sure to change the password for this user via the admin panel.

You will now see a list of admin users:

Try adding a user, and you can also test logging in with that user from an incognito window.
Feel free to play around — try filters, navigation, and more.

How to add a table to AdminForth Admin?

Now comes the most exciting part.
By now, Prisma has generated a migration for the initial adminuser table. But what if you want to manage additional tables from your existing database or add new ones? Let's do that.

Let's add a new table to our SQLite database. Open your project in VS Code / Cursor:

code .

Now, add the following code to your Prisma schema:

model car {
  id            String   @id
  title         String
  max_speed     Int
  preview       String?   
  price         Decimal
  currency      String
}

Create and apply the migration:

npm run makemigration -- --name add_car_model && npm run migrate:local

AdminForth is migration-agnostic — it never manages your database schema itself and can work with any database structure.
For quick-start and testing purposes, the app created via adminforth create-app bundles Prisma, which we used here for our SQLite schema.
However, you're free to use any migration tool for your database. All AdminForth needs to know is the table and field names for the next step.

Define the resource

Create a new resource file in the resources folder named car.ts:

import { AdminForthDataTypes, AdminForthResourceInput } from "adminforth";
import { randomUUID } from "crypto";


export default {
  table: "car",
  resourceId: "car",
  dataSource: "maindb",
  columns: [
    {
      name: "id",
      fillOnCreate: () => randomUUID(),  // generate a random UUID when creating a new record in admin
      showIn: {
        create: false,
        list: false,
      }
    },
    {
      name: "title",
      type: AdminForthDataTypes.STRING, // enforce STRING type (SQLite supports only TEXT, this ensures single-line input)
    },
    {
      name: "max_speed",
      inputSuffix: "km/h", // add a suffix in create/edit forms
    },
    {
      name: "preview",
    },
    {
      name: "price",
    },
    {
      name: "currency",
      enum: [  // define an enumeration — AdminForth will automatically create a dropdown
        {
          label: "Bitcoin",
          value: "BTC",
        },
        {
          label: "Tether",
          value: "USDT",
        },
      ]
    }
  ]
} as AdminForthResourceInput;

Now import this resource into index.ts:

import carsResource from "./resources/car.js";

And add it to the resources list so AdminForth will know about it:

  resources: [
    usersResource,
    carsResource, // added here
  ],

Finally, let's add a menu item so you can access the resource from the UI:

  menu: [
    { type: 'heading', label: 'SYSTEM' },
    {
      label: 'Users',
      icon: 'flowbite:user-solid',
      resourceId: 'adminuser'
    },
    // added this
    {
      label: 'Cars',
      icon: 'fa6-solid:car-side',
      resourceId: 'car'
    }
  ],

And you're done!

Play around by adding your favorite cars and try filtering them.
That's it for today! If you enjoyed this, feel free to leave a comment or reaction.
Let me know if you'd like me to create more posts about extending and scaling your admin panel, adding powerful features like audit logs, file uploads, Google login, password reset, CSV import/export, and much more.

I’m looking forward to your reactions!

How I Started Writing Unit Tests for Vue Components

Sun, 30 Mar 2025 02:37:53 +0000

At some point, every frontend developer realizes that it would be great to somehow verify that their code is working as expected. For me, this moment came after a painful migration from Vue 2 to Vue 3, with tons of bugs and defects. It left me with yet another strand of gray hair, and I wasn’t the only one suffering.

My project and technology stack

The current project I’m working on is a classic CRM, full of forms upon forms, list rendering, modals, and constant data transformation. The technology stack includes Vue 3, Pinia, Vite, and ElementPlus, which allows for fast and flexible interface development.

Why unit tests?

After reading up on the theory behind pyramids and testing cups, I concluded that it’s easier to gradually add “unit” tests for new components and features, as well as cover any bugs with tests.

Just a quick note on the testing pyramid. This concept, introduced by Martin Fowler, helps organize tests in a project. It involves three levels of testing:

Unit Tests: the most basic level of testing, which checks individual modules or functions. Unit tests are fast, easy to set up
and ensure that components work correctly in isolation.
Integration Tests: test the interaction between multiple components or modules, like how components work together on a page.
They are more complex and slower, but provide an understanding of the
correctness of the integrations.
E2E tests (End-to-End Tests): test the entire application, simulating real user actions. E2E tests are slower and require
complex infrastructure but ensure that the app works as a whole.

The word "unit" is in quotes here because, when testing components in a framework, there’s a nuance: testing components isn’t always about isolating them completely.

Ideally, unit tests check isolated functions, (like the famous SUM () function), but in reality, we cannot entirely "mock" the framework. So, tests for Vue components are technically integration tests. However, for simplicity, the community continues to call them “unit tests” and I’ll stick with that terminology.

Testing options and my choice

Of course, there were other options. For example, I considered E2E testing with Playwright, which runs tests in real browsers simulating user actions. While Playwright is a powerful tool,I faced several infrastructure difficulties, which I’ll discuss later in the article.

Spoiler: the backend wasn't ready for this, and realistically, E2E tests should be written under the guidance of QA engineers - they are experts at breaking systems.

Ultimately, I decided to go with Vitest and Vue Test Utils as the main tools for testing. Vitest, as a test runner, was ideal, since Vite was already installed in the project, and Vue Test Utils provided all the necessary tools for mounting and modifying Vue components.

Why Vue Test Utils and not Testing Library? First, Vue Text Urils is recommended by the Vue community (Testing Library was a bit late in supporting Vue 3). Second, I follow "London School" of testing, where we mock everything around our component to keep tests as fair isolated as possible. In addition, the Testing Library is built on top of VTU, and I wanted fewer dependencies.

Installing and setting up

To get started, we need to install and configure Vitest and Vue test utils.

npm i -D vitest @vue/test-utils

Since our tests will run in a Node.js environment, we need DOM implementers. Vitest recommends either happy-dom or jsdom.

I chose jsdom because it’s more popular and faster, though happy-dom is an option as well as you can switch quickly.

npm i jsdom -D

Configuring the testing environment

Let's add the necessary configuration to vite.config.js.

defineConfig({
...
test: {
environment: 'jsdom',
deps: {
  inline: ['element-plus'], // optional field
},
},
})

Since Pinia is in the stack, we can either use a real store or a test store for testing. I opted for a test store, as it’s easier to mutate directly during tests.

npm i -D @pinia/testing

What and how to test?

Let's take a component with a button and a modal as an example.

Component diagram and description

Here’s the basic flow:

There is a button (which is enabled if the user has permission).
When clicked, it opens a form in a modal window (a separate
component).
When the form is filled and the "Add" button is clicked, a request is
sent to the server.
After a successful response, an event is emitted to indicate that the
document has been added.

Component code:

<template>
 <div>
   <button :disabled="!isAddDocumentAvailable" class="button button--primary" @click="addIncomingMail">Add incoming correspondence</button>
   <popup drawer :is-form-open="isFormOpen" @closed="closeForm">
     <add-incoming-mail-modal :lawsuit-id="lawsuitId" @closeForm="closeForm" @mail-added="onMailChanged" >
   </popup>
 </div>
</template>

<script setup >
import { ref } from 'vue';
import AddIncomingMailModal from '@/.../AddIncomingMailModal.vue';
const isFormOpen = ref(false);

const emits = defineEmits(['mail-added']);
defineProps({
 lawsuitId: {
   type: Number,
   required: true,
 },
});

function addIncomingMail() {
 isFormOpen.value = true;
}

function closeForm() {
 isFormOpen.value = false;
}
function onMailChanged() {
 emits('mail-added');
}
const isAddDocumentAvailable = computed(() => {
 return checkAvailabilityByClaim(...);
});
</script>

A bit of theory.

To start, we need to decide what should be tested. The general advice is to follow the user's behavior and avoid focusing on implementation details, which makes sense. Essentially, we’ll treat the component as a black box: changing (preparing) its input data and testing the output.

Note: if the component has a complex function with heavy calculations, it should ideally be extracted and tested separately as a traditional unit test.

Mocks and stubs play a key role in isolating tests. Mocks replace real dependencies, while stubs simplify interaction with external systems (API, for example). The main rule is not to mock everything: only mock what affects the functionality being tested. This reduces test dependence on the mock.

Input data includes properties, components, dependency injections, external stores, and slots. For a fair test, we should replace real components, stores, and DIs with stubs. This minimizes the risk of false positives.

Output: we should test the resulting HTMLcheck API calls (which should also be stubbed to avoid affecting the backend), and verify that events are emitted and handled correctly outside the component.

Let's move on to writing the test. First, we need to define what we are testing (as they say, "draw a circle").

describe('Adding incoming correspondence - AddIncomingMail', () => {

 it.todo('The "Add incoming correspondence" button is active if the user has rights', async () => {});

 it.todo('By clicking on the "Add incoming correspondence" button, a modal window for adding a new document opens', async () => {});

 it.todo('When adding incoming correspondence, we generate an event outside the component', async () => {});
});

Notice how these test descriptions serve as self-documenting code — in theory.

I prefer placing tests as close to the components as possible. This approach seems better suited for understanding how the component works.

In general, we draw another circle, add details, and - we have a test.

import { getButtonByText } from '@/mocks/helpersForTesting/searchElements/index.js';
import { mount } from '@vue/test-utils';
import AddIncomingMail from '@/components/AddIncomingMail.vue';
import { afterEach, beforeEach, describe, expect, it, vi } from 'vitest';
import { createTestingPinia } from '@pinia/testing';

let wrapper; // storing a component instance

beforeEach(() => { // before each test we mount the component with the initial settings
 wrapper = mount(AddIncomingMail, {
   global: {
plugins:[    
createTestingPinia({ // Create a test instance of Pinia
         createSpy: vi.fn,
         stubActions: false,
         initialState: {
           user: {
             state: {
               claims: [1,2],
             },
           },
         },
       }),]
     stubs: { // Since this is unit testing, we replace all child components with stubs
       AddIncomingMailModal: {
         name: 'AddIncomingMailModal',
         emits: ['mail-added'],
         template: '<div><h2 >Add correspondence</h2></div>',
       },
       popup: {
         props: { isFormOpen: false },
         template: '<div v-if="isFormOpen"><slot></div>',
       },
     },
   },
   props: {
     lawsuitId: 15,
   },
 });
});

afterEach(() => { // After each test, we reset the stubs and destroy the instance
 wrapper.unmount();
 vi.resetAllMocks();
});

describe('Adding incoming correspondence - AddIncomingMail', () => {
 it('The "Add incoming correspondence" button is active if the user has rights', async () => {
   const button = getButtonByText({ wrapper, buttonText: 'Add incoming correspondence' }); // Made a helper for quick search of buttons

expect(button.element.disabled).toBe(false);
});

 it('By clicking on the "Add incoming correspondence" button, a modal window for adding a new document opens', async () => {
   const button = getButtonByText({ wrapper, buttonText: 'Add incoming correspondence' });

   await button.trigger('click');
   await wrapper.vm.$nextTick(); //Since Vue makes changes asynchronously, it is important to wait

   expect(wrapper.text()).contain('Add correspondence');
 });

it('When adding incoming correspondence, we generate an event outside the component', async () => {
   const button = getButtonByText({ wrapper, buttonText: 'Add incoming correspondence' });
   await button.trigger('click');
   await wrapper.vm.$nextTick();
   const modalStub = wrapper.findComponent({ name: 'AddIncomingMailModal' });

   modalStub.vm.$emit('mail-added');
   expect(wrapper.emitted()).toHaveProperty('mail-added');
 });
});

I would like to draw your attention to how element searching occurs. You should try to search for elements the way a user would search. A less recommended, but more popular approach is using data-testid=”foo”.

Note: Settings like the ones below:

afterEach(() => { // After each test, we reset the stubs and destroy the instance
  wrapper.unmount();
  vi.resetAllMocks();
});

can be moved to external files and connected in the vite.config.js settings as a global setting:

// vite.config.js
export default defineConfig({
  test: {
    // ...
    setupFiles: ['path to your file'],
    // ...
  },
});

Problem with unit tests

Ultimately, unit tests help establish a contract between components. However, there's a downside: if we change the modal’s code, for example, its emitted events, the test for AddIncomingMail won’t fail.

This is where integration tests (as mentioned earlier) come in, testing larger sections of the app.

I haven’t fully implemented those tests yet, as I’m still thinking about the infrastructure and mocks (particularly for server requests), through a conditional msw. However, there is a problem with maintaining the relevance of mocked responses (fixtures). Ideally, I'd like to use “Vitest browser mode” or “Playwright CT”, but these tools are still in their infancy.

Start testing your code early and don’t treat testing as something separate from development. Yes, at first it will be tough, and yes, it will continue to be tough, but soon enough, you’ll just get used to it.

Author: Dmitry Simonov, Frontend Developer at ByteMinds

Coder Legion - Recent posts tagged vue

Headless Vue + WordPress Boilerplate v2.0.0

Headless Vue + WordPress Boilerplate v2.0.0

Key Features

Requirements

Folder Structure

Getting Started

Build for Production

Working with the API

Add a route (PHP)

Use it (Vue)

Routing

Integration Tips

❓ Troubleshooting

⬆️ Upgrading from 1.x

Github Repo

License

I remade Hamurabi, the game I used to play a lot as a kid

I Kept Rebuilding PDF Features in Vue 3, So I Built vue-pdf-export

What it supports

Installation

Basic usage

Canvas or selectable text

Programmatic output

Nuxt support

Pagination

Large-document rendering

Cancellation

Page-aware progress

Headers

Footers

Footer performance improvements

Repeated image optimization

Resource cleanup

Browser responsiveness

Watermarks

PDF security

Metadata and compression

Clickable links

Safer filenames

A note about encrypted raster PDFs

Testing and performance work

Why I built a Vue layer instead of replacing the underlying libraries

Current release

Try it

Run Vue Component Tests Where Vue Runs: The Browser

Why this works at all

The setup

The part that changes how the test reads

Both kinds of test, one run

Where each style fits

Try it

How to Convert Word to PDF in the Browser with Vue 3, mammoth, and html2pdf.js

Why Client-Side?

The Stack

Loading the Word Document

Generating the PDF

Styling the Preview

Handling Errors Gracefully

Lessons Learned

Try It

Want More Advanced PDF Features?

From Modal to Full Page: How We Refactored a Vue 3 Recipe Detail View (and Made It Faster)

From Modal to Full Page: How We Refactored a Vue 3 Recipe Detail View (and Made It Faster)

The Old Approach: Everything in a Modal

The New Approach: Dedicated Route + Page

What We Cut From HomePage.vue

What the Page Layout Looks Like

Mobile: Icon Buttons + Bottom Sheet AI

SEO + Meta Tags

Async Components Throughout

Auth Guard on Grocery Import

The Result

Creative Ways to Leverage JavaScript Frameworks for Modern Development

Introduction

1. Component Reusability

2. Custom Hooks in React

3. Vue Mixins for Shared Functionality

4. Angular Schematics

5. State Management through Context API