DEV Community: Obiwan Pelosi

The Future of Web UI: Trends in React, Vue & Svelte

Obiwan Pelosi — Fri, 24 Oct 2025 09:22:45 +0000

"React was a mistake" -- Twitter User

On September 12, Cloudflare experienced a dashboard and API outage that lasted for over an hour. It was later discovered that cloudflare DDoSed itself; the culprit ? a useEffect bug that lead to repeated API calls.

This incident reignited the never-ending debate about the superior frontend framework and if you've spent anytime online, it really is never-ending.

If you opened this article to find out the "winner", that's too damn bad. It doesn't really matter anyway, my two cents ? Pick what feels right for you or your team, your constraints, and the problem at hand.

In this article, what we want to do instead is to dig into the data. We’ll explore how React, Vue and Svelte stack up in terms of adoption, satisfaction and trend-momentum. From those numbers you can draw your own conclusions about the future of web UI.

Let’s dive in.

How We’re Looking at the Data

The goal here isn’t to crown a new “king of JavaScript frameworks,” but to understand where the front-end ecosystem is heading, using real data.

Most of the numbers and trends in this article come directly from the latest State of JavaScript Survey, specifically the Front-end Frameworks section. It’s one of the most comprehensive developer sentiment and usage surveys out there, covering thousands of responses from developers worldwide.

Here’s how we’re approaching it:

Metrics we’re focusing on:

Usage: how many developers actually use the framework, especially in production.
Retention: how many would use it again which is a good measure of satisfaction.
Happiness: the overall sentiment developers have toward each tool.
Trends over time: how these frameworks have grown, stabilized, or declined across survey years.

Our lens:

We’re keeping it objective; numbers first, opinions later. But we’ll still interpret what those numbers could mean for the future of UI development.

Of course, it’s worth noting that surveys like this aren’t a perfect reflection of the entire industry (after all, not every developer fills them out). But they do give a pretty reliable pulse on where the developer community’s excitement and frustrations lie.

Now that we know what we’re measuring and why, let’s see what the numbers actually say.

Popularity & Adoption: The Framework League Table

Let’s start with the question that sparks most arguments at meetups and online threads: which framework is the most popular?

Unsurprisingly, React still wears the crown. According to the State of JS 2024 Survey, React remains the most widely used front-end framework, with roughly eight out of ten respondents saying they’ve worked with it in some capacity; and more than 8,500 developers using it at work. That’s a huge footprint.

Coming in second is Vue.js, holding its ground as a mature and widely trusted alternative. About 4,000 respondents reported using Vue professionally, which translates to just over half of all developers surveyed. Vue’s adoption has plateaued a bit compared to its explosive early growth years, but it’s clearly not going anywhere; it’s found its niche and holds onto it well.

And then there’s Svelte, the minimalist rising star. While only 1,400 developers in the survey said they use it at work (around a quarter of respondents), Svelte has something the others don’t: a cult-like loyalty and satisfaction score that punches way above its weight.

Here’s how they line up if we strip away all the noise and look purely at adoption numbers:

So yes — React continues to dominate by sheer numbers, but Vue and Svelte aren’t just background noise. Vue has solidified itself as the dependable second choice, while Svelte has captured the hearts (and code editors) of developers looking for something refreshingly different.

Popularity, though, only tells part of the story. What really matters is how much people actually enjoy using these tools; and whether they’d choose them again.
That’s where things start to get interesting.

Retention & Satisfaction: Love It or Leave It?

Popularity is great, but let’s be honest; just because everyone’s using something doesn’t mean they’re happy about it. Just ask a cloudflare developer 😉.

That’s why it’s worth looking at a more telling metric: retention; how many developers would willingly use a framework again. It’s a solid indicator of developer satisfaction and long-term staying power.

Here’s what the State of JS 2024 Survey tells us:

So, while React continues to lead in raw usage, Vue and Svelte take the crown when it comes to developer joy.

In other words, most React users stick around mostly because it’s the industry default. Vue and Svelte users, on the other hand, stay because they want to.

And this sentiment shows in the happiness charts too. The survey’s “Front-end Frameworks Happiness” graph paints a clear picture: React’s curve is starting to flatten, Vue’s stays consistently high, and Svelte’s line shoots to the top.

The takeaway?
If the front-end world were a dating app, React would be the long-term partner you’ve settled down with. Vue would be the balanced, reliable choice you actually enjoy spending time with. And Svelte — well, that’s the exciting new fling everyone’s talking about.

But beyond love and loyalty, the real question is: where are these frameworks headed next? Let’s zoom out and see how their stories have evolved over time.

Usage Trends Over Time: The Shifting Front-End Landscape

Frameworks, like fashion trends, have their moments. React had its meteoric rise in the late 2010s, Vue exploded shortly after, and Svelte quietly entered the chat.

If you glance at the survey’s “Ratios Over Time” chart, you’ll notice a few clear storylines:

React is no longer the scrappy newcomer; it’s the default. Its usage curve peaked and then began to level off. That’s not necessarily decline; it’s maturity. React has saturated the ecosystem so thoroughly that growth can only be incremental now.

Vue remains the solid number-two choice. After its explosive early years, it has settled into a steady rhythm. The data shows Vue holding its ground, even gaining a few points in retention, suggesting that those who adopt it tend to stick.

Svelte, meanwhile, is on a gentle but consistent upward trajectory. It doesn’t have the mass adoption of React or Vue (yet), but its curve is pointing in exactly the right direction; growing steadily year after year.

The survey summary even puts it succinctly:

_“Vue managed to keep its number two spot — as well as gained a whopping three spots in terms of retention percentage! Meanwhile, Svelte usage is increasing at a steady pace, while it continues to top the rankings in terms of overall positive opinions.”
_

