Forem: Jakub Andrzejewski

Why Loaders Matter for Performance

Jakub Andrzejewski — Mon, 11 May 2026 09:29:43 +0000

When developers think about performance optimization, they usually focus on things like:

lazy loading
caching
image optimization
bundle size

And while those things absolutely matter there’s another area that heavily impacts user experience -> Loading states and layout stability.

A badly implemented loading experience can make an app feel slow, jumpy, or frustrating to use. This is strongly connected to an important Core Web Vital metric Cumulative Layout Shift (CLS).

In this article, we’ll explore:

What CLS is
Why loaders are critical for perceived performance
How poor loading states hurt UX
Practical examples in Vue
Best practices for stable layouts

Let’s dive in.

🤔 What Is Cumulative Layout Shift (CLS)?

CLS measures how much elements unexpectedly move during page loading.

Example of bad CLS:

Text suddenly jumps down
Buttons move while you try to click
Images appear late and push content around

We’ve all experienced websites like this:

👉 You try to click something… and suddenly the layout shifts. Extremely annoying.

Why does this happen? Usually because:

content loads asynchronously
elements have no reserved space
loaders are missing
images don’t define dimensions
components suddenly appear

Why does CLS matter? Because it affects user experience, accessibility, or mobile usability (and obviously Google Core Web Vitals). Even if your app is technically fast poor layout stability can make it feel slow.

👉 Users care more about perceived performance than actual milliseconds.

A good loader communicates progress, prevents layout jumping, and makes apps feel responsive

A bad or missing loader creates uncertainty. Users start thinking:

“Did the app freeze?”
“Is something broken?”
“Why is everything moving?”

🟢 Implementing proper loaders in Vue

Let's take a look at the following example:

<script setup lang="ts">
const users = ref([])
const loading = ref(true)

onMounted(async () => {
  users.value = await fetchUsers()
  loading.value = false
})
</script>

<template>
  <div v-if="loading" class="skeleton-list">
    <div
      v-for="n in 5"
      :key="n"
      class="skeleton-card"
    />
  </div>

  <UserCard
    v-else
    v-for="user in users"
    :key="user.id"
    :user="user"
  />
</template>

<style scoped>
.skeleton-card {
  height: 120px;
  border-radius: 12px;
  margin-bottom: 16px;
}
</style>

We fetch users, but when the fetch is in progress we display the same hard coded number of loaders/skeletons. When the users are loaded there is no layout shift as it occupies the same space improving perceived performance and User Experience.

If we don't know how many results there will be, we have to assume some number but it is still better than not having skeletons at all :)

Many apps still use simple spinners or text/icon loaders like:

<div>Loading...</div>

But modern UX usually prefers Skeleton loaders because they mimic final layout, reduce layout shift, and improve perceived speed.

🧪 Best Practices

Prefer skeleton loaders over tiny spinners
Reserve space before content loads
Keep loading and final layouts similar
Always define image dimensions
Avoid injecting large content suddenly
Test CLS using Lighthouse or Core Web Vitals tools
Think about perceived performance — not just raw speed

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Loaders are much more important than most developers realize.

In this article, you learned:

What Cumulative Layout Shift (CLS) is
Why poor loading states hurt UX
How skeleton loaders improve perceived performance
How to avoid layout jumping in Vue and other frameworks
Best practices for stable, responsive interfaces

Fast apps are great.

But apps that feel smooth and stable are what users truly remember.

Take care!
And happy coding as always 🖥️

How to Safely Allow Inline Scripts Without Breaking Security with CSP Nonce

Jakub Andrzejewski — Mon, 27 Apr 2026 06:46:57 +0000

When building modern web applications, security is not optional. One of the most important protections you can add is a Content Security Policy (CSP).

But here’s the catch:

👉 CSP often blocks inline scripts and styles — which can break your app.

So how do you keep your app secure without disabling useful features?

That’s where CSP nonce comes in - it allows you to safely execute inline code without opening security holes.

In this article, we’ll explore:

What CSP nonce is
What problem it solves
How to implement it
How it works automatically in Nuxt with nuxt-security
Best practices and common pitfalls

Let’s dive in.

🤔 What Is CSP Nonce?

A nonce (short for number used once) is a unique, random value generated for each request.

It is used in CSP to explicitly allow trusted inline scripts or styles.

Example:

<script nonce="abc123">
  console.log('Secure inline script')
</script>

And in your HTTP headers:

Content-Security-Policy: script-src 'nonce-abc123'

The browser will only execute scripts that have a matching nonce.

CSP nonce is a whitelist mechanism:

Only scripts with the correct nonce are allowed
Everything else is blocked
The nonce changes on every request

This makes it extremely effective against XSS (Cross-Site Scripting) attacks.

CSP nonce is commonly used for:

SSR frameworks - Injecting initial state, Hydration scripts
Analytics / tracking snippets - Inline scripts required by providers
Critical inline scripts - Small scripts needed before app bootstraps

🟢 What Problem Does CSP Nonce Solve?

Without nonce, you usually face a trade-off:

❌ Allow inline scripts (unsafe)

Content-Security-Policy: script-src 'unsafe-inline'

Problem:

Opens the door to XSS attacks
Any injected script can run

❌ Block inline scripts completely

Content-Security-Policy: script-src 'self'

Problem:

breaks inline event handlers
breaks injected scripts (SSR hydration, state)
breaks some frameworks

🟢 How to Implement CSP Nonce

The process is relatively simple but let's break it down and explain each step individually.

Step 1: Generate a nonce per request

Example (Node.js):

import crypto from 'crypto'

function generateNonce() {
  return crypto.randomBytes(16).toString('base64')
}

Step 2: Add it to response headers

const nonce = generateNonce()

res.setHeader(
  'Content-Security-Policy',
  `script-src 'nonce-${nonce}'`
)

Step 3: Inject it into your HTML

<script nonce="{{nonce}}">
  window.__INITIAL_STATE__ = {}
</script>

⚠️ Critical rule

The nonce in the header and HTML must match exactly. Otherwise, script will be blocked and app may break silently.

🟢 CSP Nonce in Nuxt (with nuxt-security)

If you’re using Nuxt, things get much easier thanks to nuxt-security module that can:

Automatically generate nonce per request
Inject it into CSP headers
Attach it to scripts/styles

It makes it much easier to work with CSP nonces in Nuxt. Let's take a look at the following configuration:

export default defineNuxtConfig({
  modules: ['nuxt-security'],
  security: {
    headers: {
      contentSecurityPolicy: {
        'script-src': [
          "'self'",
          "'nonce-{{nonce}}'"
        ]
      }
    }
  }
})

What happens automatically:

Nuxt generates a nonce per request
Replaces {{nonce}} in headers
Applies nonce to inline scripts

You don’t need to manually wire everything

You can read more here:
https://nuxt-security.vercel.app/

🟢 Common Mistakes

