Feathers-vuex: Use instance variable for modelName in BaseModel

[RubyRubenstahl]

When setting up the base model using javascript instead of typescript, the modeName needs to be added outside of the class, e.g:

// Extend the base class
class User extends BaseModel {
    constructor(data, options) {
        super(data, options)
    }
    static instanceDefaults() {
        return {
            username: '',
            email: '',
            password: ''
        }
    }
}
User.modelName = "user"

While it works, I think it could cause some confusion and lead to erroneous bug reports.

I propose that it, instead, be defined as an instance variable in the constructor:

// Extend the base class
class User extends BaseModel {
    constructor(data, options) {
        super(data, options)
        this.modelName = "user"
    }

    static instanceDefaults() {
        return {
            username: '',
            email: '',
            password: ''
        }
    }
}

I'm not sure if this is feasible, given how & where it is used, but I think could reduce friction in supporting both TS and JS use cases.

[marshallswain]

Have you tried defining it directly as a static instance property? This is how I use it in production, currently.

[RubyRubenstahl]

White I try to declare the property as static, e.g.

class User extends BaseModel {
    static modelName = "user";
    constructor(data, options) {
        super(data, options)

    }

    static instanceDefaults() {
        return {
            username: '',
            email: '',
            password: ''
        }
    }
}

I receive the following error:

Module parse failed: Unexpected token (9:21)
File was processed with these loaders:
 * ./node_modules/eslint-loader/index.js
You may need an additional loader to handle the result of these loaders.
| // Extend the base class
| class User extends BaseModel {
>     static modelName = "user";
|     constructor(data, options) {
|         super(data, options)

 @ ./src/store/index.js 3:0-42 16:4-15
 @ ./src/main.js
 @ multi (webpack)-dev-server/client?http://192.168.123.107:8080/sockjs-node (webpack)/hot/dev-server.js ./src/main.js

To ensure that this error wasn't specific to eslint, I disabled eslint an tried again, receiving essentially the same error:

Module parse failed: Unexpected token (11:21)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders| class User extends BaseModel {
|     // eslint-disable-next-line
>     static modelName = "user";
|     constructor(data, options) {
|         super(data, options)

I admit, I don't use classes in JS all that often, so it may be just that I'm missing something.

[marshallswain]

@RubyRubenstahl Did you try without the semicolon?

[RubyRubenstahl]

I hadn't before, but I just gave it a shot with the same results.

[marshallswain]

Are you having this error with a new VueCLI project? The static prop syntax works for me on multiple projects ranging from about 6 months old to this week.

[morphatic]

I'm experiencing the same error. Weirdly, it worked just fine a couple of weeks ago. I got sidetracked from the project that uses feathers-vuex and when I came back and upgraded, suddenly I'm getting the error. I think something in the ecosystem changed, but I'm not sure what, exactly. Unfortunately, I think I upgraded too many things at once, so can't pinpoint the source of the problem. Sigh. Of course I forgot to commit before upgrading stuff, so don't have a restore point to go back to. Investigating now. Will report back what I find.

Last Config that Worked

This doesn't work anymore, but fwiw, here's what I had (based on this comment):

// vue.config.js
module.exports = {
  transpileDependencies: [
    '@feathersjs',
    'debug',
    'feathers-vuex'
  ]
}

// babel.config.js
module.exports = {
  presets: ['@vue/app'],
  sourceType: 'unambiguous'
}

Things I've Tried

None of these have worked so far.

• Rolling back to an earlier version of feathers-vuex, e.g. v2.0.0-pre.70.
• Installing @babel/plugin-proposal-class-properties and adding it to the plugins prop in babel.config.js (based on this comment). Even tried explicitly requiring as described here.
• Setting useBuiltIns: 'entry' in @vue/app babel preset config

[morphatic]

@RubyRubenstahl I tried following your lead and changing all instances of:

export class User extends BaseModel {
  static modelName = 'User'
  static diffOnPatch (data) {
    return diff(original, data)
  }
}

to

export class User extends BaseModel {
  static diffOnPatch (data) {
    return diff(original, data)
  }
}
User.modelName = 'User'

But that just kicked the can down to the next static prop, e.g.:

 warning  in ./src/store/services/users.js

Module parse failed: Unexpected token (5:19)
File was processed with these loaders:
 * ./node_modules/eslint-loader/index.js
You may need an additional loader to handle the result of these loaders.
|
| export class User extends BaseModel {
>  static diffOnPatch (data) {
|     const original = User.store.state.keyedById[data._id]

It doesn't look like you had the same experience. Any ideas?

[marshallswain]

@morphatic what vue template are you using to get started? I'd like to help you solve this one. How can I reproduce the issue? When I use the current @vue/cli to produce the app, it comes with the ability to understand classes and class properties.

[morphatic]

Ok, I just moved everything outside of the class definition and defined static props in the pre-es6 style. That seems to have worked.

[morphatic]

Project was started with @vue/cli. It used to work a few weeks ago. I figured out a way to revert everything to how it was when it was working. Still webpack choked on the static props. I'm now thinking it has nothing to do with my project or packages including feathers-vuex. I'm wondering if I changed something globally on my system to make this happen. A different project I was working on was using yarn (I'm using npm in this project) and I'm wondering if there's some sort of global conflict or config change that caused this.

[J3m5]

@RubyRubenstahl @morphatic

Could you try to add

  parserOptions: {
    parser: "babel-eslint",
  }

to your eslint config, and install the babel-eslint parser

npm install babel-eslint --save-dev

This should fix the problem

You should also remove the transpileDependencies and sourceType options of your vue.config.js file

If you still have errors, try to add

        exclude: ["babel-plugin-transform-classes"],

to the babel preset in your babel.config.js file like this

  presets: [
    [
      "@vue/app",
      {
        exclude: ["babel-plugin-transform-classes"],
      },
    ],
  ],

This will prevent the classes from being transpiled and make eslint recognize the es6 class keywords.
It will also fix the errors like in #238 and #259 .

[morphatic]

@J3m5 babel-eslint came pre-configured (like you described it) when I bootstrapped the app with @vue/cli. I tried adding the exclude in the settings like you described, but I still get the error. 😕

The good news is that it still works fine after removing the transpileDependencies and source: 'unambiguous'. The only thing that seems to allow it to compile is to NOT use class properties, so all of my models look like:

export class User extends BaseModel {}
User.modelName = 'User'
User.diffOnPatch = data => {
  // ... custom diff code ...
}
User.instanceDefaults = () => ({
  first_name: '',
  last_name: '',
  // ... etc. ...
}

While admittedly this is a weird mix of using classes, and not, if it works for now I can live with it. Would love to figure out why I'm not able to get class props to work, though.

[morphatic]

Ugh. Figured it out.

Rolled back to a commit from a month ago (when it still worked). Re-implemented all changes since then one by one. Upgraded all packages one-by-one, recompiling each time. Finally found the dependency that was causing the problem (vue-cli-plugin-vuetify). And it was only a patch upgrade (0.6.1 -> 0.6.3)!

Hey, it only took a week!

Anyway, false alarm. No issues with feathers-vuex. Thanks to anyone to who spent time looking into or thinking about this.

[marshallswain]

Since this was caused by an external dependency, I'm going to go ahead and close this. Thanks @morphatic.