Discussion: Removal of Vuex store "classic mode"

shven
0
shven
commented 10 months ago

Version

v2.4.1

Reproduction link

https://github.com/nuxt/nuxt.js/tree/dev/examples/vuex-store

Steps to reproduce

  1. Clone https://github.com/nuxt/nuxt.js/tree/dev/examples/vuex-store
  2. Change dependency to "nuxt": "latest" instead of "nuxt-edge": "latest"
  3. npm install && npm run dev
  4. Visit http://localhost:3000/

What is expected ?

A code sample should not return a deprecation warning

What is actually happening?

The console outputs this warning:
WARN Classic mode for store/ is deprecated and will be removed in Nuxt 3.

Additional comments?

Fix the Vuex Store example or remove this warning

bug
0
cretueusebiu
210
cretueusebiu
commented 10 months ago

What is the alternative now if you want to create the store instance manually ?

0
manniL
6.9k
manniL
commented 10 months ago

@cretueusebiu Don't ☺️

Use the modules syntax :)
It has the same "power"

0
shven
0
shven
commented 10 months ago

@manniL I don't get it :s

I tried this modules syntax and I still get this warning.

store/index.js

import Vuex from 'vuex';
import settings from './modules/settings';

export default () => new Vuex.Store({
  actions: {    
    nuxtServerInit({dispatch}, {query}) {
      dispatch('loadEditMode', query);
    },
  },
  modules: {
    settings
  }
});

store/modules/settings.js

export default {
  state: {
    editMode: false,
  },
  mutations: {
    setEditMode(state, editMode) {
      state.editMode = editMode;
    },
  },
  actions: {
    loadEditMode({commit}, query) {
      let isEditMode = false;      
      if(query['editMode']) {
        isEditMode = true;
      }      
      commit('setEditMode', isEditMode);
    },
  }
};
0
manniL
6.9k
manniL
commented 10 months ago

Your index.js is not in module form πŸ€”

0
Krutie
10
Krutie
commented 10 months ago

@shven - try the following convention - it should remove the warning message πŸ™‚ Also do the fresh npm start or npm run dev after making the changes, otherwise you'll still see the message.

// store/index.js

export const state = () => ({
  leads: []
})

export const mutations = {
  SET_LEADS(state, leads) {
    state.leads = leads
  }
}

export const actions = {
  async nuxtServerInit ({ commit }, { $axios }) {
    const leads = await $axios.$get('http://localhost:3000/api/leads')
    commit('SET_LEADS', leads)
  }
}
0
renspoesse
0
renspoesse
commented 10 months ago

@manniL I understand that modules syntax has the same power but what is wrong with preferring the original, documented Vuex syntax (ie., classic) that I also use in non-Nuxt projects, if there's no functional difference?

0
homerjam
233
homerjam
commented 10 months ago

@manniL I understand that modules syntax has the same power but what is wrong with preferring the original, documented Vuex syntax (ie., classic) that I also use in non-Nuxt projects, if there's no functional difference?

@renspoesse one thing it does for me is make it more straightforward to include reusable store modules - it's now more inline with the way plugins work.

1
manniL
6.9k
manniL
commented 10 months ago

@renspoesse IMO it's way more "in line" with other areas of Nuxt. As @homerjam mentioned, things like plugins or routes are heavily utilizing the filesystem. Same should be for the store.

If the demand is high enough or somebody is willing to put in the time, the "classic" store might have a chance to exist as a community module but it will likely vanish from the core in the next major version.

1
imns
0
imns
commented 9 months ago

Why are you making me use vuex-store in a specific way? If it's not a security risk, you shouldn't be forcing how to use anything on me.

0
homerjam
233
homerjam
commented 9 months ago

@imns Nuxt exists to streamline and simplify the development of complex applications. It does this by providing a framework which encompasses a set of "best practices". As such there's a trade-off with total developer freedom.

0
manniL
6.9k
manniL
commented 9 months ago

Why are you making me use vuex-store in a specific way? If it's not a security risk, you shouldn't be forcing how to use anything on me.

We don't force you to do anything 🀷‍♂️
But removing the non-fs-based vuex store handling helps us to keep Nuxt lean in the core.

If you still want to use this mode, we'll probably release a community module that allows this behavior ;)

0
MaxKostenko
0
MaxKostenko
commented 9 months ago

Proposal to use fs-based store sounds strange in case if I have several pages with totally different modules. Unless you will have possibility to register/unregister them automatically based on current page file.
Or may be is there any solution for it?

0
manniL
6.9k
manniL
commented 9 months ago

@MaxKostenko you can dynamically (un-)register store modules as usual, sure. But I wonder whether there is a situation where you need to do that. These modules don't add much to the bundle size πŸ€”

0
MaxKostenko
0
MaxKostenko
commented 9 months ago

