DEV Community: Lukas Borawski

Faro.js 🌴🏖️☀️

Lukas Borawski — Fri, 09 Feb 2024 18:25:10 +0000

Some months ago, my family and I embarked on a new adventure and set sail for the stunning landscapes of Portugal. Yes, we’ve made this place of vibrant culture, breathtaking nature, and delicious cuisine our home. 🏡☀️

However, I find myself missing the thrilling interactions and the spirit of the tech community that I enjoyed back in Poland. The lively tech events and the learning opportunities from meetups — both as an attendee and as an organizer — were not just about technology but also about connecting with people and sharing knowledge.

Feeling this void, I have decided to bring a piece of that community spirit to my new home by starting local meetups focused on front-end technologies (and not only). Especially since there is a lack of such here in the Algarve area. So my goal would be to create a space where tech enthusiasts in Portugal and visitors alike can come together to learn, share, and grow. It’s about recreating that sense of community and collaborative innovation here, where anyone interested in front-end development can find new friendships and inspiration… and maybe even some new business opportunities.

Now, “meetups” might sound ambitious at first, hence my initial step is to create a community. To achieve this, I plan to leverage the Meetup platform as a foundational tool to connect with like-minded individuals. Once we have established a core group of enthusiasts, I hope to organize events. The aim is to gradually build a robust series of events, focusing on modern front-end technologies and beyond. Imagine this: beach, palm trees, sunshine, beer, pizza, and tech discussions 🤩.

So hear me out — while this opportunity might not be a perfect fit for you personally, perhaps someone in your circle — friends, colleagues, or fellow community members — would find it intriguing and interesting. So, I kindly ask for your support in sharing this post and the Meetup group link. A big thank you in advance for any shares, and please, stay tuned for more updates!

Meetup Group: www.meetup.com/farojs
Twitter/X Profile: www.twitter.com/faro_js

Vue Use State Effect - Your small and fast alternative to Vuex and Pinia.

Lukas Borawski — Mon, 23 May 2022 13:10:35 +0000

We all know Vuex. It is a great addition to the Vue ecosystem from the very beginning. It helped to manage the state in dozens of projects. It is very versatile and extensive. However, for small applications, it might be too big and complex, and the general flow too tangled and complicated. Back in the day, there were no good alternatives tho. So we used to it, every time when there was a need to share some data across the application we were using Vuex.

With Vue 3 and the new Composition API, our eyes shone. Because of its awesome reactivity system for many of us, it was obvious that now, we can share small states from composables in regular components. We started to doubt that maybe Vuex is not needed anymore. Despite this Vuex in version 4 was adopted to the new APIs and now with Vue 3 you can still use it and enjoy the old good Vue state management.

However, many developers decided to go with the new path and use composables to share small and reactive states in their projects. Turns out that rather this approach is quite convenient and comfortable it might cause - because of globally exposed data objects - some security issues, and memory leaks with/on SSR as well.

Because of these and willingness of creating something less complicated as Vuex, without mutations, commits, and data dispatching the idea of building Pinia was born. So Pinia is a new, built-in mind of Vue 3 (Composition API) ecosystem state management. It provides a quite simple API that might be similar in reception to other state-based patterned solutions out there. Pinia is able to handle state management in your application painless, it delivers a versatile and straightforward flow of data traveling/sharing in your project. Just check it … and read further.

Although Pinia is great and easy it adds a new abstraction to your development process - new stores, methods, flows. And if you're building a small application it might be (still) too mature and too complex for it. It's also a custom solution that is handling various scenarios and that weights.

So because I'm a huge fan of the Composition API and getting rid of this Vuex complexity I was also unhappy to deal with this approach of leaving the composable-based small states concept. And on top of that idea of this library (composable) came up.

In short 😏 - Vue Composition API provides something called EffectScope which is able to record all the effects created during the current instance existence. For example, you'll find there computed properties. What's more important this Effect Scope can be shared across the application area. Then, accordingly, to the original RFC of this feature, we can attach any additional data to it.

And that's how and why the vue-use-state-effect library was created. With it, your composable in any shape that you want to share can be wrapped and joined. Used in the other components afterward. Finally, without any additional abstraction, you can use it to create sharable states/stores inside your application - handling them via composables with your own custom logic. Still, kept the native-like flow of the development. Awesome right? In the end, to avoid data stacking you have destroy utility that you can use along with it anytime you want. So composable that is using Effect Scope to create state - Vue Use State Effect. ✨

