DEV Community: Sebastian Wrzalek

Stop Making These 5 Common Vue Mistakes!

Sebastian Wrzalek — Fri, 27 Jun 2025 22:12:38 +0000

1. Treating Everything as Reactive

Vue's ref is an excellent way to manage reactive state, but not everything should be reactive. When using Vue, developers often mistakenly treat all variables as reactive. For values that will remain static and never change, define them using const. Reserve ref or reactive exclusively for state that truly needs to update the view.

Incorrect:

const createdBy = ref('JohnDoe'); // If username never changes, this is unnecessary.

Correct:

const createdBy = 'JohnDoe';

2. Using `watch()` Without Understanding State Flow

It's easy to misuse watchers (watch()) when you don’t fully grasp how your application's data flow works. Watchers can create hidden side-effects and subtle race conditions if logic is scattered and improperly managed.

❌

const comments = ref([]);
const article = ref({});

fetchArticle().then((data) => article.value = data.article);

watch(article, () => {
  fetchComments(article.value.id).then((data) => { comments.value = data.comments });
});

✅

const comments = ref([]);
const article = ref({});

const fetchArticleAndComments = async () => {
  const { article: articleData } = await fetchArticle();
  article.value = articleData;

  const { comments: commentsData } = await fetchComments(articleData.id);
  comments.value = commentsData;
};

fetchArticleAndComments();

Use watchers only as escape hatches, not as the default approach.

3. Using `v-if` Where `v-show` Fits

Many Vue developers use v-if unnecessarily. v-if mounts and destroys elements or components, making it ideal for one-time, conditional rendering. However, frequent toggles should use v-show, as it simply toggles CSS display, making it much more efficient.

Use v-show when:

Elements toggle frequently.
The cost of mounting/destroying elements repeatedly is high.

❌

<div v-if="isVisible">Toggle me frequently!</div>

✅

<div v-show="isVisible">Toggle me frequently!</div>

4. Computed Properties Mutating State

Computed properties in Vue should always be pure and free from side effects. A common subtle mistake is directly mutating state within computed properties, especially with array methods like reverse() or sort().

❌

  const reversedNumbers = computed(() => numbers.reverse()) // This mutates the original array!

✅

  const reversedNumbers = computed(() => [...numbers].reverse()) // Creates a new array, maintaining purity

5. Overusing Pinia/Vuex Store

State management libraries like Pinia or Vuex are powerful, but it's important not to overuse them. As Dan Abramov says, "Flux libraries are like glasses: you'll know when you need them."

Initially, manage state with props, emits, and local state. Consider using a store when you have deeply nested components or need shared state across multiple component branches. Excessive reliance on stores can lead to unintended complexity and side effects.

Guidelines for using a store wisely:

Use local state or component props/emits first.
Consider a store when dealing with shared state across unrelated components.
Avoid overloading the store with local, component-specific state.
Avoid circular dependencies - store A in store B and store B in store A

Thanks for reading

If you liked it leave some ❤️

Building a Microfrontend Architecture with Vue 3, Vite, Single-SPA

Sebastian Wrzalek — Sun, 02 Mar 2025 15:05:01 +0000

Microfrontends with Vue 3, Vite, and Single-SPA

Microfrontends have become a popular approach for scaling frontend applications, especially in environments where multiple teams work on various parts of the app independently. In this guide, we'll explore how to build a simple microfrontend application using Vue 3, Vite, Single-SPA, and vite-plugin-single-spa.

Introduction to Microfrontends
Understanding Single-SPA Framework
Demo Project
Prerequisites
Creating the Secondary (Microfrontend) Application
Configuring the Secondary App
Handling Different Bundle Locations
Registering the Microfrontend in the Root Project
Testing the Setup
The Problem
The Second Problem
Final Words

Introduction to Microfrontends

"The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specializes in. A team is cross-functional and develops its features end-to-end, from database to user interface."

Microfrontends are an architectural approach that extends the concept of microservices to the frontend. Instead of building a single monolithic frontend application, the app is divided into smaller, manageable pieces called microfrontends. Each microfrontend is a self-contained application with its own codebase, framework, and deployment pipeline.

Benefits of Microfrontends:

Scalability – Multiple teams can work independently on different features.
Flexibility – Each microfrontend can use its own tech stack.
Resilience – Failures in one microfrontend don’t affect others.