Let's take a look at the list of common mistakes to understand what to look for:

❌ Reusing the same nonce - Nonce must be unique per request and cryptographically random
❌ Forgetting to apply nonce in HTML - if you only set CSP header the scripts will still be blocked
❌ Mixing nonce with unsafe-inline - script-src 'unsafe-inline' 'nonce-abc'
❌ Caching issues - if HTML is cached nonce may not match header

🧪 Best Practices

Generate nonce per request
Use secure randomness (crypto)
Never reuse nonce
Avoid unsafe-inline
Use frameworks/tools (like nuxt-security)
Test CSP in report-only mode first
Monitor browser console for CSP violations

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

CSP nonce is a powerful mechanism that allows you to safely use inline scripts while maintaining strong security.

In this article, you learned:

What CSP nonce is and how it works
What problem it solves (security vs flexibility)
How to implement it step by step
How Nuxt + nuxt-security handle it automatically
Common mistakes and best practices

Take care!
And happy coding as always 🖥️

Flexible Code Without Losing Type Safety with TS Generics

Jakub Andrzejewski — Mon, 30 Mar 2026 09:03:13 +0000

When working with TypeScript, you quickly run into a common problem:

👉 You want your code to be reusable, but also type-safe.

At first, it’s tempting to use any to make things flexible… but that comes at a cost:

You lose type safety
You lose autocomplete
You introduce hidden bugs

This is exactly the problem that TypeScript Generics solve.

They let you write reusable code without sacrificing type safety.

In this article, we’ll explore:

What Generics are
What problem they solve
Practical examples you’ll actually use
Best practices to avoid common mistakes

Let’s dive in.

🤔 Problem with type reusability

When you want your function to be reusable, you usually end up with this any approach:

function identity(value: any): any {
  return value
}

It works but it also comes with problems such as no type safety, no IntelliSense, and can easily lead to break things.

The second problem is code duplication:

function identityString(value: string): string {
  return value
}

function identityNumber(value: number): number {
  return value
}

With this approach, we are breaking the Don't Repeat Yourself (DRY) rule which also makes the code harder to maintain and less scalable.

🤔 Solution: TypeScript Generics

Generics allow you to create components, functions, or classes that work with multiple types, while still preserving full type information.

Think of them as:

👉 “Type placeholders” that get filled in later

Basic example:

function identity<T>(value: T): T {
  return value
}

Here:

T is a generic type
It represents whatever type you pass in

Usage:

identity<string>("hello") // string
identity<number>(123)    // number

TypeScript automatically knows what comes out based on what goes in.

🟢 Practical Examples

Let’s look at real-world scenarios where generics shine.

✅ Example 1: Reusable API Response Type

Very common pattern in frontend apps:

type ApiResponse<T> = {
  data: T
  error: string | null
}

Usage:

type User = {
  id: number
  name: string
}

const response: ApiResponse<User> = {
  data: { id: 1, name: "John" },
  error: null
}

Now your API types are consistent, reusable, and fully typed.

✅ Example 2: Generic Array Helper

function getFirstItem<T>(arr: T[]): T {
  return arr[0]
}

Usage:

const number = getFirstItem([1, 2, 3]) // number
const string = getFirstItem(["a", "b"]) // string

TypeScript knows exactly what type is returned.

✅ Example 3: Generic Props in Vue

Check out my other article where I have explained this topic in more details here.

✅ Example 4: Constraining Generics

Sometimes you want flexibility — but with rules.

function getLength<T extends { length: number }>(value: T) {
  return value.length
}

Usage:

getLength("hello") // ✅
getLength([1, 2, 3]) // ✅
getLength(123) // ❌ error

With this approach, you ensure flexibility but also controlled structure.

✅ Example 5: Keyof + Generics

function getProperty<T, K extends keyof T>(obj: T, key: K) {
  return obj[key]
}

Usage:

const user = {
  id: 1,
  name: "John"
}

getProperty(user, "name") // ✅
getProperty(user, "age") // ❌ error

This is extremely powerful for forms, dynamic access, or utilities.

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

TypeScript Generics are one of the most powerful features in the language. They let you write code that is both flexible and safe — which is exactly what you want in modern applications.

Once you start using them properly, it’s hard to go back.

Take care!
And happy coding as always 🖥️

When You Should Use Vue Teleport

Jakub Andrzejewski — Mon, 23 Mar 2026 09:36:56 +0000

When building modern Vue applications, not everything fits neatly inside your component tree. Some UI elements — like modals, tooltips, dropdowns, or overlays — often need to escape their parent container due to:

z-index issues
overflow constraints
stacking context problems
layout limitations

This is where Vue Teleport becomes incredibly useful as it allows you to render part of your component outside of its DOM hierarchy, while still keeping it logically connected to the component.

In this article, we’ll explore:

What Vue Teleport is
When you should use it
Real-world use cases (like dialogs and overlays)
What defer Teleport does and when to use it

Let’s dive in.

🤔 What Is Vue Teleport?

Vue Teleport is a built-in component that allows you to render content in a different part of the DOM than where it is declared.

Basic example:

<Teleport to="body">
  <div class="modal">
    I am rendered in body!
  </div>
</Teleport>

Even though this code exists inside a component, the rendered HTML is moved to <body>. Teleport changes where elements are rendered, not how they behave. This means that reactivity still works, events still work, and component logic stays intact.

Teleport is purely about DOM placement.

🟢 When Should You Use Vue Teleport?

Teleport is ideal when UI elements need to visually break out of their parent container.

✅ Modals / Dialogs

Modals are the most common use case.

Without Teleport, modals can break due to:

overflow: hidden
nested containers
stacking issues

Example:

<Teleport to="body">
  <div class="modal-backdrop">
    <div class="modal">
      Modal content
    </div>
  </div>
</Teleport>

✅ Tooltips & Dropdowns

Dropdowns and tooltips often need to appear above everything else.

Teleport helps avoid:

clipping inside parent containers
z-index conflicts

✅ Notifications / Toasts

Global UI elements like notifications should not depend on local layout.

<Teleport to="#notifications">
  <Toast message="Saved!" />
</Teleport>

✅ Third-party UI Libraries (Real Example)

Libraries like Reka UI use Teleport internally for components such as dialogs.

Example usage pattern:

<DialogRoot>
  <DialogTrigger>Open</DialogTrigger>

  <DialogPortal>
    <DialogOverlay />
    <DialogContent>
      Dialog content
    </DialogContent>
  </DialogPortal>
</DialogRoot>

Under the hood, DialogPortal uses Teleport to render content outside the component tree — usually into <body>.

This ensures:

Proper layering
Accessibility compliance
Correct focus management

This pattern is standard for headless UI libraries.

🟢 Deferred Teleport (`defer`)

Vue also provides an advanced feature: deferred teleport.

Example:

<Teleport to="#target" defer>
  <div>Deferred content</div>
</Teleport>