In simpler terms: React’s dominant, Vue’s stable, and Svelte’s on the rise.

So where does that leave us?
It paints a front-end ecosystem that’s diversifying rather than consolidating. Instead of one framework crushing all others, we’re seeing multiple strong players thriving in their own lanes — and that’s actually great news. It means developers have options that fit different project needs and preferences.

What This Means for the Future of Web UI

If there’s one thing the State of JS 2024 data makes clear, it’s that the front-end landscape isn’t about one framework winning anymore — it’s about evolution and coexistence.

React has solidified its role as the dependable heavyweight — the foundation of countless production apps and entire ecosystems. Vue continues to thrive as the pragmatic alternative, offering a gentle learning curve without sacrificing power and with its latest approach to reactivity system, it's now believed to be the fastest of them all. And Svelte? It’s quietly shaping the future, reminding everyone that innovation often starts at the fringes.

We’re entering a phase where the “React vs. Vue” debate feels outdated. Each framework now appeals to a different kind of developer mindset

The future of Web UI isn’t about choosing sides; it’s about choosing fit. As new tools like Solid, Qwik, and Signals-based reactivity models gain traction, one truth remains: the front-end world never stands still.

So whether you’re a React loyalist, a Vue enthusiast, or a Svelte experimenter, the key is to stay curious, adaptable, and willing to unlearn. Because in this space, today’s underdog might just be tomorrow’s default.

🎉 Vue-icons (a react-icons equivalent) is finally here, LFG

Obiwan Pelosi — Sun, 29 Jun 2025 08:20:26 +0000

If you've ever used React, you've probably come across the excellent react-icons library — a single, tree-shakeable, well-typed icon package that just works.

But for Vue developers? The icon ecosystem has felt scattered and inconsistent... until now.

👉 Say hello to Vue Icons Library — a modern, TypeScript-first icon library designed specifically for Vue.

🔗 Quick Links

🧑‍💻 Visit the Website
📦 GitHub Repository
🚀 Install Now:

npm install vue-icons-lib

🔍 What is Vue Icons Library?

Vue Icons Library is the Vue 3 equivalent of react-icons — a comprehensive, zero-dependency, tree-shakeable icon library that bundles 7+ popular icon sets into a single, intuitive API.

Built with modern Vue tooling, it brings performance, type safety, and simplicity to working with icons in your Vue apps.

🎯 Key Features

✅ Tree-shakeable by design – Only the icons you import are included in your bundle
💡 TypeScript-first – Full type definitions with IDE IntelliSense
🧩 Built for Vue 3 – Composition API, script setup support, and reactivity-ready
⚡ Lightweight & Fast – Clean SVGs, optimized build pipeline
🧱 Consistent API – Unified props (size, color, class, etc.) across all icons
♿ Accessible – Proper viewBox and accessible by default
🌐 SSR Compatible – Works great with Nuxt, Vite SSR, etc.

🎨 Included Icon Sets

Vue Icons Library ships with thousands of icons from your favorite sets:

Ant Design Icons
Box Icons
Circum Icons
CSS.gg Icons
Dev Icons
Feather Icons

More sets (like Material Icons and Heroicons) are coming soon!

⚙️ Getting Started

Installation:

npm install vue-icons-lib

Basic usage:

<script setup>
import { FiHeart } from 'vue-icons-lib/fi';
import { AiFillStar } from 'vue-icons-lib/ai';
import { BxHome } from 'vue-icons-lib/bx';
</script>

<template>
  <div>
    <FiHeart color="#ff6b6b" size="24px" />
    <AiFillStar color="#ffd700" />
    <BxHome class="home-icon" />
  </div>
</template>

Advanced Example:

<script setup>
import { FiHeart } from "vue-icons-lib/fi";

function handleClick() {
  console.log("Heart clicked!");
}
</script>

<template>
  <FiHeart
    size="32px"
    color="#ff6b6b"
    class="heart-icon"
    style="cursor: pointer; transition: transform 0.2s;"
    @click="handleClick"
  />
</template>

🚀 Real-World Usage Example:

<script setup>
import { FiHeart, FiStar, FiShare, FiBookmark } from "vue-icons-lib/fi";

const props = defineProps<{
  isLiked: boolean;
  isStarred: boolean;
}>();
</script>

<template>
  <div class="action-buttons">
    <FiHeart
      :color="isLiked ? '#ff6b6b' : '#666'"
      size="20px"
      class="action-icon"
      @click="$emit('toggle-like')"
    />
    <FiStar
      :color="isStarred ? '#ffd700' : '#666'"
      size="20px"
      class="action-icon"
      @click="$emit('toggle-star')"
    />
    <FiShare size="20px" class="action-icon" @click="$emit('share')" />
    <FiBookmark size="20px" class="action-icon" @click="$emit('bookmark')" />
  </div>
</template>

📦 Bundle Optimization

Before (bad):

<script setup>
import * as Icons from 'some-icon-library'; // 😱 All icons are bundled
</script>

After (with Vue Icons Library):

<script setup>
import { FiHeart, FiStar } from 'vue-icons-lib/fi'; // ✅ Only what you need
</script>

Result? ⚡ Smaller bundle size and faster load times — especially important for production apps.

🧪 Compatibility & Support

✅ Vue 2 & 3.x

✅ Vite, Webpack, Rollup

✅ TypeScript

✅ SSR (Nuxt.js, etc.)

✅ Tree-shaking compatible bundlers

✅ All modern browsers

🤝 Get Involved

Vue Icons Library is open source and welcomes contributions!

💬 Submit issues or feature requests
🛠 Add more icon sets or improve performance
🧾 Help refine the docs and examples
🌟 Star the repo if you like the project!

