DEV Community: Mohsen Vaziri

Updating My Mac Window Shortcuts Strategy for Optimal Workflow

Mohsen Vaziri — Wed, 01 May 2024 12:55:22 +0000

I previously wrote about using keyboard shortcuts to manage windows in macOS. With recent macOS updates and my discovery of the Rectangle app, it’s time for a strategy refinement.

The Challenge of macOS Shortcut Reliability

While I found the ⌃⌥⌘ keyboard combinations effective in the past, comments from others indicated that they’ve become less reliable on newer macOS versions. This inconsistency can disrupt productivity. After some investigation, switching to ⌃⌥⇧ shortcuts has restored the expected smooth functionality.

Introducing Rectangle: Efficiency and Customization

Rectangle is a fantastic free app that streamlines window resizing and arrangement through keyboard shortcuts. It offers a high degree of customization, but its default shortcuts are intuitive and work perfectly for me without any adjustments.

While the macOS native window animations are slightly smoother, Rectangle’s superior reliability makes it a clear winner in a professional workflow.

Seamless Setup, Enhanced Productivity

Rectangle’s installation is incredibly straightforward. Its immediate out-of-the-box functionality was a pleasant surprise. For anyone seeking to reduce the friction of window management on their Mac, Rectangle is a solution I wholeheartedly recommend.

The Power of Optimized Window Management

Don’t underestimate the impact streamlined window organization can have on your workflow. The ability to quickly position and resize windows minimizes distractions and helps maintain focus on the task at hand.

Share Your Productivity Tips!

Do you have other Mac productivity tips or tricks involving window management? Please share them below!

Developer experience with nuxt 3 — Vue Amsterdam Conference 2022 — Tenth Talk

Mohsen Vaziri — Tue, 22 Aug 2023 09:25:48 +0000

Daniel Roe - Core team member at Nuxt.js

Hello, dear readers! I'm back with another insightful piece, this time focusing on the developer experience in Nuxt 3, as presented by Daniel Roe, a core team member of Nuxt. Daniel also did a live coding session which covers all the following topics in action. If you want to watch that, or the entire talk, you can find it on YouTube.

Intro

Daniel Roe, with his background as a CTO of a SaaS startup and experience with a creative agency, emphasizes the significance of the developer experience. Having been a user of Nuxt, he understands the challenges developers face and believes that enhancing this experience is beneficial for both developers and companies.
He believes that improving the developer experience is beneficial for everyone. It aids the developer in implementing their ideas faster and more efficiently, and it's also advantageous for companies as it leads to quicker and better results.

The vision is to be as minimal as possible, as lightweight as possible, and to reduce context switching

Typescript in Nuxt 3

One of the significant changes in Nuxt 3 is the full integration of Typescript. This doesn't mean developers have to use Typescript, but it offers full control of the IDE, generating a tsconfig.json file that sets paths and provides type hinting.

Nuxt 3 takes full control of the developer's IDE. This is achieved by generating a tsconfig.json file. This configuration file is the heart of any Typescript project, and by controlling it, Nuxt 3 can introduce a plethora of features. For instance, it sets paths for every alias defined in the Nuxt project, whether it's by Nuxt itself, some other module, or an additional library. This ensures that developers have a smooth experience with imports, type hinting, and other IDE features.

Documentation at Fingertips

One of the significant advantages of using Typescript is the ability to provide inline documentation. Nuxt 3 leverages this by moving as much documentation as possible into the editor. This includes detailed descriptions of functions, their parameters, expected return types, code examples, and even links to further reading. This approach ensures that developers have immediate access to crucial information without having to switch contexts or browse external documentation.

Reducing Boilerplate in Nuxt 3

One of the standout features of Nuxt 3 is its commitment to reducing boilerplate code, making the developer experience smoother and more intuitive. Here's a deeper dive into how Nuxt 3 achieves this:

Auto-imported Functions

In Nuxt 3, developers no longer need to manually import commonly used functions. For instance, when using Vue 3, functions like ref, onMounted, and reactive are frequently utilized. In Nuxt 3, these are auto-imported, eliminating the need for repetitive import statements. This not only reduces the noise in the code but also streamlines the coding process.

<script setup>
const props = defineProps ({ name: String })
const greeting = computed(() => 'Hi ${props. name]')
</script>

<template>
    {{ greeting }}
</template>

Minimal Initial Setup

A fresh Nuxt 3 project comes with a minimal set of files. This includes:

app.vue: The starting point of the application.
nuxt.config: While this configuration file is present, it's initially empty and can often remain so, thanks to Nuxt's convention-over-configuration approach.
package.json: Contains just one dependency - Nuxt.
tsconfig.json: A configuration file generated by Nuxt to take full control of the IDE, enabling features like path aliases and type hinting.

Smart Data Fetching

Nuxt 3 introduces an isomorphic fetch function, $fetch, which smartly handles response headers. This function can determine whether the response is text, JSON, an array buffer, or another type, and processes it accordingly. This eliminates the need for developers to manually parse responses, making data fetching more intuitive.