Normally, Teleport tries to move content immediately but sometimes the target element does not exist yet or it is rendered later (e.g., in SSR or layouts)

With defer, Vue waits until the target exists before teleporting.

🟢 Common Mistakes When Using Teleport

There are few things we should take care when using Teleport:

Overusing Teleport - avoid using Teleport for regular layout, simple components, or static UI.
Forgetting Accessibility - teleport does not solve focus trapping, keyboard navigation, or ARIA roles.
Styling issues - Teleported content is no longer inside the same DOM tree which means scoped styles may not apply and parent CSS may not affect the component.

🧪 Best Practices

Use Teleport primarily for overlays and global UI
Combine with proper focus management
Use defer when working with dynamic targets
Prefer UI libraries (like Reka UI) for complex patterns
Keep Teleport usage minimal and intentional

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Vue Teleport is a powerful tool for handling UI elements that need to exist outside normal DOM hierarchy.

Teleport helps you solve layout problems cleanly while keeping your component logic simple and maintainable.

Use it wisely — and your UI architecture will become much more flexible.

Take care!
And happy coding as always 🖥️

Reusable Architecture for Large Applications with Nuxt Layers

Jakub Andrzejewski — Mon, 16 Mar 2026 09:51:13 +0000

As applications grow, managing shared code across projects becomes increasingly difficult. Teams often face problems like:

Duplicated logic across repositories
Inconsistent project structure
Hard-to-maintain design systems
Repeated configuration setup

This is where Nuxt Layers become extremely useful.

In this article, we’ll explore:

What Nuxt Layers are
How they work
How to use them to reuse code across projects
How they help build scalable architecture
Potential tradeoffs and when to avoid them

Let’s dive in.

🤔 What Are Nuxt Layers?

Nuxt Layers allow one Nuxt project to extend another using the extends feature.

In practice, this means you can create a base layer containing shared logic, and multiple applications can build on top of it.

A layer can include:

Components
Composables
Pages
Layouts
Middleware
Configuration
Modules

Think of layers as reusable Nuxt building blocks.

Example architecture:

base-layer/
  components/
  composables/
  layouts/
  nuxt.config.ts

app/
  pages/
  nuxt.config.ts

The application extends the base layer.

🟢 Creating a Nuxt Layer

A layer is essentially a Nuxt project that other projects can extend.

Example layer structure:

ui-layer/
  components/
    AppButton.vue
  composables/
    useTheme.ts
  nuxt.config.ts

Then in your application:

export default defineNuxtConfig({
  extends: ['../ui-layer']
})

Now everything inside the layer becomes available inside your app.

For example, the AppButton component can be used directly:

<AppButton>
  Click me
</AppButton>

No additional imports required. This makes sharing UI systems across multiple apps much easier.

🟢 Reusing Code Across Multiple Projects

One of the biggest benefits of Nuxt Layers is code reuse across multiple repositories.

For example, you may create layers for:

UI components
Authentication logic
Analytics integrations
Design systems
API composables

Example layered architecture:

core-layer
  composables/
  utils/

ui-layer
  components/
  layouts/

marketing-app
admin-app
dashboard-app

Each application extends the shared layers.

Example configuration:

export default defineNuxtConfig({
  extends: [
    '../core-layer',
    '../ui-layer'
  ]
})

This ensures that:

Shared code lives in one place
Updates propagate across projects
Teams maintain consistent patterns

It’s particularly useful for large organizations managing multiple applications.

🟢 Using Layers for Scalable Architecture

Nuxt Layers also help structure large applications.

Instead of a single large codebase, you can divide your system into logical layers.

Example architecture:

design-system-layer
business-logic-layer
feature-layer
app-layer

Each layer builds on top of the previous one.

Example:

design-system-layer
  components/
  styles/

business-layer
  composables/

feature-layer
  pages/
  components/

app-layer
  pages/

Then your main application config:

export default defineNuxtConfig({
  extends: [
    '../design-system-layer',
    '../business-layer',
    '../feature-layer'
  ]
})

This approach:

Improves maintainability
Encourages separation of concerns
Helps teams scale development

It becomes easier to reason about the architecture of large Nuxt projects.

🟢 Layer Overrides and Merging

One powerful aspect of Nuxt Layers is that later layers override earlier ones.

For example:

base-layer/components/Header.vue
app/components/Header.vue

The application version overrides the base layer component.

This allows you to:

Provide defaults in layers
Customize behavior in applications

Configuration is also merged automatically.

Example:

export default defineNuxtConfig({
  runtimeConfig: {
    apiBase: '/api'
  }
})

If multiple layers define runtimeConfig, Nuxt merges them.

This merging behavior makes layers flexible and customizable.

⚠️ Tradeoffs of Nuxt Layers

While layers are powerful, they introduce some complexity.

Increased Architectural Complexity

When many layers are involved, it can become harder to understand:

Where components come from
Which layer overrides which
How configuration is merged

This can slow onboarding for new developers.

Debugging Can Be Harder

If a component behaves unexpectedly, you may need to check multiple layers.

Example problem:

Component defined in:
- layer A
- layer B
- application

Understanding which one is active requires careful inspection.

Tooling and IDE Navigation

Depending on your editor setup, navigating across layers may be less straightforward than working within a single project.

Although modern Nuxt tooling is improving, it still requires good project organization.

Overengineering Risk

For small projects, layers may be unnecessary.

If you only have one application, layers may introduce more complexity than value.

They shine most when:

Managing multiple applications
Building reusable systems
Maintaining design systems

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Nuxt Layers introduce a powerful way to structure and reuse code across applications. When used correctly, layers can transform a collection of applications into a well-organized ecosystem of reusable building blocks.

But like any architectural tool, they should be applied thoughtfully and only when they truly provide value.

Take care!
And happy coding as always 🖥️

How Vue Protects Your App Against Injections

Jakub Andrzejewski — Mon, 09 Mar 2026 07:52:51 +0000

Security is one of the most important aspects of modern web development. Applications that process user input must protect themselves against various forms of attacks — especially injection attacks.

Luckily, Vue provides several built-in mechanisms that help protect your application from common vulnerabilities like:

Cross-Site Scripting (XSS)
HTML injection
Attribute injection

These protections are built into the framework, meaning that in many cases Vue secures your app by default.

In this article, we’ll explore:

How Vue escapes interpolated content
Why v-html can be dangerous
How Vue protects against attribute injection
Best practices for keeping your Vue apps secure

Let’s dive in.

🤔 What Are Injection Attacks?

Injection attacks occur when an attacker manages to insert malicious code into an application that is later executed in the browser.

A common example is Cross-Site Scripting (XSS).

Example of malicious input:

<script>alert('Hacked')</script>

If your application renders this directly into the DOM, the script executes in the user’s browser.

That could allow attackers to:

Steal authentication tokens
Hijack user sessions
Inject malicious UI
Redirect users to phishing pages