GitHub → github.com/vue-icons-lib

👉 Explore the icons and docs site here

🚀 Supercharge Your Web Apps with Web Workers in React and Vue

Obiwan Pelosi — Mon, 19 May 2025 15:00:46 +0000

Have you ever noticed your web app freezing for a moment while processing something complex—maybe parsing a huge JSON file, crunching numbers, or resizing an image? 😬

That’s your main thread choking under pressure.

But fear not! There's a superhero in the browser world that can take some of the heavy lifting off your main thread’s shoulders. Meet Web Workers, your friendly background JavaScript buddies.

In this article, we’ll explore how to integrate Web Workers into both React and Vue applications. Let’s make your apps faster, smoother, and more responsive, with some fun along the way!

🧠 Why even use Web Workers?

Javascript is single-threaded which means the browser's main thread is responsible for handling both UI rendering and also logic. This can get "too much" and cause lags especially when performing expensive operations. Web Workers run in a separate thread from the main browser thread. This means they can handle resource-heavy tasks without blocking your UI.

✅ When You Should Use Web Workers

🔁 1. Heavy Computation

If you're performing tasks that take more than a few milliseconds, like:

Processing large datasets (e.g., CSV parsing, log processing)
Image manipulation (e.g., filters, compression)
Cryptographic computations
Complex math or simulations

These tasks block the main UI thread if not offloaded.

📈 2. Real-time Data Processing:

When you're streaming and processing real-time data:

WebSocket streams (e.g., trading dashboards, multiplayer games)
Audio/video analysis
IoT sensor data parsing

🔍 3. Machine Learning Inference in the Browser
Using models (like TensorFlow.js or ONNX) can strain the main thread. Running inference in a Web Worker can keep the UI smooth.

🧠 4. Apps Needing Maximum Responsiveness
Apps where UI responsiveness is crucial:

Graphic editors
Code editors
Collaborative tools

🚫 When Not to Use Web Workers

🐣 1. Simple or Short Tasks

Don’t use a worker for trivial operations. Spinning up a Web Worker has a cost, especially for very small jobs—it could be slower than just running the task in the main thread.

🔗 2. If You Need Access to the DOM

Web Workers can’t:

Read/write the DOM
Access window, document, or localStorage directly.

Use them only for data processing—not UI manipulation.

📦 3. If You’re Already Using Backend Processing

If a task is already handled by a backend service or API, using a worker to process it locally might be redundant or even wasteful.

🔌 4. When Browser Support Is Critical

Web Workers are widely supported, but there may be edge cases (e.g., very old mobile browsers or embedded webviews) where they're unavailable. Test accordingly.

🔨 Web Workers in Action (Vanilla Style)

Before diving into frameworks, let’s get a sense of how Web Workers work.

worker.js

// This runs in a separate thread
self.onmessage = function (event) {
  const data = event.data;
  const result = data * 2; // simulate heavy task
  self.postMessage(result);
};

main.js

const worker = new Worker('worker.js');

worker.postMessage(10);

worker.onmessage = function (event) {
  console.log('Result from worker:', event.data); // 20
};

That's it!

⚛️ Using Web Workers in React

Let’s integrate a worker into a React app with Vite. We'll create a component that uses a worker to perform a CPU-heavy calculation.

🔧 Setup

First, create a worker file:

src/workers/counterWorker.js

self.onmessage = function (e) {
  const num = e.data;
  let result = 0;
  for (let i = 0; i < num; i++) result += i;
  self.postMessage(result);
};

🧩 React Component Example

Imagine you have a component that has to loop over 10 million items

HeavyCounter.jsx

import { useState } from 'react';

export default function HeavyCounter() {
  const [result, setResult] = useState(null);
  const [loading, setLoading] = useState(false);

  const runWorker = () => {
    setLoading(true);
    const worker = new Worker(new URL('@/workers/counterWorker.js', import.meta.url), { type:'module' });
    worker.postMessage(1e7); // pass 10 million items to worker


    worker.onmessage = (e) => {
      setResult(e.data);
      setLoading(false);
      worker.terminate();
    };
  };

  return (
    <div>
      <h2>🔁 Heavy Counter (React + Worker)</h2>
      <button onClick={runWorker} disabled={loading}>
        {loading ? 'Calculating...' : 'Run Task'}
      </button>
      {result && <p>Result: {result}</p>}
    </div>
  );
}

🧩 Using Web Workers in Vue 3

Vue makes this just as easy, especially with Vite.

Using the same worker setup, we can create a vue component that utilizes it:

HeavyCounter.vue

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

const result = ref(null);
const loading = ref(false);

const runWorker = () => {
  loading.value = true;
      const worker = new Worker(new URL('@/workers/counterWorker.js', import.meta.url), { type:'module' });


  worker.postMessage(1e7);

  worker.onmessage = (e) => {
    result.value = e.data;
    loading.value = false;
    worker.terminate();
  };
};
</script>
<template>
  <div>
    <h2>🔁 Heavy Counter (Vue + Worker)</h2>
    <button @click="runWorker" :disabled="loading">
      {{ loading ? 'Calculating...' : 'Run Task' }}
    </button>
    <p v-if="result !== null">Result: {{ result }}</p>
  </div>
</template>

Communication with the worker is asynchronous, you listen for responses from the worker using worker.onmessage and send data to it using worker.postMessage.
Always remember to call worker.terminate() to stop the worker once it's done to free up resources.

🧰 Bonus: Want more power? Look into:

Shared Workers (for multi-tab communication)
Comlink – abstracts away postMessage/onmessage

I really hope you found this article helpful, 🚀 Happy threading!

✨ Vue Tip: Add Undo/Redo to Your App with useRefHistory