Now, let's check how it works with some real-life example.

First, you need to - of course - install it then we can create our first data-related composable with some state and the function that will update it.

/* composables/useSharedState.ts */

import { ref } from 'vue'

const sharedState = () => {
  const state = ref({
    test: '🚀 Initial state value.',
  })
  const updateState = () => {
    state.value = {
      test: '🌝 Updated state value.',
    }
  }
  return {
    state,
    updateState,
  }
}

OK, we can import the vue-use-state-effect and use it with our newly created composable. Like that ... Please notice that this is the same file/component, I’m just repeating it (snippet) to show the next step of importing the composable.

/* composables/useSharedState.ts */

import { useStateEffect } from 'vue-use-state-effect'

/* you composable logic, up there  */

export const useSharedState: any = useStateEffect(sharedState, {
  name: 'sharedState',
  debug: true,
  destroy: false,
})

Fantastic. We’ve just created the shared composable that we can use along with our components. Let’s create one and check how we can use it.

<!-- Home Page | home.vue -->

<template>
  <div>{{ test }}</div>
  <button @click="updateState">update state</button>
</template>

<script setup lang="ts">
import { computed } from 'vue'
import { useSharedState } from '@composables/useSharedState'

const {
  sharedState: { state, updateState },
} = useSharedState()

const test = computed(() => state.value.test) // '🚀 Initial state value.',
</script>

What you can see here is that we’ve gotten the state/store data from the composable. The parent object key is defined on top of the name that we provided within the composable establishing. We’re using computed property to create the reactive one to reflect it in the template. Additionally, we’ve passed the update method with the help which we can use along with the button to update the state from the UI. Now we can create a new page to see/use saved or updated state. Like that.

<!-- New Page | new.vue -->

<template>
  <div>{{ test }}</div>
</template>

<script setup lang="ts">
import { ref } from 'vue'
import { useSharedState } from '@composables/useSharedState'

const {
  sharedState: { state },
} = useSharedState()
const test = ref(state.value.test) // '🌝 Updated state value.',
</script>

And we have it. That’s it. You can now go and use your shared state (composable) across your application. In the end, if you would like to clear this data, to not stock it much inside the application lifecycle you can use destroy option to handle it. Quick tip here tho — because of asynchronously rendered components (especially in Nuxt), if you need it, you can retrieve the reconstructed state with onMounted hook. Like this.

<!-- New Page | new.vue -->

<script setup lang="ts">
import { onMounted } from 'vue'

const test = ref('')

onMounted(() => {
  const {
    sharedState: { state },
  } = useSharedState()
  test.value = state.value.test
})
</script>

Simple as it can be. Native as it can be. Nothing more. Not so sophisticated, not so complicated, but for the majority of the small Vue apps it might be the best, fastest, and most convenient solution. Just give it a try, now or with your next project.

Drawbacks? Yeah. It’s simple so you will not get the structural shape and flow like with Pinia or even Vuex. You’ll not check it within the devtools as well, but you have debug mode which might be enough replacement (I hope). Probably you’ll find more but it’s not for everybody and not for each project. It’s the meter of defining a balance. 😋

You can download it from the npm registry. You can find its repository on GitHub. And with the StackBlitz Nuxt 3 demo you can try it out in action, without even installing it. Want to help or contribute, please create some new GitHub Issue for it. Thanks for the support in advance.

Wanna support? Buy me a coffee or sponsor me via GitHub.

Cheers and Enjoy.

Dealing with TypeScript configs for the mono-repo application.

Lukas Borawski — Fri, 22 Oct 2021 09:02:26 +0000

Let’s say that you’re building a mono-repo app. The structure is dividing some services like fronted, backend and docs. This application and the structure can be handled by Lerna — a tool for managing JavaScript projects with multiple packages. What Lerna does (as a part of many features) is the ability to resolve local and global package.json files to use one and correct packages list and representation of dependencies. This means that you can use global packages in all of your services but if you use some package in the frontend app you don’t need to install it for the backend one. And with the Lerna boostrap feature, you can install and manage dependencies for all of your services with one command and process.

OK, take a look at the repo structure.

|root
|--- frontend
|--- backend
|--- docs

Now, let’s say that you want to set some global TypeScript config but use it just for the one service. For example, you’re building some frontend app with TypeScript but the backend one is in plain JavaScript. However, in the future, you might want to use TS for the backend as well. What can we do?