Understanding Single-SPA Framework

Single-SPA is a framework that allows multiple microfrontends, potentially using different frameworks (e.g., Vue, React), to coexist and operate within the same application. It manages the lifecycle of each microfrontend, enabling them to load and unload dynamically based on routing configurations.

Single-SPA Components:

Root Configuration – Responsible for rendering the HTML page and registering applications. Each application is registered with:
- A name
- A function to load the application’s code
- A function to determine when the application is active or inactive
Applications – Microfrontends functioning as SPAs packaged into modules. Each application must implement methods to bootstrap, mount, and unmount itself from the DOM.

Core Concepts of Single-SPA:

Application Registrations – Register each microfrontend as an application.
Lifecycle Methods – Each microfrontend has lifecycle methods (mount, unmount, etc.).
Routing – Single-SPA can load microfrontends based on URL paths.

Example:

A React or Vue SPA can be registered as an application. When active, it listens to URL routing events and renders content on the DOM; when inactive, it stops listening to routing events and is fully removed from the DOM.

Demo Project

In this article, we’ll build both the root application—responsible for orchestrating the mounting and unmounting of microfrontends—and a sample microfrontend for demonstration. Although the official recommendation discourages using a framework in the root configuration, this project uses a Vue application at the root to provide a consistent layout, global navigation, and cohesive styling across all microfrontends.

Prerequisites

Let’s create our root application. This project uses Vue as its framework:

npm create vue@latest

✔ Project name: … root
✔ Add TypeScript? … Yes
✔ Add JSX Support? … No
✔ Add Vue Router for Single Page Application development? … Yes
✔ Add Pinia for state management? … No
✔ Add Vitest for Unit Testing? … No 
✔ Add an End-to-End Testing Solution? › No
✔ Add ESLint for code quality? …  Yes
✔ Add Prettier for code formatting? …  Yes
✔ Add Vue DevTools 7 extension for debugging? (experimental) … No

cd root
npm install
npm run format
npm run dev

After creating the root application, install the necessary dependencies:

npm install --save single-spa-vue vite-plugin-single-spa single-spa

Next, integrate vite-plugin-single-spa within your vite.config.ts:

import { fileURLToPath, URL } from 'node:url'
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import vitePluginSingleSpa from 'vite-plugin-single-spa';

// https://vite.dev/config/
export default defineConfig({
  plugins: [
    vue(), 
    vitePluginSingleSpa({ 
      type: 'root', 
      imo: '3.1.1' 
    })
  ],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  }
})

Creating the Secondary (Microfrontend) Application

Before we configure the root application to load a microfrontend, let’s create another Vue app:

npm create vue@latest

✔ Project name: … app
✔ Add TypeScript? … Yes
✔ Add JSX Support? … No
✔ Add Vue Router for Single Page Application development? … Yes
✔ Add Pinia for state management? … No
✔ Add Vitest for Unit Testing? … No 
✔ Add an End-to-End Testing Solution? › No
✔ Add ESLint for code quality? …  Yes
✔ Add Prettier for code formatting? …  Yes
✔ Add Vue DevTools 7 extension for debugging? (experimental) … No

cd app

Install additional dependencies for this new app:

npm install --save single-spa-vue vite-plugin-single-spa

Below is the directory structure so far:

single-spa-demo
├── root
│   ├── src
│   ├── vite.config.ts
│   └── package.json
└── app
    ├── src
    ├── vite.config.ts
    └── package.json

Configuring the Secondary App

We must configure the Vite Single-SPA plugin so the Vue application outputs a microfrontend:

// ### app/vite.config.ts ###
import { fileURLToPath, URL } from 'node:url'
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import vitePluginSingleSpa from 'vite-plugin-single-spa'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    vue(),
    vitePluginSingleSpa({
      type: 'mife',
      serverPort: 4101,
      spaEntryPoints: 'src/main.ts',
    })
  ],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  },
  // Ensure the dev server uses the same port as set in the plugin
  server: {
    port: 4101
  }
})

Here, vitePluginSingleSpa({ type: 'mife', serverPort: 4101 }) configures the plugin, identifying this build as a microfrontend and setting the development server to port 4101.

Main File Modifications

The microfrontend must know how to bootstrap, mount, and unmount itself from the DOM. Update main.ts accordingly:

// ### app/main.ts ###
import App from './App.vue'
import './assets/main.css'
import singleSpaVue from 'single-spa-vue'
import { createApp, h } from 'vue'
import router from './router'

const vueLifecycles = singleSpaVue({
  createApp,
  appOptions: {
    render() {
      return h(App, {
        props: {
          name: this.name,
        },
      });
    },
  },
  handleInstance: (app) => {
    app.use(router);
  },
});

const mountVue = () => {
  const app = createApp(App)
  app.use(router)
  app.mount('#app')
}

// Only mount the app in standard SPA mode during development
if (import.meta.env.MODE === 'development') {
  mountVue();
}

export const bootstrap = vueLifecycles.bootstrap;
export const mount = vueLifecycles.mount;
export const unmount = vueLifecycles.unmount;

Because Single-SPA handles mounting and unmounting, we cannot mount the application in production in the usual way. However, we still want to support standalone development, so we only mount if import.meta.env.MODE is development.

Below is an example of how to differentiate development modes in your package.json:

{
  "scripts": {
    "dev": "vite --mode development",
    "dev:sspa": "vite --mode staging"
  }
}

With these changes, the microfrontend is ready to be consumed by the root project.

Handling Different Bundle Locations

One challenge is that the microfrontend’s entry file (main.ts) is served at different URLs in development vs. production:

Development: http://localhost:4101/src/main.ts
Build: http://localhost:4101/main.js

We will address this discrepancy using native import maps. Within the root project, create two files for mapping these paths:

`root/src/importMap.dev.json`

{
  "imports": {
    "@howlydev/app": "http://localhost:4101/src/main.ts"
  }
}

`root/src/importMap.json`

{
  "imports": {
    "@howlydev/app": "http://localhost:4101/main.js"
  }
}

These files instruct the root application to resolve the microfrontend’s path differently based on environment.

Registering the Microfrontend in the Root Project

Create a file named single-spa.setup.ts in your root app:

// ### root/single-spa.setup.ts ###
import { registerApplication, start } from "single-spa"

const apps = {
  "app": "@howlydev/app"
}

export function registerSpas() {
  for (const [route, moduleName] of Object.entries(apps)) {
    registerApplication({
      name: route,
      app: () => import(/* @vite-ignore */ moduleName),
      activeWhen: `/${route}`,
    })
  }
  runSpas();
}

export function runSpas() {
  start();
}

registerApplication: Tells Single-SPA which application to load and on which route path.
start(): Initializes Single-SPA, enabling the lifecycle of registered applications.

Testing the Setup

Run both the root and microfrontend applications in separate terminals:

# In the root folder
npm run dev

# In the app folder
npm run dev:sspa