Obiwan Pelosi — Mon, 14 Apr 2025 09:30:00 +0000

When building dynamic interfaces, especially where users can make changes (text editors, or design tools), providing undo and redo functionality dramatically improves user experience.

Thankfully, Vue + VueUse makes this a breeze with the useRefHistory composable.

🔄 What is useRefHistory?
useRefHistory from the @vueuse/core package allows you to track the history of changes to a ref in Vue. It enables you to programmatically undo or redo changes made to that ref, just like in text editors or drawing apps.

💡 Let's Build a Simple To-do App with Undo/Redo

In this example, we have a list of to-do items. Every time you add or remove an item, the change is tracked — and you can go back and forth using Undo and Redo buttons.

🧠 The Key Code:

<script setup>
import { ref } from "vue";
import { useRefHistory } from "@vueuse/core";

const todoItems = ref(["walk my dog", "go to the gym", "eat lunch"]);
const add = (e) => {
  todoItems.push(e.target.value);
  e.target.value = "";
};
const remove = (index) => todoItems.value.splice(index, 1);

// 👇 Track changes to `todoItems` and enable undo/redo
const { undo, redo } = useRefHistory(todoItems, {
  deep: true,
});
</script>
<template>
  <div>
    <button @click="undo">Undo</button>
    <button @click="redo">Redo</button>

    <input type="text" @keyup.enter="add" placeholder="Add todo" />
    <ul>
      <li v-for="(item, index) in todoItems" :key="item">
        {{ item }}
        <button @click="remove(index)">Remove</button>
      </li>
    </ul>
  </div>
</template>

Here it is in action:

🛠 Use Cases for useRefHistory
Here are a few places where useRefHistory can be a game changer:

Forms: Revert user inputs step-by-step (e.g., a multi-field form with preview).
Design Tools: Let users undo shapes, colors, or movements in a canvas.
Text Editors: Implement undo/redo in markdown or WYSIWYG editors.
Games: Go back to previous states (e.g., board games like chess).
Collaborative Tools: Temporarily revert shared content locally before syncing changes.

📝 Final Thoughts
useRefHistory is a simple yet powerful utility that adds professional polish to your Vue apps. Whether you're building productivity tools or just want to offer a better user experience, this is definitely one to have in your toolbox.

Want to see the full code? Try it yourself here!

I love slots, do you ?

Obiwan Pelosi — Wed, 12 Mar 2025 12:19:16 +0000

When building Vue applications, components are the backbone of your UI. But what happens when you need a component that isn’t just reusable but also highly customizable? Enter Vue slots—a powerful feature that lets you define placeholders inside components, allowing you to pass in custom content while maintaining reusability.

Vue slots provide unmatched flexibility, making it easy to create dynamic, adaptable components. Whether you need to inject content into a modal, customize the layout of a card, or pass complex UI structures into child components, slots make it effortless. They also promote separation of concerns, ensuring that parent components control layout and logic while child components focus on rendering content.

In this article, we’ll explore:
✅ Named and scoped slots for advanced use cases
✅ Dynamics slot names
✅ Scoped slots with functions

By the end, you'll see how slots can help you write cleaner, more maintainable code while boosting the versatility of your components.
The code is hosted here so you can follow along. Let’s dive in!

Consider the UserList.vue component below:

<script setup>
import { onMounted, ref } from "vue";

const userList = ref([]);
const loading = ref(true);

async function fetchUsers(){
    try {
        const response = await fetch("https://randomuser.me/api/?results=10");
        const data = await response.json();
        userList.value = data.results;
    } catch (error) {
        console.error("Error fetching data: ", error);
    } finally {
        loading.value = false;
    }
}
onMounted(() => {
  setTimeout(() => {
    fetchUsers();
  }, 2000);
});
</script>
<template>
  <div>
    <slot name="title">Users</slot>
    <slot
      name="userlist"
      :list="userList"
      v-if="!loading && userList.length"
    >
      <ul class="userlist">
        <li v-for="item in userList" :key="item.email" class="list-item">
          <div>
            <img
              width="48"
              height="48"
              :src="item.picture.large"
              :alt="item.name.first + ' ' + item.name.last"
            />
            <div>
              <div>{{ item.name.first }}</div>
            </div>
          </div>
        </li>
      </ul>
    </slot>
    <slot v-if="loading" name="loading">Loading...</slot>
  </div>
</template>

<style scoped>
ul {
  list-style: none;
  display: flex;
  flex-direction: column;
  gap: 1em;
}
li.list-item > div {
  display: flex;
  gap: 1em;
}
li img {
  border-radius: 50%;
  width: 50px;
  height: 50px;
}</style>

It's a simple component that fetches a list of users when it mounts. You can also see three main slots sections : title, userlist and loading. They all have fallback content, so rendering this component as it is is gonna look like:

App.vue

<script setup>
import UserList from "./components/UserList.vue";
</script>

<template>
  <UserList />
</template>

In the browser, you should see:

This is barely scratching the surface, for each slot sections, we can define new templates for them wherever needed. So we could change the title to be more descriptive or even insert a new component there. Let's go ahead and do that, let's also pass the number of users to the new title component:

Receive the count as a prop in ListTitle.vue:

<script setup>
const props = defineProps({
  count: Number,
});
</script>
<template>
  <section>
    <h1>My incredible list of {{ count }} users</h1>
  </section>
</template>

<style scoped>
section {
  background-color: #f0f0f0;
  padding: 20px;
  border-radius: 5px;
  margin: 20px 0;
}
h1 {
  color: #333;
}
</style>

Assign the user list length to a variable from the title slot in UserList.vue

<slot name="title" :count="userList.length">Users</slot>

Then in App.vue, access the count variable from the slot and pass it as a prop to the ListTitle component like so :