Put your TypeScript config (tsconfig.json) into the root folder. Then define rootDir and place there the frontend app folder name, like this.

{
  "compilerOptions": {
    "rootDir": "frontend",
    "types": [
      "@types",
    ]
  },
}

Now. For sure you’ll need some additional types definitions. Usually, you can define them by adding package names into the types object. Here is the moment when you will get some problems. As the TypeScript config uses the root directory for your frontend services there’s no notation that your types are installed globally and TypeScript is looking for them in your frontend services node_modules.

TS2688: Cannot find type definition file for '@types'. The file is in the program because: Entry point of type library '@types' specified in compilerOptions.

How to deal with this issue? It’s super simple. Just define — in your tsconfig.json file — the typeRoots property and pass there your local node_modules path. You can set it also for the aliases. Like that.

{
  "compilerOptions": {
    "rootDir": "frontend"
    "paths": {
      "~/*": ["./frontend/*"]
    },
    "typeRoots": ["./frontend/node_modules/"],
    "types": [
      "@types",
    ]
    "exclude": ["./*.config.js"]  },
}

One thing, worth mentioning here is that TypeScript probably will look for some globally defined configs like commitlint or stylelint. As they’re in most cases .js files you can exclude them in the tsconfig.json file.

Finally, you need to define some dummy tsconfig.json for your services. So to do that create it and add this simple configuration — in the frontend folder/service.

{
  "extends": "../tsconfig.json",
  "compilerOptions": {}
}

You can also create one TypeScript config file for all of your services and use it across the whole mono-repo. This way you can feel confident that your whole codebase follows one standard.

And that’s it. Simple and very helpful. Enjoy.

Tailwind class madness. Never again?!

Lukas Borawski — Wed, 29 Sep 2021 09:17:29 +0000

A couple of days ago my sister asked for a favor. She wanted to create a small contact/promo page for the kindergartner’s that she is running. Nothing special and fancy, just a regular landing page with some event graphics and the contact form. Weekend job.

Well, sounds like a very easy and fast task to do and help my sibling in need. First thought was Vue, the next one was Tailwind. After some further thinking turns out this is a great opportunity to finally use Vite … with the real-life project.

So I do have my tools for UI/frontend part, what's left was the form handler and app deployment, serving platform. And as I can get all of this from Netlify … the decision was made.

Installing and running the Vite was super easy. The performance of this tool is incredible, it's extremely fast and powerful. Turns out that I can play a bit with the script setup concept as well. It "forces" kinda new writing approach but eventually it's very convenient and aligned with the Composition API flow.

OK, my development environment is ready now I just need to start creating actual components. As I'm using Tailwind I need to set some initial config with my default style values. You know, font sizes, colors, and other stuff. Fine.

Create containers with some grid classes, great, nothing special here. Time for some global, reusable components like buttons. And here we go... 🤕 Tailwind utility classes madness. To define a simple button I had to use like a' twenty-plus classes. Flashback - every time when I'm using Tailwind I'm dealing with these super long line markups - terrible. Nightmare right?

This must be ended! At least for my Vue apps. 😃

I know, I can use apply handler and define all the classes in the style section. But this is not solving the problem at all. This is also not so global, "reuse" friendly. So what I need is to define some global variants for my global components like buttons, inputs, blocks. But how to use them with Tailwind and Vue? Easy, as long I can bind my styles inside the Vue templates I can define my styles as an object and use them everywhere. And of course, while I'm using Composition API I can create some fancy composable. That is how the vue-use-variant package was created.

The main goal was to create the globally accessible object or objects with some style definitions, components variants. Let's do that. For the banner.

import { ref } from 'vue'

export const buttonVariants = {
  button: 'font-bold rounded border-0 bg-blue hover:opacity-80',
  buttonPrimary: 'p-4 text-lg',
  buttonSecondary: 'p-2 text-md',
}

export const buttonVariantsRef = ref(buttonVariants)

Great. 👍 We have some overall button styles and some variant definitions — for primary and secondary. Typical one. 😅

OK, now the composable and how I’m using it with the above variants.

<template>
  <button :class="buttonVariant" type="button" />
</template>

<script lang="ts">
import { defineComponent, ref } from 'vue'
import { buttonVariants, buttonVariantsRef } from './variants.ts'
import { useVariant, UseVariant } from 'vue-use-variant'
export default defineComponent({
  name: 'Button',
  setup() {
    const { defineVariant } = useVariant() as UseVariant
    return {
      buttonVariant: defineVariant(
        ref({
          button: true,
          buttonPrimary: true,
        }),
        buttonVariantsRef,
      ),
    }
  },
})
</script>

