DEV Community: Roland Doda

🚀 Vue > React: Why Are We Still Pretending Otherwise?

Roland Doda — Sat, 31 Jan 2026 09:29:00 +0000

Let's be brutally honest: React has been the default choice for too long. It’s the IE of frontend frameworks!! After years of wrestling with dependency arrays, memoization hell, and a fragmented ecosystem, I’m here to tell you it’s time to move on.

The frontend landscape has shifted. While React has been busy adding complexity, Vue has been quietly perfecting the developer experience. In 2026, choosing Vue is the smarter, faster, and more enjoyable path to building incredible web applications. Here is why you should ditch the React hype train and embrace the elegance of Vue.

👉 Reactivity That Just Works (No Ph.D. Required)
Remember the first time you tried to understand useEffect and its dependency array? It feels like solving a riddle where the penalty for a wrong answer is an infinite loop or stale data. React’s "run everything again" model forces you to manually manage performance with useMemo and useCallback, cluttering your code with optimization logic that has nothing to do with your product's features.

Vue's reactivity system is a breath of fresh air. It uses a surgical proxy-based system that automatically tracks dependencies. With the release of Vue 3.6 and its "alien signals" architecture, reactivity is now fine-grained at the leaf level. You change a value, and only the exact part of the DOM that uses it updates. No manual re-render management. You write code that makes sense, and Vue makes it reactive. Period.

👉 Performance: Vue Runs Circles Around React
No need to mention React here, we all know the overhead of a heavy Virtual DOM. 😅

Vue is performant by default. Late 2025 benchmarks show Vue leading in startup time and memory usage, especially on mobile devices. But the real kicker for 2026 is Vapor Mode. By compiling components into super-efficient, DOM-less imperative code, Vue offers the performance of a "no-runtime" framework without losing its signature ease of use. Performance is baked into the core, not something you have to "tune" for weeks.

👉 A Cohesive, Powerhouse Ecosystem
React's ecosystem is a chaotic bazaar of competing tools. Setting up a modern React project often feels like stitching together a Frankenstein's monster of configurations.

Vue is a well-oiled machine. Whether it's the core framework or Nuxt, the synergy of Vite, Vitest, and Nitro creates a first-class development lifecycle. Nitro, the server engine, is a game-changer! It allows your app to run on the Edge (like Cloudflare Workers) out of the box. Everything is designed to work together from day one.

👉 The DX Advantage (And the DevTools King)
Vue just feels easier. Its batteries‑included approach means the framework handles the grunt work. Single‑File Components (SFCs) keep template, styles, and logic together in a way that’s familiar and tidy.

But the real "secret weapon" is Vue & Nuxt DevTools. While React DevTools gives you a basic component tree, Nuxt DevTools is a full command center inside your browser. You can inspect your database, check your SSR payload, analyze bundle sizes, and live-edit state, all without leaving your app. It’s the highest level of developer productivity available today.

👉 Nuxt vs. Next.js: The Meta-Framework Reality
Next.js is powerful, but it’s heavy and increasingly opinionated. Its shift toward Server Components has introduced a layer of mental overhead that many teams find overwhelming.

Nuxt, on the other hand, wins with its "convention over configuration" philosophy. Auto-imported components, simple file-based routing, and a zero-config setup let you focus on your app, not your config. Nuxt is a productivity booster shot that helps you ship full-stack apps faster than any React alternative.

🔥 Strong Take
If you’re starting a project in 2026 and you choose React over Vue + Nuxt, you’re not being pragmatic. Vue + Nuxt is faster, more innovative, and more future-ready. React is the VHS tape of frontend frameworks: still around, but only because people are afraid to move on.

🙈 In Defense of the Giant (The Reality Check)
Look, I’m being a bit of a provocateur here. Is React actually going to disappear in 2026? Of course not. It’s a massive ecosystem with incredible libraries and a job market that remains unrivaled. If you’re maintaining a legacy enterprise app or your entire team consists of React wizards, switching to Vue tomorrow might not be the "pragmatic" choice for your specific context.

But for new projects, for teams that prioritize developer happiness, and for those who want to spend more time building features than fighting the framework, Vue and Nuxt are no longer just "alternatives." They are the leading edge.

The goal isn't to start a framework war but it's to remind ourselves that we don't have to settle for "how it's always been done." The web is evolving, and in 2026, the view is a lot better from over here.

7 Vue3 tips you need to know

Roland Doda — Sat, 17 Sep 2022 16:08:11 +0000

VNode hooks
Debugging hooks
Expose slots from a child component
Scoped styles and multi-root nodes don't work well together
Be careful when using CSS selectors
Boolean casting
Template refs with v-for - order is not guaranteed

VNode hooks

On each component or HTML tags, we can use some special (undocumented) hooks as event listeners. The hooks are:

onVnodeBeforeMount
onVnodeMounted
onVnodeBeforeUpdate
onVnodeUpdated
onVnodeBeforeUnmount
onVnodeUnmounted

I mainly use onVnodeMounted on components when I need to execute some code when the component is mounted or onVnodeUpdated to debug when something is updated but I am quite sure all of them can come in handy in some cases.

Example:



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

    const count = ref(0)

    function onMyComponentMounted() {}

    function divThatDisplaysCountWasUpdated() {}
</script>

<template>
    <MyComponent @vnodeMounted="onMyComponentMounted" />
    <div @vnodeUpdated="divThatDisplaysCountWasUpdated">{{ count }}</div>
</template>

It should be noted, that these hooks pass some arguments to the callback function. They pass only one argument which is the current VNode except for onVnodeBeforeUpdate and onVnodeUpdated that pass two arguments, the current VNode and the previous VNode.

Debugging hooks

We all know the lifecycle hooks that Vue provides us. But did you know that Vue 3 gives us two hooks that we can use for debugging purposes? They are:

onRenderTracked gets called for every reactive dependency that has been tracked.



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

const count = ref(0)
const count2 = ref(0)

// It will be called twice, once for count and once for count2
onRenderTracked((event) => {
    console.log(event)
})
</script>

onRenderTriggered gets called when we trigger a reactivity update, or as the docs say it: "when a reactive dependency triggers the component's render effect to be re-run".



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

const count = ref(0)

// It will be called when we update count
onRenderTriggered((event) => {
    debugger
})
</script>

Expose slots from a child component

If you use a third-party component, chances are that you wrap the implementation of it in your own "wrapper" component. This is a good practice and scalable solution, but in that way, the slots of that third-party component are getting lost and we should find a way to expose them to the parent component:

WrapperComponent.vue



<template>
  <div class="wrapper-of-third-party-component">
    <ThirdPartyComponent v-bind="$attrs">

        <!-- Expose the slots of the third-party component -->
        <template v-for="(_, name) in $slots" #[name]="slotData">
            <slot :name="name" v-bind="slotData || {}"></slot>
        </template>

    </ThirdPartyComponent>
  </div>
</template>

Now every component that uses WrapperComponent can use the slots of ThirdPartyComponent 🎉.

Scoped styles and multi-root nodes don't work well together

In Vue 3 we can finally have more than "one root node" components. That is great, but personally I fall into a design limitation when doing that. Imagine we have a child component:



<template>
  <p class="my-p">First p</p>
  <p class="my-p">Second p</p>
</template>

And a parent component:



<template>
    <h1>My awesome component</h1>
    <MyChildComponent />
</template>

<style scoped>
// There is no way to style the p tags of MyChildComponent
.my-p { color: red; }
:deep(.my-p) { color: red; }
</style>

There is no way from the scoped styling of the multi root parent component to style the child component's p tags.

So in short, a multi-root component, can't target multi-root child component's styles with scoped styles.

The best way to fix that, would be to wrap the parent or child component (or both) so we have only one root element.

But if you absolutely need both to have multi-root nodes, you can:

Use a non-scoped style



<style>
.my-p { color: red; }
</style>

Use CSS Modules



<template>
    <h1>My awesome component</h1>
    <MyChildComponent :class="$style.trick" />
</template>

<style module>
.trick {
    color: red;
}
</style>

Since we are specifying a class here, then the multi-root child component has to explicitly specify the attribute fallthrough behavior.

If you want my opinion, unless you absolutely need a multi-root node component, go with a single root node and don't deal with this design limitation at all.

Be careful when using CSS selectors

#main-nav > li {} will be many times slower compared to .my-li { color: red }. From the docs:

Due to the way browsers render various CSS selectors, p { color: red } will be many times slower when scoped (i.e. when combined with an attribute selector). If you use classes or ids instead, such as in .example { color: red }, then you virtually eliminate that performance hit.