<UserList>
    <template #title="{ count }">
      <ListTitle :count="count" />
    </template>
  </UserList>

In your browser, you should have:

Let's take it even further, let's modify UserList.vue. Add a remove function to remove users from the list:

function remove(item) {
  userList.value = userList.value.filter(
    (user) => user.login.uuid !== item.login.uuid
  );
}

Let's also modify the userlist slot to look like:

<slot
      name="userlist"
      :list="userList"
      :remove="remove"
      v-if="!loading && userList.length"
    >
      <ul class="userlist">
        <li v-for="item in userList" :key="item.email" class="list-item">
          <slot name="listitem" :user="item">
            <div>
              <img
                width="48"
                height="48"
                :src="item.picture.large"
                :alt="item.name.first + ' ' + item.name.last"
              />
              <div>
                <div>{{ item.name.first }}</div>
                <slot name="secondrow" :item="item"></slot>
              </div>
            </div>
          </slot>
        </li>
      </ul>
    </slot>

Notice we're now also passing the remove function to the slot data. Now we can access the list items and the function to remove items from the list as well. Let's see how we can implement that, let's create a new CardListComponent:

<script setup>
const { list } = defineProps({
  list: Array,
});
</script>
<template>
  <ul class="userlist">
    <li v-for="item in list" :key="item.email">
      <slot name="listitem" :user="item">
        <div class="card">
          <img
            class="resposive"
            :src="item.picture.large"
            :alt="item.name.first + ' ' + item.name.last"
          />
          <div class="card-body">
            <p>{{ item.name.first }} {{ item.name.first }}</p>
            <p>{{ item.email }}</p>
          </div>
        </div>
      </slot>
    </li>
  </ul>
</template>

<style scoped>
ul{
  list-style-type: none;
}
.userlist {
  display: grid;
  gap: 1rem;
  grid-template-columns: 1fr 1fr 1fr;
}

.resposive {
  width: 100%;
}

.card {
  box-shadow: 0 0 4px rgba(0, 0, 0, 0.25);
  border-radius: 4px;
  overflow: hidden;
}

.card-body {
  padding: 1rem;
}
</style>

In App.vue we now have access to the list array and remove function from the userlist slot. We can pass the list to the as a prop to the CardList component like so:

<UserList>
    <template #title="{ count }">
      <ListTitle :count="count" />
    </template>
    <template #userlist="{ list, remove }">
      <CardList :list="list"> </CardList>
    </template>
  </UserList>

Let's take it even further, let's modify the CardList.vue component to have slots and let's make it dynamic. So instead of just rendering the first name, last name and email of the user. let's add the ability to choose what to render using slots.

Modify the card body in CardList.vue to look like:

<div class="card-body">

            <slot name="first" :text="item.name.first"></slot>

            <slot name="last" :text="item.name.last"></slot>

            <slot name="full" :text="`${item.name.first} ${item.name.last}`"></slot>

            <slot name="fullWithTitle" :text="`${item.name.title} ${item.name.first} ${item.name.last}`"></slot>

            <slot name="secondrow" :item="item"></slot>
</div>

Now in App.vue, add a selected ref and options array and bind the value of selected to the slot name inside of the CardList.vue :

const selected = ref("first");

const options = [
  { value: "first", label: "First Name" },
  { value: "last", label: "Last Name" },
  { value: "full", label: "Full name" },
  { value: "fullWithTitle", label: "Name with title" },
];

<template>
  <select v-model="selected">
    <option
      v-for="(option, index) in options"
      :key="index"
      :value="option.value"
    >
      {{ option.label }}
    </option>
  </select>
  <UserList>
    <template #title="{ count }">
      <ListTitle :count="count" />
    </template>
    <template #userlist="{ list }">
      <CardList :list="list">
        <template #[selected]="{ text }">
          <h2>{{ text }}</h2>
        </template>

      </CardList>
    </template>
  </UserList>
</template>

Now when a user selects the option with the value of "first", the line template #[selected] evaluates to template #first and the first name of the users is rendered on the page.

We can also modify the App.vue to include the remove function:

<template #userlist="{ list, remove }">
      <CardList :list="list">
        <template #[selected]="{ text }">
          <h2>{{ text }}</h2>
        </template>
        <template #secondrow="{ item }">
          <button @click="remove(item)">Remove User</button>
        </template>
      </CardList>
</template>

Using Vue slots effectively allows for highly flexible and reusable components. In this example, we started with a simple UserList.vue component and progressively enhanced it by introducing slots for customization. We saw how named and scoped slots can help control the rendering of dynamic content and pass necessary data between parent and child components.

By structuring components in this way, we achieved:
✅ A customizable title component (ListTitle.vue) that dynamically updates with the number of users.
✅ A flexible CardList.vue component that allows users to choose how to display names using slots.
✅ A dynamic way to modify and interact with the rendered list, including removing users.

This pattern is powerful because it enables component composition without tightly coupling logic and UI. You can reuse and extend these components for various applications, making your Vue.js projects more maintainable and scalable.🚀

Custom Events in the Browser: A Handy Tool You Didn't Know You Needed

Obiwan Pelosi — Mon, 27 Jan 2025 19:16:20 +0000

Up until recently, I had no idea you could create custom events in the browser. Yes, you read that right—you can create and dispatch your own custom events and listen for them in your application.

Why Use Custom Events?

Let me share a use case to explain. I was working on a Chrome extension built with React. The extension consisted of multiple modules, each with its own isolated logic. Some of this logic lived outside React components, in standalone TypeScript files. I needed a way to communicate between these isolated modules and my React app.