This is why modern frameworks must protect developers against unsafe rendering.

Vue does exactly that.

🟢 Vue Automatic HTML Escaping

By default, Vue escapes all interpolated content.

Example:

<p>{{ userInput }}</p>

If userInput contains:

<script>alert('Hacked')</script>

Vue will render it as text:

<p>&lt;script&gt;alert('Hacked')&lt;/script&gt;</p>

Instead of executing the script.

This simple rule protects against most XSS attacks is that Interpolation ({{ }}) is always safe.

The browser sees escaped text rather than executable HTML.

🟢 Template Compilation Safety

Vue templates are compiled into JavaScript functions.

However, Vue only compiles trusted templates — the ones written by developers.

For example:

<div>{{ message }}</div>

This template becomes optimized render functions internally.

But Vue does not compile user-provided templates dynamically. Doing so would be extremely dangerous.

Bad example (never do this):

app.component('UnsafeComponent', {
  template: userInput
})

If userInput contains malicious JavaScript, it could execute inside your app.

The rule of thumb here is to never use user input as a Vue template.

🟢 Attribute Injection Protection

Vue also escapes values used inside HTML attributes.

Example:

<div :title="userInput"></div>

If userInput contains:

" onmouseover="alert('Hacked')

Vue safely escapes it before inserting it into the DOM.

Instead of executing malicious JavaScript, the browser treats it as a simple string value.

This protects against:

Event handler injection
Attribute-based XSS attacks

🟢 URL Injection Protection

Another attack vector involves injecting dangerous URLs like:

javascript:alert('Hacked')

Example:

<a :href="userLink">Click me</a>

Vue does not automatically sanitize URLs, because valid URLs may include many protocols.

This means developers must validate URLs themselves.

Safe practice:

<script setup>
function sanitizeUrl(url) {
  if (url.startsWith('http://') || url.startsWith('https://')) {
    return url
  }
  return '#'
}
</script>

<template>
  <a :href="sanitizeUrl(userLink)">Open link</a>
</template>

This prevents dangerous protocols like:

javascript:
data:
vbscript:

🔴 The Danger of `v-html`

While Vue escapes interpolation by default, v-html bypasses that protection.

Example:

<div v-html="userContent"></div>

If userContent contains:

<script>alert('XSS')</script>

The script will execute.

That makes v-html the most common source of XSS vulnerabilities in Vue apps.

Only use it when:

Rendering trusted HTML
Rendering sanitized content

Example with sanitization library:

import DOMPurify from 'dompurify'

const safeHtml = DOMPurify.sanitize(userContent)

Then:

<div v-html="safeHtml"></div>

🧪 Best Security Practices for Vue Apps

Even though Vue protects your application by default, developers should still follow security best practices.

1.Prefer interpolation

Safe:

{{ content }}

Avoid:

v-html="content"

2.Sanitize external HTML

If you must render HTML, use sanitization tools like:

DOMPurify
sanitize-html

3.Validate URLs

Never blindly render user-provided links.

Always validate allowed protocols.

4.Avoid dynamic template compilation

Never use user input inside Vue templates.

5.Use CSP (Content Security Policy)

A strong CSP header can mitigate many injection attacks.

Example policy:

Content-Security-Policy: script-src 'self'

This prevents execution of inline malicious scripts.

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Vue includes several built-in protections against injection attacks.

These mechanisms make Vue a secure-by-default framework, but security still depends on responsible developer practices.

When used correctly, Vue helps ensure your application stays safe from common injection vulnerabilities.

Take care!
And happy coding as always 🖥️

Lesser-Known but Powerful Vue Features

Jakub Andrzejewski — Mon, 02 Mar 2026 08:51:59 +0000

Vue is often praised for its simplicity and clean API. Most developers are familiar with:

ref()
reactive()
computed()
watch()
v-if / v-for

But Vue also includes several lesser-known features that can significantly improve Performance, Code clarity, Architecture, and Developer experience.

In this article, we’ll explore some powerful yet underused Vue features:

nextTick()
watchEffect()
provide() / inject()
useId()
shallowRef()
v-memo
v-once
CSS v-bind()

Let’s dive in.

🤔 Why These Features Matter

As applications grow component trees get deeper, state becomes more complex, performance becomes critical, and reusability becomes harder.

Knowing these features helps you:

Write cleaner logic
Avoid unnecessary re-renders
Improve performance
Build better abstractions

They’re not always needed — but when they are, they’re incredibly useful.

🟢 nextTick()

Vue updates the DOM asynchronously. That means when you change state, the DOM is not updated immediately.

Sometimes you need to wait for the DOM to update before running code.

That’s where nextTick() comes in.

Example:

<script setup>
import { ref, nextTick } from 'vue'

const count = ref(0)

async function increment() {
  count.value++
  await nextTick()
  console.log('DOM updated')
}
</script>

Use cases:

Accessing updated DOM elements
Measuring element size
Managing focus after state change

Without nextTick(), you may interact with outdated DOM.

🟢 watchEffect()

Most developers use watch(), but watchEffect() is often simpler.

watchEffect() automatically tracks reactive dependencies.

Example:

<script setup>
import { ref, watchEffect } from 'vue'

const count = ref(0)

watchEffect(() => {
  console.log('Count is:', count.value)
})
</script>

No need to specify dependencies manually.

Difference:

watch() → explicit dependency
watchEffect() → automatic dependency tracking

Best used for:

Side effects
Logging
Reactive debugging
Simple reactive reactions

🟢 provide() / inject()

Prop drilling becomes painful in large component trees.

Instead of passing props multiple levels down, you can use dependency injection.

Parent:

<script setup>
import { provide } from 'vue'

provide('theme', 'dark')
</script>

Child (deeply nested):

<script setup>
import { inject } from 'vue'

const theme = inject('theme')
</script>

Use cases:

Theming
Plugin systems
Form context
Shared services

It’s lightweight and avoids unnecessary prop chains.

But remember:

👉 It’s not a state management replacement. Use it intentionally.

🟢 useId()

useId() generates unique, SSR-safe IDs.

Very useful for accessibility and form labeling.

Example:

<script setup>
import { useId } from 'vue'

const id = useId()
</script>

<template>
  <label :for="id">Email</label>
  <input :id="id" type="email" />
</template>

Benefits:

No ID collisions
SSR compatibility
Cleaner form components

Especially helpful in reusable UI libraries.

🟢 shallowRef()

Normally, ref() makes nested objects reactive.

But sometimes you don’t want deep reactivity.

That’s where shallowRef() helps.

Example:

<script setup>
import { shallowRef } from 'vue'

const chartInstance = shallowRef(null)
</script>

Best used for:

Third-party libraries
Large objects
Non-reactive instances
Performance optimization

shallowRef() tracks only .value changes — not nested properties.

This avoids unnecessary reactive overhead.

🟢 v-once

v-once renders an element only once.

After that, it never updates again.

Example:

<h1 v-once>
  Static Title
</h1>

Use cases:

Static content
Large lists of immutable data
Performance optimization

Be careful:

👉 It will never update — even if data changes.

🟢 v-memo

v-memo is lesser-known but powerful.

It memoizes part of a template based on dependencies.

Example:

<div v-memo="[user.id]">
  {{ user.name }}
</div>

The block only re-renders when user.id changes.

Useful for:

Large lists
Performance-critical UI
Preventing unnecessary updates

It gives you fine-grained control over rendering behavior.

🟢 CSS v-bind()

Vue allows binding reactive values directly inside <style>.

Example:

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

const color = ref('red')
</script>

<template>
  <div class="box">Hello</div>
</template>

<style scoped>
.box {
  background-color: v-bind(color);
}
</style>

This enables:

Dynamic styling without inline styles
Cleaner separation of logic and presentation
Reactive CSS variables

Great for:

Theming
Dynamic layouts
Design systems

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Vue has many powerful features beyond the basics.

In this article, you discovered:

How nextTick() helps with DOM timing
Why watchEffect() simplifies reactive side effects
How provide() / inject() reduces prop drilling
When to use useId() for accessibility
How shallowRef() optimizes performance
How v-once and v-memo improve rendering control
How CSS v-bind() enables reactive styling

These features can elevate your Vue code from good to great — when used intentionally.

Take care!
And happy coding as always 🖥️

Accessibility in Vue: Quick Tips for Building Inclusive Apps

Jakub Andrzejewski — Mon, 23 Feb 2026 08:29:06 +0000

Accessibility is not a “nice to have” — it is a fundamental part of building modern web applications.

An accessible application:

Reaches more users
Improves usability for everyone
Reduces legal risks
Strengthens brand reputation

When working with Vue, accessibility is largely in your hands. Vue does not limit accessibility — but it also does not automatically solve it for you.

In this article, we’ll go through practical and quick tips for improving accessibility in Vue apps:

Keyboard shortcuts & navigation
ARIA labels & roles
Focus management

Enjoy!

🤔 Why Accessibility Matters in Vue Apps

Modern SPAs introduce challenges that traditional multi-page websites did not have:

Dynamic content updates
Client-side routing
Modal dialogs
Complex component trees

Without proper accessibility handling, users relying on:

Screen readers
Keyboard navigation
Assistive technologies

may struggle to use your app.

The good news? Most accessibility improvements require small, intentional changes.

🟢 Keyboard Navigation & Shortcuts

Many users do not use a mouse. They rely entirely on:

Tab
Shift + Tab
Enter
Space
Arrow keys

Make Elements Focusable

Use semantic HTML whenever possible:

<button @click="submit">
  Submit
</button>

Avoid:

<div @click="submit">
  Submit
</div>

If you must use a non-semantic element, make it keyboard-accessible:

<div
  role="button"
  tabindex="0"
  @click="submit"
  @keydown.enter="submit"
>
  Submit
</div>

Logical Tab Order

Ensure that your DOM structure follows a logical navigation flow.

Avoid:

Random tabindex values
Skipping interactive elements
Hidden focus traps

Use tabindex="0" only when necessary.

Keyboard Shortcuts

Vue makes it easy to listen for keyboard events:

<script setup>
import { onMounted, onBeforeUnmount } from 'vue'

function handleKey(e) {
  if (e.key === 'k' && e.ctrlKey) {
    openSearch()
  }
}

onMounted(() => {
  window.addEventListener('keydown', handleKey)
})

onBeforeUnmount(() => {
  window.removeEventListener('keydown', handleKey)
})
</script>

Best practices:

Always document shortcuts
Avoid overriding browser defaults
Provide alternative UI access

Keyboard shortcuts should enhance usability — not replace accessibility.

🟢 ARIA Labels & Roles

ARIA (Accessible Rich Internet Applications) attributes help screen readers understand UI meaning when semantic HTML is not enough.

aria-label

Useful when visual text is not descriptive:

<button aria-label="Close modal" @click="close">
  ✕
</button>

Without aria-label, a screen reader might only read “button”.

aria-hidden

Hide decorative elements from assistive technologies:

<span aria-hidden="true">🎉</span>

aria-live

For dynamic updates (like notifications):

<div aria-live="polite">
  {{ message }}
</div>

This informs screen readers that content has changed.

Proper Roles

If you create custom components (dropdowns, tabs, modals), use appropriate roles:

<div role="dialog" aria-modal="true">
  <h2>Settings</h2>
</div>

However, remember:

👉 Native HTML elements are always preferred over ARIA when possible.

🟢 Focus Management

Focus management is one of the most overlooked accessibility issues in Vue apps.

Especially when dealing with:

Modals
Route changes
Dynamic content
Dropdowns

Managing Focus in Modals

When opening a modal:

Move focus into the modal
Trap focus inside
Return focus when closing

Example:

<script setup>
import { ref, nextTick } from 'vue'

const modalRef = ref(null)

function openModal() {
  isOpen.value = true

  nextTick(() => {
    modalRef.value?.focus()
  })
}
</script>

<template>
  <div
    v-if="isOpen"
    ref="modalRef"
    tabindex="-1"
    role="dialog"
  >
    Modal content
  </div>
</template>

Focus After Route Changes

In SPAs, screen readers do not automatically detect route changes.

You should move focus to the main heading after navigation.

Example:

<script setup>
import { useRoute } from 'vue-router'
import { watch, nextTick } from 'vue'

const route = useRoute()

watch(() => route.path, async () => {
  await nextTick()
  document.querySelector('h1')?.focus()
})
</script>

And ensure the heading is focusable:

<h1 tabindex="-1">
  Page Title
</h1>

Avoid Focus Traps

Common mistakes:

Removing elements without restoring focus
Dynamically hiding focused elements
Infinite focus loops

Always test:

Tab navigation
Shift + Tab navigation
Screen reader behavior

🧪 Quick Accessibility Checklist for Vue

Before shipping your feature:

✅ Can I navigate everything using only keyboard?
✅ Are all buttons real <button> elements?
✅ Do interactive icons have aria-label?
✅ Does focus move correctly after modals and navigation?
✅ Are dynamic updates announced properly?

These small checks dramatically improve usability.

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Accessibility in Vue does not require massive architectural changes — it requires intentional implementation.

Small improvements make your app:

More inclusive
More professional
More compliant
More usable for everyone

Take care!
And happy coding as always 🖥️

Business Advantages of Using Nuxt

Jakub Andrzejewski — Mon, 16 Feb 2026 10:10:53 +0000

Choosing the right framework is not just a technical decision — it’s a business decision. When building modern web applications, companies care about:

Scalability
Performance
SEO
Accessibility
Hosting flexibility
Enterprise integrations
Long-term maintainability

This is where Nuxt becomes more than just a Vue meta-framework — it becomes a strategic advantage.

In this article, we’ll explore:

Why Nuxt is hosting-agnostic
How its module ecosystem benefits enterprise projects
Built-in SEO advantages (including @nuxtjs/seo)
Accessibility support with @nuxt/a11y
Performance optimization with Hints
Script and font optimization modules

Let’s dive in.

🤔 Why Framework Choice Matters for Business

From a business perspective, poor architectural decisions can lead to:

❌ Expensive rewrites
❌ SEO problems and lost traffic
❌ Performance issues affecting conversion rates
❌ Vendor lock-in
❌ Slower time-to-market

Nuxt reduces these risks by providing:

SSR / SSG / Hybrid rendering
A powerful module ecosystem
Enterprise-ready integrations
Deployment flexibility

This makes it attractive not only to developers — but to CTOs and product teams as well.

🟢 Hosting Agnostic Architecture

One of Nuxt’s strongest business advantages is that it is hosting agnostic.

You can deploy Nuxt to:

Node servers
Serverless platforms
Edge runtimes
Static hosting
Docker environments

You are not locked into a specific cloud provider.

Nuxt supports adapters and deployment to platforms like:

Vercel
Netlify
AWS
Azure
Google Cloud
Traditional VPS

This means:

✅ No vendor lock-in
✅ Easier migration between providers
✅ Cost optimization flexibility
✅ Infrastructure freedom

For businesses, this reduces long-term risk significantly.

🟢 Enterprise Module Ecosystem

Nuxt’s module ecosystem is one of its biggest strengths.

Instead of building integrations from scratch, you can rely on production-ready modules for enterprise services such as:

Storyblok
Sanity
Cloudinary
Stripe
Supabase
Auth providers

Example: using Storyblok module

npx nuxi module add storyblok

Example configuration:

export default defineNuxtConfig({
  modules: ['@storyblok/nuxt'],
  storyblok: {
    accessToken: process.env.STORYBLOK_TOKEN
  }
})

This gives you:

CMS integration
Live preview support
SSR compatibility
Production-ready setup

The same applies to Sanity or Cloudinary — reducing development time and integration costs.

For businesses, this means:

🚀 Faster time-to-market
🧩 Reliable integrations
💰 Lower development cost

🟢 Built-in SEO Capabilities

SEO is critical for organic traffic and revenue.

Nuxt provides:

Server-side rendering (SSR)
Static generation (SSG)
Meta management
Sitemap support
Robots.txt support

Additionally, you can use the official @nuxtjs/seo module to centralize and standardize SEO configuration across your application.

Install it:

npx nuxi module add @nuxtjs/seo

Basic configuration:

export default defineNuxtConfig({
  modules: ['@nuxtjs/seo'],
  seo: {
    redirectToCanonicalSiteUrl: true
  }
})

And dynamic metadata with composables:

useSeoMeta({
  title: 'Nuxt Business Advantages',
  description: 'Learn why Nuxt is a strategic framework choice.',
  ogTitle: 'Nuxt for Business',
  ogDescription: 'Enterprise-ready Vue framework'
})

Nuxt ensures:

✅ Better indexing
✅ Improved Core Web Vitals
✅ Stronger search visibility
✅ Consistent SEO configuration at scale

For e-commerce and marketing-driven platforms, this directly impacts revenue.

🟢 Accessibility Support with @nuxt/a11y

Accessibility is no longer optional — it is:

A legal requirement in many regions
A brand reputation factor
A usability advantage

Nuxt provides an official accessibility module: @nuxt/a11y.

Install it:

npx nuxi module add @nuxt/a11y

Basic configuration:

export default defineNuxtConfig({
  modules: ['@nuxt/a11y'],
  a11y: {
    enabled: true
  }
})

The module helps with:

Automated accessibility checks
WCAG compliance improvements
Accessibility devtools integration
Route announcements for screen readers

For enterprises, this reduces:

⚖️ Legal risks
🧪 Manual QA costs
♿ Accessibility regressions

Accessibility becomes part of the development workflow — not an afterthought.

🟢 Performance Optimization with Nuxt Hints

Performance directly affects:

Conversion rates
SEO rankings
User engagement

Nuxt provides performance optimization tools like Nuxt Hints.

Nuxt Hints helps:

Identify render bottlenecks
Detect unnecessary payload size
Suggest performance improvements

This gives teams visibility into:

Hydration issues
Bundle size problems
Runtime inefficiencies

Instead of guessing, teams can measure and optimize systematically.

🟢 Script Optimization with Nuxt Scripts

Third-party scripts are often a major performance and security problem.

Nuxt provides @nuxt/scripts to:

Control when scripts load
Define triggers
Add warmup strategies
Improve security

Example:

export default defineNuxtConfig({
  modules: ['@nuxt/scripts']
})

Google Analytics example:

<script setup>
useScript({
  src: 'https://www.googletagmanager.com/gtag/js?id=GA_ID',
  trigger: 'onInteraction'
})
</script>

Benefits:

🚀 Improved performance
🔐 Safer script execution
🎯 Controlled loading strategies

For business-critical apps, this means fewer third-party performance issues.

🟢 Font Optimization

Fonts can significantly slow down rendering.

Nuxt offers modules to:

Self-host fonts
Optimize font loading
Avoid layout shifts

Example configuration:

export default defineNuxtConfig({
  modules: ['@nuxt/fonts'],
  fonts: {
   defaults: {
      weights: [400],
      styles: ['normal', 'italic'],
      subsets: [
        'cyrillic-ext',
      ]
   }
  }
})

This reduces:

CLS (Cumulative Layout Shift)
Render-blocking resources
External dependency risk

Performance improvements directly impact user retention and conversion.

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Nuxt is not just a developer-friendly framework — it is a business-ready platform.

It provides:

Hosting agnostic deployment
Enterprise module ecosystem
Built-in SEO support with @nuxtjs/seo
Accessibility tooling with @nuxt/a11y
Performance optimization (Hints)
Script and font management

For companies, this means:

Lower long-term risk
Faster development cycles
Better performance and SEO
Improved scalability

Choosing Nuxt is not just about Vue — it’s about making a strategic technical decision that supports business growth.

Take care!
And happy coding as always 🖥️

Responsive Images for Better Web Performance

Jakub Andrzejewski — Mon, 09 Feb 2026 07:50:32 +0000

Images are often the largest assets on a website—and one of the most common performance bottlenecks. Serving the same large image to every device, regardless of screen size or resolution, leads to wasted bandwidth, slower load times, and poor user experience.

This problem becomes even more visible in modern frameworks like Vue and Nuxt, where performance, SEO, and Core Web Vitals matter more than ever.

In this article, we’ll explore:

Why non-responsive images are a performance problem
How responsive images work on the web
How to implement responsive images in plain HTML
How to optimize images in Nuxt using unpic-vue and Nuxt Image

Enjoy!

🤔 What’s the Problem With Non-Responsive Images?

When you serve a single static image like this:

<img src="/hero.jpg" alt="Hero image" />

Every user downloads the same file, whether they are:

on a mobile phone
on a tablet
on a high-resolution desktop display

This leads to several issues:

❌ Mobile users download unnecessarily large images
❌ Slower page load and Time to Interactive
❌ Worse Core Web Vitals (especially LCP)
❌ Higher data usage and costs for users
❌ Poor SEO performance

Modern websites need images that adapt to the device, not the other way around.

🟢 How Responsive Images Work on the Web

Responsive images allow the browser to decide which image variant to download based on:

viewport size
device pixel ratio
layout constraints

This is achieved using:

srcset
sizes
<picture> element
modern image formats (WebP, AVIF)

Example:

<img
  src="image-800.jpg"
  srcset="
    image-400.jpg 400w,
    image-800.jpg 800w,
    image-1600.jpg 1600w
  "
  sizes="(max-width: 600px) 90vw, 800px"
  alt="Responsive example"
/>

The browser automatically selects the best possible image for the current device.

🟢 Using unpic-vue for Responsive Images in Vue

unpic-vue provides a framework-agnostic way to generate optimized, responsive images with a clean API.

Example:

<script setup>
import { Image } from '@unpic/vue'
</script>

<template>
  <Image
    src="https://your-website.com/image.jpeg"
    alt="Amazing Product Image"
    width="800"
    height="600"
    layout="constrained"
  />
</template>

What you get:

automatic srcset
responsive sizing
modern image formats
lazy loading by default

This is a great choice when you want provider-agnostic image optimization in Vue but also other frameworks like React, Angular, Svelte and more.

🟢 Optimizing Images in Nuxt with Nuxt Image

Nuxt offers a first-class solution via Nuxt Image, designed specifically for SSR and performance.

Example using <NuxtImg>:

<template>
  <NuxtImg
    src="/hero.jpg"
    width="1200"
    sizes="(max-width: 768px) 100vw, 1200px"
    format="webp"
    alt="Hero image"
  />
</template>

Nuxt Image automatically:

generates responsive variants
serves modern formats
integrates with CDNs
optimizes for SSR and hydration

It supports providers like:

static
IPX
Cloudinary
ImageKit
and more

For Nuxt applications, this is usually the best default choice.

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Responsive images are one of the highest-impact performance optimizations you can make.

Serving the right image to the right device improves load times, SEO, Core Web Vitals, and user satisfaction—all with relatively little effort.

Take care!
And happy coding as always 🖥️

Using effectScope to Control Vue Reactivity Lifecycles

Jakub Andrzejewski — Mon, 02 Feb 2026 13:06:58 +0000

Vue’s reactivity system is powerful, but that power comes with responsibility. As applications grow, uncontrolled reactive effects can easily outlive the components that created them, leading to memory leaks, unnecessary recomputation, and hard-to-debug behavior.

This is especially common when working with:

composables reused across multiple components
manual watchers and effects
integrations with external systems
long-lived reactive processes

Vue 3 introduced effectScope to give developers explicit control over the lifecycle of reactive effects.

In this article, we’ll explore:

What effectScope is and why it exists
How it helps manage reactivity lifecycles
Practical examples with composables and watchers
When you should (and shouldn’t) use it
How it prevents subtle performance and memory issues

Enjoy!

🤔 What Is `effectScope` in Vue?

effectScope is a low-level Vue API that allows you to group reactive effects (like watch, watchEffect, and computed dependencies) into a single scope that can be stopped all at once.

In simple terms:

It lets you control when reactivity starts and when it ends.

Without effectScope, reactive effects are tied implicitly to:

the current component instance, or
global execution context

This works most of the time — until it doesn’t.

Use effectScope when:

building complex composables
managing reactivity outside components
working with plugins or services
creating start/stop reactive behavior
debugging memory or performance issues

🟢 The Problem: Reactivity That Lives Too Long

Consider a composable that sets up a watcher:

export function useLogger(source) {
  watch(source, (value) => {
    console.log(value)
  })
}

If this composable is used:

outside of a component
inside a plugin
conditionally
or repeatedly without cleanup

That watcher may:

never be disposed
keep reacting forever
leak memory
react to stale state

This is where effectScope becomes essential.

🟢 Basic Usage of `effectScope`

Here’s the simplest example:

import { effectScope, ref, watch } from 'vue'

const scope = effectScope()

scope.run(() => {
  const count = ref(0)

  watch(count, (value) => {
    console.log(value)
  })
})

scope.stop()

What happens here:

All reactive effects created inside run() are tracked
Calling stop() disposes everything at once
No lingering watchers, no surprises

This explicit lifecycle control is the key benefit.

🟢 Using `effectScope` Inside Composables

One of the best use cases for effectScope is advanced composables.

Example:

import { effectScope, ref, watch } from 'vue'

export function usePolling(interval = 1000) {
  const scope = effectScope()
  const data = ref(null)

  scope.run(() => {
    const timer = setInterval(() => {
      data.value = Date.now()
    }, interval)

    watch(data, () => {
      console.log('updated')
    })

    scope.onStop(() => clearInterval(timer))
  })

  return {
    data,
    stop: () => scope.stop()
  }
}

Now:

The composable owns its reactivity
Consumers can explicitly stop it
Side effects are cleaned up correctly

This pattern is invaluable for:

polling
subscriptions
event listeners
external integrations

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

effectScope gives Vue developers explicit control over reactivity lifecycles.

In this article you learned:

What effectScope is and why it exists
How it prevents runaway reactive effects
How to use it in composables and services
How to manage start/stop reactivity patterns
When it’s worth the added complexity

Used thoughtfully, effectScope helps keep Vue apps predictable, performant, and leak-free — especially as they grow in complexity.

Take care!
And happy coding as always 🖥️

Config-driven Vue Interfaces with Dynamic Components

Jakub Andrzejewski — Mon, 26 Jan 2026 07:37:42 +0000

Modern Vue applications are no longer built from hardcoded layouts alone. As products scale, UIs increasingly need to adapt to configuration, CMS content, feature flags, experiments, or backend-driven schemas.

This is where config-driven interfaces and Vue’s dynamic components (<component :is>) truly shine.

Instead of baking layout decisions into templates, you let configuration decide what gets rendered — and Vue handles how it’s rendered.

In this article, we’ll explore:

What config-driven UI means in Vue
How <component :is> enables truly dynamic rendering
Patterns for CMS-driven and backend-driven interfaces
Common pitfalls and how to avoid them
When dynamic components are powerful — and when they’re not

Enjoy!

🤔 What Are Config-driven Interfaces in Vue?

A config-driven interface is one where structure, composition, or behavior is controlled by data, not hardcoded templates.

Instead of writing:

<Hero />
<Features />
<Testimonials />

You render UI based on configuration:

[
  { type: 'hero', props: { title: 'Hello' } },
  { type: 'features', props: { items: [...] } },
  { type: 'testimonials', props: { quotes: [...] } }
]