Your final result will look something like this.

font-bold rounded border-0 bg-blue hover:opacity-80 p-4 text-lg

That’s it. Awesome right? It’s clean, readable, convenient, fast, and globally available. The class madness has been ended. 🎉 You can use it with Ref objects, with props, and straight away inside the component. Finally, you can use it with any other framework. It was built for the Vue ecosystem but it’s not stopping you to use it with React if you want.

Create your variants for all the reusable components and use them across your application. This way you’ll always get one source of truth and your UI components will always come with the same shape and visual representation.

Find the technical specification and some guidelines here. You can install it from npm or yarn. You can play with the very basic demo provided inside the repository. It was created with Vite, so that might be the additional stimulant. And of course, any suggestions, issue reports are very warmly welcome.

Thanks for reading. Enjoy! ✋

Node.js app continuous deployment with AWS, PM2, and Github Actions.

Lukas Borawski — Tue, 08 Dec 2020 14:51:39 +0000

So you have this node.js app. It's not static, it's in Vue, React, Angular, whatever... It's ready and steady to publish and deploy. But where, how? In this article, I'll cover some steps on how to automatically deploy your app and keep it delivered continually.

Here is a quick summary:

Runing EC2 instance on AWS
PM2 setup
Deployment script
GitHub Action

Digression: If your app does not have any backend-related functionalities I'm almost sure that it can be built with static mode. So for that, you can use ie Netlify and skip this thread. 🙃

Static apps generate a smaller carbon footprint.

OK, let's back to the main topic.

1. Runing EC2 instance on AWS.

For that case, we will use EC2 on AWS. If you're not familiar with the installation process all you need to do is:

Don't worry, it's super simple and we don't need to move through. Just watch the guidelines and you'll be fine. However, maybe for you, the Digital Ocean Droplet will be the best solution; or any other. Use what you like the most, we just need a regular Ubuntu instance. However, note that paths in the below configs are AWS specific.

Now, log in to your newly created instance.

ssh -i key.pem ubuntu@12.345.67.891

For sure - for the new machine - you’ll need to configure the webserver, most likely Nginx. More about this you can find here or just use this predefined one.

$ sudo vim /etc/nginx/conf.d/nodejs-basic.conf

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {
    listen 80;

    server_name your-server-name.com;

    location / {
         proxy_pass http://localhost:3000;
         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection 'upgrade';
         proxy_set_header Host $host;
         proxy_cache_bypass $http_upgrade;
    }
}

2. PM2 setup.

PM2, what the heck? PM2 is a daemon process manager that will help you manage and keep your application online 24/7. So it will help keep our app live and running. Let’s install it.

npm install pm2 -g

Then, in your home folder create a simple configuration file (eccosystem.json).

{
  "apps" : [
     {
        "name"          : "App Name",
        "script"        : "npm",
        "args"          : "run start",
        "watch"         : false,
        "cwd"           : "/home/ubuntu/app-name/",
        "out_file"      : "/home/ubuntu/hooker.out.log",
        "err_file"      : "/home/ubuntu/hooker.err.log",
        "merge_logs"    : true,
        "instances"     : 1,
        "exec_mode"     : "cluster"
     }
  ]
}

3. Deployment script.

Therefore we need some simple bash script (deploy.sh) that will run the app build and invoke PM2 process after that.

echo "Kill all the running PM2 actions"
sudo pm2 kill

echo "Jump to app folder"
cd /home/ubuntu/app-name

echo "Update app from Git"
git pull

echo "Install app dependencies"
sudo rm -rf node_modules package-lock.json
sudo npm install

echo "Build your app"
sudo npm run build

echo "Run new PM2 action"
sudo cp /home/ubuntu/ecosystem.json ecosystem.json
sudo pm2 start ecosystem.json

You can test it by using sh deploy.sh command.

Great, we're almost there. Server configuration is relatively simple and you can make it almost effortless. If your daily environment is MacOS or Linux it will be very straightforward.

Now - just for the test - we can run the whole process manually. To do this follow the below steps.

configure webserver
clone/fetch your app on the instance
build the app
install PM2 manager
run sudo pm2 start npm --name "process" -- start

Or set it as a simple checklist for the instance setup.

4. GitHub action.

Finally, we can create a GitHub action that will run our deployment process. Just for our case, we will create an action that will be called for each merge to the develop branch.