@manniL
But for it I need to keep it in different dir (not store) for preventing autoimport?

Problem about store not in bundle size. Problem in performance on old/budget mobile devices. It could be solved if I will reset state to initial. But if you are going to build big application it will be a mess in store. For example, if you open dev-tools, getters will not be grouped by modules its just a long list.
Also I think current situation could provoke programmer to create bad architecture with a lot relations between store modules. Nuxt like framework should force you to do better architecture.

0
manniL
6.9k
manniL
commented 9 months ago

@MaxKostenko Thanks for the feedback so far ☺️

You can ignore them with a .nuxtignore, so they won't be embedded automatically.
I'll get back to the rest of the @nuxt/core-team regarding the performance aspect.

Also I think current situation could provoke programmer to create bad architecture […].

Nuxt aims to do the opposite. πŸ‘

0
berenicestr
0
berenicestr
commented 9 months ago

Good Morning. I have the same problem. I have included auth-external-jwt: https://nuxtjs.org/examples/auth-external-jwt/

If you run the editor you can see the same warning: "Classic mode for store/ is deprecated and will be removed in Nuxt 3."

Please, any help to solve it?
Regards

0
ScrippsFEE
5
ScrippsFEE
commented 9 months ago

@berenicestr change store/index.js to this:

/* global require, process */
const cookieparser = process.server ? require("cookieparser") : undefined;

export const state = () => {
  return {
    auth: null
  };
};
export const mutations = {
  setAuth(state, auth) {
    state.auth = auth;
  }
};
export const actions = {
  nuxtServerInit({ commit }, { req }) {
    let auth = null;
    if (req.headers.cookie) {
      const parsed = cookieparser.parse(req.headers.cookie);
      try {
        auth = JSON.parse(parsed.auth);
      } catch (err) {
        // No valid cookie found
      }
    }
    commit("setAuth", auth);
  }
};

Remove everything that isn't included above.

1
John0x
22
John0x
commented 9 months ago

As far as I can see, this would mean that I won't be able to use vuex-module-decorators with Nuxt anymore?

That would suck pretty much for the typescript way of dealing with vuex.

0
kevinmarrec
370
kevinmarrec
commented 9 months ago

@John0x 2 ways to have vuex-module-decorators when "classic mode" will be removed :

  1. (Recommended) Don't pass your modules to the store with classic mode, you can just use this way : https://github.com/championswimmer/vuex-module-decorators#module-re-use-use-with-nuxtjs and just export the class, Nuxt will handle it :) (it needs to be @Module({ stateFactory: true, namespace: true, name: 'someName' }) to suceffuly work if I remember)

  2. We'll provide a external official Nuxt module to let people have the classic mode back

0
hareku
15
hareku
commented 7 months ago

@kevinmarrec
Would you add an example with vuex-module-decorators ?

0
kevinmarrec
370
kevinmarrec
commented 7 months ago

@John0x @hareku For Vuex with TypeScript I might suggest now vuex-orm which seems to fit better in TypeScript projects. I planned to do an example if you want to give it a try.

0
hareku
15
hareku
commented 7 months ago

@kevinmarrec
I want to try it!

0
Akash187
0
Akash187
commented 3 months ago

If you are still getting the annoying warning "Classic mode for store/ is deprecated and will be removed in Nuxt 3".

you should read this question on StackOverflow.
Vuex Classic mode for store/ is deprecated and will be removed in Nuxt 3

0
redLineColor
0
redLineColor
commented 3 months ago

so ugly to use this.$store.getters['fileName/getterName']

0
mehul-dev
0
mehul-dev
commented 22 days ago

I strongly feel that classic mode should be kept even though it's shipped with nuxt but having to choose between legacy and the nuxt way would be grateful. I recently started a project with nuxt and coming from the background where I have developed the project with vue-cli. I prefer the same development approach with nuxt, for instance even though nuxt provide an automated router configuration for you in the background which is great but personally, for me, I like the traditional approach where I can define custom routes and don't rely on the directory structure just to follow nuxt way. I certainly don't know whether classic mode causes any perfomance issue or overhead in development but having to choose as per your prefernce is always great to have in a frame work

0
Atinux
28.1k
Atinux
commented 20 days ago

With the latest Nuxt version (v2.10.X), you can directly create a app/store.js file to overwrites our module system:

app/store.js:

import Vue from 'vue'
import Vuex from 'vuex'
​
Vue.use(Vuex)
​
export const createStore = () => {
  return new Vuex.Store({
    state: () => ({
      counter: 0
    }),
    mutations: {
      increment (state) {
        state.counter++
      }
    }
  })
}

You will also have to define store: true in your nuxt.config.js

0
Informations
Bug Report β€’ Open
#c8581 - Created 10 months ago