This approach is common in:

CMS-driven websites
Page builders
Design systems
A/B testing
White-label products
Dashboard builders

Vue’s <component :is> is the core primitive that makes this possible.

🟢 Dynamic Components with `<component :is>`

At its core, Vue allows you to dynamically choose which component to render:

<component :is="currentComponent" />

Where currentComponent can be:

A component reference
A registered component name
A function that resolves a component
A value from configuration

This makes Vue ideal for config-driven rendering — as long as you structure it correctly.

Mapping Config to Components (Recommended Pattern)

Avoid rendering arbitrary strings directly. Instead, define an explicit mapping:

import HeroBlock from '@/components/HeroBlock.vue'
import FeaturesBlock from '@/components/FeaturesBlock.vue'

const componentMap = {
  hero: HeroBlock,
  features: FeaturesBlock
}

Then render safely:

<component
  :is="componentMap[block.type]"
  v-bind="block.props"
/>

Benefits:

Strong boundaries
Better type safety
Easier refactoring
Clear ownership of what can be rendered

This pattern scales well with CMS-driven systems.

Rendering Lists of Dynamic Blocks

Most config-driven UIs involve iteration:

<template>
  <component
    v-for="block in blocks"
    :key="block.id"
    :is="componentMap[block.type]"
    v-bind="block.props"
  />
</template>

This allows:

Reordering content without code changes
Enabling/disabling blocks via config
Experimenting with layouts safely

The UI becomes data-driven, not template-driven.

CMS-driven Interfaces in Practice

A typical CMS payload might look like:

{
  "blocks": [
    { "id": 1, "type": "hero", "props": { "title": "Welcome" } },
    { "id": 2, "type": "features", "props": { "items": [] } }
  ]
}

Vue consumes this naturally using dynamic components — no conditionals, no giant v-if chains.

This is significantly more maintainable than:

<Hero v-if="type === 'hero'" />
<Features v-else-if="type === 'features'" />

🟢 Common Pitfalls of Dynamic Components

Overusing Dynamic Rendering

Not every UI should be config-driven.

Avoid dynamic components when:

The layout is static
The structure rarely changes
The complexity outweighs flexibility

Dynamic components introduce indirection — use them intentionally.

Leaking Logic into Configuration

Configuration should describe what, not how.

Bad:

{ "type": "hero", "showIf": "user.isAdmin && env === 'prod'" }

Good:

Keep logic in code
Keep config declarative
Validate inputs before rendering

Performance Considerations

Dynamic components are still Vue components:

They mount
They update
They re-render

Optimize with:

markRaw for component maps
KeepAlive for frequently toggled blocks
defineAsyncComponent for heavy CMS sections

Dynamic doesn’t mean free — measure when needed.

📖 Learn more

If you would like to learn more about Vue, Nuxt, JavaScript or other useful technologies, checkout VueSchool by clicking this link or by clicking the image below:

It covers most important concepts while building modern Vue or Nuxt applications that can help you in your daily work or side projects 😉

🧪 Advance skills

A certification boosts your skills, builds credibility, and opens doors to new opportunities. Whether you're advancing your career or switching paths, it's a smart step toward success.

Check out Certificates.dev by clicking this link or by clicking the image below:

Invest in yourself—get certified in Vue.js, JavaScript, Nuxt, Angular, React, and more!

✅ Summary

Config-driven interfaces are one of Vue’s quiet superpowers.

In this article you learned:

What config-driven UI means in Vue
How <component :is> enables dynamic rendering
Patterns for CMS-driven and backend-driven layouts
Common pitfalls to avoid
When dynamic components are worth the complexity

Used intentionally, dynamic components turn Vue into a flexible UI runtime — not just a templating system.

Take care!
And happy coding as always 🖥️

Forem: Jakub Andrzejewski

Why Loaders Matter for Performance

🤔 What Is Cumulative Layout Shift (CLS)?

🟢 Implementing proper loaders in Vue

🧪 Best Practices

📖 Learn more

🧪 Advance skills

✅ Summary

How to Safely Allow Inline Scripts Without Breaking Security with CSP Nonce

🤔 What Is CSP Nonce?

🟢 What Problem Does CSP Nonce Solve?

❌ Allow inline scripts (unsafe)

❌ Block inline scripts completely

🟢 How to Implement CSP Nonce

Step 1: Generate a nonce per request

Step 2: Add it to response headers

Step 3: Inject it into your HTML

⚠️ Critical rule

🟢 CSP Nonce in Nuxt (with nuxt-security)

🟢 Common Mistakes

🧪 Best Practices

📖 Learn more

🧪 Advance skills

✅ Summary

Flexible Code Without Losing Type Safety with TS Generics

🤔 Problem with type reusability

🤔 Solution: TypeScript Generics

🟢 Practical Examples

✅ Example 1: Reusable API Response Type

✅ Example 2: Generic Array Helper

✅ Example 3: Generic Props in Vue

✅ Example 4: Constraining Generics

✅ Example 5: Keyof + Generics

📖 Learn more

🧪 Advance skills

✅ Summary

When You Should Use Vue Teleport

🤔 What Is Vue Teleport?

🟢 When Should You Use Vue Teleport?

✅ Modals / Dialogs

✅ Tooltips & Dropdowns

✅ Notifications / Toasts

✅ Third-party UI Libraries (Real Example)

🟢 Deferred Teleport (defer)

🟢 Common Mistakes When Using Teleport

🧪 Best Practices

📖 Learn more

🧪 Advance skills

✅ Summary

Reusable Architecture for Large Applications with Nuxt Layers

🤔 What Are Nuxt Layers?

🟢 Creating a Nuxt Layer

🟢 Reusing Code Across Multiple Projects

🟢 Using Layers for Scalable Architecture

🟢 Layer Overrides and Merging

⚠️ Tradeoffs of Nuxt Layers

Increased Architectural Complexity

Debugging Can Be Harder

Tooling and IDE Navigation

Overengineering Risk

📖 Learn more

🧪 Advance skills

✅ Summary

How Vue Protects Your App Against Injections

🤔 What Are Injection Attacks?

🟢 Vue Automatic HTML Escaping

🟢 Template Compilation Safety

🟢 Attribute Injection Protection

🟢 URL Injection Protection

🔴 The Danger of v-html

🧪 Best Security Practices for Vue Apps

📖 Learn more

🧪 Advance skills

✅ Summary

Lesser-Known but Powerful Vue Features

🤔 Why These Features Matter

🟢 nextTick()

🟢 watchEffect()

🟢 provide() / inject()

🟢 useId()

🟢 Deferred Teleport (`defer`)

🔴 The Danger of `v-html`

🤔 What Is `effectScope` in Vue?

🟢 Basic Usage of `effectScope`

🟢 Using `effectScope` Inside Composables

🟢 Dynamic Components with `<component :is>`