While I can't disclose all the details about the extension, imagine you're building a service for car manufacturers, and you're working with Toyota, Ford, and Mercedes. Each manufacturer requires unique handling, so you end up with separate logic files for each. These files aren't React components, so you can't use tools like useState, React context, or global state managers like Reduxor MobX.

Faced with this challenge, I explored various solutions. That's when I discovered custom events.

How Do Custom Events Work?

Custom events allow you to create, dispatch, and listen for events with custom data. Here's the basic syntax:

Adding a Listener

window.addEventListener(type, listener);

type: A case-sensitive string that represents the event's name.
listener: A function that runs when the event is dispatched.

You can also pass an optional options object to addEventListener. Read more about that here

Dispatching an Event

const event = new CustomEvent(eventName, { detail });
window.dispatchEvent(event);

eventName: The name of the custom event (must match the type used in addEventListener)
detail: An object containing additional parameters to be passed to the listener.

The detail object makes custom events incredibly powerful because you can send any data to the event listener.

Real-World Example: Using Custom Events in React

Here’s how I implemented custom events in my Chrome extension:

Set Up the Event Listener I declared the event listener in a useEffectin my App.tsx file:

useEffect(() => {
    const handleCustomEvent = (event: CustomEvent<{ key: string; value: any }>) => {
        console.log(event.detail);
    };

    window.addEventListener(ADD_CUSTOM_EVENT, handleCustomEvent as EventListener);

    return () => {
        window.removeEventListener(ADD_CUSTOM_EVENT, handleCustomEvent as EventListener);
    };
}, []);

ADD_CUSTOM_EVENT: is the event name (declared as a constant to avoid typos).
handleCustomEvent: is the listener function, which logs the event's detail object in this example.

Dispatch the Event From anywhere in your app, you can dispatch the event like this:

const event = new CustomEvent('ADD_CUSTOM_EVENT', { detail: { key: 'exampleKey', value: 'exampleValue' } });
window.dispatchEvent(event);

Why I Love This Approach

With custom events, I was able to easily trigger and handle events across different parts of my app. It provided a simple and elegant solution for cross-module communication without relying on React-specific tools like context or state management libraries.

I hope this helps someone else as much as it helped me. Custom events are a versatile tool for solving complex communication problems in web applications. Until next time—happy coding!

Understanding the Importance of res.ok in Fetch API

Obiwan Pelosi — Tue, 10 Dec 2024 09:06:47 +0000

I've always been an avid user of Axios for data fetching, but I recently decided to use the Fetch API instead. While exploring it, I encountered a subtle but significant difference that I thought was worth sharing.

Let’s start with this snippet of code. What do you think it logs?

try{
   //this returns a 404 error
   const res = await fetch("randomapi....") 
   console.log("successful")
  }catch(err){
   console.log("failed", err)
}

If you guessed it would log "failed" along with the error object to the console, you’re not alone—I thought the same thing until recently. However, that’s not how Fetch works!

Here’s the catch: even if the Fetch request receives a 404 or 500 status code, it doesn’t throw an error and doesn’t trigger the catch block. Instead, the fetch function resolves the promise, leaving it to you to check whether the response was successful.

To correctly handle errors with Fetch, you need to explicitly check the res.ok property, like so:

try{
    //returns 404 error
    const res = await fetch("randomapi")
    if(!res.ok){
      throw new Error("fetch request failed")
    }
    console.log("successful")
    let data = await res.json()
    console.log(data)
}catch(err){
  console.log(err)
}

With this approach, if the response status is outside the successful range (200–299), the throw statement is executed, and the error is caught in the catch block.

Why Does This Happen?

Unlike Axios, Fetch doesn’t consider HTTP response codes outside of the 2xx range to be errors. Instead, it treats all HTTP responses, successful or not, as fulfilled promises. This design choice gives developers more control but also requires extra effort to handle errors correctly.

Understanding response.ok

The response.ok property is a boolean that evaluates to truefor HTTP status codes between 200and 299. For any other status code, it evaluates to false. This makes it an easy and reliable way to check whether your fetch request was successful.

For example:

A 200 status indicates success and will set response.ok to true.
A 404 status (not found) or 500status (server error) will set response.ok to false.

You can also access the status code directly using response.status if you need more granular error handling, like distinguishing between a client-side error (4xx) and a server-side error (5xx).

Thanks for reading and I hope this helps someone out there!

Common Vue.js Development Mistakes and How to Avoid Them: Part 3 ✅

Obiwan Pelosi — Wed, 25 Oct 2023 09:25:47 +0000

Welcome to the third installment of our series on common Vue.js development pitfalls. In this part, we're going to unravel another intriguing challenge – "Watching Arrays."

Demystifying Array Watching in Vue 3

Watching arrays in Vue 3 can sometimes be tricky. Have you ever tried to watch an array, confident that your syntax is spot-on, only to find that the watcher doesn't trigger as expected until you add {deep: true}? If you've experienced this, you're not alone. But rest assured, there's a reason behind this behavior, and it's time to shed some light on it.

Consider the seemingly straightforward code snippet below:

<script setup>
import { ref, watch } from "vue";

const numArr = ref([]);
const addRandom = () => {
  numArr.value.push(Math.random());
};

watch(numArr, () => {
  console.log("random number added");
});
</script>

<template>
  <button @click="addRandom">Add a random number to the array</button>
</template>

You'd expect that when you click the button, a random number should be added to the numArr array, and since we're watching the array, the console should log "random number added," right?

Well, here's where things get interesting: this won't work as expected 😧.

Yes, the random number is added to the array. You would then ask if the array is changing and it is being watched for changes, why the heck isn't it working 🤬🤬??

You can experiment with the code and witness the changes in behavior by using this CodeSandbox playground.

Now let's add the deep: true option to the watcher and see what happens.