Open the URL for your root application (e.g., http://localhost:5173/). The microfrontend should be dynamically loaded and displayed when its route is accessed.

The Problem

When you navigate to the route that initializes the microfrontend, you may notice unexpected behavior: because both the root application and the microfrontend use Vue, there are two Vue instances running. Additionally, the microfrontend is not rendered within the router-view controlled by the root’s Vue Router.

Inspecting the DOM reveals that both the root and microfrontend instances are active, but the microfrontend content is appended directly to the body (or another top-level element) rather than where the root router expects it.

To fix this, you can leverage Vue’s Teleport feature to “teleport” the microfrontend’s content into a specified container within the root application:

<!-- ### app/App.vue ### -->
<template>
  <Teleport to=".container" :disabled="isTeleportDisabled">
    <div style="background-color: lightcoral">
      <h1>Hello From the Microfrontend</h1>
      <router-view />
      <ul>
        <li>
          <router-link to="/foo">Go to Foo</router-link>
        </li>
        <li>
          <router-link to="/bar">Go to Bar</router-link>
        </li>
      </ul>
    </div>
  </Teleport>
</template>

<script setup lang="ts">
const isTeleportDisabled = import.meta.env.MODE === 'development'
</script>

Meanwhile, in your root application, ensure there is a .container element available to receive this teleported content:

### root/App.vue ###
<template>
    <main>
      <div class="container">
        <router-view />
      </div>
    </main>
</template>

Here, the microfrontend’s content is rendered where you want it, and the teleport is disabled during standalone (development) mode so you can still see the microfrontend by itself.

The Second Problem

A common requirement is that each microfrontend can handle its own internal routing. In this example:

The root application doesn’t “know” about /app.
The microfrontend expects its base route to be /.

When you visit "/app", you might see a warning in the console:

[Vue Router warn]: No match found for location with path "/app"

Though you can’t fully suppress these warnings (see this Vue Router issue), you can enable routing in the microfrontend by changing the base path, we will go even further and pass it from root application:

### root/single-spa.setup.ts ###

export const apps = {  
  app : "@howlydev/app"  
}  

export function registerSpas() {  
  for (const [route, moduleName] of Object.entries(apps)) {  
    registerApplication({  
      name: route,  
      app: () => import(/* @vite-ignore */ moduleName),  
      activeWhen: `/${route}`,  
      customProps: {  
        basePath: `/${route}` /* <-- this is new */
  }  
    });  
  }  

  runSpas();  
}  

export function runSpas() {  
  start();  
}

Next we will pass our basePath to the router.

### app/src/main.ts ###

import App from './App.vue'  
import './assets/main.css'  
import singleSpaVue from 'single-spa-vue'  
import {createApp, h} from "vue";  
import router from './router'  

type Props = {  
  name: string,  
  basePath: string,  
}  

const vueLifecycles = singleSpaVue({  
  createApp,  
  appOptions: {  
    render() {  
      const { name, basePath } = this as unknown as Props;  
      return h(App, {  
        name: name,  
        basePath: basePath,  
      });  
    },  
  },  
  handleInstance: (app, props: Props) => {  
    app.use(router(props.basePath));  
  }  
});  

const mountVue = () => {  
  const app = createApp(App)  
  app.use(router())  
  app.mount('#app')  
}  

if (import.meta.env.MODE === 'development') {  
  mountVue();  
}  

export const bootstrap = vueLifecycles.bootstrap;  
export const mount = vueLifecycles.mount;  
export const unmount = vueLifecycles.unmount;

### app/src/router/index.ts ###

import { createRouter, createWebHistory } from 'vue-router'  
import FooView from "@/views/FooView.vue";  
import BarView from "@/views/BarView.vue";  

const router = (basePath = '/app') => createRouter({  
  history: createWebHistory(basePath),  
  routes: [  
        {  
          path: "/foo",  
          name: "foo",  
          component : FooView,  
        },  
        {  
          path: "/bar",  
          name: "bar",  
          component : BarView  
        }  
  ],  
})  

export default router

Our router is now a function that accepts basePath as an argument and returns Router instance that can be used by a Vue app.

Final Words

Microfrontends can be highly beneficial for large-scale applications, but they’re not always straightforward to implement. As shown here, multiple Vue instances and routing complexities can create unexpected issues. Despite these trade-offs (and alternatives such as vite-plugin-federation), microfrontend architecture is worth knowing about. You might ask: is it solving a real problem?

It depends.

If you need to build a simple Todo app, it’s probably overkill.
If you’re building a Cloud ERP, it might be worth exploring.

I’ll quote Uncle Bob here:

You should be able to structure your code in a clean, modular fashion within a monolith before considering distribution. If you cannot form clear boundaries in a single-process system, you are unlikely to succeed by splitting it into microservices.

The full GitHub repository can be found here:

https://github.com/swrzalek/vue3-vite-sspa-demo/tree/main

If you’d like to see a more complex, real-world microfrontend example, let me know in the comments!

If you found this article helpful, please leave a like! ❤️

How to deploy Nuxt 3 app to Netlify with Github Actions

Sebastian Wrzalek — Wed, 19 Apr 2023 23:04:57 +0000

Deploying a Nuxt 3 app to Netlify seems like a easy job. You can connect repository to Netlify site and it is automatically deployed when you pushed your changes to the origin branch.
Me in the other hand, prefer to have everything in one place, so I wanted to control my CI/CD from Github Actions. In this article I will show you how, let's go!

As you might not know Nuxt 3 works with Nitro (open engine powering Nuxt) so normally, the deployment to Netlify does not require any configuration. Nitro will auto-detect that you are in a Netlify build environment and build the correct version of your server. But our scenario is not normal so we need to take some additional steps.

Create empty project

Make sure you have installed yarn, npx (included by default with npm
v5.2+) or npm (v6.1+) and node with at least
16.x version installed

yarn create nuxt-app <project-name>

Inside of the nuxt.config.ts file change the preset to netlify

export default defineNuxtConfig({  
    nitro: {  
        preset: 'netlify'  
  },  
  ...
})

Create workflow configuration

mkdir -p .github/workflows && touch .github/workflows/main.yml

Here is the inside of main.yml file

name: 'My Workflow'  

on:  
  push:  
    branches:  
    - main  

jobs:  
  deploy:  
    # Operating system to run job on  
  runs-on: ubuntu-latest  

    # Steps in job  
  steps:  
      # Get code from repo  
  - name: Checkout code  
        uses: actions/checkout@v1  
      # Install NodeJS  
  - name: Use Node.js 16.x  
        uses: actions/setup-node@v1  
        with:  
          node-version: 16.10.0  
      # Run npm install and build on our code  
  - run: npm install  
      - run: npm run build  
      # Deploy to Netlify using our dev secrets  
  - name: Deploy to netlify  
        uses: netlify/actions/cli@master  
        env:  
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_TOKEN }}  
          NETLIFY_SITE_ID:  ${{ secrets.SITE_ID }} 
        with:  
          args: deploy