In your main app directory create the .github folder inside which the workflows one. Then create a deploy.yaml file.

name: Deploying

on:
  push:
    branches:
      - develop

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest

    steps:
      - name: executing remote ssh commands using ssh key
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.AWS_HOST }}
          username: ${{ secrets.AWS_USER }}
          key: ${{ secrets.AWS_KEY }}
          script: sh deploy.sh

As you can see we have some variables here. These are GitHub specific secrets. You can define them in your account settings. Values for AWS-related credentials can be found in the console. Here you have some detailed instructions.

Remember! Always keep sensitive data outside the repository.

And that's it. Push the workflow into your repo and wait for your first automatic deployment. It will take circa a couple of minutes (max). Done.

Cheers, Lukas.

Rewriting Vuex module to Composition API.

Lukas Borawski — Wed, 11 Nov 2020 17:26:56 +0000

Hi there. In this post, I'll show you how to rewrite some Vuex module to the Vue Composition API. It might be a great example of how you can replace the old, good Vue state management system with this new powerful tool from the Vue 3 release.

The module comes from a simple notebook app that I've made for some workshops that I ran a while ago. You can find it here.

So what this module does? In short, it aggregates, saves, and removes notes. Let's look at it briefly.

import { Module, ActionTree, GetterTree, MutationTree } from 'vuex'
import { MainState, NotesState, Note } from '~/types/store'

export const state: NotesState = {
  notes: [],
}

const mutations: MutationTree<NotesState> = {
  setNotes(state, payload: Note[]) {
    state.notes = payload
  },
}
const actions: ActionTree<NotesState, MainState> = {
  async saveNote({ state, commit }, $payload: Note) {
    commit('setNotes', [...state.notes, $payload] as Note[])
    // saving note into the storage
  },
  async removeNote({ state, commit }, $id: string) {
    commit('setNotes', notes.filter() as Note[])
    // removing notes from the storage
  },
  async getNotes({ state, commit }) {
    // getting notes from the storage
    notes.map((note: Note) => {
      commit('setNotes', [...state.notes, note] as Note[])
    })
  },
}
const getters: GetterTree<NotesState, MainState> = {
  notes: ({ notes }) => notes,
}

const namespaced: boolean = true

export const note: Module<NotesState, MainState> = {
  namespaced,
  state,
  mutations,
  actions,
  getters,
}

OK, for some context, we have here Typescript and some types that you can find below. In the app, there is also a $localForage Nuxt module that stores data locally. Check it here. For purpose of this article storing data logic will be removed.

export interface Note {
  id: string
  title: string
  note: string
  date: Date
}
export interface MainState {
  version: string
  $localForage: any
}
export interface NotesState {
  notes: Note[] | {}[]
}

Now, let’s move across this module. From the top, we have - of course - a state with our notes array. Mutations keep notes saving into the state functionality. Then we have actions that add, remove, and read notes from/to storage. One getter to receive current notes at the end.

OK, time to get our hands dirty.

The major and one of the most important things that Composition API allows is to split and move our common business logic into separated blocks (files) called composables. Then reuse them in the whole app.

So we can create one of them now. Place it into the new folder ~/composables as a useNotes.ts file - we're operating with Nuxt structure. Firstly copy the types that will be used the same way as it was with Vuex module.

In the beginning, we have to recreate the state. To do that we will use a new utility that Composition API provides called reactive.

reactive is the equivalent of the current Vue.observable() API in 2.x, renamed to avoid confusion with RxJS observables. Here, the returned state is a reactive object that all Vue users should be familiar with. The essential use case for reactive state in Vue is that we can use it during render. Thanks to dependency tracking, the view automatically updates when reactive state changes.

Tip: check the ref object as well here.

The code:

import {
  reactive,
  computed,
  useContext,
  ComputedRef,
} from '@nuxtjs/composition-api'
import { NotesState, Note } from '~/types/store'

const state: NoteState = reactive({
  notes: [],
})

One thing worth noticing is that we need to define our reactive state object outside the main composable function. We want full reactivity and access to this data from other components. We don't need to export it though.

Time for our composable useNotes.

In the same file we'll define this code:

export default function useNotes(): {
  notes: ComputedRef<Note[]>
  getNotes: () => void
  saveNote: ($payload: Note) => void
  removeNote: (id: string) => void
} {
  const setNotes = ($notes: Note[]) => {
    return (state.notes = $notes)
  }
  const saveNote = async ($payload: Note) => {
    setNotes([...state.notes, $payload] as Note[])
    // saving note into the storage
  }
  const removeNote = async ($id: string) => {
    setNotes(notes.filter() as Note[])
    // removing notes from the storage
  }
  const getNotes = async () => {
    // getting notes from the storage
    notes.map((note: Note) => {
      setNotes([...state.notes, note] as Note[])
    })
  }

  return {
    notes: computed(() => state.notes),
    getNotes,
    saveNote,
    removeNote,
  }
}

Let's dive into it. What we have here is a simple function that returns notes from previously defined state and handlers/actions to save, remove, and get notes. Actually, they look exactly the same as the Vuex module ones. Notes are the computed value now which is delivered from Composition API and it's an equivalent of well known computed from Vue Options API.

Done. We got rid of all the Vuex module complexity - no mutations, no actions, no getters. All we need is one functional composable that can be reused anywhere we want in the app.

Additionally, we've provided some typings for returns. And as for notes handling functions is pretty straightforward, that for notes we're using now the generic type for ComputedRef. As of version 3 of Vue we get all the typings out of the box - awesome.

Now we can use it with the real component. In our case, it will be an index page. Data from the useNotes composable will be passed, propagated to the child components as a prop - more about chaining data through props and Composition API soon, stay tuned.

The index.vue page code:

<template>
  <app-notes-list :notes-prop="notes" />
</template>

import useNotes from '~/composables/useNote.ts'

export default Vue.extend({
  name: 'PageIndex',
  setup() {
    const { notes, getNotes } = useNotes()
    onBeforeMount(() => {
      getNotes()
    })
    return {
      notes,
    }
  },
  components: {
    AppNotesList,
  },
})

With Vue 3 we get this new optional syntax with setup function. It allows us to combine all component logic in one place, ordered by logical blocks. The perfect scenario is that you keep your whole business code outside the component and just invoke it along with setup function. And as with our index page example, we've imported the useNotes composable chunks to collect notes.

One new thing that you might remark here is this new function onBeforeMount. And of course, it's a hook. With Composition API there are newly redefined hooks that we can use with setup function.

And that's it. Controversial? A bit? Well, now with Composition API we could get rid of almost all Vuex complexity. From a technical perspective, it will be almost the same, but the way of defining it and acting with will be less complicated. It's just functions that we all know. We don't need mutations, actions, and getters. More we don't have to map them at all. Now just a simple import is enough and we're moving on. And the biggest advantage of the Vuex modules - separation of logic - we can still have with Composition API. One more thing might be speed and performance, but this one needs some benchmarks to confirm. Give it a try, you'll be thrilled.

The whole code is available on this repo with mentioned before a simple notebook app.

Thanks, enjoy.

Nuxt asyncData recall.

Lukas Borawski — Mon, 09 Nov 2020 20:18:38 +0000

Short disclaimer at the beginning - this one might be not valid anymore soon because the Nuxt 3.0 is just right behind the corner. Along with it, we will get a new, fresh, and shiny useFetch API. Recreated with Composition API it will change the whole process of fetching data across our Nuxt apps.

A simple example will look like:

import { useFetch } from '@nuxt/composables'

export default {
  async setup() {
    const { data: posts } = await useFetch('https://your.api.url')
    return posts
  }
}

Sexy, I know. 😆

But since it's not public and not quite official at that very moment we still using the 2.x version of the framework and we still lay our apps on the existing API. According to that, this might be helpful for some of you.

As we all know for various cases of data fetching we can use the fetch() hook with $fetchState object which contains pending and error values. It also can be recalled with this.$fetch method. For others when we need our data just before the page render we have to use asyncData. One problem with asyncData is that we can't call it again - for example on route change action. What we can do about it then?

Firstly define your fetch function outside the regular component.

async fetch() {
  const { posts } = await forApiResponse()
  return {
    posts
  }
}

Then inside the asyncData hook use this function.

asyncData() {
  return fetch()  
}

Recall it while watching some route changes.

data: () => ({
  posts: []  
}),
watch: {
  $route() {
    const data = fetch()
    Object.assign(this.$data, data)
  }
}

To avoid data conflicts we might want to reset it to the default state before fetching it again. Maybe this one is not so elegant as the fancy fetch() API but that way we can get our data before the page renders and react to it. Displaying a 404 error for example - very valuable from SEO perspective.

And this is it. Enjoy.