I highly recommend you to read Efficiently Rendering CSS if you want to dive deeper into this topic.

Boolean casting

In Vue 2 or early versions of Vue 3, for props with Boolean types we had different behavior depending on the order:

1st case:



props: {
  hoverColor: [String, Boolean] // <- defaults to ''
}

2nd case:



props: {
  hoverColor: [Boolean, String] // <- defaults to false
}

Not only that, but if you pass the prop like this:



<my-component hover-color></my-component>

In the first case, it would be an empty string ''. In the second case, it would be true.

As you can see, this was a bit confusing and inconsistent. Fortunately, in Vue 3, we have a new behavior that is consistent and predictable:

Boolean behavior will apply regardless of type appearance order.

So:



hoverColor: [String, Boolean] // <- defaults to false
hoverColor: [Boolean, String] // <- defaults to false
hoverColor: [Boolean, Number] // <- defaults to false

Template refs with v-for - Order is not guaranteed

remember this one so you don't lose hours of debugging trying to figure out what is going on

In the code below:



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

const list = ref([1, 2, 3]);
const itemRefs = ref([]);
</script>

<template>
  <ul>
    <li v-for="item in list" ref="itemRefs" :key="item">
      {{ item }}
    </li>
  </ul>
</template>

we are looping over the list array, and we create the itemRefs array.

itemRefs is not guaranteed to have the same order as list array.

If you want to find out more about this, you can read this issue.

Ending the article

I do have more tips and tricks, but this article became long already. Expect another article in the near future with even better tips/tricks.

Thank you all for reading, any feedback is highly appreciated!

Know a cool company hiring Vue.js developers?

Also, I am looking for a new job, so if you know a cool company that is hiring a Senior Vue.js developer, please reach out to rolanddoda2014@gmail.com 🙏.

How to use Composition API the right way

Roland Doda — Tue, 16 Aug 2022 19:24:00 +0000

Intro

In this article we are going to explore why we should use Composition API and how to do it properly.

Why not the old Options API way?

First of all, even though the Options API is not deprecated, reading through the docs you will see that it is discouraged and the new recommended way is Composition API and script setup.

From the docs:

Go with Options API if you are not using build tools, or plan to use Vue primarily in low-complexity scenarios, e.g. progressive enhancement.

Go with Composition API + Single-File Components if you plan to build full applications with Vue.

If you intend to exclusively use Composition API (along with the options listed above), you can shave a few kbs off your production bundle via a compile-time flag that drops Options API related code from Vue

Options API does allow you to "think less" when writing component code, which is why many users love it. However, in reducing the mental overhead, it also locks you into the prescribed code organization pattern with no escape hatch, which can make it difficult to refactor or improve code quality in larger scale projects. In this regard, Composition API provides better long term scalability.

So in short, using Composition API instead of Options API gives you performance benefits, provides better long term scalability and is the recommended way if you plan to build full applications.

Why Composition API is indeed better?

Now that we understood that Composition API is better and is the recommended way to write components, let's try to understand why.

With Options API we could have a code like this:

export default {
    data: () => ({
        count: 0,
        newUser: ''
        newTodo: ''
    }),

    computed: {
        filteredTodos(){ /*...*/ },
        filteredUsers(){ /*...*/ }
    },

    methods: {
        doubleCount(){ /*...*/ },
        addAndClearUser(){ /*...*/ },
        addAndClearTodo(){ /*...*/ }
    }
}

This component deals with 3 logical concerns: count, user, and todo. At a first glance we don't see an issue because the component is very small but if we add more to that component, we will see that the logical concerns are forced to be split under different options, located in different parts of the file.

Now that we know the issue, let's see how we can solve it with the Composition API:

import { ref, computed } from 'vue'

// Count
const count = ref(0)
function doubleCount(){ /*...*/ }

// User
const newUser = ref('')
const filteredUsers = computed(() => { /*...*/ })
function addAndClearUser(){ /*...*/ }

// Todo
const newTodo = ref('')
const filteredTodos = computed(() => { /*...*/ })
function addAndClearTodo(){ /*...*/ }

Notice how the code related to the same logical concern can now be grouped together: we no longer need to jump between different options blocks while working on a specific logical concern.

So now with Composition API we don't have to scroll up and down to find the code related to a specific logical concern.

What's even more exciting is that we can move a group of code into an external file with minimal effort, since we no longer need to shuffle the code around (like with Options API) in order to extract them. So if we were to do that our component would look like this:

import { useCount, useUser, useTodo } from './composables'

const { count, doubleCount } = useCount()
const { newUser, filteredUsers, addAndClearUser } = useUser()
const { newTodo, filteredTodos, addAndClearTodo } = useTodo()

Amazing isn't it? 😎🆒

How to structure logical concerns?

So while the key takeaway from Composition API is that we need to group code related to a specific logical concern together, I have experienced that the code can be hard to read and understand if there is no consistency.

So we need to organize a logical concern in a consistent way.
Personally, I organize the logical concerns as if I were to write it with Options API. So in the following order:

<script setup>
// Props (defineProps)
// Emits (defineEmits)
// Reactive variables (inc composables)
// Computed
// Methods
// Watchers
// Lifecycle Hooks
// Expose (defineExpose)
</script>

Let me know in the comments if you use a different way of organizing a logical concern.

By using this consistent way of organizing logical concerns, the code is easier to read and understand.

Another pattern I have seen, is adding a comment before each logical concern to differentiate between them. Personally, I use this pattern and it has helped me reading the code easier so I highly recommend it.

For example:

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

// Count 👈 this
const count = ref(0)
function doubleCount(){ /*...*/ }

// User 👈 this
const newUser = ref('')
function addAndClearUser(){ /*...*/ }
</script>

Lastly, I always prefer function declaration over const (arrow functions) for functions. That has resulted a good pattern and one reason is that you won't get Uncaught ReferenceError: Cannot access '<variable>' before initialization 😉.

Conclusion

I hope this article helped you to understand why Composition API is a better way to write components and how to use it properly. In the beginning you might not immediately see the benefits, but as your application grows, you will thank yourself for using it.

Composition API has unlocked a lot of possibilities and it enables clean and efficient logic reuse. It's just a matter of time falling in love with it but you have to use it the right way and so far in my experience I have seen many devs using it the wrong way.

Thanks for reading this article and make sure to leave a like and share with your network if you liked it. 🎉

Composition api or Options api?

Roland Doda — Fri, 17 Jun 2022 18:28:17 +0000

Clarification 🧼

I would like to note that this article is not expressing hate or anything towards Vue.js.
I LOVE Vue and I sponsor the development of it 💝.
I just want to share my opinion, and I would love to hear your thoughts as well 👂.

Options API is not Vue 2 🙅

First, I see a lot of people referring to OptA (Options API) as it is Vue 2 and that using it means you also have to use mixins and whatnot. That's not true.
I don't see why we distinguish between OptA (Options API) and CompA (Composition API).
We can write CompA inside OptA, in the setup method:

import { useCounter } from './my-composables'

export default {
  setup() {
    const [count, increment] = useCounter()

    return { count, increment }
  },

  data: () => ({
    username: null
  })
}

In fact, in the Composition API RFC we saw just that. The introduction of a new component option inside OptA called setup.
So Options API is not Vue 2. You can use CompA api using the setup method, which means you can use composables instead of mixins.

Composition api is powerful 💪

The first time I saw CompA I loved it! With it, we have more control about how we define reactivity, we can have reactivity outside of components and sharing code with composables is a great alternative to mixins.

The first time I tried the setup method along with OptA I thought to myself: "What a wonderful world" 🎶.

I replaced my mixins with composables, and I saw that CompA is really powerful and that it unlocks a lot of possibilities.
I could even extract and group code together that have the same logic, and I could even compose them together.
Composables look so clean, and they seem so simple compared to mixins.
Most importantly, you don't have to worry about the drawbacks of mixins.

No one complained about the Options API 🤨

It's crystal clear that CompA is a great addition to Vue 3. With it, you can dig deeper and manually control reactivity:

<script>
import { ref, reactive } from 'vue'

export default {
  setup() {
    const count = ref(0)
    const nonReactive = 'I am not reactive'
    const person = reactive({
      name: 'John'
    })

    return { count, person }
  }
}
</script>

Whereas with OptA reactivity works automatically:

<script>
export default {
  data: () => ({
    count: 0,
    person: {
      name: 'John'
    }
  })
}
</script>

So for me, it was like:

Create components with Options API and in advanced cases use Composition API to better control reactivity.

But no! OptA syntax is no longer recommended by Vue team even though I never heard anyone complaining about it.

Options api for Todo apps? 😲

Vue docs say:

For primarily low-complexity scenarios use OptA.
For full applications, use CompA.

What does this mean? Use options api only for TODO apps? ❓🤔

Even though the setup method was introduced as a new component option, the docs recommend using it only if you have an existing OptA codebase. Because for new apps it's not recommended to use it:

So it's clear! OptA is not recommended and from my experience on reading the docs, it's discouraged.

Be careful! 😨

If you say that you like OptA more, some devs will attack you!
If you say that you don't like script setup syntax, some devs will respond with:

OptA is Legacy! You don't understand coding. You are a junior! Become a better dev just by using CompA.

DX of the Composition API 🐛

Alright, since the Vue team & other devs push us to use CompA, we should drop OptA. Right? R i g h t ??
So let's see some CompA magic seen through my eyes.

Why `ref` and `reactive` ??

reactive has some limitations:

We can't pass a nested property of a reactive variable to a function.
We can't use destructuring.

const state = reactive({ count: 0 })

// the function receives a plain number and
// won't be able to track changes to state.count
callSomeFunction(state.count)

// count is a plain number that is disconnected
// from state.count.
let { count } = state
// does not affect original state
count++

And thus, Vue provides us ref to avoid the limitations of reactive. Vue docs say that by using ref we can avoid the limitations of reactive and gives us the following snippet:

const obj = {
  foo: ref(1),
  bar: ref(2)
}

// the function receives a ref
// it needs to access the value via .value but it
// will retain the reactivity connection
callSomeFunction(obj.foo)

// still reactive
const { foo, bar } = obj

So ref comes as a solution. But does it solve the limitations of reactive ? Why not use the same example we had with reactive but by using ref to have a better comparison ?

// const state = reactive({ count: 0 })
const state = ref({ count: 0 })

// callSomeFunction(state.count)
callSomeFunction(state.value)

// let { count } = state
let { count } = state.value

Hmm, that doesn't work either. So ref has the same limitations.
If you pull out a property of that object you will get a non-reactive property.

ref is a smart trick by providing an object that has a value property. While you use the ref as is you are good. If you mess with .value though, you might end up with the limitations of reactive.

Usage in the template

You might wonder, how to display a ref variable in the template ? Should I access it via .value ?

The answer is no. Vue automatically "unwraps" the ref variable and displays the .value.

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

const count = ref(0)
</script>

<template>
  {{ count }}
  <button @click="count++">Increase counter</button>
</template>

Updating the ref variable in the template can be done without using .value, as you can see from the example above where we directly do count++.

Ref unwrapping

So ref gets unwrapped when we use it in the template.
But not always:

Automatic unwrapping of ref applies only to top-level properties.

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

  const object = { foo: ref(1) }
</script>

<template>
  {{ object.foo }} <!-- does NOT get unwrapped -->
</template>

Automatic unwrapping of ref in reactive objects:

const count = ref(0)
const state = reactive({ count })

console.log(state.count) // no need for .value

No unwrapping in reactive arrays or native collections like Map:

const books = reactive([ref('Vue 3 Guide')])
console.log(books[0].value) // need .value here

const map = reactive(new Map([['count', ref(0)]]))
console.log(map.get('count').value) // need .value here

Ref syncing

Say that we have the 2 following variables:

import { ref, reactive } from 'vue'

const count = ref(0)
const state = reactive({ count })

From the example above, here are some things that maybe don't work as you think they should work.

state.count can be accessed and mutated directly. No state.count.value needed.
If we update count variable then state.count will be updated too 😳.
If we update state.count then count will get updated too 😲.
So state.count and count.value are in sync. If we update one, the other will get updated too. But not always 🤔. If we re-assign to state.count another ref then the count will not be in sync anymore. 🤯

Whaaat 😳? Calm down, let's explain it.

So what happens, is that a ref inside a reactive object is getting unwrapped so no .value is available on the refs inside that object.
But remember that there is no unwrapping happening inside a reactive Array or a native collection type like Map or Set.

How about the sync part ? Why does that happen? And why does it stop only when assigning another ref ?

That's how it works. That can be powerful but with great power comes great responsibility.

A lot to keep in mind right? And we only touched on the ref and reactive APIs. But there is more:

So what? 🤷

So, with Composition API:

We have to decide what to use: ref or reactive? Believe me, there is no answer to that except that "it depends". Personally I mostly use ref.
You have to manually define and make sure you don't lose reactivity. As we learned above, ref and reactive limitations can easily lead to reactivity loss
You have to always keep in mind the limitations and the behaviors of how reactivity works. (unwrapping, syncing, .value, etc.)
Many APIs like toRef, toRefs, unref, isRef, etc.

It's true that CompA is really powerful, but I believe that the points above show us that the DX is not that great compared to OptA.

