Vuex-module-decorators: Namespaces do not function. Throws "ERR_ACTION_ACCESS_UNDEFINED" when using namespaces

Created on 21 Jan 2019  路  19Comments  路  Source: championswimmer/vuex-module-decorators

I setup namespaces for my Vuex modules, and after that the following error is thrown whenever I try and access an action:

ERR_ACTION_ACCESS_UNDEFINED: Are you trying to access this.someMutation() or this.someGetter inside an @Action?
That works only in dynamic modules.

Vuex Module:

@Module({ namespaced: true, name: 'Accounts' })
export default class AccountStore extends VuexModule {

  accounts: AccountModel[] = [];

  @Mutation
  SetAccounts(accounts: AccountModel[]){
    this.accounts = accounts;
  }

  @Action({commit: 'SetAccounts'})
  FetchAll(){
    axios.get('/api/accounts').then((response) => {
      return response.data;
    })
  }
}

Store initialization:

Vue.use(Vuex);

export default new Vuex.Store({
    state:{},
    modules:{
        Accounts: AccountStore
    }
})

Calling It:

this.$store.dispatch('Accounts/FetchAll');

If I remove the namespace bits and call this.$store.dispatch(FetchAll'); it works as expected.

I assume this is a problem with my usage of this?

Most helpful comment

@Action({ rawError: true })
You can add this to the decorator. I think the decorator catches every error that happens inside the action and just give you this error.
I had the same thing.

All 19 comments

@Action({ rawError: true })
You can add this to the decorator. I think the decorator catches every error that happens inside the action and just give you this error.
I had the same thing.

@douglasg14b You don鈥檛 return the promise in your FetchAll @Action. So vuex-module-decorators will only receive undefined. Did you check if this causes your issue?

Edit: turns out there was a problem with my main component class and after I fixed it, the problem went away.


I'm getting this same error when trying to namespace modules. Without namespacing everything works fine.

My super simple store:

@Module({ namespaced: true, name: 'hoyci' })
export default class HoyciModule extends VuexModule {
  year = 0

  @Mutation
  setYear(year: number) {
    this.year = year
  }

  @Action({})
  init() {
    const d = new Date()
    this.context.commit('setYear', d.getFullYear())
  }
}

If I add rawError: true I get: "Unhandled promise rejection Error: "ERR_STORE_NOT_PROVIDED: To use getModule(), either the module should be decorated with store in decorator, i.e. @Module({store: store}) or store should be passed when calling getModule(), i.e. getModule(MyModule, this.$store)""

Using Vue 2.6.6 and vuex 3.1.0

image
I use getModule function, then call action successfully.

I think something somewhere is a red herring here. I, too, had this problem, though it didn't seem related to namespaces. I was going to file an issue about creating promises in actions causing errors, because whenever I created a promise, my actions failed with this same error.

Turns out adding ({rawError: true}) revealed exactly what my error was. It had nothing to do with promises.

So I think there needs to be better error-reporting in this particular failure case, since any errors are getting caught and reported with this generic message. I lost a few hours to this. :)

Thanks.

Putting the whole namespace path in name worked for me:

@Module({ namespaced: true, name: 'full/path/to/module' })

Not to invalidate your solution, but in my case, the module was only a single level deep. So I'm wondering if we're dealing with an overly broad try-catch here? Maybe the error was that you weren't specifying a full path, and specifying a full path fixed the error?

Or did the above solution not reveal any errors? This was a strange bug to deal with. :)

Did anyone manage to solve this problem? As others in this thread, I get the error following error ERR_ACTION_ACCESS_UNDEFINED with rawError: false and ERR_STORE_NOT_PROVIDED with rawError: true if I try to call a namespaced action.

// In some component
connect() {
  this.$store.dispatch('Connection/testAction'); // Error
}

...