<script setup>
import { ref, watch } from "vue";

const numArr = ref([]);
const addRandom = () => {
  numArr.value.push(Math.random());
};

watch(numArr, () => {
  console.log("random number added");
}, 
{deep: true});
</script>

<template>
  <button @click="addRandom">Add a random number to the array</button>
</template>

With this adjustment, you'd notice that the callback is now working as expected. But why does this make a difference? It's a valid question.

The key lies in understanding how Vue.js watches arrays.

When you replace an array entirely, you don't need to use the deepoption. However, in scenarios where you're mutating the array, such as adding or removing items, or modifying existing elements, the deep option is essential.
It ensures that Vue.js watches for changes within the array's elements.

If we were to replace the entire array, we could achieve our goal without the deepoption. Here's an example of how you can modify our code to replace the array in its entirety:

<script setup>
import { ref, watch } from "vue";

const numArr = ref([]);
const addRandom = () => {
  numArr.value = [...numArr, Math.random()]
};

watch(numArr, () => {
  console.log("random number added");
});
</script>

<template>
  <button @click="addRandom">Add a random number to the array</button>
</template>

While this approach is effective, some might find it less intuitive compared to simply using the push method and enabling the deep option. Additionally, what adds an extra layer of complexity is the fact that in Vue 2, you didn't need to use the deep option for this purpose.

However, according to Vue 3 migration guides, this change was introduced as a breaking change. In Vue 3,

"when watching an array, the callback will only trigger when the array is replaced. If you need to trigger on mutation, the deep option must be specified.
"

So there you have it, if you find that your callbacks aren't firing as expected, the first thing to check is whether you've included the deep option in your watcher. This simple addition can make a significant difference in how your Vue 3 application handles array watching.

Common Vue.js Development Mistakes and How to Avoid Them: Part 2 ✅

Obiwan Pelosi — Wed, 18 Oct 2023 18:33:55 +0000

Do you ever find yourself in a situation where you're passing a prop to a component, and then passing that same prop to a child component, and then to a grandchild component? If so, you've encountered a common challenge in Vue.js development known as "prop drilling."

But what exactly is prop drilling, and why is it considered an anti-pattern in Vue.js? The same issue can also arise with event emitting, creating what's known as "event tunneling." Both of these techniques, prop drilling and event tunneling, can make your code less intuitive and harder to maintain.

Prop Drilling in Vue.js:

Prop drilling occurs when you pass a prop through multiple levels of nested components to reach its final destination. While Vue's component-based architecture encourages reusability and modularity, this practice can lead to complexities that make your codebase less elegant and maintainable.

Event Tunneling in Vue.js:

On the other hand, event tunneling happens when you emit an event from a deeply nested child component and then capture and handle that event at a higher-level parent component. This can also result in code that's challenging to follow, as it breaks the clear data flow that Vue.js promotes.

So, how can we avoid these anti-patterns and make our Vue.js code more efficient and easier to maintain?

Solution 1: Use provide and inject in Vue.js

One effective method to combat prop drilling and event tunneling in Vue.js is by leveraging the built-in feature called provide and inject. This powerful duo allows you to provide data at a higher component level and then inject that data deep down the component tree, regardless of how many nested levels you have. Read the docs here

A noteworthy example of this pattern in action is Vue Router. It provides the router and route objects throughout your application by offering them at the App component level and injecting them into each individual component. This approach eliminates the need to accept route or router props in every single component, leading to a cleaner and more maintainable codebase.

By embracing provide and inject, you can ensure that data flows seamlessly through your Vue.js application, reducing the need for excessive prop passing and event emitting. This not only enhances code readability but also simplifies the maintenance of your components, making your development journey smoother and more efficient.

The syntax for using provide and inject in Vue.js is quite straightforward. In the parent component, you call the provide function with two parameters: an identifier (known as the injection key) and the data you want to pass down. Here's a snippet of code illustrating this:

<script setup>
import { ref, provide } from "vue";
import Child from "./Child.vue";

const todos = ref(["Get Lunch", "Play Ball", "Check Todo", "Call John"]);
provide("todoList", todos);
</script>
<template>
  <Child />
</template>

In this example, we're providing a list of todos with the identifier "todoList" using the provide function. This data can now be injected into the Child component, making it accessible there without the need for prop chaining or event emission. This method simplifies the data flow and improves the maintainability of your Vue.js application. Every direct or indirect descendant of this component will have access to this data using the inject function like so:

<script setup>
import { shuffle } from "lodash";
import { inject } from "vue";

const todos = inject("todoList");
const shuffleItems = () => {
  todos.value = shuffle(todos.value);
};
</script>
<template>
  <ul>
    <li v-for="todo in todos" :key="JSON.stringify(todo)">{{ todo }}</li>
  </ul>
  <button @click="shuffleItems">Shuffle Items</button>
</template>

I really believe this is an under-utilized feature in Vue.js and I don't see it often.
You can check out and play around with this concept in this sandbox environment

Solution 2: Use a global state management option

Using Vue's global state management tools is another powerful solution to address the challenges of prop drilling and event tunneling in your Vue.js applications. Instead of maintaining state at a higher-level component and passing it down, global state management enables you to store and manage the state outside of the components themselves. This makes the state accessible in any component within your application, enhancing flexibility and maintainability.

There are several options available for global state management in Vue.js, including:

Composables: Vue 3 introduced Composition API, which includes the use of composable functions to manage and share state across components.
Vuex: Vuex is a popular state management library for Vue.js, designed specifically for managing application-level state and actions.
Pinia: Pinia is a state management solution recommended by the Vue.js core team. It offers a robust and highly efficient way to manage state in Vue applications.