Conclusion (❁´◡`❁)

CompA is extremely powerful and has a lot of features, but it takes time to learn it and it can become difficult to debug especially if you don't use TypeScript.
Personally, I would say that the Development experience of OptA is much better than CompA for creating components.

You don't have to worry about reactivity loss or what apis to choose for reactivity and be careful with the limitations that come with them, but you focus on the component output.

Generally, I would say that using CompA for creating components has the following disadvantages:

Unorganized/verbose code.

I know that people show simple snippets where script setup looks cleaner, but the truth is that in real-world apps the code doesn't look that clean:

lots of lines of ungrouped code
difficult to visually analyze the code (refs, functions, comments, etc. in one place)
In order to make the code clean, devs usually add empty lines and comments (eg lifecycle hooks, watch etc) which is not ideal
it is not clean and intuitive and makes it hard to search for specific sections (eg where is a specific method)
enforce extraction. When a setup method becomes relatively big, since it has the above downsides, you feel the push to split it into composables. I've experienced that too many composables make it really difficult to debug and follow the flow of the code and also developers don't initially extract everything. Personally, I like building the component first, and then I do refactoring/cleanup code.

My thoughts 💭

In the beginning of using Vue 3, I loved using OptA for creating components and CompA for things like sharing code, stores, etc. I thought that I had to use CompA for creating components only in advanced use cases just like I was using render-functions (only for advanced use cases).

And I believe that if the Vue team would push towards this way of using Vue, things would be much better.
But from what I see, the recommendation is to use script setup and stick with CompA only.
And this is exactly what I did. I switched to using only CompA.

But, sometimes I work on a Vue 2 project for a part-time job and when I use OptA I feel more productive, and I love the facts that I don't have to manually define reactivity and that I can fold/unfold section of the code, and I visually analyze the code better (where is the method, where is the computed, etc.).

Even though now I am confident using CompA, there are still cases where I fall into reactivity loss or forget about reactivity apis behaviors (e.g. unwrapping, syncing, .value, etc.).

Haven't tried script setup with Typescript extensively yet, but I am experimenting with it, and it definitely feels great. I would dare to say that script setup was made to work only with Typescript because without it, development experience is not that great.

Share your thoughts

All in all, CompA is great. OptA was great too.
Even though I loved OptA, I switched to CompA and probably is just a matter of time in order to get convinced that CompA is the way to go "for building full applications".

Or who knows? I might end up using OptA again despite the fact that docs discourage it. 😁

But what do you think? 🤔
Please share your thoughts. Let's discuss!

What do you prefer for creating components? Options or Composition API and why?

Pinia: How to reset stores created with function/setup syntax

Roland Doda — Tue, 19 Apr 2022 08:14:45 +0000

What is Pinia

Pinia is a state management solution for Vue 3.
If you are thinking "Oh, another tool?", the truth is that Pinia can be thought as the next version of Vuex 4. Or as Evan said:

// Detect dark theme var iframe = document.getElementById('tweet-1463429442076745730-849'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1463429442076745730&theme=dark" }

Pinia shares a lot of similarities with Vuex but it's simpler, type safe and extensible!

If you haven't tried it yet, checkout the docs to get started!

Object and Function stores

There are two ways of creating a store with Pinia.

Object syntax:



import { defineStore } from 'pinia'

export const useStore = defineStore('main', {
  state: () => ({
    counter: 0,
  }),
  getters: {
    doubleCount: (state) => state.counter * 2,
  },
  actions: {
    increment() {
      this.counter++
    },
  }
})

Function syntax:



import { ref, computed } from 'vue'
import { defineStore } from 'pinia'

export const useStore = defineStore('main', () => {
  const counter = ref(0)
  const doubleCounter = computed(() => counter.value * 2)

  function increment() {
    counter.value++
  }

  return {
   counter,
   doubleCounter,
   increment
  }
})

The Object syntax looks very similar to Vuex. The Function syntax is similar to a component setup() method where we manually define reactivity.

How to reset the store with Object syntax

When using Object syntax you can simply call the built-in $reset method:



<script setup>
import { useStore } from './useStore'

const store = useStore()

store.$reset // 👈

</script>

However, with Function syntax the built-in $reset method simply throws an error:



🍍: Store "main" is build using the setup syntax and does not implement $reset().

How to reset the store with Function syntax

In order to make $reset method work with Function syntax we are going to create a Pinia plugin: ✨

reset-store.js



import cloneDeep from 'lodash.clonedeep'

export default function resetStore({ store }) {
  const initialState = cloneDeep(store.$state)
  store.$reset = () => store.$patch(cloneDeep(initialState))
}

Here, we deep-copy the initial state of the store with lodash.clonedeep and we add the $reset function which sets the state to its initial value. It's important to deep-copy the state again in order to remove references to the copy itself.

With store.$patch we apply multiple changes at the same time. Read more on the docs.

Then in main.js or wherever you initialize Pinia:



// ...
import { resetStore } from './reset-store'

//...
const pinia = createPinia()
pinia.use(resetStore)

app.use(pinia)

//...

See demo here on Stackblitz or embed:

Learn more about Pinia plugins

Conclusion

Awesome! Now no matter if we use Object or Function syntax, $reset method works! 🥳🥳

I want to thank on of the best Vue devs out there @tony19 for his answer on StackOverflow.

Part 2:Unified SVG icons with Vite, Vue 3, Quasar and Pinia

Roland Doda — Sat, 16 Apr 2022 18:08:38 +0000

Summary

This is the second part of the article. Read the first part here.

In this article, we will:

use built-in component: Suspense
create an interactive playground to play with the SvgIcon component
generate and highlight the code using Highlight.js
add responsive design with CSS Grid & Quasar
add CSS Gradient rounded borders
More usage of Quasar, Pinia and Composition API with script setup

What are we going to build:

Click here to see the app what we are going to build
Play with the code online on Stackblitz (you might have to run vite in the terminal to run the app)
Repo with each lesson in a branch

Create controls and result section

The SvgIcon component is customizable by props:

Wouldn't be awesome to dynamically change the props of the component? Guess what? We are going to do just that! 🕺

Before we start, we need to create 2 simple global components:

AppSelect.vue

<template>
  <q-select dense dark outlined />
</template>

and AppInput.vue

<template>
  <q-input dense dark outlined />
</template>

We just need to put those 2 components inside src/components/global folder and our "auto-registering" we wrote in Part 1 will take care of making them global components 🪄

Now let's create the src/components/ControlsSection.vue component by using Composition API with script setup:

<script setup>
import { useGlobalStore } from '@/stores/global-store'

const globalStore = useGlobalStore()
</script>

<template>
  <div class="controls relative-position q-pa-xl">
    <h4 class="h4 text-indigo-3 text-center">Controls</h4>

    <AppSelect label="Icon" v-model="globalStore.selectedIcon" :options="globalStore.availableIcons" />
    <AppSelect label="Size" v-model="globalStore.selectedSize" :options="globalStore.availableSizes" />
    <AppInput label="Color:" v-model="globalStore.color" hint="default value: var:primary" />

    <section class="section">
      <q-checkbox label="Enable hover color" dark dense v-model="globalStore.hasHoverColor" class="q-mb-sm" />
      <AppInput
        label="Hover color"
        v-model="globalStore.hoverColor"
        :disable="!globalStore.hasHoverColor"
        hint="default value: white"
      />
    </section>
  </div>
</template>

<style lang="scss" scoped>
.controls {
  display: grid;
  align-items: start;
  gap: 16px;
}
</style>

As you can see, we have connected our fields with the global Pinia store.
Now in order for the ControlsSection component to be able to change the props of SvgIcon, we need to bind the global store to its props. Since we used a component for the controls section, let's use a component for the usage of SvgIcon component with props bound to the global store:

src/components/ResultSection.vue:

<script setup>
import { useGlobalStore } from '@/stores/global-store'

const globalStore = useGlobalStore()
</script>

<template>
  <div class="result-area">
    <div class="icon-container">
      <div class="bg"></div>
      <SvgIcon
        :name="globalStore.selectedIcon"
        :color="globalStore.color"
        :hover-color="globalStore.hasHoverColor ? globalStore.hoverColor : false"
        :size="globalStore.selectedSize"
      />
    </div>
  </div>
</template>

<style lang="scss" scoped>
.result-area {
  display: grid;
  gap: 16px;
  flex: 1;

  .icon-container {
    position: relative;
    display: grid;
    place-items: center;
    place-content: center;
    border-radius: 12px;
    padding: 32px;
    box-shadow: 0 0 15px black;

    .bg {
      position: absolute;
      inset: 0;
      border-radius: inherit;
      background: linear-gradient(135deg, rgba(66, 211, 146) 25%, #647eff);
      filter: brightness(0.5);
      opacity: 0.6;
      z-index: -1;
    }
  }
}
</style>

Great! Now when we change the fields in the Controls section, the props of SvgIcon reactively change. 🪄
In order to try it out, let's import and use the components we created in App.vue:

<script setup>
import { useGlobalStore } from '@/stores/global-store'
// Components
import ResultSection from '@/components/ResultSection.vue' // ++
import ControlsSection from '@/components/ControlsSection.vue' // ++

const globalStore = useGlobalStore()
</script>

<template>
  <header>
    <div class="gradient-font q-my-sm">Unified way of using SVG Icons</div>
  </header>

  <main class="">
    <ResultSection /> <!-- ++ -->
    <ControlsSection /> <!-- ++ -->
  </main>
</template>

<style lang="scss">
@import 'css/base';

.main {
  --q-primary: v-bind('globalStore.cssVarColors.primary');
  --q-secondary: v-bind('globalStore.cssVarColors.secondary');
  --q-positive: v-bind('globalStore.cssVarColors.positive');
  --q-negative: v-bind('globalStore.cssVarColors.negative');
  --q-info: v-bind('globalStore.cssVarColors.info');
  --q-warning: v-bind('globalStore.cssVarColors.warning');

  width: 100%;
}
</style>

The app now should look like this:

and be fully functional. Try to change icon, size, color, hover color and see the result.

See the working code here on Github or online on Stackblitz.

Show the generated code

Now that we have the controls section, we can change how the icons looks. Let's show the generated code as well. In order to do that, let's create a computed property in 'global-store.js' before the return statement:

  /* Example Output
      <svg-icon
        name="user
        color="var:primary"
        has-hover-color
      />
  */
  const generatedCode = computed(() => {
    let code = '<svg-icon'
    code += `\n name="${selectedIcon.value}"`

    if (selectedSize.value !== 'xl') {
      code += `\n size="${selectedSize.value}"`
    }

    if (color.value) {
      code += `\n color="${color.value}"`
    }

    if (hasHoverColor.value) {
      if (!hoverColor.value) {
        code += `\n hover-color`
      } else {
        code += `\n hover-color="${hoverColor.value}"`
      }
    }

    code += `\n/>`

    return code
  })

And return it together with the other properties:

  return {
    // ...
    generatedCode
}

Now that we have the code, we can use Highlight.js to show it highlighted:

<script setup>
import { useGlobalStore } from '@/stores/global-store'
</script>

<template>
  <highlightjs language="html" :code="globalStore.generatedCode" />
</template>

Here is the full code:
src/components/CodeSnippet.vue:

<script setup>
// eslint-disable-next-line no-unused-vars
import hljs from 'highlight.js/lib/common'
import hljsVuePlugin from '@highlightjs/vue-plugin'
import { useGlobalStore } from '@/stores/global-store'

const highlightjs = hljsVuePlugin.component
const globalStore = useGlobalStore()
</script>

<template>
  <div class="container">
    <div class="code-snippet">
      <div class="shadow">
        <div class="shadow-background"></div>
      </div>

      <div class="highlightjs-container">
        <div class="snippet-header">
          <div v-for="i in 3" :key="i" class="circle"></div>
        </div>

        <highlightjs language="html" :code="globalStore.generatedCode" class="overflow-auto hide-scrollbar" />
      </div>
    </div>
  </div>
</template>

<style lang="scss" scoped>
// Stolen design from https://ray.so
.container {
  padding: 24px 16px;
  display: grid;
  place-items: center;
  border-radius: 12px;
  background: linear-gradient(140deg, rgb(207, 47, 152), rgb(106, 61, 236));
}

.code-snippet {
  position: relative;
  border-radius: 12px;
  min-width: 250px;
  width: 100%;
  font-size: clamp(1.1rem, 9vw - 2rem, 1.7rem);

  .shadow,
  .shadow-background {
    position: absolute;
    top: 0;
    left: 0;
    border-radius: 12px;
    height: 100%;
    width: 100%;
  }

  .shadow:after {
    position: absolute;
    content: '';
    left: 0;
    top: 24px;
    width: 100%;
    height: 100%;
    border-radius: 12px;
    background-color: rgba(0, 0, 0, 0.6);
    transform: translateZ(-1px);
    filter: blur(30px);
    z-index: -1;
  }

  .shadow-background {
    background: linear-gradient(140deg, rgb(207, 47, 152), rgb(106, 61, 236));
  }

  .highlightjs-container {
    position: relative;
    height: 100%;
    width: 100%;
    background-color: rgba(0, 0, 0, 0.75);
    border-radius: 12px;
    padding: 16px;
    transform-style: preserve-3d;
  }
}

.snippet-header {
  display: grid;
  grid-auto-flow: column;
  justify-content: start;
  gap: 8px;
  margin-bottom: 16px;

  .circle {
    width: 12px;
    height: 12px;
    border-radius: 6px;
    background-color: #fff3;
  }
}
</style>

<style lang="scss">
.hljs-tag {
  color: #6599ff;
  .hljs-name {
    color: #6599ff;
  }
}
.hljs-attr {
  color: #f8518d;
}
.hljs-string {
  color: #e9aefe;
}
</style>

Awesome! Now we only have to install highlight.js and the vue plugin:

npm install highlight.js
npm install @highlightjs/vue-plugin

Finally, we can import the CodeSnippet component in App.vue and see our code dynamically generated.

See the working code here on Github or online on Stackblitz.

CSS Variables section && responsive design

We use css variables to define the color of the icon and the hover color of it. But wouldn't be nice if we could change the css variable colors?

Since we already have cssVarColors in globalStore.js as a reactive property that's really easy to implement. We can simply create a component where we loop over the properties of cssVarColors and bind each property to an input "type='color'" field.

Since we use Quasar, out input can be beautiful with a built-in color picker. Let's see the code:

src/components/VariablesSection.vue

<script setup>
import { useGlobalStore } from '@/stores/global-store'

const globalStore = useGlobalStore()
</script>

<template>
  <div class="css-vars-area relative-position q-pa-xl">
    <h4 class="h4 text-indigo-3 text-center q-mb-md">CSS Variables</h4>

    <q-input
      v-for="(colorValue, colorKey) in globalStore.cssVarColors"
      v-model="globalStore.cssVarColors[colorKey]"
      :key="colorKey"
      filled
      dark
      dense
      class="my-input q-mb-sm"
    >
      <template #prepend>
        <q-icon name="circle" :color="colorKey"></q-icon>
        <small> {{ colorKey }}:</small>
      </template>
      <template #append>
        <q-icon name="colorize" class="cursor-pointer">
          <q-popup-proxy cover transition-show="scale" transition-hide="scale">
            <q-color dark v-model="globalStore.cssVarColors[colorKey]" />
          </q-popup-proxy>
        </q-icon>
      </template>
    </q-input>
  </div>
</template>

Great! Now we have to import that component and use it in App.vue. But alongside that let's add responsive design by using CSS Grid and some help from Quasar:

App.vue:

<script setup>
import { useGlobalStore } from '@/stores/global-store'
// Components
import ControlsSection from '@/components/ControlsSection.vue'
import CodeSnippet from '@/components/CodeSnippet.vue'
import ResultSection from '@/components/ResultSection.vue'
import VariablesSection from '@/components/VariablesSection.vue'

const globalStore = useGlobalStore()
</script>

<template>
  <header>
    <div class="gradient-font q-my-sm">Unified way of using SVG Icons</div>
  </header>

  <main class="main" :class="`screen-${$q.screen.name}`">
    <ResultSection class="result-section" style="grid-area: result" />
    <CodeSnippet class="code-snippet" style="grid-area: code" />
    <ControlsSection class="controls-section" style="grid-area: controls" />
    <VariablesSection class="variables-section" style="grid-area: variables" />
  </main>
</template>

<style lang="scss">
@import 'css/base';

.main {
  --q-primary: v-bind('globalStore.cssVarColors.primary');
  --q-secondary: v-bind('globalStore.cssVarColors.secondary');
  --q-positive: v-bind('globalStore.cssVarColors.positive');
  --q-negative: v-bind('globalStore.cssVarColors.negative');
  --q-info: v-bind('globalStore.cssVarColors.info');
  --q-warning: v-bind('globalStore.cssVarColors.warning');

  width: 100%;
  display: grid;
  grid-template-areas:
    'code'
    'result'
    'controls'
    'variables';
  gap: 12px;

  &.screen-xs,
  &.screen-sm {
    .code-snippet {
      padding: 0 4px;
    }
  }

  &.screen-md {
    display: grid;
    grid-template-columns: auto 1fr auto;
    grid-template-areas:
      'result code'
      'controls variables';
  }

  &.screen-lg,
  &.screen-xl {
    display: grid;
    grid-template-columns: 1fr minmax(500px, 1fr) 1fr;
    grid-template-areas:
      'controls code variables'
      'controls result variables';
  }
}
</style>

$q.screen plugin is used to detect screen size (sm, md, lg or xl). We use it to add classes to the main element, and we use CSS grid with grid-template-columns and grid-template-areas to make the grid responsive.

Simple, right?

See the working code here on Github or online on Stackblitz.

Suspense and gradient borders

Resize the window of your browser to see the mobile version of the playground.
You will see that the app is responsive. In the mobile view try to change the icon and see the result area change. You will notice that the content is "jumping" when we change the icon.

In order to fix that, we will use Suspense and show the icon only when it's loaded.
To do that, open SvgIcon.vue and change the html code to this:

  <Suspense>
    <component
      :is="dynamicComponent"
      class="svg-icon"
      :width="svgSize"
      :height="svgSize"
      :stroke-width="strokeWidth"
      :class="{ 'add-hover': !!hoverColorBind }"
    />

    <template #fallback> <q-spinner :size="svgSize" /> </template>
  </Suspense>

So we have wrapped the component with Suspense. We also have a fallback component, which is a spinner, and it will be shown when the icon is loading.

Awesome! 😎😎😎

Now the last things we need to do, is to add gradient borders to the "Controls" and "CSS Variables" sections.
First, go to src/css/base.css and add the following class:

.gradient-border {
  border-radius: 12px;
  box-shadow: 0 0 5px;
  padding: 32px;

  &::before {
    content: '';
    position: absolute;
    inset: 0;
    border-radius: inherit;
    padding: 3px;
    background: linear-gradient(
                    45deg,
                    var(--q-secondary),
                    var(--q-positive),
                    var(--q-negative),
                    var(--q-info),
                    var(--q-warning)
    );
    -webkit-mask: linear-gradient(#fff 0 0) content-box, linear-gradient(#fff 0 0);
    -webkit-mask-composite: xor;
    mask-composite: exclude;
  }
}

Now to the root element in ControlsSection.vue and VariablesSection.vue add the class gradient-border.

And that's it! 🥳🥳 Now we have gradient borders and the app should look like this:

See the working code here on Github or online on Stackblitz.

If you liked this article, you can show your support by buying me a coffee. It would motivate me a lot.

Thanks for reading, I hope you enjoyed it!

Part 1:Unified SVG icons with Vite, Vue 3, Quasar and Pinia

Roland Doda — Mon, 14 Feb 2022 20:17:01 +0000

Summary

In this article, we will:

use custom SVG icons
build a flexible and customizable reusable component to use SVG icons
use Vite, Vue 3, Quasar and Pinia
use both Composition API with script setup and Options API with Vue 3
auto-register global components using import.meta.glob and import.meta.globEager
link CSS values to dynamic component state using v-bind CSS function

Wait😲! All of these in an article ?

YES! Let's do it! 🤹‍♂️

What are we going to build:

Click here to see the app what we are going to build
Play with the code online on Stackblitz (you might have to run vite in the terminal to run the app)
Repo with each lesson in a branch

Requirements

Let's add a designer into the game who defines how we should build that component.

Our designer 👨‍🎨/👩‍🎨 is tired of using icon sets and has decided that the app needs its own unique SVG icons. Here are the specifications he/she gave us:

Most icons fall in 16, 24, 32, 48 sizes. However, a few icons, some special ones, have different sizes. The most used size is 48px.
SVG icons are scalable and their strokes too, but our smart designer wants to manually control the stroke width in different sizes:
- 16px and 24px: 1px stroke width
- 32px: 2px stroke width
- 48px: 2.5px stroke width
All icons have outlined style.
All icons should have a default color which is called 'primary' and a default hover color white, however, it must be easy to overwrite those defaults.
The app has colors defined in CSS variables, but it should be possible to set the color with a color value (hex, rgb etc)

Here are the CSS Variables colors:

  --primary: #007bff;
  --secondary: #6c757d;
  --positive: #28a745;
  --negative: #dc3545;
  --info: #17a2b8;
  --warning: #ffc107;

Alright! As you can see, we need a flexible and customizable reusable component. 🏯

Let's start coding! ⌨️🔥

We could start by creating a new Vite + Vue 3 project which you can do by running npm init vue@latest in the terminal, but to speed things up, I have already done that, cleaned up the project and added some SVG icons.

So, clone or download the repo or play directly with the code online on Stackblitz.

As you can see, we have a clean Vite + Vue 3 app and some SVG icons in src/components/icons folder.
The next step, is to install Quasar and Pinia. Before doing so, I loved how in Vue 2 we could keep main.js file clean and simple, so we are going to do exactly that!

First, let's create a plugins folder (src/plugins) and inside a main-app.js file:

import { createApp } from 'vue'
import App from '../App.vue'

export const app = createApp(App)

Then, our main.js should look like this:

import { app } from './plugins/main-app'

app.mount('#app')

Clean and simple right?

Install Quasar and Pinia

First run the command:

npm install quasar @quasar/extras pinia

In order to make Quasar work in Vite, we need to install the appropriate plugin:

 npm install -D @quasar/vite-plugin

Now that we installed them, let's register them in the plugins folder:

pinia.js

import { app } from './main-app'
import { createPinia } from 'pinia'

app.use(createPinia())

quasar.js

import { Quasar } from 'quasar'
import { app } from './main-app'

// Import icon libraries
import '@quasar/extras/material-icons/material-icons.css'
// Import Quasar css
import 'quasar/src/css/index.sass'

app.use(Quasar, {
  plugins: {} // import Quasar plugins and add here
})

Finally, let's import the Quasar and Pinia plugins in the main.js file:

import { app } from './plugins/main-app'
import './plugins/quasar' // +
import './plugins/pinia' // +

app.mount('#app')

If something doesn't work on your end, see the working code here on Github or online on Stackblitz

Create reusable component for SVG icons

Now, we need to create a reusable component for SVG icons. Let's do it. 👷

We will call it SvgIcon and make it a global component so we can use it everywhere without importing it.

Let's create a SvgIcon.vue and a contants.js in src/components/global/svg-icon folder. Inside components/global we will keep all of our global components

Remember our requirements?

our common icon sizes are 16, 24, 32 and 48. So we will call them sm, md, lg, xl respectively.
Default one is 48, so that means xl.
16 and 24 have 1px stroke width, 32 has 2px, 48 has 2.5px.
Default color is primary, and default hover color is white.

Let's define those in contants.js file:

export const sizes = {
  sm: {
    size: 16,
    strokeWidth: 1
  },
  md: {
    size: 24,
    strokeWidth: 1
  },
  lg: {
    size: 32,
    strokeWidth: 2
  },
  xl: {
    size: 48,
    strokeWidth: 2.5
  }
}
export const defaults = {
  color: 'var:primary',
  varPrefix: 'q-',
  hoverColor: 'white',
  size: 'xl'
}

Quasar variables are prefixed with q- by default. e.g. --q-primary.
In order to account for that we define a varPrefix property in defaults object.

var:primary: color and hoverColor can either be a color value e.g. yellow or a variable e.g. var:primary. var:primary targets the --q-primary variable.

Next, let's write some code in SvgIcon.vue file. We will use Options API 😎:

<script>
import { defineAsyncComponent } from 'vue'
import { sizes, defaults } from './constants'

export default {
  props: {
    name: {
      type: String,
      required: true
    },

    color: {
      type: String,
      default: defaults.color
    },

    size: {
      type: String,
      default: defaults.size,
      validator: (val) => Object.keys(sizes).includes(val)
    },

    hoverColor: [Boolean, String]
  },

  computed: {
    dynamicComponent() {
      const name = this.name.charAt(0).toUpperCase() + this.name.slice(1) + 'Icon'

      return defineAsyncComponent(() => import(`../../icons/${name}.vue`))
    },

    colorBind() {
      const color = this.color ? this.color : defaults.color

      return this.getVarOrColorValue(color)
    },

    hoverColorBind() {
      if (this.hoverColor === false) return

      if (this.hoverColor === true || !this.hoverColor) return defaults.hoverColor
      return this.getVarOrColorValue(this.hoverColor)
    },

    svgSize() {
      return sizes[this.size].size
    },

    strokeWidth() {
      return sizes[this.size].strokeWidth
    }
  },

  methods: {
    getVarOrColorValue(str) {
      return str.startsWith('var:') ? str.replace(/^var:/, `var(--${defaults.varPrefix}`) + ')' : str
    }
  }
}
</script>

I think the component's code is straightforward, but here is some explanations:

dynamicComponent: Based on the name prop, we import the corresponding icon component.
colorBind: if color prop is falsy use defaults.color, otherwise use color. Call getVarOrColorValue to return the color or the variable.
hoverColorBind: if hoverColor prop is false no hover is enabled. If it's falsy(e.g. undefined) we will use defaults.hoverColor. Call getVarOrColorValue to return the color or the variable.
getVarOrColorValue: if str is a color value it returns it as is. Otherwise, if it starts with var: then it returns the CSS variable. e.g. str === var:primary will return var(--q-primary) taking into account defaults.varPrefix.

Next, let's add the <template> and <style> tags:

<template>
  <component
    :is="dynamicComponent"
    class="svg-icon"
    :width="svgSize"
    :height="svgSize"
    :stroke-width="strokeWidth"
    :class="{ 'add-hover': !!hoverColorBind }"
  />
</template>

<style lang="scss" scoped>
.svg-icon {
  color: v-bind(colorBind);
  transition: color 0.2s ease-in-out;

  &.add-hover:hover {
    color: v-bind(hoverColorBind);
  }
}
</style>

Not much to explain about the template but in the style we use v-bind to link colorBind and hoverColorBind computed properties to the CSS color property. Whenever these computed properties change, the color property will be updated. In fact, the actual value will be compiled into a hashed CSS variable. Learn more in the docs.

Greatness! Here are some simple examples of using the component we just created:

<svg-icon name="home" />

<svg-icon name="home" size="sm" color="var:primary" hoverColor />

<svg-icon name="home" size="sm" color="var:primary" hoverColor="blue" />

<svg-icon name="home" size="sm" color="blue" hoverColor="var:primary" />

See the working code here on Github or online on Stackblitz.

Auto-register components

We haven't made our SvgIcon.vue component global yet, so let's register all components in the components/global folder.
In Vite, we can do this by using Glob import.

First create plugins/global-components.js file:

`import.meta.glob`

By using import.meta.glob, matched files are lazy loaded via dynamic import and will be split into separate chunks during build:

import { defineAsyncComponent } from 'vue'
import { app } from './main-app'

const globalComponentsPaths = import.meta.glob('/src/components/global/**/*.vue')

Object.entries(globalComponentsPaths).forEach(([path, module]) => {
  // "./components/SvgIcon.vue" -> "SvgIcon"
  const componentName = path
    .split('/')
    .pop()
    .replace(/\.vue$/, '')

  app.component(componentName, defineAsyncComponent(module))
})

`import.meta.globEager`

If you want to load all matched files eagerly, you can use import.meta.globEager:

import { app } from './main-app'

const globalComponentsPaths = import.meta.globEager('/src/components/global/**/*.vue')

Object.entries(globalComponentsPaths).forEach(([path, module]) => {
  // "./components/SvgIcon.vue" -> "SvgIcon"
  const componentName = path
    .split('/')
    .pop()
    .replace(/\.vue$/, '')

  app.component(componentName, module.default)
})

In our case, we don't want separate chunks since we will only have a single page, so we will use import.meta.globEager. This will load all components eagerly and will be included in the main bundle.

The last step is to import the global-components.js file in main.js:

import { app } from './plugins/main-app'
import './plugins/quasar'
import './plugins/pinia'
import './plugins/global-components' // +

app.mount('#app')

Now we can use the <svg-icon> component everywhere in our app without the need to import it.
Now it's time to start building our interactive playground. 🔥🔥

See the working code here on Github or online on Stackblitz.

Create and use Pinia store 🏪

The first step on building the interactive playground, is to create a global store so all our components can interact with it.
So let' go and create a global-store.js file in src/stores folder:

import { reactive, ref } from 'vue'
import { defineStore } from 'pinia'

export const useGlobalStore = defineStore('global-store', () => {
  const availableIcons = ['user', 'search', 'home']
  const selectedIcon = ref(availableIcons[0])

  const color = ref()

  const hasHoverColor = ref(false)
  const hoverColor = ref()

  const availableSizes = ['sm', 'md', 'lg', 'xl']
  const selectedSize = ref(availableSizes[3])

  const cssVarColors = reactive({
    primary: '#007bff',
    secondary: '#6c757d',
    positive: '#28a745',
    negative: '#dc3545',
    info: '#17a2b8',
    warning: '#ffc107'
  })

  return {
    availableIcons,
    selectedIcon,
    color,
    hasHoverColor,
    hoverColor,
    availableSizes,
    selectedSize,
    cssVarColors
  }
})

Great! We have created a Pinia store 🍍! That was simple right?

Now, let's use this store in App.vue to bind cssVarColors to Quasar CSS variables. We will use Composition API with script setup for App.vue and finally use SvgIcon.vue component:

<script setup>
import { useGlobalStore } from '@/stores/global-store'

const globalStore = useGlobalStore()
</script>

<template>
  <header>
    <div class="gradient-font q-my-sm">Unified way of using SVG Icons</div>
  </header>

  <main class="">
    <svg-icon name="user" />
  </main>
</template>

<style lang="scss">
@import 'css/base';

.main {
  --q-primary: v-bind('globalStore.cssVarColors.primary');
  --q-secondary: v-bind('globalStore.cssVarColors.secondary');
  --q-positive: v-bind('globalStore.cssVarColors.positive');
  --q-negative: v-bind('globalStore.cssVarColors.negative');
  --q-info: v-bind('globalStore.cssVarColors.info');
  --q-warning: v-bind('globalStore.cssVarColors.warning');

  width: 100%;
}
</style>

See the working code here on Github or online on Stackblitz.

Next steps

The article became a bit long, so let's build the interactive playground in the next article where we will:

Use built-in component: Suspense
create an interactive playground to play with the SvgIcon component
highlight and generate the code using Highlight.js
add responsive design with CSS Grid & Quasar
add CSS Gradient rounded borders
More usage of Quasar, Pinia and Composition API with script setup

If you liked this article, you can show your support by buying me a coffee. It would motivate me a lot.

Thanks for reading, I hope you enjoyed it!

About me

My name is Roland Doda (Feel free to connect with me on Linkedin or follow me on Github, Dev.to, Hashnode or Twitter) and I work as a Senior Frontend Developer at CPI technologies.
We are also hiring btw! Check out CPI Career Center and also VueJS Frontend Developer job description.

Deploy to Github Pages like a pro with Github Actions

Roland Doda — Sun, 15 Mar 2020 09:12:10 +0000

GitHub Pages is a static site hosting service designed to host your personal, organization, or project pages directly from a GitHub repository.

Note that GitHub Pages is a static site hosting service and doesn’t support server-side code such as, PHP, Ruby, or Python.

To learn more about the different types of GitHub Pages sites, take a look here.

🤨 That’s the theory! Let’s start: 🤨

Copy the name of your project.

The name of my repo is deploy-react-to-gh-pages.

For React specify the `homepage` in `package.json` (Docs).

{
  ...
  "homepage": "/name-of-your-project/",
  ...
}

For Vue create a new file in your project root named `vue.config.js` (Docs) and specify the `publicPath` (Docs).

module.exports = {
  publicPath: '/name-of-your-project/'
}

Now commit and push your changes.

Note: if you don't commit your changes, you will lose them in the next command, so make sure you don't skip this step

Open your terminal in your project and run:

Note: For the following commands, if you are using vue, just copy paste them, if you are using react replace dist with build.
npm run build creates a directory with a production build of your app. In vue, that directory in named dist, in react is named build.

git checkout --orphan gh-pages Docs
npm run build
git --work-tree dist add --all Docs (for react: replace dist with build)
git --work-tree dist commit -m 'Deploy' (for react: replace dist with build)
git push origin HEAD:gh-pages --force
rm -r dist (for react: replace dist with build)
git checkout -f master
git branch -D gh-pages
Navigate to your github project and click 'Settings'
Scroll to find the section 'Github Pages' , select the gh-pages branch and click 'Save'

🚀🚀 Congrats 🚀🚀

Your site is ready to be published.
You might have to wait a bit. Generally it takes 2–10 minutes until this process is done.

🤔🤔But... wait. You probably want to re-deploy. There must be a simpler solution instead of re-doing over and over again all the commands above.

Create a node.js script

Now, we are gonna create a node.js script so whenever we want to deploy, we just run one command.

Create a scripts folder in your project root.
Inside scripts folder, create a gh-pages-deploy.js file.
Copy and paste the code below:

  const execa = require("execa");
  const fs = require("fs");

  (async () => {
    try {
      await execa("git", ["checkout", "--orphan", "gh-pages"]);
      console.log("Building...");
      await execa("npm", ["run", "build"]);
      // Understand if it's dist or build folder
      const folderName = fs.existsSync("dist") ? "dist" : "build";
      await execa("git", ["--work-tree", folderName, "add", "--all"]);
      await execa("git", ["--work-tree", folderName, "commit", "-m", "gh-pages"]);
      console.log("Pushing to gh-pages...");
      await execa("git", ["push", "origin", "HEAD:gh-pages", "--force"]);
      await execa("rm", ["-r", folderName]);
      await execa("git", ["checkout", "-f", "master"]);
      await execa("git", ["branch", "-D", "gh-pages"]);
      console.log("Successfully deployed");
    } catch (e) {
      console.log(e.message);
      process.exit(1);
    }
  })();

Open package.json and add execa (Docs) to your devDependencies.

    "devDependencies": {
      ...
      "execa": "latest"
    },

Also add a new script in scripts section:

    "scripts": {
     ...
     "gh-pages-deploy": "node scripts/gh-pages-deploy.js"
    },

Finally, run npm install.

✨🎉 And... that's it! 🎉✨

You can now deploy as many times as you want by just running npm run gh-pages-deploy.

Me- But, hey... 🤫🤫! Wouldn't be even more exciting if we automate everything ?

Everyone- Do you mean that the app will be deployed itself ? 🤨🤨

Me- 😉😉

Everyone- 😲😲

Github Pages- 🤭🤭

Create a github action to automate deployment

Wouldn't be great if on every push on master, the app gets deployed without us doing nothing ?? 🧙‍♂️🧙‍♂️

We can achieve that by using... 🙌🙌 Github Actions 🙌🙌.

GitHub Actions enables you to create custom software development life cycle (SDLC) workflows directly in your GitHub repository. Docs

Let's start:

Create a .github (Don't forget the dot in front) folder in your project root
Inside create another folder named workflows
Inside workflows create a file named gh-pages-deploy.yml (The name is up to you).
Now copy & paste the code below inside that file.

  name: Deploy to github pages
  on:
    push:
      branches:
        - master
  jobs:
    gh-pages-deploy:
      name: Deploying to gh-pages
      runs-on: ubuntu-latest
      steps:
        - name: Setup Node.js for use with actions
          uses: actions/setup-node@v2
          with:
            version:  12.x
        - name: Checkout branch
          uses: actions/checkout@v2

        - name: Clean install dependencies
          run: npm ci

        - name: Run deploy script
          run: |
            git config user.name "Your username" && git config user.email "your email"
            npm run gh-pages-deploy

Important: Make sure to change your username and email:

Commit and push your changes
Now, navigate to your github project and first click Actions (1) then Deploy to github pages (2) and last click on the action (3).

If everything goes well, you will see this:

🌟🌟 Taadaaa!!! You successfully automated deployment!!! 🌟🌟

Now, whenever you merge a PR or push to master this action will run and will deploy your app automatically. 👏👏

Things to know

React & Vue provide their own steps to deploy on github pages:
- For React, See the steps Here.
- For Vue, see the steps Here.
- Also Read the steps to create a github action
Great libraries to use for deploying to gh-pages:
- gh-pages
- push-dir
It's definitely a good thing to know how to manually deploy to gh-pages. Also, the script is very minimal and easy to understand. This simplicity gives you the power to modify it. (add colors, emojis, promts). So here are some great resources to enrich the script:
- inquirer
- ora
- chalk
- node-emoji
Repositories (feel free to checkout the commits):
- deploy-vue-to-gh-pages
- deploy-react-to-gh-pages

🙏🙏 Thank you for reading. I would be glad to help you if you face any problem, so don't hesitate to email me at rolanddoda2014@gmail.com 🙏🙏

8 secrets Vue Developers must know

Roland Doda — Sat, 13 Jul 2019 19:17:25 +0000

Inline statement handler: Handle multiple arguments
Emit event from functional components
Pass all props to the child component
Watch child properties changes from parent
Listening for child event in the router-view
Vue components lifecycle hooks don't run in the order you think they run
How to know if a child component is mounted
How to know if a dynamically vuex registered module is registered

Inline statement handler: Handle multiple arguments

Short Explanation:

In an inline statement handler besides the $event special variable we have access to another special variable: arguments. $event will have access only to the first argument, whilst the arguments will have access to all arguments.

Detailed Explanation:

In an inline statement handler we already know that we have access to the special $event variable.

So if a child components emits an event with a parameter, we have access to it by using $event:

Parent component

<template>
  // ...
   <Child @event="someVariable = $event" />
  // ...
</template>

Child component

export default {
  //...
    emitEvent () {
      this.$emit('event', 'a simple text')
    }
  //...
}

That works really well when the child component, is a component that we have access to, since we can be sure we pass only one parameter.

But how if we use a third-party component/library (e.g. dropzone.js) which passes many arguments up via event ??

The $event will have access only to the first argument. See this codesandbox example which illustrates that $event will catch only the first argument. (Click the button and see the console)

In that case, instead of $event we can use arguments and all arguments will be accessible.

So in the codesandbox above, in order to make it work, we have to change the line 4 in the Child.vue

from:

<GrandChild @event="$emit('event', $event)"/>

to:

 <GrandChild @event="$emit('event', arguments)"/>

Emit event from functional components

Short Explanation:

Using functional components, means that we don't have access to this context. Thus, we cannot do this.$emit(). But... we have access to listeners so we can do <button @click="listeners.clicked"></button>

Detailed Explanation:

Functional components are stateless (no reactive data) and instanceless (no this context). But functional components have access to some properties such as props, children etc and most importantly (for this case), listeners.

According to Vue docs:
listeners: An object containing parent-registered event listeners. This is an alias to data.on

That means that we can emit event from functional components. Wiii :P

Simple example:

<template functional>
  <button @click="listeners['custom-event']('message from child')">
    Button from child
  </button>
</template>

Working example (click the button and open the console)

How if we want to emit an event from functional component with render functions? Can we do that? Of course!

Simple example:

export default {
  functional: true,
  render(createElement, { listeners }) {
    return createElement(
      "button",
      {
        on: {
          click: event => {
            const emit_event = listeners.event_from_child;
            emit_event("Hello World!Is this the message we excpected? :/");
          }
        }
      },
      "Pass event to parent"
    );
  }
};

Working example

Someone may wonder if we can use .sync Modifier using this approach.
The answer ? Of course!

<button @click="listeners['update:message']('some text')">Click me</button>

Pass all props to the child component

Say that we have a component which receives props and we want to pass all those props to a child component. To achieve that, we can do:

  <ChildComponent v-bind="$props" />

Taking advantage of v-bind we can also have an object like:

data: () =>({
  obj: {
    firstName: 'John',
    lastName: 'Doe',
    age: 30
  }
})

And pass firstName, lastName, age as props to a child component, like:

<Child v-bind="obj" />

Watch child properties changes from parent

You may wonder why to do that and you are right! That's a bad practice. But sometimes you use a third-party component and you want to watch their properties to fit your needs.

A long time ago, in a project we were using a date picker and we wanted to be able to detect when the popup was visible. Unfortunately there was no option to do that.I discovered that the date picker was using a popupVisible reactive property but it wasn't exposed by the library. So I had to somehow watch this property from my component.

The below code is NOT able to detect changes:

  watch: {
    '$refs.datePicker.popupVisible': {
      handler (new_value) {
        console.log('value changed')
      },
      deep: true
    }
  }

In order to detect changes of a child component's property you should do:

  mounted() {
    this.$watch(
      "$refs.picker.popupVisible",
      (new_value, old_value) => {
         //execute your code here
      }
    );
  }

Working example:

Learn more about vm.$watch

Listening for child event in the router view

Most of you, should already know that since it is straightforward, but I've been asked many times about the question below.

Say you have a component which has nested routes:

<template>
  //...
  <router-view></router-view>
  //...
</template>

And you have a nested route as follow:

<template>
  //...
  <button @click="$emit('event')"></button>
  //...
</template>

So the component corresponding to a nested route, emits an event. The question is : how to listen to that event ?

The simple answer demonstrated with code:

<template>
  //...
  <router-view @event="callAMethod"></router-view>
  //...
</template>

Exactly! We listen to that event in the router-view component

Vue components lifecycle hooks don't run in the order you think they run

Say you have 2 pages. Home and About.

When switching from Home to About, the created hook of the About component will run before the beforeDestroy hook of Home component. (take a moment here)

Weird?? Try switching routes in the working example below by seeing the console.

As solution (idk if it's the best solution though) you can use transition-mode out-in

    <transition mode="out-in">
      <router-view></router-view>
    </transition>

How to know if a child component is mounted ?

This one of my favorite tips I've read here (Vue Dose)

Say you have a child component and you want to do something when a hook of the child component is executed. You can do:

<Child @hook:created="doSomething" />

So the question to How to know when a child component mounted is:

<Child @hook:mounted="componentMountedDoSomething" />

How to know if a dynamically vuex registered module is registered ?

With the power of dynamically register/unregister vuex modules we can improve the performance a lot.

I recommend you to read a very useful article: Performance optimization: Lazy load vuex modules

We can register a vuex module:

this.$store.registerModule('my-module', MyModule)

And unregister it:

this.$store.unregisterModule('my-module')

To know if a module is already registered:

if (Object.keys(this.$store._modules.root._children).includes('my-module')) {
        // module is registered
}

My time is very limited but I am glad that I found some time to write this article (it took me some time though). I hope it helped and you enjoyed reading it.

I would be very happy if you leave a comment providing your solution. For example regarding the last "secret" you can use vuex store to indicate that a module is registered or not.

This is my first article on DEV community. Thank you for reading.

DEV Community: Roland Doda

🚀 Vue > React: Why Are We Still Pretending Otherwise?

7 Vue3 tips you need to know

VNode hooks

Debugging hooks

Expose slots from a child component

Scoped styles and multi-root nodes don't work well together

Be careful when using CSS selectors

Boolean casting

Template refs with v-for - Order is not guaranteed

Ending the article

Know a cool company hiring Vue.js developers?

How to use Composition API the right way

Intro

Why not the old Options API way?

Why Composition API is indeed better?

How to structure logical concerns?

Conclusion

Composition api or Options api?

Clarification 🧼

Options API is not Vue 2 🙅

Composition api is powerful 💪

No one complained about the Options API 🤨

Options api for Todo apps? 😲

Be careful! 😨

DX of the Composition API 🐛

Why ref and reactive ??

Usage in the template

Ref unwrapping

Ref syncing

So what? 🤷

Conclusion (❁´◡`❁)

My thoughts 💭

Share your thoughts

Pinia: How to reset stores created with function/setup syntax

What is Pinia

Object and Function stores

How to reset the store with Object syntax

How to reset the store with Function syntax

Conclusion

Part 2:Unified SVG icons with Vite, Vue 3, Quasar and Pinia

Summary

What are we going to build:

Create controls and result section

Show the generated code

CSS Variables section && responsive design

Suspense and gradient borders

Part 1:Unified SVG icons with Vite, Vue 3, Quasar and Pinia

Summary

What are we going to build:

Requirements

Let's start coding! ⌨️🔥

Install Quasar and Pinia

Create reusable component for SVG icons

Auto-register components

import.meta.glob

import.meta.globEager

Create and use Pinia store 🏪

Next steps

About me

Deploy to Github Pages like a pro with Github Actions

Copy the name of your project.

For React specify the homepage in package.json (Docs).

For Vue create a new file in your project root named vue.config.js (Docs) and specify the publicPath (Docs).

Now commit and push your changes.

Open your terminal in your project and run:

🚀🚀 Congrats 🚀🚀

Create a node.js script

✨🎉 And... that's it! 🎉✨

Create a github action to automate deployment

🌟🌟 Taadaaa!!! You successfully automated deployment!!! 🌟🌟

Things to know

8 secrets Vue Developers must know

Inline statement handler: Handle multiple arguments

Short Explanation:

Detailed Explanation:

Emit event from functional components

Short Explanation:

Detailed Explanation:

Pass all props to the child component

Why `ref` and `reactive` ??

`import.meta.glob`

`import.meta.globEager`

For React specify the `homepage` in `package.json` (Docs).

For Vue create a new file in your project root named `vue.config.js` (Docs) and specify the `publicPath` (Docs).