A few TypeScript Questions - Trying to work with vuex-module-decorators

[armenr]

Hi folks! Long-time lurker, first-time question ask-er, here...so I hope I'm posting the right thing in the right place! :)

I'm trying to get "vuex-module-decorators" set up with my brand-new Quasar project (everything is vanilla, as per boilerplate). I was compelled to do so after reading THIS wonderful article: The state of Typed Vuex

The project was generated from the beta branch of the CLI beta --> quasar create <folder_name> --branch next

3.0.0-beta.10

Create options:

? Pick your CSS preprocessor: SCSS
? Check the features needed for your project: ESLint (recommended), TypeScript, Vuex, Axios, Vue-i18n
? Pick a component style: Composition
? Pick an ESLint preset: Standard
? Continue to install project dependencies after the project has been created? (recommended) yarn

I have also installed the recommended VSCode Settings + VSCode extensions suggested SPECIFICALLY for using "Standard" instead of Prettier, and have those saved as workspace settings. I've disabled all other VSCode extensions that have to do with linting, formatting, etc.

To that end, let me kick off by sharing my quasar info output:

╰─ quasar info

Operating System - Darwin(20.3.0) - darwin/x64
NodeJs - 14.16.0

Global packages
  NPM - 7.6.3
  yarn - 1.22.10
  @quasar/cli - 1.1.3
  @quasar/icongenie - 2.3.3
  cordova - Not installed

Important local packages
  quasar - 2.0.0-beta.11 -- Build high-performance VueJS user interfaces (SPA, PWA, SSR, Mobile and Desktop) in record time
  @quasar/app - 3.0.0-beta.10 -- Quasar Framework local CLI
  @quasar/extras - 1.10.0 -- Quasar Framework fonts, icons and animations
  eslint-plugin-quasar - Not installed
  vue - 3.0.6 -- vue
  vue-router - 4.0.3
  vuex - 4.0.0 -- state management for Vue.js
  electron - 12.0.2 -- Build cross platform desktop apps with JavaScript, HTML, and CSS
  electron-packager - Not installed
  electron-builder - Not installed
  @babel/core - 7.13.10 -- Babel compiler core.
  webpack - 4.44.1 -- Packs CommonJs/AMD modules for the browser. Allows to split your codebase into multiple bundles, which can be loaded on demand. Support loaders to preprocess files, i.e. json, jsx, es7, css, less, ... and your custom stuff.
  webpack-dev-server - 3.11.2 -- Serves a webpack app. Updates the browser on changes.
  workbox-webpack-plugin - 6.1.2 -- A plugin for your Webpack build process, helping you generate a manifest of local files that workbox-sw should precache.
  register-service-worker - 1.7.2 -- Script for registering service worker, with hooks
  typescript - 3.9.9 -- TypeScript is a language for application scale JavaScript development
  @capacitor/core - 2.4.7 -- Capacitor: cross-platform mobile apps with the web
  @capacitor/cli - 2.4.7 -- Capacitor: Cross-platform apps with JavaScript and the web
  @capacitor/android - 2.4.7 -- Capacitor: cross-platform mobile apps with the web
  @capacitor/ios - 2.4.7 -- Capacitor: cross-platform mobile apps with the web

Quasar App Extensions
  *None installed*

So, I've got a few questions:

• (Unimportant) Should I be using/installing eslint-plugin-quasar?

Now on to the big question:

I found the following article from November 15, 2020: Quasar Framework With TypeScript AKA "Clean Quasar TypeScript"

So, when I follow the very first step and change my /src/store/index.ts file to:

import { store } from 'quasar/wrappers'
import Vuex, { Store } from 'vuex'

export let storeInstance: Store<unknown>

export default store(function ({ Vue }) {
  Vue.use(Vuex)
  const store = new Store<unknown>({
    modules: {},
    strict: !!process.env.DEBUGGING
  })
  storeInstance = store
  return store
})

VSCode immediately begins to show "Property 'Vue' does not exist on type '{}'.ts(2339)" <--- /src/store/index.ts

From there, if you follow this dude's implementation, EVERYTHING breaks. :)

Could anyone possibly advise on the correct way to implement this "dynamic" modules pattern + module-decorators in the Quasar-friendly way? If not, is there any reference for how to achieve the equivalent through the provided/templated/boilerplate Quasar app that I've generated?

Sorry for sounding like a newb. I'm happy to donate or buy someone a cup of coffee if they're willing to spend their time helping me :)

Thank you for EVERYTHING you've poured into this framework. It's GREAT!

[smolinari]

@IlCallo - Can probably help best with your questions.

As for donating. You can become a direct sponsor via Github or offer donations to the main dev, Razvan.

https://quasar.dev/why-donate#donating

Scott

[armenr]

Got it, thank you!

[outofmemoryagain]

@armenr One key thing to keep in mind in this case is the post that you are following was created targeting Quasar V1 + Vue 2, and you are using Quasar V2 + Vue 3. There are some key breaking changes between the two so it is not surprising bringing that code directly into a quasar 2 project fails. For example the store() wrapper function no longer has a parameter with a property named Vue. If you would like to try to use vuex-module-decorates, which does not have official Vue 3 support you should look to see if anyone has posted an example of using it. I would also recommend reading up on the latest versions of Vuex (Vuex 4) with Vue 3 and it's Typescript support, as this library may no longer be needed to get the type safe code you are trying to achieve.

[armenr]

(Disclaimer: I'm a VueJS newb, and I've never worked with Vue2, Vue3, Quasar, or Vuex before...)

You make a good point! For what it's worth, had to do a lot of reading, and digging until I stopped and realized:

In the Quasar boilerplate /boot files (like Axios) --> there is code that reads:

export default boot(({ app }) => {          // WHERE HE HECK IS "app" coming from, and where are its types?!)
  // for use inside Vue files (Options API) through this.$axios and this.$api

  app.config.globalProperties.$axios = axios
  // ^ ^ ^ this will allow you to use this.$axios (for Vue Options API form)
  //       so you won't necessarily have to import axios in each vue file

  app.config.globalProperties.$api = api
  // ^ ^ ^ this will allow you to use this.$api (for Vue Options API form)
  //       so you can easily perform requests against your app's API
})

export { axios, api }

And THEN I realized, that in Vue3, Vue.use() is NOT the approach. Instead, we use createApp, so my newb brain realized these examples I'm referencing or following along with cannot/will not work here.

Soooooo I sat there, asking myself: "Where the heck is this 'app' object being created (and being Typed), because I can't seem to find a main.ts or any such file in the /src/ folder of my project?!"

That led me to dig into the source code of /node_modules/@quasar...which is when I finally found the client-entry.js files within the Quasar library itself.

Once I realized that Quasar completely abstracts that away from us, but that it exists UNDER the hood in Quasar, everything else finally clicked!

I wish the documentation was a bit more clear about these sorts of architectural decisions, just because (as a newb) it would help me translate other tutorials and reference implementations out there using Vue3 to a Quasar-friendly implementation.

With that said, I think I might have figured out how to move forward, and your response definitely helped :)

Thank you!

[armenr]

For what it's worth: Decorators are nice, but trying to get the decorators to work in a SANE And TYPESAFE way (without disabling linting or taking shortcuts) proves to be more risky than valuable.

I came across this article, and it helped me to understand the logical flow implementing state & modules...of course, I took some liberties with his approach, to make the resulting code more expressive, and slightly less painful to read or write:

https://soshace.com/building-web-apps-with-vue-3-composition-api-typescript-vuex4-0/

Anyone got objections or observations about this approach before I really jump in? :)

[IlCallo]

@armenr hey there, just pointing out we just merged the suggested setup to have typed Vuex 4 stores: #8712 (comment)
I also saw there is a PR on Vuex 4 repo which would add a better native typesafeness: vuejs/vuex#1953

[armenr]

@IlCallo - You do need to copy that over, but there's still more.

Only way to get it working was to go into .quasar and modify the following. I'm going to also test doing this through a bootfile, although I wonder/fear if having the bootfile fiddle with the state object at "bootup time" might cause unforeseen side-effects.

• .quasar/app.js

import { Quasar } from 'quasar'
import quasarUserOptions from './quasar-user-options.js'
import RootComponent from 'app/src/App.vue'


import createStore from 'app/src/store/index'

import createRouter from 'app/src/router/index'





export default async function (createAppFn) {
  // create store and router instances
  const { storeKey } = await import('app/src/store/index');    // ADDED STOREKEY

  const store = typeof createStore === 'function'
    ? await createStore({})
    : createStore

  const router = typeof createRouter === 'function'
    ? await createRouter({ store })
    : createRouter

  // make router instance available in store
  store.$router = router


  // Create the app instance.
  // Here we inject into it the Quasar UI, the router & possibly the store.
  const app = createAppFn(RootComponent)


  app.config.devtools = true


  app.use(Quasar, quasarUserOptions)



  // Expose the app, the router and the store.
  // Note that we are not mounting the app here, since bootstrapping will be
  // different depending on whether we are in a browser or on the server.
  return {
    app,
    store,
    storeKey,
    router
  }
}

• .quasar/clientEntry.js (SNIPPET)

async function start ({ app, router, store, storeKey }, bootFiles) {      // ADDED STOREKEY



  let hasRedirected = false
  const redirect = url => {
    hasRedirected = true
    const normalized = Object(url) === url
      ? router.resolve(url).fullPath
      : url

    window.location.href = normalized
  }

  const urlPath = window.location.href.replace(window.location.origin, '')

  for (let i = 0; hasRedirected === false && i < bootFiles.length; i++) {
    try {
      await bootFiles[i]({
        app,
        router,
        store,
        ssrContext: null,
        redirect,
        urlPath,
        publicPath
      })
    }
    catch (err) {
      if (err && err.url) {
        window.location.href = err.url
        return
      }

      console.error('[Quasar] boot error:', err)
      return
    }
  }

  if (hasRedirected === true) {
    return
  }


  app.use(router)
  app.use(store, storeKey)        // ADDED STOREKEY

[armenr]

aaaaaaaaaaand THERE YOU HAVE IT! This works without modifying .quasar at all!

// /boot/typedStore.ts

import { boot } from 'quasar/wrappers'
import { storeKey } from 'src/store'

// "async" is optional;
// more info on params: https://quasar.dev/quasar-cli/boot-files
export default boot(({ app, store }) => {
  // something to do
  app.use(store, storeKey)
  console.log('STORE KEY', storeKey)
})

[IlCallo]

The PR I linked hasn't yet published with a new beta release, it should be done near the weekend.
At that point you won't need that typedStore boot file

[armenr]

Perfect. It's throwing warnings in the console about the plugin having already been loaded, so that's good. :)

To be clear, this new addition to the codebase doesn't magically produce types/type inference for actions/mutations/getters, right? Just state...because I do have a working implementation now that provides intellisense autocompletion and types on my state...just not my actions/getters/mutations etc.

[IlCallo]

Yeah, only the state will be typed, unluckily

This pending PR could help on that side, otherwise you'll need a third party package

Here you can find some suggestions