export default defineEventHandler (event => {
    const { id } = useQuery(event) // /api/user?id-1 => 1
    const user = await $fetch( https: //api.dev/users/${id}*)
    return {
        id,
        user,
    }
})

Server Functions

In Nuxt 3, server functions can directly return objects, such as JSON. This means developers no longer need to set headers or stringify responses manually. This approach not only simplifies server-side code but also powers type inference, providing developers with accurate type hints when fetching from these endpoints.

Conclusion

I hope you enjoyed this part and that it was as valuable to you as it was to me.
Over the next few days, I’ll share the rest of the talks with you. Stay tuned…

Shout out to my friend Shahrokh, who made me excited to write the next part.

Full Stack Development With Nuxt 3 and Nitro — Vue Amsterdam Conference 2022 — Ninth Talk

Mohsen Vaziri — Thu, 02 Feb 2023 22:06:24 +0000

Pooya Parsa - Head of Framework at Nuxt.js

Welcome! It's been a while since my last article, but I'm excited to return with the ninth part of my series on the Vuejs Amsterdam conference 2022. In this part, we will delve into the exciting world of full-stack development using Nuxt 3 and Nitro. You can watch the talk on JSWorld's YouTube channel as well.

Intro

I remember last time [two years ago] I was on the stage here, we had a really big dream of Nuxt to extending from an SSR application to something that we can use everywhere and beyond it.

To make this happen, they had to rewrite everything, which took more than 2 years. But before talking about Nuxt 3, Pooya talks about Nuxt 2, its strengths and limitations, and the reason behind starting with a project called Nitro which is a part of Nuxt 3.

Nuxt 2 Server Middleware

Nuxt 2 is a framework mainly focused on Server Side Rendering due to its benefits. Now that we already have a server, why not take this opportunity to extend it and add our APIs? Here's how we do it in Nuxt 2 using Server Middleware:

// server-middleware/test.ts
export default function (req, res) {
    res.end(JSON.stringify({ hello: 'world' }))
}

To register this middleware:

// nuxt.config
export default {
    serverMiddleware: {
        '/api/test': './server-middleware/test'
    }
}

Now if we call http://localhost:3000/api/test we get the response:

{
    "hello": "world"
}

As you can see it's plain simple node.js middleware, supports typescript and it had a basic router system using prefixes. But it has some limitations. For example, lack of dynamic path support in the route, no alias and transform support, and files are not bundled and are loaded in the runtime and we have to deploy the entire source code to the production to make it work.

Server Middleware HMR in Nuxt 2

Nuxt 2 is using an older version of express.js called connect which is lighter. On top of that, it has an isolation for SSR, so every code that you write like plugins and components is bundled through webpack or vite and is loaded in this isolated environment with HMR support.

It supports TypeScript with unjs/jiti and is fast at cache invalidation, but the server and node_modules were not isolated and the entire node_modules folder had to be deployed. Runtimes varied between production and development too.

Nuxt 2 with Express

We Could use nuxt 2 not only as a standalone framework but also as a middleware for an existing application. That gives us lots of flexibility but it comes with its own downsides.

It needs node_modules entirely to deploy to production, which limits us for some environments like serverless or makes it impossible in some other environments like edge rendering which are workers - Because we can not deploy node application with node_modules to edge.
It has a bad Developer Experience without server HMR and you have to reload the server every time you change something in the code.
It has unpredictable behaviors because it was designed to be used in specific ways.

API Calls in Nuxt 2

When you try to fetch something from the server side in your nuxt 2 application some strange things happen.

In this example, we are loading a product page in a webshop. In order to Server side render this endpoint we have to fetch the product's data, from the same API that is living on the same server. Maybe the only upside is that we have a shared server and there is no need to set up another server for the APIs.

But there are more downsides:

The base URL has to be manually configured and is a nightmare.
SSR API calls roundtrip in real-world apps to bring huge latency, making nuxt 2 apps slower than expected.
There is no built-in HTTP client.

Static Generation in nuxt 2

Nuxt 2 allows you to generate a static application that is not dependent on server files so you can deploy it everywhere.

When you run the nuxt generate command to generate the static app, nuxt will:

Build and bundle the whole app.
Load the bundle using a programmatic API to emulate the server.
Using this server and an internal API, nuxt tries to render each page and write them to the file system.
The dist/ is ready to use!

It is simple and fast in implementation, has full static support, and there is also a shared generation cache feature between pages. But there are also some issues with that.

You can either target server or static. There are many cases in that you can choose between one of them, but there are some use cases that need to have best of the both worlds.
Generation on demand is not possible and we have to pre-generate all of the pages every time on deployment.
The direct rendering method used in nuxt 2 makes also the internal code more complicated which was making some improvements harder.

Nuxt 2 server deployment

Deploying a nuxt 2 SSR App to production seems to be easy, but it's not efficient.

The whole repo must be deployed.
Only Node.js hosting is supported.
Extra unused node_modules.

Nitro

During an internal team meeting about cloud flare workers at the time that the team was actively working on nuxt 2, Pooya realized that nuxt was limited in some important aspects.

Nitro project started as an experiment on top of nuxt 2 thanks to the modularity and the hooks that it provides. They managed to create a proof of concept to deploy nuxt 2 apps to the edge and remove most of those limitations.

Nitro's goal according to Pooya is to deploy any JavaScript server anywhere you want, including edge, and he even claims that we can even run a package like express in the browser service worker using nitro.

Server Routes in Nuxt 3

To create a server route in Nuxt 3:

// server/api/hello.ts
export default () => ({ nuxt: "is easy!" })

// http://localhost:3000/api/hello
{
    "nuxt": "is easy!"
}

Also, it has a first-class integration with the runtime application and works out of the box:

// app.vue
<template>
    <div> {{ data }} </div>
<template>

<script setup>
    const { data } = await useFetch('/api/hello')
</script>

Some of the benefits are:

Minimalist API using unjs/h3 created by themselves, which is one of the fastest libraries.
Built using TypeScript
Fast router using unjs/radix3
Integrated HTTP client (fetch and $fetch)
It's platform agnostic, meaning you can write the code and expect it to run on every platform.
Lots of new built-in helpers

API Calls in Nuxt 3

In opposite to Nuxt 2 where we had to make a round-trip, here we have direct API calls with 0 latency, baseURL is automatically handled, and also fetch is improved with unjs/ohmyfetch.

Server HMR in Nuxt 3

In Nuxt 3, server Entry is also integrated into the same bundle compared to nuxt 2. Also, the entire server is isolated, and it's much faster in HMR. The new gotcha is that runtime isolation is more complex.

Pluggable KV Storage

Nitro comes with something called Pluggable Key-Value storage, which is powered by unjs/unstorage built by the nuxt team.

The unstorage solution is a unified and powerful Key-Value (KV) interface that allows combining drivers that are either built-in or can be implemented via a super simple interface and adding conventional features like mounting, watching, and working with metadata.

It works in all environments (Browser, NodeJS, and Workers) and offers multiple built-in drivers (Memory, FS, LocalStorage, HTTP, Redis).

Here you can see a snippet of an example of a simple note-taking app:

// server/api/notes/index.post.ts
export default defineEventHandler (async (event) => {
    const id = (await useStorage().getKeys( 'data: notes')) . Iength + 1
    const body = await useBody(event)
    const note = { ...body, id }
    await storage.setItem(`data:notes:${id}`, note)
    return { id }
])

// server/api/notes/[id].ts
export default defineEventHandler (async (event) =› {
    const { id ] = event. context. params
    const note = await useStorage().getItem(`data:notes:$(id)`)
    if (!note) {
        throw createError ({
            statusCode: 404,
            statusMessage: "Note not found!"
        })
    return note
})

Nuxt 3 server deployment

Deployment in Nuxt 3 is easier. You will fire nuxt build and the result will be a portable .outputdirectory with required public files and a tree-shaken version of the node_modules.

Static generation in Nuxt 3

Here are the steps from running the command to receiving the output:

In opposite to nuxt 2, here we have a hybrid solution to have the best of both worlds (server and static), and also generation on demand is now also possible.

End of the ninth Talk

I hope you enjoyed this part and that it was as valuable to you as it was to me. Over the next few days, I’ll share the rest of the talks with you. Stay tuned…

The Nuxt Web — Vue Amsterdam Conference 2022 Summary series — Eighth Talk

Mohsen Vaziri — Sun, 07 Aug 2022 19:15:03 +0000

Welcome! Happy to see you in the seventh part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you.

You can read my JSWorld Conference 2022 Summary series (in four parts) here, where I summarized all the first day’s talks. You can also find the previous Talks of the Vue Amsterdam conference 2022 in my blog.

(Recurring) Introduction

After two and a half years, JSWorld and Vue Amsterdam Conference were back in Theater Amsterdam between 1 and 3 June, and I had the chance to attend this conference for the first time. I learned many things, met many wonderful people, spoke with great developers, and had a great time. On the first day the JSWorld Conference was held, and on the second and third days, the Vue Amsterdam.

The conference was full of information with great speakers, each of whom taught me something valuable. They all wanted to share their knowledge and information with other developers. So I thought it would be great if I could continue to share it and help others use it.

At first, I tried to share a few notes or slides, but I felt it was not good enough, at least not as good as what the speaker shared with me. So I decided to re-watch each speech, dive deeper into them, search, take notes and combine them with their slides and even their exact words in their speech and then share it with you so that what I share with you is at least at the same level as what I learned from them.

A very important point

Everything you read during these few articles is the result of the effort and time of the speaker itself, and I have only tried to learn them so that I can turn them into these articles. Even many of the sentences written in these articles are exactly what they said or what they wrote in Slides. This means if you learn something new, it is because of their efforts.

Last but not least, I may not dig into every technical detail or live codings in some of the speeches. But if you are interested and need more information, let me know and I’ll try to write a more detailed article separately. Also, don’t forget to check out their Twitter/Linkedin.

Here you can find the program of the conference:

JSWORLD Conference

The Nuxt Web

Sebastien Chopin - Co-Founder of Nuxt

Our mission at @nuxtlabs is to provide the best Developer Experience to deliver the best User Experience for your end users. We are doing this with Nuxt for six Years now.

Nuxt is a web framework for creating any kind of Vue app. That means you can do:

Servier Side Rendering (SSR)
Static Site Generation (SSG)
Client Side Rendering (CSR)
Edge Side Rendering (ESR) thanks to Nuxt 3

Since the beginning of Nuxt in October 2016 it has been downloaded about 46M times on npm, has 300k live websites, and 18k GitHub contributors.

A comparison between Nuxt 2 and Nuxt 3

Web server: For the development and production web server, Nuxt 2 uses to connect, which is the core of Express.js, but for Nuxt 3 they created h3 and it works in any kind of JavaScript environment.
Bundler: Webpack 4 is used in Nuxt 2, and for Nuxt 3 they started with Webpack 5, but after the release of Vite, it is officially supported as the default Bundler.
UI framework: Vue 2 in Nuxt 2 and Vue 3 in Nuxt 3
Routing library: Vue Router 3 in Nuxt 2 and Vue Router 4 in Nuxt 3, which will not be included if no pages/ directory is found.
Meta management: Since Nuxt does SSR, it’s important to be able to manage meta tags. Vue Meta is used in Nuxt 2 and VueUse Head in Nuxt 3.
Server(less) packager: This is introduced in Nuxt 3, which compacts the nuxt application for production by removing the node_modules so your Nuxt application will be about 1 megabyte.

This is a hello world bundle size comparison between Nuxt 2 and Nuxt 3:

One of the reasons Nuxt 3 is so much smaller is that it's tree shakable, like Vue 3. So if you don't use a feature, it will not be included in the bundle.

The Next equivalent bundle size is around 80kB.

In that Nuxt 3 JS bundle, 25.3kB are from Vue, and the 8.7kB left includes:

App entry with hydration
Root component with <Suspense>
Universal and lightweight router: useRouter(), middleware and <NuxtLink>
Head composable & components: useHead(), <Title>, <Meta>, <Script>, …
Universal data fetching: $fetch()
Default error pages: 404 and 500
Plugins and runtimeConfig logic
useNuxtApp() composable and hooks: app:created, app:mounted, page:start, …

Edge Side Rendering

Edge Side Rendering - also named JavaScript containers by Ryan Dahl - is the capability of running JavaScript at the CDN nodes somewhere around the world close to the end user.

The advantages:

Runs milliseconds from end users
0ms cold starts
No servers to maintain
Automatic scaling
Affordable

Some of the Edge computing providers right now:

CloudFlare Workers
Vercel Edge
Netlify Edge
Deno Deploy
Lambda Edge
StackPath

Content V2

Nuxt Content is a Nuxt module that reads Markdown, YAML, CSV, and JSON files in the content/ directory to create a powerful data layer for your application and Content V2 is out now with more features.

Nuxt 2.X

What’s coming for Nuxt 2.X:

Vue 2.7
Nuxt Bridge (beta)
- Vite
- Nitro
- Composition API & Script setup
- TypeScript
- nuxi CLI
- PostCSS 8

Nuxt 3.0

What's coming for Nuxt 3.0:

Nuxt Image
Hybrid rendering: Server + SWR + Pre-rendering
Full static generation
Preview mode
Server sessions and Auth
Service Workers (PWA)
SEO helpers and i18n support

End of the Eighth Talk

I hope you enjoyed this part and it can be as valuable to you as it was to me.

Over the next few days, I’ll share the rest of the talks with you. Stay tuned…

Animating with Vue — Vue Amsterdam Conference 2022 Summary series — Seventh Talk

Mohsen Vaziri — Tue, 19 Jul 2022 20:21:00 +0000

Welcome! Happy to see you in the seventh part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you.

(Recurring) Introduction

A very important point

Here you can find the program of the conference:

JSWORLD Conference

Animating with Vue

Ramona Biscoveanu - Frontend Developer at SAP

Sometimes our applications need a little bit of "wow" and we can do this with some "movement" just the perfect amount to make them more alive.

We will be looking at how to use the Vue magic to create awesome animations, from simple ones to more complex ones, combining Vue with animation libraries.

90s Websites

On 90s websites, there were sometimes a lot of motions and colors. But the only way we could have animations back then was with gifs. Just imagine the bandwidth those gifs consumed in the era of Dial-Up internet! So we end up with some tiny low-frame gifs to limit the bandwidth consumption, and this was the result:

Why animate?

One of the reasons we use animations these days, even back then, is to capture users' attention and focus.

Think of how many distractions we have, notifications on our phones, pop-ups on the websites, or the jumping icons on the dock on macOS.

We can also trick users into thinking that our website is a lot faster. We give them this perception that our APIs are faster by putting loaders and progress bars. Studies are saying if you have a custom loader you have a chance of keeping the people on our website longer.

Sometimes we try to inform our users efficiently. Maybe we have lots of things going on on our website and we want to tell the user what is the next step in the flow of the application with an animated button.

Other times we need interactive content for marketing materials to keep users there.

Animations are also powerful when you try to tell a story.

Vue `<Transition />`

In Vanilla JavaScript or jQuery, you need to manually calculate the timings and delays, and decide when to add or remove classes. But in Vue, we wrap the target element into the <Transition /> component and it does many of those hard things automatically. Here is a simple fade animation:

<transition name="fade">
  <p v-if="show">hello</p>
</transition>

.fade-enter-active, .fade-leave-active {
  transition: opacity .5s;
}
.fade-enter-from, .fade-leave-to 
  opacity: 0;
}

This is how Vue handles that:

Vue `<TransitionGroup />`

<TransitionGroup> is a built-in component designed for animating the insertion, removal, and order change of elements or components that are rendered in a list.

This is a simple example of some tiles sliding on the screen:

<transition-group tag="div" class="tile-section" name="list" appear>
  <TileComp
    v-for="(tile, i) in tiles"
    :key="i + 'tile'"
    :header="tile.title"
    :content="tile.content"
    :footer="tile.footer"
  ></TileComp>
</transition-group>

.list-enter-active,
.list-leave-active {
  transition: all 1s ease;
}
.list-enter-from,
.list-leave-to {
  opacity: 0;
  transform: translateY(70px);
}

JavaScript Hooks

CSS is awesome and we can do a lot with it, but sometimes it’s not enough.

Vue provides some hooks on the <Transition /> component.

<Transition
  @before-enter="onBeforeEnter"
  @enter="onEnter"
  @after-enter="onAfterEnter"
  @enter-cancelled="onEnterCancelled"
  @before-leave="onBeforeLeave"
  @leave="onLeave"
  @after-leave="onAfterLeave"
  @leave-cancelled="onLeaveCancelled"
>
  <!-- ... -->
</Transition>

GreenSock GSAP

The GreenSock Animation Platform (GSAP for short) is a powerful JavaScript library that enables front-end developers and designers to create robust timeline-based animations.

One of the most important things you will hear a lot in GSAP is Tween.

A Tween is what does all the animation work — think of it like a high-performance property setter. You feed in targets (the objects you want to animate), a duration, and any properties you want to animate and when its playhead moves to a new position, it figures out what the property values should be at that point and applies them accordingly.

Common methods for creating a Tween (all of these methods return a Tween instance):

For simple animations (no fancy sequencing), the methods above are all you need!

gsap.to(".selector", {toVars});
gsap.from(".selector", {fromVars});
gsap.fromTo(".selector", {fromVars}, {toVars});
// special properties (duration, ease, etc.) go in toVar

Now let’s add GSAP to our tiles example:

<div class="tile-section">
  <TileComp
    v-for="(tile, i) in tiles"
    :key="i + 'tile'"
    :header="tile.title"
    :content="tile.content"
    :footer="tile.footer"
  ></TileComp>
</div>

import gsap from "gsap";
...
mounted() {
  gsap.from(".tile", {
    duration: 0.5,
    opacity: 0,
    scale: 0,
    y: 200,
    ease: "power2",
    stagger: 0.1,
  });
},

Vue animation counter

Another simple example of using GSAP to make nice animations can be a celebrate counter animation. Here you can see what it will look like:

All we have in the template is just an h1 element where we pass the formatted value and a reset button.

<div>
  <h1 ref="celebrate" class="counter" :class="{ celebrate: isCelebrate }">
    {{ this.numberWithCommas(value) }}
  </h1>
  <button class="restart" @click="restart">Restart</button>
</div>

We need to use timeline function of GSAP. Think of it as a tool to sequence your animations.

import gsap from "gsap";
import confetti from "canvas-confetti";
const tl = gsap.timeline();
const start = 100000;
const end = 3240074;

export default {
  props: {
    msg: String,
  },
  data() {
    return {
      isCelebrate: false,
      value: start,
    };
  },
  mounted() {
    tl.fromTo(
      ".counter",
      {
        innerText: start,
        scale: 0.8,
      },
      {
        innerText: end,
        snap: { innerText: 1 },
        duration: 4,
        ease: "linear",
        onUpdate: () => {
          this.$refs.celebrate.innerText = this.numberWithCommas(
            this.$refs.celebrate.innerText
          );
        },
        onComplete: () => {
          this.celebrate();
        },
      }
    );
  },
  methods: {
    celebrate() {
      this.isCelebrate = true;
      confetti({
        particleCount: 150,
        spread: 100,
        origin: { y: 0.6 },
        colors: ["#647eff", "#42d392"],
        disableForReducedMotion: true,
      });
    },
    numberWithCommas(x) {
      return x.toString().replace(/\B(?=(\d{3})+(?!\d))/g, ",");
    },
    restart() {
      tl.restart();
      this.isCelebrate = false;
    },
  },
};

Page Transition

In Vue Router 4 the syntax for transitioning pages has changed a bit. We don’t wrap the router into the transition component anymore. instead, we use the v-slot:

<router-view v-slot="{ Component }">
  <transition name="fade">
    <component :is="Component" />
  </transition>
</router-view>

Here is an example of a page transition:

For building this page transition, we need the enter hook:

<router-view v-slot="{ Component }">
  <transition
    :key="$route.path"
    @enter="onEnter"
    :css="false"
  >
    <component :is="Component" />
  </transition>
</router-view>

Then we need to register the SplitText plugin from GSAP:

import gsap from "gsap";
import SplitText from "gsap/SplitText";

gsap.registerPlugin(SplitText);

gsap.defaults({
  duration: 1,
  ease: "power3.inOut",
});

And then using the plugin we split the text to be able to animate it:

mySplitText(el) {
  return new SplitText(el, { type: "words,chars,lines" });
},

Let’s take a look at onEnter hook:

onEnter(el, done) {
  const masterTL = gsap.timeline({
    onComplete: () => {
      done;
    },
  });

  masterTL.add(
    this.enterContentTextAnimation(
      mySplitText(".content-text-header").chars
    )
  );
  masterTL.add(
    this.enterContentTextAnimation(".content-text-body"),
    "-=0.9" //overlap with previous by 0.9s
  );
  masterTL.add(this.imgScaleOut(".content img"), "<");
    //The start of previous animation
},

And here you can see how you can nest GSAP timelines and what enterContentTextAnimation and imgScaleOut functions do:

enterContentTextAnimation(id) {
  const tl = gsap.timeline();

  tl.fromTo(
    id,
    {
      yPercent: "100",
      opacity: 0,
    },
    {
      yPercent: "0",
      opacity: 1,
      stagger: 0.03,
    }
  );
},

imgScaleOut(id) {
  const tl = gsap.timeline();

  tl.from(id, {
    scale: 1.5,
  });

  return tl;
},

SVG

Animated charts can be a good example of SVG animation:

Here is the part of the code that makes this chart animation possible:

watch: {
  data(newValue, oldValue) {
    newValue.map((data, index) => {
      var id = "#arc" + index;
      var d = this.calculateArc(data, index);
      var oldValueD = this.calculateArc(oldValue[index]);
      const tl = gsap.timeline();

      tl.fromTo(
        id,
        {
          attr: { d: oldValueD },
        },
        {
          duration: 0.5,
          attr: { d: d },
          yoyo: true,
        }
      );
    });
  },
},

It’s important to not abuse animations on your website. Sometimes they are useful, but sometimes they can kill your audience.

End of the seventh Talk

I hope you enjoyed this part and it can be as valuable to you as it was to me.

Here you can find the next talk about Nuxt 3.

It’s a (Testing) trap! — Vue Amsterdam Conference 2022 Summary series — Sixth Talk

Mohsen Vaziri — Sun, 10 Jul 2022 10:18:33 +0000

Welcome! Happy to see you in the sixth part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you.

(Recurring) Introduction

A very important point

Here you can find the program of the conference:

JSWORLD Conference

It’s a (Testing) trap! Common testing pitfalls and how to solve them

Ramona Schwering - Software developer at shopware

“It’s a trap” - a call or feeling we all might be familiar with, not only when it comes to Star Wars. It’s signalizing a sudden moment of noticing imminent danger.

This situation is an excellent allegory for an unpleasant realization in testing. Imagine having the best intentions when it comes to testing, but still ending up with tests failing to deliver you any value at all?

Tests who are feeling like a pain to deal with?

When writing frontend tests, there are lots of pitfalls on the way.

In sum, they can lead to lousy maintainability, slow execution time, and - in the worst-case - tests you cannot trust.

But the worst pain point is those tests that give you new value and result because they are flaky. You have a build that sometimes passes and sometimes fails and you did nothing in between.

Pain points

You might be sure that testing has many perks and advantages, but all of those wonderful things can be out shadowed by pain points caused by various reasons. All the things you did with the best intentions but in the long run or even earlier they turned out painful or exhausting.

For example, slow tests can kill the fun. Imagine you have your pull request and you want it to be merged, but you need to wait hours or maybe days for the pipeline to finally be completed.

Even worse are tests that are painful to maintain. You think about your past self and you ask: What did you do with this test? What was the purpose?! What did you think about that one? Or other team members who are asking you questions about what you did in the past and you have no clue.

But the worst pain point are test that give you new value and result because they are flaky. You have a build which some times passes and some times fails and you did nothing in between.

Simple tests

It doesn’t have to be this way. One of the most important mindsets and golden rules in JavaScript testing best practices is Simple.

Tests should be designed plain and simple in every case. In unit tests, integration tests, and End to End tests, keep it stupid simple.

Our goal should be that one is capable to understand your test and get its intent instantly without thinking about it.

Try to aim for a flat test design, which means only testing as much as needed and using few to no abstractions at all.

Traps

Let’s look at the first Trap.

describe('deprecated.plugin', () => {
    it('should throw error',() => {
        …
    });
});

It should throw an error if the deprecated plugin is in use.

When you look at the title — should throw an error — you don’t know what it wants to accomplish. But the Golden rule says you should know instantly what it’s doing.

We can make it more comprehensible with the “Three-Part Rule”. The test title should contain three things:

What is being tested
Under what circumstances should be tested
What is the expected result

With this rule in mind, this is what our test will look like:

describe('deprecated.plugin', () => {
    it('Property: Should throw an errorif the deprecated prop is used',
    () => {
        …
    });
});

The next Trap can be the test structure:

describe('Context menu', () => {
    it('should open the context menu on click', async () => {
        const wrapper = createWrapper();
        expect(wrapper.vm).toBeTruthy();
        await wrapper.trigger('click');
        const selector = '.sw-context-menu';
        expect(wrapper.find(selector).isVisible()).toBeTruthy();
    });
});

In this case, declarations, actions, and assertions are written all over the place without any clear structure. Especially in bigger tests, this can be a huge pain. We can make it more structured with AAA Pattern. You divide your test into three parts:

Arrange: Everything concerning the setup to the scenario the test aims to simulate.
Actions: Running your unit on the test and doing the steps to get to the results state.
Assert: Where you can do the assertions and check your test scenario.

This is what our test looks like with AAA Pattern:

describe('Context menu', () => {
    it('should open the context menu on click', () => {
        // Arrange
        const wrapper = createWrapper();
        const selector = '.sw-context-menu';
        // Act
        await wrapper.trigger('click');
        // Assert
        expect(wrapper.vm).toBeTruthy();
        expect(wrapper.find(selector).isVisible()).toBeTruthy();
    });
});

This looks much better!

But there is a problem. Think back to our test case. It is a context menu and it is hidden by default. So we need to open it to interact with it. But it means we need to do an assertion to make sure that it’s open before the act. Doesn’t it destroy the pattern?

If we are testing the DOM, we sometimes need to check the before and after states. So Let’s take a look at this pattern from another perspective.

…arrange my test == what I’m given.
…act in my test == when something happens.
…assert the results == something happens then this is what I expect as the outcome.

This is a pattern taken from behaviour driven development: Given - When - Then

Our prior test with the usage of this pattern:

describe('Context menu', () => {
    it('should open the context menu on click', () => {
        // Given
        const contextButtonSelector = 'sw-context-button';
        const contextMenuSelector = '.sw-context-menu';
        // When
        let contextMenu = wrapper.find(contextMenuSelector);
        expect(contextMenu.isVisible()).toBe(false);
        const contextButton = wrapper.find(contextButtonSelector);
        await contextButton.trigger('click');
        // Then
        contextMenu = wrapper.find(contextMenuSelector);
        expect(contextMenu.isVisible()).toBe(true);
    });
});

E2E Testing

Avoid using placeholders and use realistic naming as much as possible.

it('should create and read product', () => {
    …
    cy.get('.sw-field—product-name').type('T-Shirt Ackbar');
    cy.get('.sw-select-product__select_manufacturer')
    .type('Space Company’);
    …
});

If you don’t want to come up with thousands of names, maybe you can use faker or other tools to generate some dummy data, or if it’s okay with the laws and your project, import it from the production state. Just make sure that your test stays comprehensible and easy to read and that you know what it does.

Let’s take a look at the same test for the next trap, which is selectors.

If you refactor your application and change some classes — which is common — this could cause your test to fail, and in this case, the test failing without a bug present in your app — which is called a false negative giving no reliable report of your app because it’s not broken, just your implementation changed.

Look at selectors you must! In other words, you shouldn’t test implementation details. Instead, think about using things a user would call attention to and navigating your application. For example some text inside your page. Even better, use selectors which are not that prone to change, like data attributes. You can even call it for example for cypress data-cy=”submit” so one instantly know that it is meant for testing.

Last but not least, don’t use fixed waiting times.

Cypress.Commands.add('typeSingleSelect', {
        prevSubject: 'element',
    },
    (subject, value, selector) => {
        …
        cy.wait(500);
        cy.get(`${selector} input`)
        .type(value);
});

On one hand, that can slow down your test way too much if a test case will be executed so many times. It can be even worse when your application is being used on weaker hardware. In this case, you may need more than that fix 500ms.

There are some solutions for that, for example waiting for the changes in the UI, like a for loading spinner to disappear or an animation to stop or something to appear.

Or even better, wait for API Requests and Responses.

Tests are there as an assistant to you, not a hindrance. They should feel like a routine not like solving a complex mathematical formula.

End of the sixth Talk

I hope you enjoyed this part and it can be as valuable to you as it was to me.

Here you can find the next talk about animations.

Reusable Widgets that work! — Vue Amsterdam Conference 2022 Summary series — Fifth Talk

Mohsen Vaziri — Fri, 01 Jul 2022 15:48:56 +0000

Welcome! Happy to see you in the fifth part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you.

You can read my JSWorld Conference 2022 Summary series (in four parts) here, where I summarized all the first day's talks. You can also find the previous Talks of the Vue Amsterdam conference 2022 in my blog.

(Recurring) Introduction

A very important point

Here you can find the program of the conference:

JSWORLD Conference

Reusable Widgets that work!

Maria Lamardo - Head of Accessibility Training and Sr Manager of Accessibility Engineering at CVS Health

Vue.js is an amazing framework that allows you to quickly build reusable components. We can leverage this to build accessible reusable widgets with the help of ARIA (Accessible Rich Internet Application). Using ARIA roles and attributes, we can improve the accessibility of certain elements by providing additional semantics. In this talk, we will go over how to follow the specifications and build accessible and reusable tabs, accordions, toggle buttons, and modal dialogs that work for everyone!

Modal

All the things that you need to know about ARIA are well documented in W3C and it is recommended to read, but here is an abstracted version of it.

Modals Design Considerations

It must have a button that closes the dialog.
The content outside of the dialog should be obscured with visual styling like a grey background.
Make sure you prevent users from interacting with content outside of the dialog.

Modals Opening Focus Interaction

When a dialog opens, focus can be set on either the first focusable element, or a static element at the top of the dialog to make content easier to read and ensure that all the content remains in view, or the most frequently used element if interactions are limited to providing information or continue processing.

You don’t wanna set focus to something that is going to be destructive for the user, for example, let’s imagine you have an interaction where you open a modal to delete your account. You don’t want to set the first focus on “Yes, delete my account”.

Modals Closing Focus Interaction

When a dialog closes, the focus is set on the element that invoked the dialog, or when it doesn’t make sense you can set the focus on a different element, like an element that provides logical workflow if invoking element no longer exists, or on the next element if there is a subsequent step in the workflow following dialog task completion, especially if immediately reopening dialog is very unlikely.

Modals Keyboard Interaction

Tab	Moves focus to next tabbable element in modalLooping around to first element
Shift + Tab	Moves focus to previous tabbable element in modalLooping around to last element
Escape	Closes the dialog

Modals Technical Considerations

Dialog container should have:

Role of dialog
aria-modal set to true.
aria-label or aria-labelledby referring to dialog title, this is going to help assistive technologies figure out what the naming of this element will be.
Optionally you can set aria-describedby to any description.

All elements required to operate the dialog should be descendants of the element that has a dialog role.

<div 
    role="dialog" 
    aria-modal="true"
    aria-labelledby="title"
    aria-describedby="description"
>
    <h2 id="title">Title of the dialog</h2>

    <p id="description">Information provided by the dialog.</p>

    <button aria-label="close">×</button>
</div>

On the mac, you can Activate Voice Over which is the default mac screen reader by clicking Command + F5, and then you can go through your page and test it.

Also in chrome Dev-Tools, there is an accessibility tab that has some cool accessibility information.

With that, you can open this example and check it out, and here is the code.

Toggle Buttons

If you want the full information you can find it on the W3C website.

Buttons

A button is a widget that enables users to trigger an action or event, such as submitting a form, opening a dialog, canceling an action, or performing a delete operation.

In addition to the ordinary button widget, WAI-ARIA supports 2 other types of buttons:

Toggle buttons
Menu buttons

Toggle Buttons Design Considerations

A two-state button that can be either off (not pressed) or on (pressed).

To tell assistive technologies that a button is a toggle button, specify a value for the attribute aria-pressed.

The label on a toggle mustn't change when its state changes; if the label changes in the design, there is no need for the aria-pressed attribute.

Toggle Buttons Focus Handling

If activating the button does not dismiss the current context, then focus remains on the button after activation.
If activating the button opens or closes a dialog, then follow the dialog pattern.
If the button action indicates a context change, you can move focus to the starting point for that action
If the button is activated with a shortcut key, then focus usually remains in the context from which the shortcut key was activated

Toggle Buttons Keyboard Interaction

Enter	Activates the button
Space	Activates the button

Toggle Buttons Technical Considerations

The Toggle button must have the role of button.
Make sure that the button has an accessible name.
You can set aria-describedby to any description.
You can add aria-disabled set to true if action is unavailable.
The toggle button has an aria-pressed state.

<button aria-pressed="false">
  Mute
</button>

Here is a good example that you can check out and here is the code.

Accordions

Here is the complete documentation. Let’s take a look at its main points.

Accordions Design Considerations

Vertically stacked set of interactive headings that each contain a title, content snippet, or thumbnail representing a section of content

Accordion Header:

Label for or thumbnail representing a section of content that also serves as a control for showing, and in some implementations, hiding the section of content.

Accordion Panel:

Section of content associated with an accordion header.

Accordions Keyboard Interaction

Enter or Space	Expands associated collapsed panel, optionally collapses other opened panelCollapses associated expanded panel; if the implementation allows.
Tab	Moves focus to the next focusable element
Shift + Tab	Moves focus to the previous focusable element
Down Arrow (Optional)	Moves focus from the accordion header to the next accordion header Optionally loops back to the first accordion header.
Up Arrow (Optional)	Moves focus from accordion header to the previous accordion header Optionally loops back to last accordion header
Home (Optional)	Moves focus from an accordion header to the first accordion header
End (Optional)	Moves focus from an accordion header to the last accordion header

Accordions Technical Considerations

Make sure that Each accordion header button has:

wrapped in a heading
aria-controls set to the ID of the corresponding accordion panel content
aria-expanded set to true if corresponding panel content is visible
aria-disabled set to true if the collapsing accordion is not permitted

(Optional) Each panel content has role region and aria-labelledby to the corresponding header button

Avoid using the region role in circumstances that create too many landmark region

Accordions Code Example

<h3>
   <button
     aria-expanded="true"
     class="Accordion-trigger"
     aria-controls="sect1"
     id="accordion1id"
     >
        Accordion 1
   </button>
 </h3>

<div
   id="sect1"
   role="region"
   aria-labelledby="accordion1id"
   class="Accordion-panel"
>
    Content Placeholder
</div>

Here is a good example and its code.

Tabs

You can see Tabs’ full documentation on W3C.

Tabs Design Considerations

Tabs are a set of layered sections of content, known as tab panels, that display one panel of content at a time.

Tab List: A set of tab elements contained in a tablist element

Tab: An element in the tab list that serves as a label for one of the tab panels and can be activated to display that panel

Tab panel: The element that contains the content associated with a tab

It is recommended that tabs activate automatically when they receive focus as long as their associated tab panels are displayed without noticeable latency.

Tabs Keyboard Interaction

Tab	Places focus on the active tab element when user moves into the tab list
Left Arrow (Horizontal tabs)
Up Arrow (Vertical tabs)	Moves focus to the previous tab; looping to the last tabOptionally, activates the newly focused tab
Right Arrow (Horizontal tabs)
Down Arrow (Vertical tabs)	Moves focus to the next tab; looping to the first tabOptionally, activates the newly focused tab
Space or Enter	Activates the tab if it was not activated automatically on focus
Shift + F10	When focus is on a tab that has an associated popup menu, opens the menu

Tabs Optional Keyboard Interaction

Home (optional)	Moves focus to the first tabOptionally, activates the newly focused tab
End(optional)	Moves focus to the last tabOptionally, activates the newly focused tab
Delete(optional)	If deletion is allowed, deletes (closes) the current tab element and its associated tab panel, sets focus on the tab following the tab that was closed, and optionally activates the newly focused tab

Tabs Technical Considerations

Role of Tablist: Element containing a set of tabs must have aria-labelledby or aria-label.

Role of Tab: The element that serves as a tab must have aria-controls paired to the associated tabpanel, the active tab should have the state aria-selected set to true; all other tabs are set to false.

And it should have the property aria-haspopup set to either menu or true if a tab element has a pop-up menu.

Role of Tabpanel: Element containing content panel for a tab should have aria-labelledby paired to associated tab, and set aria-orientation to vertical or horizontal (default).

Tabs Code Example

<div role="tablist" aria-label="Tabs Example">
  <button
    role="tab"
    aria-selected="true"
    aria-controls="tab1-content"
    id="tab1"
  >Tab 1 </button>

  <button
    role="tab"
    aria-selected="false"
    aria-controls="tab2-content"
    id="tab2"
    tabindex="-1"
  >Tab 2</button>
</div>

<div 
  tabindex="0" 
  role="tabpanel"  
  aria-labelledby="tab1"
  id="tab1-content">
  <p>Content 1</p>
</div>

<div
  tabindex="0"
  role="tabpanel"
  aria-labelledby="tab2"
  id="tab2-content">
  <p>Content 2</p>
</div>

Here is a good example and its code.

Resources

ARIA Authoring Practices Guide

Web Content Accessibility Guidelines (WCAG) 2.1

You can find a complete Vue code example with different components here:

https://github.com/mlama007/Widgets

End of the fifth Talk

I hope you enjoyed this part and it can be as valuable to you as it was to me.

You can find the next Talk here.

The Unwanted Stack — Vue Amsterdam Conference 2022 Summary series — Forth Talk

Mohsen Vaziri — Sun, 26 Jun 2022 11:44:52 +0000

Welcome! Happy to see you in the fourth part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you.

You can read my JSWorld Conference 2022 Summary series (in four parts) here, where I summarized all the first day's talks. You can also find the previous parts of Vue Amsterdam in my blog.

(Recurring) Introduction

At first, I tried to share a few notes or slides, but I felt it was not good enough, at least not as good as what the speaker shared with me. so I decided to re-watch each speech, dive deeper into them, search, take notes and combine them with their slides and even their exact words in their speech and then share it with you so that what I share with you is at least at the same level as what I learned from them.

A very important point

Here you can find the program of the conference:

JSWORLD Conference

The Unwanted Stack

Maya Shavin - Senior Software Engineer at Microsoft

Develop with Vue, build using Vite and deploy using Netlify or Vercel sounds to be the perfect stack, for every Web developer. But life is not always that perfect. And to be a good developer, we need to learn and to adapt ourselves in any situation. How do we make the most out of Vue in a less perfect, or even an unwanted tech stack? Let's join her talk and find out.

She uses an example of the evolution of building a window as a window manufacturer to make it easier to understand.

The beginning

When you start building a simple window, you can build it in any shape that you want and you have a lot of choices. You have the freedom of choice and you can choose any frame(work), any shape, any supporting tool, and any building technique.

After a while

Assuming you finish with your windows, either you become the company who makes windows because you’ve released your window out there and it became successful, or it’s just a project that you do in your free time, so now that you know how to build a window you join a company to make windows.

At this point, you start to realize that you can not choose everything on your own like before.

Delivery/Deploying: How you’re going to Deliver the window to production or the store.
Team: How you’re going to build a team around it; Each person in the team will be in charge of building a section of the window.
Scalability: How you’re going to add another lock or another frame or even another layer of protection over your window to protect it from sun or rain.
Maintenance: You always have to maintain your window because if it’s not maintainable anymore and people use it and then one day it’s broken and someone gets hurt from it, you have to take responsibility.
Integration: Not all of the windows will fit what your customer needs. For example, it may need to be a little curvier to fit into the area where it supposes to be. So you have to do the integration and provide customization.

And suddenly, you don’t have a choice anymore and you have four factors that you need to consider to work on the window: Frameworks, Tools, Platforms, and Rules.

The Platform is the base on which you build your windows on, now the question is:

Can you build your Window on anything you want? → Can you build your application on any platform or server you want?

Every Company has its favorite platform & stack. For example, Google has its own Google Cloud, Amazon has AWS, and Microsoft has Power app and Azure. So when you work with one of these companies you don’t decide on the platform, you work with the platform. But it’s not always your favorite one!

The New Guy Phenomenon

“The one who thinks he’s cooler and knows better, and always asks: Why would you do that instead of this?!”

When you join a new company, this is how you feel and how other people see you because you come fresh, so when you go into the system you think you know it better and ask questions like why do you use Webpack instead of Vite?!

This is common and you start wanting to change things, which is good. But it leads to another debate:

“My Approach, my framework, and my stack are better!”

Or after some time you fail in convincing or feel that:

“What am I doing here?! I don’t know and don’t like this stack!”

So are you going to leave because that’s not the stack that you want?

It’s not about you

The tech stack is been there for a long time. It can be changed, but

It’s not about you, and It’s not about Evan You either! No one changes the stack just because of you or Evan You!

It’s about the Window Project

Deployment - CI/CD, Architecture, Compliance, Platforms

These represent the whole process of building a project. When you come into a new team or start a new project in a company, you need to consider these four cubes and not just go ahead and talk about a cool framework that comes with some nice tool that makes it a perfect stack. You need to consider the whole thing and find out why this is good for the project.

For example in a project which Maya works on in Microsoft, There is not much control on the Platform and Deployment part.

The Platform is already there and has all the connections to the database and all the authentication. So you can build everything up, but it also takes away some control. You don’t have control over the build process because the deployment is taken care of by the Power Apps. You don’t have control of building the server because the server is already there and you only need to config it to work with your application.

So what we have right now is the control over the architecture and compliance.

Architecture

Project nature (size, type, etc)

When you work on a project, you have to consider the nature of the project. Not every project is the same, and not every project needs the same stack.

Code Maintenance

How you are going to maintain and structure your code so that when the next new guy comes into your code base, he will not feel lost in the wood?

Scalability

How much scalability you’re going to provide in your code? If you are going to write a normal website or a landing page, you probably don’t need scalability, but if you are going to write an application where every piece is a component going to be reused by some other team or be deployed to the customer as the component itself and they would take it and use it in their applications, you probably need to understand how to do scalability.

Team performance (Skills, expertise)

This is not about the performance of the application, it is about how fast a team can walk together and can help each other to achieve what you want to do.

Compliance

This is what you want to do to comply with a bunch of protocols that your projects are given.

Startups or small companies may have fewer protocols, but in big companies like Microsoft and Google, there are many protocols to fulfill before you can release something.

Accessibility Support

Accessibility has to be a huge part because It is usability for everyone so you can not ignore it.

Testing (E2E, Unit test)

Are you going to manually run your test, check on your browser or have a whole team dedicated to doing manual testing? That’s not going to work. Nowadays finding people is hard and finding manual QAs is harder.

UI Consistency

Every Company has its own product and brand in UI design. For example, the Flat UI in Microsoft. At Microsoft in every single product, no matter what tech stack developers use, they have to use the same standards and protocols for the UI components, and in everything they do, the UI has to match the company’s branding and look and feel.

For example, if a user uses an Excel file and there is a Save button, your new application has to have the same color and look and feel for its save button.

Integration/Customization

To what extent are we going to provide integration or customization? What is the level of workaround we want our customers to have?

If you are going to build a store, that’s not much customization here except for the UI. But if you are going to build a dashboard that will be integrated into the customer database and pull data from the customer and it still needs to maintain the look and feel like Microsoft app, that would be the part where you trying to shape your application so that it will work with different customer needs.

Select(newCoolTool)

Let’s say you are the new guy on the team and you want to propose to change a testing tool. How do you want to do that?

For doing that, you have to understand what are the priorities, what are the alternatives and compare them, compatibility with the system, and only then, you propose the change to your managers or your team with Data. Here is an example:

Select(e2etesting)

What is the goal?

Speed?
Visual support?
Cross-browser support?
Flexibility in changing test runner?
Parallel testing?
Accessibility testing support?

How compatible is it?

Platform integration?
CI/CD integration?
Maintenance effort?
Learning effort?

Why would it be THE solution?

What are the tradeoffs?
Developer experience?
Community support
Comparisons
Scalability

Show me some data

You will do a demo, and not just a simple demo on a small or simple case, but make the test on the hardest and most complex case of your application. That takes time but if you do that, you can see the difference in performance between the two frameworks. Because the most complex situation is what you will face in the feature. If you choose one testing framework and it’s failed to do that complex case, then you have to revert and choose a different one and that means all the effort of trying to learn and write tests and adapt to the new testing framework got wasted.

And be ready for questions.

Change the stack, or make the best out of it

There are several things that you can do to make the best out of the stack:

Keep the coding standard
Use TypeScript
Be open-minded
Create solutions, not refactor first
Understand your window nature first
Plan your window
Instead of thy, try “What can be better?”

End of the fourth Talk

I hope you enjoyed this part and it can be as valuable to you as it was to me.

You can find the next Talk here

Fast stories powered by Vite; Histoire — Vue Amsterdam Conference 2022 Summary series — Third Talk

Mohsen Vaziri — Wed, 22 Jun 2022 18:39:38 +0000

Welcome! Happy to see you in the third part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you.

You can read my JSWorld Conference 2022 Summary series (in four parts) here, where I summarized all the first day's talks. You can also find the previous parts of Vue Amsterdam in my blog.

(Recurring) Introduction

A very important point

Here you can find the program of the conference:

JSWORLD Conference

Fast stories powered by Vite; Histoire

Guillaume Chau - Vue.js Core Team

The Talk is about writing component stories. Histoire is a tool like Storybook specifically built for the Vue ecosystem, which makes it easier to integrate and use.

I liked this project and I think Guillaume did a great job.

Why stories?

A story is a small number of components mounted in an isolated environment.

A Story makes it easier to organize and document components for other developers, Showcase features and components, Develop components in isolation, and test components.

Usually, we end up writing stories when we have a design system in the company which is common these days, where you define how each component is going to look, so it’s nice to have a place where you can showcase your design system to other developers or stakeholders. It’s also very useful when you have a component library.

Writing Stories

I found the way we write our stories could be better. So my goal was to improve the developer experience when you create stories. My experience was mostly with Storybook which is great and has a lot of features, but I felt the experience was not optimal for Vue developers specifically. I also wanted to make the stories fit into your project so that they don’t feel out of place [make them feel ‘native’ to the project]. I also wanted to use most of the same tools that developers are already using so that you don’t have to learn a new syntax and use entirely different tools to write stories, and also I wanted something which has a very nice UI and also is easily customizable to match your brand. And lastly, I wanted to be fast.

If you are a Vue developer and look at these, it’s straightforward:

<!-- Meow.story.vue -->
<template>
    <Story title="🐱 Mewo">
        🐱
    </Story>
<template>

<!-- Meow.story.vue -->
<script setup>
import Meow from './Meow.vue'
</script>

<template>
    <Story>
        <Meow />
    </Story>
<template>

<!-- Cars.story.vue -->
<template>
  <Story title="Cars">
    <Variant title="default">
      🚗
    </Variant>
    <Variant title="Fast">
      🏎️
    </Variant>
    <Variant title="Slow">
      🚜
    </Variant>
  </Story>
</template>

Vite Native

Some of the benefits of using Vite are:

Reuse the same build pipeline
Less time and effort setting up
Fast boot and instant HMR

Why Histoire?

It’s native to Vite projects, idiomatic to the developers — currently only supports Vue but in the feature, it will support other frameworks.

It’s also fast, light, customizable, and seems to have a great user experience.

Packed with features

⚡ Dynamic source: It generates the template dynamically and you can copy-paste it.
🎨 Automatic design tokens: If you have e.g. tailwind configuration, it will automatically generate stories with design tokens such as colors, shadows, text sizes, etc.
🎹 Flexible controls: Not only with props, but it also works with Vue slots.
🌔 Dark theme
📖 Markdown docs
📱 Responsive testing
🍱 Variant grids
🔍 Fast fuzzy search
📷 Visual regression testing
More to come...

Hands-on

Install:

pnpm i -D histoire
# OR
npm i -D histoire
# OR
yarn add -D histoire

Useful scripts:

"story:dev": "histoire dev",
"story:build": "histoire build",
"story:preview": "histoire preview"

The live example code from the Talk

// BaseButton.vue

<script setup>
defineProps({
    color: {
        type: String
    },
    count: {
        type: Number
    }
})
</script>

<template>
    <button>
        <slot />
    </button>
</template>

// BaseButton.story.vue

<script setup>
import { ref } from 'vue'
import { hstEvent } from 'histoire/client'
import BaseButton from './BaseButton.vue'

const text = ref('toto')
</script>

<template>
    <Story>
        <BaseButton
            @click="hstEvent('click', $event)"
        > {{ text }} </BaseButton>
        <template #controls>
            <HstText title="button text" v-model="text" />
        </template>
    </Story>
</template>

<docs lang="md">
# BaseButton


<template>
    <BaseButton color="green">
        Hulk
    </BaseBUtton
</template>

</docs>

Nuxt

Histoire fully supports Nuxt out of the box and it’s easy to install.

Histoire also automatically generates some useful stories from your Tailwind config.

Useful links

Documentation:

Histoire

Online demo:

Histoire

Try it in a live editor:

histoire-vue3-starter - StackBlitz

End of the third Talk

I hope you enjoyed this part and it can be as valuable to you as it was to me.

You can find the next Talk about Unwanted Stack here.

Getting more out of your Pinia Stores — Vue Amsterdam Conference 2022 Summary series — Second Talk

Mohsen Vaziri — Tue, 21 Jun 2022 08:22:05 +0000

Welcome! Happy to see you in the second part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you.

You can read my JSWorld Conference 2022 Summary series (in four parts) here, where I summarized all the talks of the first day. You can also find the first Talk where Evan You talks about the State of Vue in 2022 here.

(Recurring) Introduction

A very important point

Here you can find the program of the conference:

JSWORLD Conference

Getting more out of your Pinia Stores

Eduaro San Martin Morote - Creator at Vue-Router

Pinia might be a light library with a simple API but it takes advantage of many Vue Reactivity concepts like Effect Scopes, which are unknown by most. In this talk we will go through some of the internals of Pinia, understanding them and discovering how to enhance our usage of Pinia.

During the time I was creating Pinia, I had a lot of experimenting going on with the Refs and Reactives and the whole reactivity system of Vue, which gave me a lot of insights on how to keep that one single source of truth that we love so much in Vue.****

State Alchemy with Pinia

Pinia is the successor of Vuex, without compromising all the developer experience that comes with Vuex. It is compatible with Vue 2 and Vue 3, and it’s lighter and Vuex.

One of the advantages of Pinia is that it’s Fully (automatically) type-safe. This library is based on the Composition API, but you don’t need to use the Composition API to use Pinia.

It has a testing library and a Nuxt module as well.

Vuex vs Pinia

In Vuex you have some important rules:

You can only change the state in mutations.
You have to shout in action if you want to do it! (That’s why we write it in uppercase!)
Mutations have to be synchronous and only actions can be asynchronous

// Vuex

import { createApp } from 'vue'
import { createStore } from 'vuex'

// Create the store instance
const store = createStore({
    state: () => ({ count: 0 })
    mutations: {
        INCREMENT: state => { state.count++ }
    },
    getters: {
        double: state => state.count * 2
    },
    actions: {
        async increment ({ commit }) {
            await someAsyncCall()
            commit('increment')
        }
    }
})
// You have to use it as an Application plugin
createApp(App).use(store).mount('#app')

Now let’s take a look at Pinia:

// Pinia

import { createApp } from 'vue'
import { defineStore, createPinia } from 'pinia'

const useStore = defineStore({
    state: () => ({ count: 0 })
    getters: {
        double: state => state.count * 2
    },
    actions: {
        async increment () {
            await someAsyncCall()
            // There is no mutation, you can access the state with this keyword
            this.state++
        }
    }
})

createApp(App).use(createPinia()).mount('#app')

There aren’t many changes, except you no longer have to shout to change the state, and there is a function that is not creating a store, it’s defining a store. The difference is, that function is going to return another function that we call to get the actual store. The reason is to handle all the different ways we use the store to have an out of the box dynamic module registrations. In the end, CreatePinia() the function creates the Pinia instance.****

What does the Pinia instance really do?

If you look at the Pinia instance you’re going to notice two things.

A use() function which is for Pinia plugins.

A state, which is just a ref of an initially empty object which get’s populated after you call some stores.

That state is instantiated inside its own EffectScope.

To explain EffectScope we can talk about components. When you have a component that is mounted, it’s going to create its own EffectScope , which is going to collect all the reactivity variables like watchers, computed, etc. under its umbrella, and when the component is unmounted, this EffectScope is disposed and all the variables go away.

It’s the same for Pinia, except it never disappears and is always there.

Pinia Holds State

The stores are never going to hold the state by themselves, they're going to transfer that to the Pinia instance. So you can access the state at any time with pinia.state.value.

The first time you call the useSomeStore() in your application, it’s going to put the initial state into the store using the id of the store as the key.

const authStore = useAuthStore()

// Here the id will be "auth"
pinia.state.value.auth = { /* ... */ }

// If we call another store, It will add another object
const cartStore = useCartStore()

pinia.state.value.cart = { /* ... */ }

So as the user navigates through the application, the store keeps growing as it needed.

pinia.state.value = {
    auth: { /* ... */ },
    cart: { /* ... */ },
    // other stores' state
}

Pinia connects state

You can access the whole state of a store through $state. This variable is just a getter to access the store in Pinia.

There are three different ways of accessing a state in the store.

Through the Pinia instance: pinia.state.value.auth.user.login
Through $state on the store instance: authStore.$state.user.login
Directly through the store instance: authStore.user.login

Any of these variables is going to yield the same result, and also if you write to any of these variables you are also going to write to the three of them, in fact, you are only writing to the Pinia state, because there is only one source of Truth.

In Vue composition API there is a toRef function that gives you a ref to a reactive object. So if you have something that is reactive, you can get a ref to any part of the object and it will be connected and if one of them changes, the other one will change as well (and you have only one single source of truth).

When we define the store with defineStore :

const useAuthStore = defineStore('auth', {
    state: () => ({
        user: {
            login: 'alice',
        },
    }),
}),

// pinia.state.value.auth

and when we instantiate the store with the useAuthStore function and pass an object to the state, effectively what is happening is that we are getting a ref out of the state.

useAuthStore()

pinia.state.value.auth = {
    user: {
        login: 'alice',
    },
}

authStore.user = toRef(pinia.state.value.auth, 'user')

We don’t have to write authStore.user.value.login, we just read the property or write to it using .value which is called ref unwrapping.

authStore is a reactive object so any ref passed inside is going to get unwrapped.

Ref Unwrapping

When you create a reactive object, any ref passed inside at any level of that object gets automatically unwrapped, so you don’t need .value anywhere and is gonna be type-safe.

💡 You can avoid this behavior with shallowRef() and shallowReactive()

pinia.state = ref({}) // or reactive({})
pinia.state.value.auth = {
    user: {
        login: ref('alice'), // Don't do this! 🙅🏻‍♂️
    },
}
pinia.state.value.auth.user.login // alice

You should never write a ref inside a reactive object because there is no point in doing so, writing ref(’alice’) in the code above is the same as writing the string ‘alice’.

But what is interesting is not refs themselves, but refs with all their behaviors attached to them.

Composables

Composables are functions that have a stateful return. One of the common composables is useLocalStorage which is from a library called VueUse, and it gives you a ref that is going to read from and write to local storage.

pinia.state = ref({}) // or reactive({})
pinia.state.value.auth = {
    user: {
        login: useLocalStorage('pinia/user/login', 'alice'),
    },
}
pinia.state.value.auth.user.login // alice

This means that we can call that composable inside of the state function when we define a store:

import { useLocalStorage } from '@vueuse/core'

const useAuthStore = defineStore('auth', {
    state: () => ({
        user: {
            login: useLocalStorage('pinia/user/login', 'alice'),
        },
    }),
})

So if you have composables that return a writable source of truth (like a ref), you can put them inside state and they are going to get unwrapped. So the actual behavior that may be interesting for us becomes an implementation detail we don’t need to care about anymore because it is just going to work out of the box. For example useColorMode or useRouteHash.

But if you have a read-only state — which is more like a computed property — or you have a function — which is more like an action — it’s going to be a little different and we will see later how to use them.****

When does this not work?

If you are doing CSR it works fine. However, if you are doing SSR or SSG there will be some problems.

The problem is the state function is only called once the first time we instantiate the store.

In CSR, we start with an empty state, then we call the store with useAuthStore() and that’s going to instantiate the state and become reactive, easy!

In SSR, we do the same, But the problem is when the page comes back to the client on the browser, although we have the Client Side Rendering again, but on the server, the state was already executed and it was already instantiated once and we are not going to do that again on the client. That means we don’t get an empty object here and we get the object from the server.

So when we call useAuthStore, useLocalStorage is no longer called, and we no longer have that composable creating all the watchers, connecting all the event listeners to the window, it becomes just a string and probably the server is going to give us ‘alice’ because there is no local storage.

💡 Fortunately VueUse is going to make the local storage function work on the server as well.

💡 Some composables require a little bit more work if you want to make them work on SSR. For example, you have to check your current instance or check if there is a window object that you can rely on.
If you want to learn more, you can check the source code of VueUse. It’s very comfortable because in the documentation, at the very bottom of every function you see a link to the source in the Github repository.

But what do we need to make this work on SSR?

We need an extra function called hydrate() that is going to create the watchers and event listeners on the client-side. This function is called if the initial state exists at store creation.

import { useLocalStorage } from '@vueuse/core'

const useAuthStore = defineStore('auth', {
    state: () => ({
        user: {
            login: useLocalStorage('pinia/user/login', 'alice'),
        },
    }),
    hydrate(state, initialState) {
        state.user.login = useLocalStorage('pinia/user/login', 'alice')
    },
})

So that state being set by UseAuthStore is going to be replaced by the hydrate function. To recap:

On SSR:

We have an initial state:

pinia.state.value: {}

We call useAuthStore()

useAuthStore()

We have the new state:

pinia.state.value: {
    auth: { /* ... */ },
}

and that is going to be sent to the client. Then on CSR:

We start with that state

pinia.state.value: {
    auth: { /* ... */ },
}

We call useAuthStore()

useAuthStore()
// does not call state()

And then we have the hydrate function adding the little bit that we were missing from the state function again

state.user.login = useLocalStorage('pinia/user/login', 'alice')

Options Store vs Setup Store

Options store which is pretty much like options API is what we talked about so far.

Setup stores are stores that are defined with a function similar to the setup function in composition API.

const useAuthStore = defineStore('auth', () => {
    const user = useLocalStorage(...)

    return { user }
})

So in this case we don’t have multiple properties like state, getters, and actions, we just have one function and it has to create reactive objects if you want a state and return them, and it’s going to have computed for getters and functions for actions.

const useAuthStore = defineStore('auth', () => {
    const user = useLocalStorage(...)

    const isLoggedIn = computed(() => /* ... */)

    function login(user, password) { /* ... */ }
    function logout() { /* ... */ }

    return { user, login, logout, isLoggedIn }
})

In the end, you return anything you want to expose and you can keep anything you want to keep private.

Because we have just one function that defines everything, we can not just not call it! We have to call it both on the server and the client. We need to hint to Pinia that e.g. useLocalStorage shouldn’t be hydrated.

import { defineStore, skipHydrate } from 'pinia'

const useAuthStore = defineStore('auth', () => {
    const user = skipHydrate(useLocalStorage(...))

    const isLoggedIn = computed(() => /* ... */)

    function login(user, password) { /* ... */ }
    function logout() { /* ... */ }

    return { user, login, logout, isLoggedIn }
})

What happens behind the scene is that normally when we’re on the client after the server has rendered the application, the store goes through all the different properties that have been put into the initial state, takes the values from the initial state, and put them into the store state; more exactly into the ref that we return in the function: user.value = pinia.state.value.auth.user // alice

That ref created by the store is then transferred into the Pinia state so that we have one single source of truth: pinia.state.value.auth.user = user // 1 source of truth

The thing is with skipHydrate, we are skipping the first line, so the user.value = … that’s no longer happening.

We should not use skipHydrate everywhere. If we look at the useEyeDropper for example:

import { defineStore, skipHydrate } from 'pinia'
import { useEyeDropper } from '@vueuse/core'

const useColorStore = defineStore('colors', () => {
    const { isSupported, open, sRGBHex } = useEyeDropper()
    // ...
    return {
        lastColor: sRGBHex, // Ref<string>
        open, // Function
        isSupported, // Boolean
    }
})

Among these three, only the lastColor is going to become a state.

What is interesting is that we can stack these refs together. So we can pass the sRGBHex

ref to the local storage.

import { defineStore, skipHydrate } from 'pinia'
import { useEyeDropper, useLocalStorage } from '@vueuse/core'

const useColorStore = defineStore('colors', () => {
    const { isSupported, open, sRGBHex } = useEyeDropper()
    const lastColor = useLocalStorage('lastColor', sRGBHex)
    // ...
    return {
        lastColor, // Ref<string>
        open, // Function
        isSupported, // Boolean
    }
})

In this scenario, we want to use skipHydrate, because the useLocalStorage relies on what the browser is seeing and doesn’t care at all about the server response on the initial value for the lastColor. If we were using only the useEyeDropper, wouldn’t need the skipHydrate because most of the time we don’t care if we hydrate from the server-side response or not, because there is not a new value in the browser context that is interesting for us and that could get overwritten by what the server sent. But if we use the local storage then we need to make sure that the one in the browser prevails and the server one is just ignored.

So what you need is not to use skipHydrate on every single ref, just on the ones that you want to avoid setting the value from the initial state, and only on SSR of course.

Summary

Options Store

Can use basic Composition API inside state()
Can only return writable state
Use hydrate() for composables

Setup Store

Use any Composable (like in setup())
Automatically tells apart state from actions from getters
Use skipHydrate() to ignore values from the server

End of the second Talk

I hope you enjoyed this part and it can be as valuable to you as it was to me.

You can find the next talk about Histoire here

State of the Vuenion — Vue Amsterdam Conference 2022 Summary series — First Talk

Mohsen Vaziri — Sat, 18 Jun 2022 14:52:40 +0000

Welcome! Happy to see you in the first part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you.

You can read my JSWorld Conference 2022 Summary series (in four parts) here, where I summarized all the talks of the first day.

(Recurring) Introduction

A very important point

Here you can find the program of the conference:

JSWORLD Conference

State of the Vuenion

Evan You - Creator at Vue.js

The talk was an overview of the Eco System and all the new things that have been happening. On February 7th, 2022 Vue 3 has become the default version alongside the new Brand new Vuejs.org Website.

Evan explains the adoption of Vue3 by the Community, Eco System updates with the Release of Nuxt3 RC since April 21st, Vuetify 3 Beta released on May 19th, and VitePress 1.0 Alpha and the work in progress on Vite 3.0.

State of the Vuenion 2022 - Evan You

Vue 3 adoption

Currently, Vue 3 has around 800k weekly npm downloads (measured by npm downloads of @vue/runtime-core), which is +70% since the default version launch, and if we look back one year from now, that's 4x in the past year, and it counts for more than 25% of all Vue downloads and this number will probably get much higher by the end of the year.

Ecosystem updates

Nuxt 3

https://twitter.com/nuxt_js/status/1516888137716449280

Nuxt 3 is now in RC. A lot of work went into it and the core will also be working actively with Nuxt 3 to stabilize some of the final pieces such as suspense hopefully in 3.3.

Vuetify 3

To a lot of people, Nuxt and Vuetify are two of the major pieces that block them from upgrading from Vue 2 to Vue 3. But now, Vuetify 3 hit beta on May 19th too and that’s good news.

VitePress

VitePress has just released 1.0 alpha and has been used in the new Vue documentation.

They focused more on the lower-level details, but right now they are working on completely overhauling the VitePress default theme. Now it comes with dark mode and has a consistent design language with the official view documentation but with a distinction so that you know this is a VitePress site instead of the actual view documentation.

There are some small breaking changes but we are really excited because VitePress has really been proven to be a pleasure to work with when we're working on the official docs and it's super flexible and super powerful as well. We are still debating whether we should officially make it the to replace VuePress, just call the VuePress 3 or maybe it should remain a separate project but the idea is if you're looking for a Vue 3 powered static site generator VitePress will be the official recommendation.

Volar

If you're using v3 you probably know Volar which is the new recommended VSCode extension.

Starting march Vue has been sponsoring Johnson Chu who is the author of Volar, to work full time on improving it.

Johnson has been cranking out releases and bug fixes and working on refactoring the internal code base to make it more efficient and even cover more features

Vite 3.0 (WIP)

Another important piece of the new ecosystem is Vite and the team is working on version 3.

As you may know, node 12 went end of life, and that was the initial motivator for Vite 3, which drops the support for node 12.

This is not a big rewrite but it comes with a number of relatively minor breaking changes.

We always actively work with all the ecosystem partners who are building higher-level tools on top of Vite to ensure these changes comes with a reasonable amount of changes needed to upgrade.

If you’re using just the basic features of Vite you most likely won’t be affected much, also if you’re using a higher-level tool like Nuxt 3 or other frameworks on top of Vite, this upgrade path will probably be more or less transparent for you because the higher-level framework will absorb the underlying changes from Vite.

But there is still a chance of shipping some potentially breaking changes in return for big benefits:

Moving Vite itself to full ESM
SSR build defaults to ESM output

Both of these are also part of our overall efforts to make Vite an important factor in pushing the whole JS ecosystem towards pure ESM. So both of these will hopefully make the whole ecosystem transition process to ESM a bit faster.
Non-blocking dependency discovery + optimization

One of the reasons Vite can start up so fast despite having huge dependencies is that it scans your code base to look for dependencies and then pre-optimizes them.

But the initial implementation comes with two limitations:
1. The scan phase can be costly if your codebase is big.
2. Sometimes the scan phase will fail to discover dependencies because some of the code may introduce the dependency after it's been transformed by an actual plugin, so it has to wait until the app loads.
In 2.9 they introduced an improvement so that it no longer late discover dependencies and it can be non-blocking so it optimizes as it discovers them.

In 3.0 it is going to make this whole process seamless: No longer need the scan phase, no more late discovered dependencies.

Vite will discover dependencies as it serves your modules and it'll automatically wait for everything to be finalized to do one single optimization run.
Esbuild-powered dep optimization for both development server and production builds, More consistent behavior between dev/prod

For packages that are authored in commonJS, Vite used to use esbuild to process dependencies during development and rollup commonJS plugin to build the application for production, which creates inconsistency between development and production.

In 3.0 the goal is to eliminate that by using esbuild for both phases to ensure the same outcome, especially for commonJS, and it is expected to land within the next month.

Vue Core

During April and May they spent approximately a whole month on v3 core bug squash, which resulted in massive patch releases (3.2.24~26), ~70 PRs merges, and ~140 closed issues.

All of this is a preparation for other work that’s paving the road for 3.3 because we want to make sure that we get a good sense of the current outstanding bugs and make sure that we have a stable foundation to build upon for the next generation of new features.

SFC Playground

SFC Playground has been the recommended way to provide bug reproductions for v3, but there are two categories of bugs that are hard to reproduce in the SFC Playground:

Behavior inconsistency for <script setup> between production and development mode:

We’ve seen quite a few bugs in this category in the past and most of them cannot be reproduced in the SFC Playground because the SFC Playground was production by default. So we added a toggle so that you can toggle between the prod/dev mode so you can actually show us the behavior inconsistency in the case that it happens.

So, SFC Playground now supports switching between prod/dev mode for <script setup> compilation.
SSR hydration mismatch bugs:

In the past usually, you would have to create a whole repository with the full SSR setup just to show them a simple bug happening.

But now SFC Playground supports SSR reproductions. That means the whole - Full compile → render → hydrate pipeline running in the browser - pipeline happens entirely in the browser and all you need to do is just toggle a button.

Vue 2.7

Many who are stuck on Vue 2 have been asking about it and it's been delayed for various reasons. But they finally started working on it and made great progress.

Scope

Porting Composition API to become a Built-in for Vue 2 instead of using @vue/composition-api plugin.

You can directly do the same import { ref } from ‘vue’ as you would do in Vue 3 and these implementations are also more tightly integrated with Vue 2 reactivity system, so they are more efficient than the plugin version.
<script setup>

For many people script setup has been essential to use composition API, because it just makes your life so much easier.
1.

If we are porting composition API to Vue 2 then it would make sense to also push setup because it’s such an essential part of the DX.
Improved TypeScript support

They will not change the current shipped types of Vue 2, especially for Vue extend because they want to retain complete type compatibility for existing Vue 2 projects.

Instead, they are going to have separate Vue 3 types also shipped in the types but you get them when you use the new defineComponent API that's available in Vue 3. defineComponent will also allow you to define components but with the types, that are directly ported back from Vue 3, which makes it easier for you to upgrade to Vue 3 as well and it also makes it easier for Volar to support both Vue 2 and Vue 3 at the same time.

Preparation work

Vue 2 codebase is moved to TypeScript!

This is a huge shout-out to Pikax (Carlos) who spearheaded to work, made the huge pr and then also to David Walsh who helped with some cleanup, so i picked up from their work and managed to convert the whole codebase to typescript.

It is also now a pnpm monorepo, with a modernized test setup with Vitest.

Tests actually run much faster than Vue 3 now, so i need to really port the Vue 3 test to Vitest as well!

Vitest Is a new and fast unit test runner internally powered by Vite and has a fully Jest compatible interface.

Jest requires everything to have its own Jest version of it which is a painful process to configure with Vue-based setups, but if your project is running on Vite because Vitest is also powered by Vite, it’s going to be a smooth transition because Vitest can directly pick up your Vite configurations and you don’t need to configure it separately.

Current state

Composition API is already fully ported with actually named exports and full type support, but with similar restrictions from the @vue/composition-api plugin.

Vue 2.7 is currently in the alpha stage and 2.7.0-alpha.4 was released on npm under v2-alpha distribution tag, and they are focused on compatibility and stability testing.

Next steps

The next step is to port <script setup> support .

There is a lot of logic — e.g. @vue/component-compiler-utils - that is split into separate packages and should move back into the Vue 2 repo similar to how v3 does it which makes it easier to sync changes across the places and keep everything consistent.

The new single file compiler logic will be exposed as vue/compiler-sfc the same way as Vue 3. This also means when you upgrade to 2.7 and opt in to the new setup, it will be fully compatible with the existing setups. You can then just remove vue-template-compiler as a peer dependency and then upgrade to vue-loader 16+ or just directly use @vitejs/plugin-vue because the single file component compiler will have the exact same interface as Vue 3.

Our goal is so that once you upgrade to 2.7, you’ll be able to just leverage the latest versions of Vue loader or the Vite plugin Vue for both Vue 2 and Vue 3 so you no longer need to use a separate Vite plugin Vue 2 or you’re stuck on the old version of Vue loader.

It will reach Beta after <script setup> is ported and the estimated release is the end of June 2022.

Implications

2.7 will be the final minor release of Vue 2.x and there will be no new features added to Vue 2.

We will still fix bugs obviously, we'll make sure view 2.7 has a smooth upgrade path.

Vue 2 will have 18 months of LTS starting from the release of 2.7 stable. That means Vue will be End Of Life by the end of the year 2023.

We may consider offering extended support on a case-by-case basis so this will likely be a paid service. So if you’re interested, you can register interest at link.vuejs.org/xlts. So we do want to make sure that our main bandwidth is invested in Vue 3 and into the future but also understand that some of Vue 2 users may have reasons to have to stay on Vue 2 for longer than expected so we want to make sure there is a good solution for users in that scenario.

Vue 3.3

Major planned features

Stabilize Suspense
Stabilize Reactivity Transform
SSR Improvements
- Lazy / Conditional hydration for async components
- Improved SSR mismatch warnings
Support imported types in <script setup> type-based-macros

Work on this version starts after the 2.7 stable release and hopefully get it ready by Q3 2022.

Experimental new compilation strategy

This is a truly experimental early exploration phase of the feature! So it even may not land!

The majority of users use Vue through the template and most of us in our day-to-day work interact with Vue through the single-file component format and this is a source format.

Vue as a framework has the opportunity to compile the file into vanilla JavaScript and CSS, and this step allows Vue to be a super compiler-oriented framework.

This new compilation strategy is inspired by solid.js. Instead of compiling templates into Virtual DOM render functions, it compiles them into imperative DOM initialization and reactive binding setup code.

Imagine this component:

// <script setup>
import { ref } from 'vue'
const count = ref(0)

<template>
    <div>
        <button
            :id="`foo-${count}`"
            :class="{ red: count % 2 }"
            @click="count++"
        >{{ count }}</button>
    </div>
</template>

This button contains several bindings.

The output code will look something like this:

import { ref, effect } from 'vue'
import {template, on, setClass, setAttr, setText } from 'vue/vapor'

const t0 = template(`<div><button>`)

export default () => {
    const count = ref(0)

    let div = t0()
    let button = div.firstChild
    let _button_class, _button_id, _button_text
    effect(() => {
        setClass(button, _button_class, (_button_class = {red: count.value % 2 }))
        setAttr(button, 'id', _button_id, (_button_id = `foo-${count.value}`))
        setText(button, _button_text, count.value)
    })
    on(button, 'click', () => count.value++)
    return div
}

The general idea is instead of generating a virtual DOM representation of the tree first and then walking it to initialize the actual DOM, we will analyze the base HTML structure of the template during compilation time and stringify it into the plain HTML without those bindings, then we initialize them directly using a template clone node which is faster than initializing all these nodes individually and stitch them together. Then we generate imperative code that directly locates the nodes that need bindings. Then we generate code that set up the effect directly by setting up reactive updates for class, attribute bindings, and inner text.

Some of the benefits:

Better v-for performance even without v-memo
Significantly lower memory usage
Significantly lighter base runtime size (if fully opt-in)
Potentially lighter component abstraction cost

Adoption Strategy:

Opt-in at the component level
- Embed in the existing Vue 3 virtual DOM-based app
- Fully compatible with existing libraries
Opt-in at the app level
- Entirely drops Virtual DOM runtime
- Cannot use Virtual DOM-based components
- Suitable for extremely performance-sensitive use cases

This doesn't really change the development aspect of it. The template syntax and the way you write your components will remain exactly the same. This is purely just how the compiler handles the output.

End of the first Talk

I hope you enjoyed this part and it can be as valuable to you as it was to me.

You can find the next Talk about Pinia here.

JSWorld Conference 2022 Summary - 1 June 2022 - Part IV

Mohsen Vaziri — Sun, 12 Jun 2022 14:50:47 +0000

Welcome! Happy to see you in the last part of my JSWorld Conference 2022 summary series, in which I share a summary of all the talks with you.

You can read the first part here, the second part here, and the third part here, where I summarized the first ten talks of the first day that were about:

First Talk: Colin talks about the state of Deno in 2022, compares Deno with Node.js, and gives us a taste of working with Deno.
Second Talk: Negar talks about how browsers render CSS, and then introduces us to CSS Houdini, which is a set of low-level APIs that exposes parts of the CSS engine.
Third Talk: Dexter goes over his “perfect” stack, using graphQL, SvelteKit, Docker, and Github.
Fourth Talk: Gift begins with how servers have been managed in the past, continues with how it got better over time with serverless, and what can we expect with Cloudflare Edge services.
Fifth Talk: Stacy talks about creating a personal brand (blog), using Angular, TypeScript, and static web apps in Azure, and eating the elephant one bite at a time.
Sixth Talk: Sendil’s talk is about performance and why it matters. He gives some great tips to improve the performance of your app.
Seventh Talk: Natalia talks about a new provisioning experience in Azure Developer CLI which goes Public preview at end of June.
Eighth Talk: Max shares lessons he learned after dealing for 4 years with Micro-Frontend at DAZN.
Ninth Talk: Eleftheria talks about UX and UI from the perspective of both users and developers and why you should care as a developer.
Tenth Talk: Jemima takes a look at the humble beginnings of JS and how it exploded into the chimaera of frameworks and libraries that we have today

(Recurring) Introduction

Since I’m trying to include all the important points, I have to split each day into three, four, or maybe five parts to prevent the article from getting too long.

A very important point

Last but not least, I don’t dig into every technical detail or live codings in some of the speeches. But if you are interested and need more information, let me know and I’ll try to write a more detailed article separately. Also, don’t forget to check out their Twitter/Linkedin.

Here you can find the program of the conference:

JSWORLD Conference

So, let’s start with the last part of the first day.

Table of Content

Storybook embedding: Gert Hengeveld - Principal software engineer at Chromatic
The hurdles of releasing and maintaining a mobile app: Wim Selles - Lead solution architect at Saucelabs
SDKs, Relations, love & thunder: Samuel Snopko - head of developer relations at Storyblok

TL;DR

Eleventh Talk: Gert Talk about upcoming Storybook 6.4, 6.5, and 7.0.
Twelfth Talk: The problems or difficulties that must be overcome to allow our app to move freely to the phones of our end users and give ourselves the necessities to keep this app running.
Last Talk: This talk is mostly about experience. What is the best developer experience? Are the answers in SDKs, Relations, Love, or Thunder?

Storybook embedding

Gert Hengeveld - Principal software engineer at Chromatic

Storybook 6.4 will bring interaction testing to Storybook, enabled by CSF 3. In 6.5, we're going all-in on accessibility testing and will enable addon authors to provide additional testing methods. With Storybook 7.0, stories and their components become the source of truth for the entire UI development lifecycle.

Do you remember working like this?

You working on a web app and in order to do that you have to first Spin up the whole platform, Recompile with every change you make, when designers review your stuff 2 weeks later they always find something that you have to tweak or change, and that means you have to rework stuff that’s already shipped.

But now days Modern UIs are ~~built~~ assembled from components because for these reasons:

Efficiency: Reuse existing components
Speed: Parallelize development across people and teams
Quality: Verify that UIs work in different scenarios
Maintenance: Pinpoint bugs at the component level.

It’s easier to work on isolated components and not have to consider the entire context of a running app. This is where Storybook comes in.

Storybook

Storybook is a frontend tool for building UI components faster and easier in isolation. It gives you a catalog of all components in different states, and you can document your component library.

The general concept in Storybook is a story:

import Badge from './Badge'

// Metadata
export default {
    component: Badge,
    args: {
        label: 'Hello world'
    },
}

// First Story
export const Small = {
    args: {
        size: 'small',
    },
}

// Second Story
export const Large = {
    args: {
        size: 'large',
    },
}

Storybook is framework agnostic, so you can choose your favorite framework.

Component variants aka “stories”

What would you define a story for?

Different states:

Loading
Disabled
In progress
Error
Accepted / denied
Expanded / collapsed

Edge cases:

Long or short text
Big or small images
Extreme numbers
Missing data
Special characters

Context:

Signed in / signed out
Language / location
Color preference
A/B test
Offline

And it gets more complicated because there are countless combinations of these situations.

UI Development is teamwork

Sharing is essential in the workflow because:

👩‍🎨 Designers want to make corrections in the right time
🧐 QA should be part of the development cycle and not after it’s already deployed
🎯 Product owners want to check deliverables
🚀 Everyone wants to be aware of new features

and in Storybook, there are so many features that allow you to share your stories and your components with other people.

Publish to the web

Storybook provides npm run build-storybook command which gives you a statically exported version of your story and you can upload it on Github pages, netlify, or on chromatic, and then you can share a link to that with for example your stakeholders so that they can play around with them and verify that is what they had in mind.

Chromatic is a service on top of Storybook. You can upload your stories to chromatic and it gives you a library of your components.

Design with Figma

There is a Storybook Connect for Figma, in which you can Inspect stories in Figma, Link components to stories, Play with interactive stories in Figma, compare the design with implementation, or inspect the sizing of the component to verify whether or not that is developed pixel perfect or you can use accessibility add-on in Storybook to verify what the component looks like when you have blurred vision or you are color blind.

Embed anywhere with oEmbed

You can simply Paste a Storybook URL in Medium or Notion. It Automatically converts them to iframe embed and Dynamically adjusts the height of that iframe.

Build your own docs site

It’s more convenient to extract the Docs from Storybook and put them into a custom build website, and that’s Storybook Docs 2.0 (alpha) which allows you to take those MDX pages that you write in Storybook and throw them into your custom Website.

Testing UI code is really hard

Components break in unexpected places, Testing all scenarios is a lot of work, and Reproducing a specific state is tricky. On the other hand, customers have high expectations these days because they are used to the way that Apple builds their software which always works the same way.

Testing is crucial if you are building software that needs to be reliable and always works.

Interactive stories

It was a top request from the community and what it allows you to do is to Define a play function on your story, which is a function that gets executed as soon as stories run on your browser and you can use that to build Stories for complex components & pages.

You can now Simulate user behavior in the browser. That is Powered by Testing Library and they didn’t reinvent the wheel.

import { whithin, userEvent } from '@storybook/testing-library'
import { SearchForm } from './SearchForm'

export default { component: SearchForm }

export const Submitted = {
    // Play function
    play: async ({ canvasElement }) => {
        const canvas = within(canvasElement);

        // Simulated events 
        await userEvent.type(canvas.getByRole('searchbox'), 'query');
        await userEvent.click(canvas.getByRole('button', { name: 'Search' }));
    }
}

This is familiar to people written end-to-end tests and integration tests in the past with other tools, but it’s now possible directly in your Storybook as you are working on your stories.

Interaction testing

This gives you Assertions powered by Jest and gives you an In-browser debugger. They also built a Node.js test runner so that we can run all of those tests in one go in a headless browser. And when something went wrong, Storybook can give you a URL which you can click, and it opens up your Storybook exactly at that state and then you can check and figure out what was wrong.

import { expect } from '@storybook/jest'
import { whithin, userEvent } from '@storybook/testing-library'
import { SearchForm } from './SearchForm'

export default { component: SearchForm }

export const Submitted = {
    // Play function
    play: async ({ canvasElement }) => {
        const canvas = within(canvasElement);

        // Simulated events 
        await userEvent.type(canvas.getByRole('searchbox'), 'query');
        await userEvent.click(canvas.getByRole('button', { name: 'Search' }));

        // Assertion | Automatic spy on actions
        await expect(args.onSubmit).toHaveBeenCalledWith('query');
    }
}

All of this is possible in Storybook 6.5.

The hurdles of releasing and maintaining a mobile app

Wim Selles - Lead solution architect at saucelabs

Building a mobile app nowadays is pretty easy. If you have some JavaScript/HTML/CSS skills you can use technologies like Ionic, NativeScript, or React Native to release your first app to the App Stores. Building your app might seem easy but releasing and maintaining your app when it’s in production can be difficult. During this talk, Wim will walk us through most of the hurdles of releasing and maintaining a Mobile app in production.

According to Wim himself, the actual title that he chose was “The problems or difficulties that must be overcome to allow our app to move freely to the phones of our end users and give ourselves the necessities to keep this app running.” but it was too long!

Imagine a situation where you want to build your own app and release it in stores, and to do so, you need to start with an idea.

Then you need some skills. You are maybe a master in HTML, CSS, and JavaScript/TypeScript, but to develop an app and publish it in app stores you need to have some ios skills (Swift) and android skills (Java/Kotlin). But maybe it’s easier for Web developers to work with tools like React Native, NativeScript, and Ionic.

So, now grab your Coffee and your mac - if you wanna develop something for iOS you need to have a mac - and open up your favorite IDE!

Based on tools of your choice like React Native or the other tools mentioned, Start reading Docs, and you’ll see that you need some extra tools. For example, you need Xcode for iOS or Android Studio for android.

Depending on the type of framework that you selected, you might have a challenge, and the only thing you need to do is use your best friend, Google.

A couple of days later, when you built your first screens, you tested your app manually on emulators, you maybe want to test it on your real device. On Android, you need to do some signings and when you got your key, you can push an android application to your android phone. But when you start with apple, the first thing you need to do is use your credit card! You need to have a membership and there are two types of them. There is a free one but you can not push your app into the store. There is a default option that costs you 99$ but then you have the option to push your application to your own phone but also in the end into the app store so that you make some money from your app, but remember, They will still take 30%.

There is one thing that you need to be aware of. If you start with the developer certificate, there is a limitation on the number of friends that you can invite to push the application to their phones, especially iOS phones. Apple can also make it a little bit easier for you as long as you pay 299$ and you will get the enterprise certificate.

Building your app — which is better, cooler, and faster with m1 macs — and deploying it is so slow in comparison to the web.

In addition to that, you need to start testing your app with unit tests and UI tests. But when you start to run your test cases and again compare that to what you are used to, you’ll see that it’s much slower.

Now, maybe it’s time to push your app to the app store. Android would be the easier one, but for that, we also need to use our credit card and pay 25$ to be able to push our app into the store. But when you are then looking to the apple or the android app stores, you’ll see that you need to wait for a review, which will take between 1 and 7 days. The other problem is, that after a couple of days you may receive an email that tells you: “Your application has been rejected” maybe because you forgot to provide credentials or another reason. Even after acceptance it can take up to 1 day before the app or your update is in the stores, and it will be the same for every release!

After a while, and after those hard days and so much waiting, you’ll get your first review from a user, a 1.0 Star review!

Why this story?

These are the things that could happen if you compare this with your web app experiences.

Let's take a look at Software development cycles and compare each step for web applications and hybrid/native applications.

Why is it hard you may ask? If we’re talking about mobile, first thing is that we could have 20 different versions out there on the phones of our end-users, especially if we do not implement a proper way to do some version management, and unlike with web apps, a mobile native app can’t be reverted/removed from a user’s phone. This can result in having more business impact when a Native app contains bugs.

Secondly Mobile is remote by default, meaning an issue with your app is always happening somewhere else, not at your desk or your screen. it happens in the hand of a person whom you cannot easily communicate with to understand why and how the issue happened.

Last but not least, fragmented market. There is a massive variety of android and ios devices across hardware and software configurations, different levels of os versions, and locals. and this is before we get to the mobile device itself that needs reception, wifi, battery, and more.

If we go back to those pain points, the first thing that we should be aware of is Deploy. If we want to release something quickly, we are limited here and can not roll back. You can not fix something fast in production. it will take time and that time will annoy your customer.

Also, you need to focus on getting the right feedback from the devices. If you know what happens and what your customers doing, it could help you to replicate what was causing that issue.

Next, do not forget to test properly. Do not test only the web content in the case of hybrid. Your user is using his fingers. he is not using JavaScript executors to scroll something into the view, no, we are all swiping through our apps. test that, manually or automated.

And last but not least in all three parts of this process the debugging information is important. If you already have the right debugger in your test build, you might be able to retrieve information that could be valuable for you before releasing it to the stores.

SDKs, Relations, love & thunder

Samuel Snopko - head of developer relations at Storyblok

The time flies fast. We spent more than the last two years in the online bubble. Our work and life merged slowly together. We don't commute, and we are so much more effective! But are we? Did we change? Let's stop for a second. Let's put our heads together. Let's question our creativity and productivity. What is the best developer experience? Are the answers in SDKs, Relations, Love, or Thunder?

SDKs

This talk is mostly about the experience, and about having a good developer experience to enhance the final user experience.

If you work in an agency, stakeholders, clients, salespersons, and managers are asking not to create the best backend experience, but to create something for customers that can quickly use, something powerful which will make them better sales, better search optimization ratings, better accessibility and which will look cool. To do that, we as developers need one thing, and that’s time.

We spend most of our time usually on the monolithic CMSs and building and shaping them to the state that we can achieve some cool new frontend stuff because they are not ready. SDKs are here to save you time, and to use them to build a better user experience at the end.

With better SDKs → you as a developer have more time → to build a better app.

(Developer) Relations

Developer relations, which i’m currently head of, is not about developers, it’s about building the relations between all the people.

You need relations because you can not scale your knowledge in every aspect of something. On the other hand, relations are like a guide on your journey and will help you to build better products. Those relations will shape your future of you.

I can backtrace my relations and go to my high school.
I had a math teacher who lead me to the point that I started coding.
My first job as a frontend developer where I met someone and he opened for me the word of CSS and HTML and he showed me some magazines and books and conferences where I got all the inspiration. where then I made some other relations with others who show me the beauty of HTML and CSS. I really loved what I was doing and that’s also the reason why I headed to Vue and then Nuxt.
And then after the next, I met the CEO of Storyblok, and that's the reason why I’m here as head of developer relations and speaking right now.
If you think about it, it's only one person and one relation that I was building that could change the directions that I was going.

So relations are important because your success depends on them, and not only it can help you to succeed, it can save you when you have some problems, and not only the people from your bubble or your team but also the people from other teams, from the community and ambassadors.

When we have different views on the same topic, we can inspire each other.

We all need to practice it and it takes time.

Creativity

Those relations will also inspire you and give you the creative boost, the boost that we can not get if we are sitting alone in the room and just coding all the time.

On the other hand, you need to get bored and then get rest to let the creativity take over.

Next time when you face a bug, don’t drink the 20th cup of coffee and try to work 12 hours on it, just do something else or take a rest or go for a walk so that your brain has time to think and you will come up with the solution more easily.

Love

Love what you do, your community, and your time. if you don’t like it it doesn’t matter how much money you make.

Thunder

Struggles are good. We have different opinions, but the point is don’t take them personally.

There will be always some decisions that you don’t like, and there will be also some decisions that the community doesn’t like. But it’s not personal, it’s not about us. It’s because we all want to move to the next level and make it better.

Last but not least, we all need to learn to say sorry.

End of Part IV

This is the end of my JSWorld Conference summary series. Thank you for coming so far, I hope you enjoyed the journey and it can be as valuable to you as it was to me.

You can read the previous parts here:

Over the next few days, I’ll do the same for Vue Amsterdam Conference which was held on 2. and 3. June right after JSWorld Conference. Stay tuned…

DEV Community: Mohsen Vaziri

Updating My Mac Window Shortcuts Strategy for Optimal Workflow

The Challenge of macOS Shortcut Reliability

Introducing Rectangle: Efficiency and Customization

Seamless Setup, Enhanced Productivity

The Power of Optimized Window Management

Share Your Productivity Tips!

Developer experience with nuxt 3 — Vue Amsterdam Conference 2022 — Tenth Talk

Intro

Typescript in Nuxt 3

Documentation at Fingertips

Reducing Boilerplate in Nuxt 3

Auto-imported Functions

Minimal Initial Setup

Smart Data Fetching

Server Functions

Conclusion

Full Stack Development With Nuxt 3 and Nitro — Vue Amsterdam Conference 2022 — Ninth Talk

Intro

Nuxt 2 Server Middleware

Server Middleware HMR in Nuxt 2

Nuxt 2 with Express

API Calls in Nuxt 2

Static Generation in nuxt 2

Nuxt 2 server deployment

Nitro

Server Routes in Nuxt 3

API Calls in Nuxt 3

Server HMR in Nuxt 3

Pluggable KV Storage

Nuxt 3 server deployment

Static generation in Nuxt 3

End of the ninth Talk

The Nuxt Web — Vue Amsterdam Conference 2022 Summary series — Eighth Talk

(Recurring) Introduction

A very important point

The Nuxt Web

A comparison between Nuxt 2 and Nuxt 3

Edge Side Rendering

Content V2

Nuxt 2.X

Nuxt 3.0

End of the Eighth Talk

Animating with Vue — Vue Amsterdam Conference 2022 Summary series — Seventh Talk

(Recurring) Introduction

A very important point

Animating with Vue

90s Websites

Why animate?

Vue <Transition />

Vue <TransitionGroup />

JavaScript Hooks

GreenSock GSAP

Vue animation counter

Page Transition

SVG

End of the seventh Talk

It’s a (Testing) trap! — Vue Amsterdam Conference 2022 Summary series — Sixth Talk

(Recurring) Introduction

A very important point

It’s a (Testing) trap! Common testing pitfalls and how to solve them

Pain points

Simple tests

Traps

E2E Testing

End of the sixth Talk

Reusable Widgets that work! — Vue Amsterdam Conference 2022 Summary series — Fifth Talk

(Recurring) Introduction

A very important point

Reusable Widgets that work!

Modal

Modals Design Considerations

Modals Opening Focus Interaction

Modals Closing Focus Interaction

Modals Keyboard Interaction

Modals Technical Considerations

Toggle Buttons

Buttons

Toggle Buttons Design Considerations

Toggle Buttons Focus Handling

Vue `<Transition />`

Vue `<TransitionGroup />`