Next we need to add secrets to our repository settings, you can find it here
https://github.com/{GITHUB_USERNAME}/{REPOSITORY_NAME}/settings/secrets/actions

Obtain a token in the Netlify UI

You can generate an access token manually in your Netlify user settings for Personal access tokens.

Under Personal access tokens, select New access token.
Enter a description.
Select Generate token.
Copy the generated token to your clipboard. Once you navigate from the page, the token cannot be seen again.
Save the token as a NETLIFY_AUTH_TOKEN environment variable in your terminal settings or in the UI of a Continuous Integration (CI) tool.

Obtaining Site ID

On your Netlify account

Go to Site settings > General > Site details > Site information, and copy the value for Site ID.

Push Your Code

Make sure you have pushed your code to the main branch, this way you will trigger Github Workflow and deploy your app to the world.

Three Concepts you need to know as Senior Software Engineer

Sebastian Wrzalek — Wed, 19 Apr 2023 17:16:07 +0000

As a software engineer, you have likely amassed a great deal of technical knowledge and experience in your field. However, there are certain key concepts that are worth knowing. In this article, we will discuss three concepts that every experienced engineer should be familiar with in order to stay ahead of the game.

Cohesion

In programming, cohesion refers to the degree to which the elements of a module or a software component work together to achieve a single, well-defined purpose or function. In other words, it's a measure of how closely related the parts of a module are to each other.

High cohesion means that the elements within a module are highly related and work together closely to achieve a specific task or function. Low cohesion, on the other hand, means that the elements within a module are loosely related and may not work together efficiently to achieve a specific purpose.
High cohesion is generally considered desirable because it leads to more maintainable and reusable code. It makes it easier to understand and modify a module without affecting the rest of the program. On the other hand, low cohesion can lead to code that is difficult to understand, modify, and maintain, which can result in bugs, errors, and inefficiencies.
Sound great but how to achieve high cohesion and low coupling?

Single Responsibility Principle (SRP): Each class or module should have only one responsibility.
Interface Segregation Principle (ISP): Interfaces should be designed to be as small as possible, with only the methods that are necessary for the implementation of the interface.
Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules, but both should depend on abstractions.

Cognitive Complexity

Cognitive complexity is a measure of the difficulty of understanding and reasoning about a piece of code. It takes into account the number of distinct paths through the code, the nesting depth of control structures, and the number of logical operators and operands.

A higher cognitive complexity indicates that the code is more difficult to understand and reason about, which can lead to more bugs, slower development time, and more difficult maintenance.
Code with a low cognitive complexity, on the other hand, is easier to read and understand, which can lead to more efficient development and maintenance.
To make code less complex and easy to read apply Clean Code practice, you can find them for every programming languages, here for Javascript.

Design Patterns

Design patterns are reusable solutions to commonly occurring problems in software design. They are general solutions that can be applied to different situations in software development, making the design and development process more efficient and effective.

Design patterns provide a common vocabulary and a set of best practices for software designers and developers. They help to ensure that software is maintainable, flexible, and extensible, and that it meets the needs of its users.
Design patterns can be used in a variety of programming languages and environments, including object-oriented programming, functional programming, and web development. They are widely used in software development and are an important tool for creating high-quality, maintainable, and reusable software.
If you want to learn more about design patterns I highly recommend checking out Refactoring Guru, they provide great examples and graphics that help you understand it quicker.