// In connection store
@Module({ namespaced: true, name: 'Connection'})
export default class Connection extends VuexModule {
  @Action({ rawError: true })
  testAction() {
    console.log('test action');
  }
}

If I use the getModule function before calling the action, the error does not occur.

connect() {
  const connection = getModule(Connection, this.$store);
  connection.testAction() // This works fine - Ouput: "test action"
  this.$store.dispatch('Connection/testAction'); // This also works fine! - Output: "test action
}

So this is an fix to the problem, but I wouldn't say it's an optimal solution. This really seems like a bug to me.

Also, this error does not seem to occur for @MutationAction, it's only for normal actions.

Works for me, but I use
vuex-class, though ideally that
shouldn't be necessary. Maybe console.log your store at various points
to see what its shape is?

Looking that the docs, it is mentioned that there are certain benefits of using the getModule function that I agree could be useful. So I would say using getModule is the way to go.

To avoid using getModule() before calling every action, you can export your Vuex module like this:

class MyModule extends VuexModule {
...
}
export default getModule(MyModule);

You might have to also use the param dynamic: true in your @Module decorator, I am not sure.

Is there now any best practice solution for this issue?

@sfakir Have you tried taking the name property out of the Module annotation?

@sfakir Have you tried taking the name property out of the Module annotation?

Removing the module name in the module declaration fixes it for me! Not quite sure if there will be other errors when the module name is missing. But for the moment everything seems to be okay!

Changing from:
@Module({ namespaced: true, name: 'user', store })

To:
@Module({ namespaced: true, store })

As @fdeitelhoff mentioned omitting name seems to fix the problem for me as well. I have a super basic namespaced user module in the root store. That was throwing this error when trying to dispatch an action.

Can anybody weigh in on why having the name option causes this error (ERR_STORE_NOT_PROVIDED) and what are the implications?

Also removed and works now. Don't have namespace or main store (used for temporary locally-scoped stores on some forms), so simply @Module does the job.

The behavior seems to change depending on the browser.

  • Chrome 83.0.4103.116 (Official Build) (64 Bit)
  • Edge 83.0.478.54 (Official Build) (64 Bit)
  • FireFox 77.0.1 (64 Bit)
import { Module, Mutation, VuexModule, Action } from 'vuex-module-decorators'
import axios from 'axios

@Module({
  namespaced: true,
  name: 'Authentication',
})
export default class Authentication extends VuexModule {
  session = ''
  triedCount= 0

  get locked(): boolean {
    return this.triedCount > 3
  }

  @Action
  async authenticate({ id, password }: {id: string; password: string}): Promise<void> {
    try {
      const url = 'https://api.foo.bar/authentication'
      const data = {
        id,
        password: atob(password)
      }
      const result = await axios.post(url, data)

      // Chrome is no problem, but Edge / FireFox, doesn't work them
      this.reset()
      this.storeSession(result.data.session)

      // To fix below.  Chrome, Edge and FireFox are Okay
      // this.context.commit('reset')
      // this.context.commit('storeSession', result.data.session)
    } catch(e) {
      console.error('error!!')
    }
  }

  @Mutation
  private storeSession(session: string){
    this.session = session
  }

  @Mutation
  private reset(){
    this.session = ''
    this.triedCount = 0
  }
}
   //fails without { rawError: true }
    @Action({ rawError: true })
    async doSomething(){
        console.log('doing something...')
        return new Promise((resolve, reject) =>{
            // resolve('blaaaaaaaaaaaaaaaaaaaaaaaa')
            reject ('errrrrrrrrrrrrrrrrrrrrrrrrrrr')
        })
    }

if there is an reject in a Promise it always fail without rawError, I think this case should be in the read-me, is a common case.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

blackmad picture blackmad  路  4Comments

Akumzy picture Akumzy  路  5Comments

kwekujoe picture kwekujoe  路  5Comments

erathorus picture erathorus  路  5Comments

BonBonSlick picture BonBonSlick  路  5Comments