While I won't delve into the specific details of each option here, I encourage you to explore the documentation for these tools to choose the one that best suits your project's needs. Global state management is a powerful strategy that not only mitigates prop drilling and event tunneling but also empowers you to build scalable and maintainable Vue.js applications.

For a more in-depth understanding of each tool, consider referring to their respective documentation (vuex, pinia, composables).

That wraps up this article on common Vue.js pitfalls! Stay tuned for the next part, where we'll delve into yet another common mistake in Vue.js development. See you in the next article, and happy coding! 💻🥳

Common Vue.js Development Mistakes and How to Avoid Them ✅

Obiwan Pelosi — Mon, 16 Oct 2023 10:59:48 +0000

Vue.js, a popular and developer-friendly JavaScript framework, has gained a well-deserved reputation for its ease of use and efficiency. However, as with any technology, there are common pitfalls that developers can stumble upon. In this series of articles, we will explore some of the frequent mistakes that can lead to unforeseen bugs and tricky issues in Vue.js development.

Having worked with Vue.js for a significant amount of time, I’ve personally encountered and wrestled with these issues in numerous projects. Some of them, I didn’t even realize were problems until they caused headaches 😅. Now that I’ve learned from these experiences, I want to share the solutions with you to make your development journey smoother and bug-free.

The goal of this article is to help you understand and avoid these common Vue.js pitfalls, saving you time and frustration in your development process. So, let’s delve into these issues and learn from my mistakes, ensuring that you never make them in the first place.

Common Mistake #1: Omitting the Key Attribute in v-for Iteration

One of the most common pitfalls in Vue.js development is omitting the key attribute when using v-for to iterate over a list of items. Let’s take a look at the code snippet below:

Here, we’re iterating over the **items** array using **v-for**, but Vue.js requires that each iterated element has a unique **key** attribute. This is crucial for Vue to efficiently update the DOM when items are added, removed, or reordered. If you have ESLint properly set up, you’ll receive an immediate warning, indicated by a red underline beneath the v-for line. When you hover over this warning, you'll see a message like "Element in iteration expected to have 'v-bind:key*' directive.*"

In this article, our primary goal is to delve deeper into why omitting the **key** attribute in Vue.js is problematic and help you gain a comprehensive understanding of this issue. To demonstrate the significance of the **key** attribute, let’s begin by binding it to a unique identifier for each item within the **items** array. In this example, we’ll use the **id** field, a common and widely accepted practice when iterating over items from a database.

As you’ll observe, the moment we introduce the **key** attribute, the red warning indicator vanishes. However, let’s take a moment to grasp the significance of this seemingly subtle change. What have we truly achieved by incorporating this unique key into our Vue.js components?

Try it out

When dealing with static data, the absence of the **key** attribute might not be immediately evident. However, as soon as we begin working with elements and components that have their own state, this problem becomes apparent. In our current scenario, we’re dealing with an HTML input element tied to a reactive value.

Now, let’s reintroduce the **key** attribute and give shuffling another try. You’ll observe a stark difference — the labels and inputs are now perfectly synchronized and move in harmony with each other as they are shuffled.

Great, you’ve now experienced firsthand the importance of always including a **key** attribute in your **v-for** loops. While it might seem unnecessary when working with static data or items that don’t maintain state or require reordering, it’s a critical practice to adopt.

Applications have a tendency to evolve and grow, and what might seem inconsequential today could become a source of random and challenging-to-debug errors in the future. Therefore, it’s a best practice to consistently provide the **key** attribute to ensure your Vue.js components can handle state changes and reordering gracefully, even as your application scales and complexity increases. By doing so, you’re proactively guarding against potential issues and ensuring a smoother development journey.

Let’s discuss the significance of choosing the right key value for your **v-for** loops. In some cases, even if you provide a key, you may not fully address the issue.

❗❗ ️Avoid using the index as the key:

One common mistake I frequently encounter is the usage of the index as the key in a **v-for** loop, as demonstrated below:

<ul> <li v-for="(item, index) in items" :key="index">{{ item.label }} <input type="text" /></li> </ul>

If we attempt to shuffle this list, you’ll notice that we encounter the same problem as if we didn’t use a key at all. To compound the issue, most IDEs won’t flag this as an error or provide any red warnings, making it even more challenging to detect the problem. Feel free to try filling in an input and shuffling the list again.

Try it out

The key lesson here is straightforward: ❌ avoid using the index as the key. Instead, you should provide a key that is unique to each specific item, rather than relying on its position in the list, which can change. Typically, this unique key is an ‘id’, but if an ‘id’ is unavailable, you should make the best choice based on the available data. In our example, since all the labels are unique, they could also serve as keys. Additionally, you can pass a combination of ‘ids’ and ‘labels’ or even stringify the entire object, as demonstrated below:

Combination of IDs and Labels ✅:

<li v-for="item in items" :key="item.id + item.label">{{ item.label }} <input type="text" /></li>

Stringifying the Entire Object ✅:

<li v-for="item in items" :key="JSON.stringify(item)">{{ item.label }} <input type="text" /></li>

By choosing a key that is genuinely unique to each item, you ensure that Vue.js can accurately track and update your components, avoiding any unexpected issues in the future.

Conclusion:

In wrapping up, we’ve uncovered the significance of the **key** attribute in Vue.js development and the pivotal role it plays in ensuring smooth and efficient reactivity. By understanding both the “how” and “why” behind adding the **key** attribute, you’re equipped to create robust and bug-free applications.

However, our exploration of common Vue.js pitfalls doesn’t end here. Stay tuned for our next article, where we’ll delve into another prevalent mistake in Vue.js development, providing you with valuable insights to enhance your Vue.js skills. In the meantime, remember to apply the lessons learned here and make your Vue.js projects more reliable and scalable.