🗃️ Centralized State Management for Vue.js.

Overview

Vuex

npm ci status


🔥 HEADS UP! You're currently looking at Vuex 3 branch. If you're looking for Vuex 4, please check out 4.0 branch.


Vuex is a state management pattern + library for Vue.js applications. It serves as a centralized store for all the components in an application, with rules ensuring that the state can only be mutated in a predictable fashion. It also integrates with Vue's official devtools extension to provide advanced features such as zero-config time-travel debugging and state snapshot export / import.

Learn more about Vuex at "What is Vuex?", or get started by looking into full documentation.

Documentation

To check out docs, visit vuex.vuejs.org.

Examples

Running the examples:

$ npm install
$ npm run dev # serve examples at localhost:8080

Questions

For questions and support please use the Discord chat server or the official forum. The issue list of this repo is exclusively for bug reports and feature requests.

Issues

Please make sure to read the Issue Reporting Checklist before opening an issue. Issues not conforming to the guidelines may be closed immediately.

Changelog

Detailed changes for each release are documented in the release notes.

Stay In Touch

For latest releases and announcements, follow on Twitter: @vuejs.

Contribution

Please make sure to read the Contributing Guide before making a pull request.

License

MIT

Copyright (c) 2015-present Evan You

Comments
  • 2.0 design

    2.0 design

    Note: this proposal has been heavily revised based on feedback so some of the comments below may be out of context.

    1. Terms naming change for better semantics

    Dispatching a mutation never sounded right. Dispatch should be indicating the intention for something to happen. For mutations, we want a verb that indicates the state change is happening as soon as you call it.

    • The old store.dispatch is now store.commit.
    • store.dispatch will be used for firing actions instead. (see next section)

    The new naming better conveys the semantics behind the two methods:

    • "dispatching an action": indicating the intention for something to happen (possibly async with side effects).
    • "committing a mutation": indicating the synchronous transaction of actual state change.

    2. Module Portability & Composability

    Actions inside store and modules

    There has been common requests on shipping actions with the store, or inside modules. Previously, the reason for not putting actions in the store/modules was mainly how do we access them. Actions defined inside the store means we need access to the store - again the singleton problem, which is now a non-issue.

    Now since they are just functions, we may expose them as store.actions and call them directly. In fact this was the API of Vuex 0.4.x:

    store.xxx // reserved for Store class methods/properties
    store.actions.xxx // this seems ok
    

    A problem is when actions are defined inside modules, what if multiple modules define actions of the same name? Also, sometimes we may want to call an action that affect multiple stores, just like mutations.

    It seems actions are also more like event listeners. Instead of calling them directly as functions, we now use store.dispatch to trigger them:

    const store = new Vuex.Store({
      actions: {
        doSomething: ({ commit }) => {
          commit('some-mutation')
        }
      }
    })
    
    store.dispatch('doSomething')
    

    This way, you can dispatch actions in multiple modules with a single call, just like mutations. It's also more explicit that you are firing off some side-effects in your store, instead of just calling a random function.

    Getters, too

    You can now define getters in the store / modules too. Similar to module mutations, module getters receive the sub state tree:

    const store = new Vuex.Store({
      state: {
        count: 0
      },
      getters: {
        hasAny: state => state.count > 0
      }
    })
    
    // access the getter
    store.getters.hasAny // -> false
    

    3. Composable Action Flow

    Now that we are putting actions inside modules and calling them via dispatch, we somehow lose out on the composability of actions, because they are no longer just functions you can call. Here's how we can make them composable again:

    1. To indicate the completion of an action, return a Promise from the action. store.dispatch will return that Promise if there is only a single handler called. If multiple action handlers are matched, it will return a Promise that resolves when all Promises returned by those handlers are resolved.

      const store = new Vuex.Store({
        actions: {
          doSomething: ({ commit }, payload) => {
            return callPromiseAPI(payload).then(res => {
               commit('some-mutation', { res })
            })
          }
        }
      })
      
      store.dispatch('doSomething', { id: 1 }).then(() => {
        // action done
      })
      
    2. Based on (1) and async/await, we can have very clean composition between async actions:

      const store = new Vuex.Store({
        actions: {
          one: async ({ commit }, payload) => {
            const res = await callPromiseAPI(payload)
            commit('some-mutation', { res })
          },
          two: async ({ dispatch, commit }) => {
            await dispatch('one')
            commit('done')
          }
        }
      })
      
      store.dispatch('two') // fires off complicated async flow
      

      The convention of returning Promises also allows Vuex to:

      1. better handle errors during async action flow.
      2. simplify store initialization during server-side rendering.

    Component Binding

    The design of Vuex 0.6~1.0 had a somewhat annoying design constraint: avoid directly accessing stores inside components. The store is injected at the root component, and implicitly used via the vuex: { getters, actions } options. This was in preparation for Vue 2.0 SSR (server-side rendering), because in common SSR setups (directly requiring the component in Node.js and render it), dependence on a global singleton will cause that singleton to be shared across multiple requests, thus making it possible for a request to pollute the state of the next one.

    However, with the new bundleRenderer strategy implemented in Vue 2.0.0-alpha.7, this is no longer an issue. The application bundle will be run in a new context for each request, making it unnecessary to structure your app without singletons just for the sake SSR. This also means it's totally fine to just import store from './store', use plain computed properties to return store.state.xxx, or calling store.dispatch() in plain methods.

    This opens up path to simplifying the component binding usage, since theoretically you don't need any binding at all. Currently, the vuex options feels a bit clumsy and indirect.

    In Vuex 2.0, the vuex option will be deprecated in favor of just computed properties and methods. You are free to structure your Vuex store usage the way you prefer. However, we will be keeping the injection for this.$store so that you can do this:

    export default {
      computed: {
        a () {
          return this.$store.getters.a
        }
      },
      methods: {
        b (...args) {
          this.$store.dispatch('b', …args)
        }
      }
    }
    

    The above alleviates the need to import the store everywhere. But it can get verbose when you have many getters and actions in the same component. Therefore we provide two helpers, mapGetters and mapActions:

    import { mapGetters, mapActions } from 'vuex'
    
    export default {
      computed: mapGetters(['a', 'b', 'c']),
      methods: mapActions(['d', 'e', 'f'])
    }
    

    So in the component, this.a maps to this.$store.getters.a, and this.d(...args) maps to this.$store.dispatch('d', ...args).

    If you want to map a getter/action to a different local name, use an object instead:

    import { mapGetters, mapActions } from 'vuex'
    
    export default {
      computed: mapGetters({
        myComputed: 'a' // map this.myComputed to store.getters.a
      }),
      methods: mapActions({
        myMethod: 'b' // map this.myMethod() to store.dispatch('b')
      })
    }
    

    Finally, you can easily compose them with local computed properties and methods using Object spread operator:

    import { mapGetters, mapActions } from 'vuex'
    
    export default {
      computed: {
        localComputed () { … },
        ...mapGetters(['a', 'b', 'c', 'd'])
      },
      methods: {
        localMethod () { … },
        ...mapActions(['b'])
      }
    }
    

    2.0 so soon? How about 1.0?

    1.0 contains small breaking changes but should be a very easy upgrade for existing 0.6~0.8 users. It will be maintained as a stable release in parallel to 2.0.

    opened by yyx990803 65
  • 项目也许有电脑病毒(Malicious program)

    项目也许有电脑病毒(Malicious program)

    今天下载了这个项目 然后安装了依赖~随后不久360杀毒(360 Internet Security)报项目文件夹里有恶意程序,我不知道是我电脑本身问题还是项目中依赖还是项目压缩包有问题,或者是项目某文件或依赖的文件让360错误识别了。但是个人建议检查下,以下是360杀毒日志 360杀毒实时防护日志

    时间 防护说明 处理结果 文件

    2017-02-17 17:47:26 恶意软件(js.packed.dropper.c) 已删除此文件,如果您发现误删,可从隔离区恢复此文件。 e:\testdemo\vuex-dev\node_modules.2.1.6@typescript\lib\typingsinstaller.js 2017-02-17 17:47:24 恶意软件(js.packed.dropper.c) 已删除此文件,如果您发现误删,可从隔离区恢复此文件。 e:\testdemo\vuex-dev\node_modules.2.1.6@typescript\lib\tsc.js 2017-02-17 17:47:13 恶意软件(js.packed.dropper.c) 已删除此文件,如果您发现误删,可从隔离区恢复此文件。 e:\testdemo\vuex-dev\node_modules.2.1.6@typescript\lib\tsserver.js 2017-02-17 17:46:57 恶意软件(js.packed.dropper.c) 已删除此文件,如果您发现误删,可从隔离区恢复此文件。 e:\testdemo\vuex-dev\node_modules.2.1.6@typescript\lib\tsserverlibrary.js 2017-02-17 17:46:32 恶意软件(js.packed.dropper.c) 已删除此文件,如果您发现误删,可从隔离区恢复此文件。 e:\testdemo\vuex-dev\node_modules.2.1.6@typescript\lib\typescript.js 2017-02-17 17:45:55 恶意软件(js.packed.dropper.c) 已删除此文件,如果您发现误删,可从隔离区恢复此文件。 e:\testdemo\vuex-dev\node_modules.2.1.6@typescript\lib\typescriptservices.js

    opened by hyxdppt 57
  • Clear all stores or set them all to its initial state

    Clear all stores or set them all to its initial state

    What problem does this feature solve?

    I have several modules defined on my store, with its own store on each module:

    export default new Vuex.Store({
      modules: {
        user,
        items,
        invoices,
        ... // A bunch of other modules
      }
    })
    
    

    The issue is that when the user logs out the app, all the information in the store remains since no mutation is being called to effect them or the set them to its initial state, therefore when another user logs in he can see information of the previous user, I know that I can just create a new mutation to set the store to its initial state, but that means that I'd need to call this mutation for each module that I have.

    Is there a way to clear them all?

    What does the proposed API look like?

    It would be great to have a reserved mutation named 'clearAll' or alike, that resets all the module stores to its initial state as they were defined

    ...mapMutations([
      'clearAll'
    ])
    

    Then on the logout method

    logout: function () {
      this.$store.dispatch('logout').then(
        () => {
          this.$router.push('/login')
          this.clearAll()
        }
      )
    },
    
    
    opened by JonaMX 51
  • feat: improve helper types for more type safety

    feat: improve helper types for more type safety

    This typings update allows to use typed getters/actions/mutations out of the box if they are used in the following manner.

    1. Declare each store assets types as interfaces.

    // State
    export interface CounterState {
      count: number
    }
    
    // Getters
    // key: getter name
    // value: return type of getter
    export interface CounterGetters {
      power: number
    }
    
    // Mutations
    // key: mutation name
    // value: payload type of mutation
    export interface CounterMutations {
      increment: { amount: number }
    }
    
    // Actions
    // key: action name
    // value: payload type of action
    export interface CounterActions {
      incrementAsync: { amount: number, delay: number }
    }
    

    2. annotate a namespaced module with DefineModule utility type.

    The annotated assets must fulfill specified names and return type (getters) / payload type (actions, mutations). Also the assets types will be inferred.

    The type in the following example should be fully inferred:

    import { DefineModule } from 'vuex'
    
    const counter: DefineModule<CounterState, CounterGetters, CounterMutations, CounterActions> = {
      namespaced: true,
    
      state: {
        count: 0
      },
    
      getters: {
        power: state => state.count * state.count
      },
    
      mutations: {
        increment (state, payload) {
          state.count += payload.amount
        }
      },
    
      actions: {
        incrementAsync ({ commit }, payload) {
          setTimeout(() => {
            commit('increment', { amount: payload.amount })
          }, payload.delay)
        }
      }
    }
    

    3. create typed namespaced helpers with createNamespacedHelpers.

    Then, we can acquire typed mapXXX helpers for the defined namespaced module.

    export const counterHelpers = createNamespacedHelpers<CounterState, CounterGetters, CounterMutations, CounterActions>('counter')
    

    4. use the namespaced helpers in a component.

    import { counterHelpers } from '@/store/modules/counter'
    
    export default Vue.extend({
      computed: counterHelpers.mapState({
        value: 'count'
      }),
    
      methods: counterHelpers.mapMutations({
        inc: 'increment'
      }),
    
      created () {
        // These are correctly typed!
        this.inc({ amount: 1 })
        console.log(this.value)
      }
    })
    

    Caveats

    Store is still not typed

    I think it is probably impossible to infer the entire store type correctly since we cannot concat getter/actions/mutations names with namespace on type level. So this PR focuses how we do not use $store directly but use typed helpers instead.

    It does not infer the types completely if passing functions to mapXXX helpers.

    For example:

    counterHelpers.mapState({
      foo: state => state.count
    })
    
    counterHelpers.mapMutations({
      bar (commit) {
        commit('increment', { amount: 1 })
      }
    })
    

    We can write the above code with inferred state and commit types but the component will have a type of foo: any and bar: (...args: any[]) => any.

    It can be easily rewrite with a combination of object form mapXXX helpers and normal methods, so I think it would not be a problem.

    Using root assets

    The default mapXXX helpers still accepts any asset names and returns record of any type. To manually annotate them, we can use createNamespacedHelpers too. If we don't specify a namespace as an argument, it returns the root mapXXX helpers so that we annotate with root module assets types as same as namespaced modules.

    const rootHelpers = createNamespacedHelpers<RootState, RootGetters, RootMutations, RootActions>()
    

    fix #532 fix #564 fix #1119

    types 
    opened by ktsn 42
  • Usage with vue-router

    Usage with vue-router

    It is pretty clear how to use the Vuex with single page app with only one active view. But how do I manage states in more complex app with different views? Should I override v-link behavior and run a mutation to change the view?

    It would be awesome if you could provide an example for this case, thanks!

    opened by enyancc 40
  • Vuex and GraphQL

    Vuex and GraphQL

    Hi,

    I am very interested in getting vue to work with data coming into the client from a GraphQL server. Would vuex be the place to start working on that? Or would I need to code my own module to support and fill vue with data queried via GraphQL? I'd really like to be able to add GraphQL queries in vue components directly, similar to how it is done with React.

    Thanks for any help on a proper direction.

    Scott

    opened by smolinari 39
  • Should a component commit a mutation directly?

    Should a component commit a mutation directly?

    I open the issue here instead of the forum is because that I think this may relate to the documentation.

    In the Mutations chapter, you can see an example that uses mapMutations to map mutations to component methods. It also says

    You can commit mutations in components ...

    So the question comes, is committing a mutation directly from a component (not through an action) fine in vuex? If it is, then this diagram may need to update: image

    also I think it is worth to mention in the docs, it's ok to commit a mutation directly from a component, because there are a lot of people come from redux, which the client only dispatches actions, won't call the reducer directly.

    If this is an anti-pattern, the Mutations chapter may also need to be updated. Shouldn't we remove the mapMutations method? (but people can still use this.$store.commit('xxx'), so still need to add some clarification)

    documentation 
    opened by CodinCat 38
  • add hasModule API

    add hasModule API

    What problem does this feature solve?

    When adding/removing modules dynamically, it is sometimes mandatory to know if a module has already been added.

    What does the proposed API look like?

    Store#hasModule(path)

    2.x 
    opened by FranckFreiburger 37
  • [vuex] already installed. Vue.use(Vuex) should be called only once.

    [vuex] already installed. Vue.use(Vuex) should be called only once.

    Version

    2.0.0

    Reproduction link

    https://jsfiddle.net/15ww4vog/8/

    Steps to reproduce

    1. Load jsfiddle page
    2. Vue init method is executed.(With CDN, Just VUE and Jquery)
    3. Vue init method makes a Ajax call to "https://api.myjson.com/bins/13xym3". and responds a HTML, JS injected to #dinamic-container div.
    4. HTML, JS injected also includes a Vue instance.
    5. creating conflicts "[vuex] already installed. Vue.use(Vuex) should be called only once."

    What is expected?

    1. Load page, instantiate VUE.
    2. When a page is injected and includes a VUE instance. load with no conflicts.

    What is actually happening?

    1. Load page, instantiate VUE.
    2. When page is injected and includes a VUE instance. a conflict is raised and show the "[vuex] already installed. Vue.use(Vuex) should be called only once." console error.

    My parent view is loading Vue instance. and I'm injecting a Child view that also contains its own Vue instance.

    opened by f1729 33
  • Extend plugin functionalities

    Extend plugin functionalities

    WIP

    The idea of this PR is to give plugins more than just subscribing:

    • Adding anything to the context passed to actions. This would allow constants or custom methods and can be useful to integrate a Database or Service like firebase.
    • Adding new actions
    • Adding new getters
    • Adding new mutations

    There's no need to add something to the state because it can be achieved by doing Vue.set(store.state, key, value). Although this should be pointed out in the docs


    The content of this PR is still unfinished so we can iterate over the API before releasing it


    API proposal

    Adding properties to the context

    Using functions allow to let the plugin check the path and use the context:

    // multiple names are possible like assignContext, mergeContext, registerInContext, etc
    mergeInContext((modulePath, context) => {
      // path is an array of strings: ['some', 'module']
      // Only registers for some/module
      if (modulePath.join('/') === 'some/module') {
        return {
          foo: 'staticProperty',
          bindRef () {
            context.commit(modulePath.join('/') + '/myPlugin/MUTATION')
          }
        }
      }
    })
    
    // registering in every context (most of the time)
    mergeInContext((modulePath, context) => ({
      foo: 'staticProperty',
      bindRef () { // a function }
    }))
    

    This needs some kind of walk method on Modules that recursively invoke a function. ModuleCollection's walk can simple be called on the root module

    Then we can use the merged data in actions:

    // merging properties directly into context
    function someAction ({ commit, foo, bindRef }) {
      foo === 'staticProperty'
      bindRef()
    }
    
    // OR merging them in a plugins property
    function someAction ({ commit, plugins: { foo, bindRef } }) {
      foo === 'staticProperty'
      bindRef()
    }
    
    // OR forcing a first parameter as the name of the plugin
    // this name should not override existinting properties or at least
    // display a warning
    function someAction ({ commit, firebase: { foo, bindRef } }) {
      foo === 'staticProperty'
      bindRef()
    }
    

    Merging in a plugins property would prevent plugins to break with future releases of Vuex (as pointed out by @ktsn) but also make it impossible for them to overwrite the commit function or any other

    Adding actions, mutations and getters

    Differently from adding to context, when adding actions, mutations or getters, you may want to add them to a specific module (imagine something like `plugins: [MyPlugin('moduleA', 'moduleB'). You may also want to add it to every module existing. This would be the case for VuexFire, allowing it to use the context-specific commit functions to allow the user to bind firebase references in any module.

    // We should use the same name of context
    mergeInModule((modulePath, context) => ({
      mutations: {
        // Dynamic names
        [`${modulePath.join('/')}/myPluginName/MUTATION`] (state) { // state.foo = 'bar' }
      }
    }))
    

    I'm not sure about what to do with the namespace. I think not using it may be safer since plugins relying on it to register different mutations would fail

    Extra things in this PR:

    • Added a context to the rootStore (same as modules) accessible as store.context
    • Moved plugin test to plugin.spec.js
    opened by posva 33
  • mapState alias for child state?

    mapState alias for child state?

    The mapState alias supports one-level only.

    Can we support the child state with the alias like this:

    computed: mapState
    ({
        screen: 'homepage.screen'
    })
    

    Instead of doing this?

    computed: mapState
    ({
        screen: state => state.homepage.screen
    })
    
    2.x 
    opened by YamiOdymel 32
  • build(deps): bump json5 from 1.0.1 to 1.0.2

    build(deps): bump json5 from 1.0.1 to 1.0.2

    Bumps json5 from 1.0.1 to 1.0.2.

    Release notes

    Sourced from json5's releases.

    v1.0.2

    • Fix: Properties with the name __proto__ are added to objects and arrays. (#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (#295). This has been backported to v1. (#298)
    Changelog

    Sourced from json5's changelog.

    Unreleased [code, diff]

    v2.2.3 [code, diff]

    v2.2.2 [code, diff]

    • Fix: Properties with the name __proto__ are added to objects and arrays. (#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (#295).

    v2.2.1 [code, diff]

    • Fix: Removed dependence on minimist to patch CVE-2021-44906. (#266)

    v2.2.0 [code, diff]

    • New: Accurate and documented TypeScript declarations are now included. There is no need to install @types/json5. (#236, #244)

    v2.1.3 [code, diff]

    • Fix: An out of memory bug when parsing numbers has been fixed. (#228, #229)

    v2.1.2 [code, diff]

    ... (truncated)

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 1
  • [Vuex] Store.commit() persists all pending changes on object lists, even if method does nothing

    [Vuex] Store.commit() persists all pending changes on object lists, even if method does nothing

    Version

    Vue: 2.6.14 Vuex: 3.5.1

    Description

    We did not find any documentation of the behavior we encountered with the store's commit() method when working with a list of objects, so we do not know what to make of it.

    It seems like any call to commit() persists all pending changes to the state, even if the method called in commit() does not do anything.

    In the example below, when editing one of the fields and clicking "Commit nothing", the changes are persisted in the state, even though the store's doNothing() method did not do anything.

    The Vuex "Mutations" page does not address this at all, hence we wonder, is this a bug or intended behavior? In case of the latter, it should be documented and emphasized on the "Mutations" page, because it is very unintuitive.

    Example

    example.vue

    <template>
      <div>
        <div>
          <input v-model="computedObject.string"/>
          <input type="number" v-model="computedObject.number"/>
        </div>
    
        <div>
          <div>computedObject.string: {{ computedObject.string }}</div>
          <div>computedObject.number: {{ computedObject.number }}</div>
        </div>
        
        <button @click="clearList">Clear list</button>
        <button @click="resetList">Reset list</button>
        <button @click="commitNothing">Commit nothing</button>
      </div>
    </template>
    
    <script>
    export default {
      name: "example",
      methods: {
        clearList() {
          this.$store.commit("clearList");
        },
        resetList() {
          this.$store.commit("resetList");
        },
        commitNothing() {
          this.$store.commit("doNothing");
        },
      },
      computed: {
        computedObject() {
          return this.$store.state.someList.at(-1) ?? {};
        },
      },
    }
    </script>
    

    store.js

    import Vue from "Modules/vue";
    import Vuex from "Modules/vuex";
    
    Vue.use(Vuex);
    
    export default new Vuex.Store({
        state: {
            someList: [{
                string: "Hello World!",
                number: 123,
            }],
        },
        
        mutations: {
            clearList(state) {
                state.someList = [];
            },
    
            resetList(state) {
                state.someList = [{
                    string: "Hello World!",
                    number: 123,
                }];
            },
    
            doNothing() {
                console.log("I did nothing.");
            },
        },
    });
    
    opened by enloc-port 0
  • fix: keep computed getter be reactive after registering new modules

    fix: keep computed getter be reactive after registering new modules

    close: #2197

    The computed getters will be unreactive after registering modules,

    Approach:

    When stopping effectScope, only stop the effect that has no dependencies.

    opened by Azurewarth0920 8
  • build(deps): bump decode-uri-component from 0.2.0 to 0.2.2

    build(deps): bump decode-uri-component from 0.2.0 to 0.2.2

    Bumps decode-uri-component from 0.2.0 to 0.2.2.

    Release notes

    Sourced from decode-uri-component's releases.

    v0.2.2

    • Prevent overwriting previously decoded tokens 980e0bf

    https://github.com/SamVerschueren/decode-uri-component/compare/v0.2.1...v0.2.2

    v0.2.1

    • Switch to GitHub workflows 76abc93
    • Fix issue where decode throws - fixes #6 746ca5d
    • Update license (#1) 486d7e2
    • Tidelift tasks a650457
    • Meta tweaks 66e1c28

    https://github.com/SamVerschueren/decode-uri-component/compare/v0.2.0...v0.2.1

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 1
Releases(v4.0.2)
  • v4.0.2(Jun 17, 2021)

  • v4.0.1(May 24, 2021)

  • v4.0.0(Feb 2, 2021)

    This is the official Vuex 4 release.

    The focus for Vuex 4 is compatibility. Vuex 4 supports Vue 3, and it provides the exact same API as Vuex 3, so users can reuse their existing Vuex code with Vue 3.

    There are a few breaking changes described in a later section, so please check them out.

    You can find basic usage with both Option and Composition API in the example directory.

    It's still released under next tag in NPM package as same as Vue 3. We're planning to remove next tag once Vue 3 is ready to remove it.

    There have been a lot of contribution to make Vuex 4 stable. Thank you all for your very much appreciated help. It wouldn't have been possible without this wonderful Vue community!

    Documentation

    To check out docs, visit next.vuex.vuejs.org.

    Breaking changes

    Installation process has changed

    To align with the new Vue 3 initialization process, the installation process of Vuex has changed.

    To create a new store instance, users are now encouraged to use the newly introduced createStore function.

    import { createStore } from 'vuex'
    
    export const store = createStore({
      state() {
        return {
          count: 1
        }
      }
    })
    

    Whilst this is not technically a breaking change, you may still use the new Store(...) syntax, we recommend this approach to align with Vue 3 and Vue Router 4.

    To install Vuex to a Vue instance, pass the store instance instead of Vuex.

    import { createApp } from 'vue'
    import { store } from './store'
    import App from './App.vue'
    
    const app = createApp(App)
    
    app.use(store)
    
    app.mount('#app')
    

    Bundles are now aligned with Vue 3

    The following bundles are generated to align with Vue 3 bundles:

    • vuex.global(.prod).js
      • For direct use with <script src="..."> in the browser. Exposes the Vuex global.
      • Global build is built as IIFE, and not UMD, and is only meant for direct use with <script src="...">.
      • Contains hard-coded prod/dev branches and the prod build is pre-minified. Use the .prod.js files for production.
    • vuex.esm-browser(.prod).js
      • For use with native ES module imports (including module supporting browsers via <script type="module">.
    • vuex.esm-bundler.js
      • For use with bundlers such as webpack, rollup and parcel.
      • Leaves prod/dev branches with process.env.NODE_ENV guards (must be replaced by bundler).
      • Does not ship minified builds (to be done together with the rest of the code after bundling).
    • vuex.cjs.js
      • For use in Node.js server-side rendering with require().

    Typings for ComponentCustomProperties

    Vuex 4 removes its global typings for this.$store within Vue Component to solve issue #994. When used with TypeScript, you must declare your own module augmentation.

    Place the following code in your project to allow this.$store to be typed correctly:

    // vuex-shim.d.ts
    
    import { ComponentCustomProperties } from 'vue'
    import { Store } from 'vuex'
    
    declare module '@vue/runtime-core' {
      // Declare your own store states.
      interface State {
        count: number
      }
    
      interface ComponentCustomProperties {
        $store: Store<State>
      }
    }
    

    createLogger function is exported from the core module

    In Vuex 3, createLogger function was exported from vuex/dist/logger but it's now included in the core package. You should import the function directly from vuex package.

    import { createLogger } from 'vuex'
    

    Bug Fixes Included Since 4.0.0-rc.2

    Source code(tar.gz)
    Source code(zip)
  • v3.6.2(Jan 26, 2021)

  • v3.6.1(Jan 26, 2021)

  • v4.0.0-rc.2(Nov 25, 2020)

  • v3.6.0(Nov 25, 2020)

  • v4.0.0-rc.1(Oct 30, 2020)

  • v4.0.0-beta.4(Jun 29, 2020)

  • v4.0.0-beta.3(Jun 29, 2020)

  • v3.5.1(Jun 29, 2020)

  • v3.5.0(Jun 29, 2020)

  • 4.0.0-beta.2(May 11, 2020)

  • v3.4.0(May 11, 2020)

  • v4.0.0-beta.1(Apr 25, 2020)

    Features

    • Added TypeScript support.

    Breaking Changes

    Bundles are now aligned with Vue 3

    The bundles are generated as below to align with Vue 3 bundles.

    • vuex.global(.prod).js
      • For direct use via <script src="..."> in the browser. Exposes the Vuex global.
      • Note that global builds are not UMD builds. They are built as IIFEs and is only meant for direct use via <script src="...">.
      • Contains hard-coded prod/dev branches, and the prod build is pre-minified. Use the .prod.js files for production.
    • vuex.esm-browser(.prod).js
      • For usage via native ES modules imports (in browser via <script type="module">.
    • vuex.esm-bundler.js
      • For use with bundlers like webpack, rollup and parcel.
      • Leaves prod/dev branches with process.env.NODE_ENV guards (must be replaced by bundler).
      • Does not ship minified builds (to be done together with the rest of the code after bundling).
    • vuex.cjs.js
      • For use in Node.js server-side rendering via require().

    Typings for ComponentCustomProperties

    Vuex 4 removes its global typings for this.$store within Vue Component due to solving issue #994. When using TypeScript, you must provide your own augment declaration.

    Please place the following code in your project to have this.$store working.

    // vuex-shim.d.ts
    
    declare module "@vue/runtime-core" {
      // Declare your own store states.
      interface State {
        count: number
      }
    
      interface ComponentCustomProperties {
        $store: Store<State>;
      }
    }
    
    Source code(tar.gz)
    Source code(zip)
  • v3.3.0(Apr 25, 2020)

  • v3.2.0(Apr 19, 2020)

  • v4.0.0-alpha.1(Mar 15, 2020)

    This is the Vue 3 compatible version of Vuex. The focus is compatibility, and it provides the exact same API as Vuex 3, so users can reuse their existing Vuex code for Vue 3.

    Status: Alpha

    All Vuex 3 feature works. There are a few breaking changes described in a later section, so please check them out. You can find basic usage with both option and composition API at example folder.

    Please note that it's still unstable, and there might be bugs. Please provide us feedback if you find anything. You may use vue-next-webpack-preview to test out Vue 3 with Vuex 4.

    Breaking changes

    Installation process has changed

    To align with the new Vue 3 initialization process, the installation process of Vuex has changed as well.

    You should use a new createStore function to create a new store instance.

    import { createStore } from 'vuex'
    
    const store = createStore({
      state () {
        return {
          count: 1
        }
      }
    })
    

    This is technically not a breaking change because you could still use new Store(...) syntax. However, to align with Vue 3 and also with Vue Router Next, we recommend users to use createStore function instead.

    Then to install Vuex to Vue app instance, pass the store instance instead of Vuex.

    import { createApp } from 'vue'
    import store from './store'
    import App from './APP.vue'
    
    const app = createApp(Counter)
    
    app.use(store)
    
    app.mount('#app')
    

    Kown issues

    • The code is kept as close to Vuex 3 code base as possible, and there're plenty of places where we should refactor. However, we are waiting for all of the test cases to pass before doing so (some tests require Vue 3 update).
    • TypeScript support is not ready yet. Please use JS environment to test this for now.
    Source code(tar.gz)
    Source code(zip)
  • v3.1.3(Mar 9, 2020)

  • v3.1.2(Nov 10, 2019)

    Bug Fixes

    • types: avoid broadening vue instance type when using map helpers (#1639) (9a96720) (@ktsn)

    Improvements

    • warn when the different namespaced modules has the same namespace (#1554) (91f3e69) (@liyangworld)
    • warn when mapXXX helpers receives an invalid parameter #1093 (#1297) (e5ca2d5) (@EdyHartono)
    • warn when registered module conflicts with existing parent module state (#1365) (538ee58) (@simplesmiler)

    Performance Improvements

    • cache getters object in an action context of a namespaced module (#1546) (4003382) (@frankcs)
    Source code(tar.gz)
    Source code(zip)
  • v3.1.1(May 8, 2019)

  • v3.1.0(Jan 17, 2019)

    Features

    • store.subscribeAction can now specify whether the handler should be invoked before the action, after the action, or both. 76818c1 (#1115 by @wa3l)

    Improvements

    • Errors thrown inside action subscribers no longer cause the entire action to fail.
    Source code(tar.gz)
    Source code(zip)
  • v3.0.1(Nov 3, 2017)

  • v3.0.0(Oct 11, 2017)

    Breaking Changes

    This major release only breaks backwards compatibility if you use TypeScript.

    • TypeScript type declarations have been updated to be compatible with Vue core 2.5+ and no longer work with 2.4 and below.

    • All type declarations are now exported using ES-style exports, and must be imported using ES modules syntax:

      import { Store } from 'vuex'
      
    Source code(tar.gz)
    Source code(zip)
  • v2.5.0(Oct 11, 2017)

    New

    • store.registerModule can now be called while preserving current state if the module is already registered, by passing a 3rd argument as { preserveState: true }. Useful in server-side rendering.

    • New method: store.subscribeAction() - similar to store.subscribe, but for actions instead.

    • Namespaced modules can now also register global actions using the following syntax:

      const module = {
        actions: {
          rootAction: {
            root: true,
            handler: () => {}
          } 
        }
      }
      
    • The createLogger function now also accepts a logger option, allowing the user to provide a custom implementation of the console object to be used when logging.

    Source code(tar.gz)
    Source code(zip)
  • v2.4.1(Sep 27, 2017)

    Fixed

    • Allow installation on different copies of Vue for testing purposes
    • Fix #731 by moving auto installation code into the store constructor (#914)
    Source code(tar.gz)
    Source code(zip)
  • v2.4.0(Aug 29, 2017)

    New

    • New helper method createNamespacedHelpers: a helper-generator that generates namespaced mapXXX helpers for you:

      const { mapState, mapActions } = createNamespacedHelpers('some/nested/module')
      // everything generated by mapState and mapActions are bound to the module.
      

      See docs for more info.

      (@riophae via #800)

    Misc

    • Various typing and assertion improvements.
    Source code(tar.gz)
    Source code(zip)
  • v2.3.0(Apr 13, 2017)

    • Modules can now declare state using a function - this allows the same module definition to be reused (e.g. multiple times in the same store, or in multiple stores)
    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Feb 26, 2017)

  • v2.1.2(Feb 6, 2017)

    Fixed

    • #524 avoid firing unrelated watchers when calling registerModule (@ktsn)
    • #528 ensure module local state always refers to actual state (@ktsn)
    Source code(tar.gz)
    Source code(zip)
:tada: A magical vue admin https://panjiachen.github.io/vue-element-admin

English | 简体中文 | 日本語 | Spanish SPONSORED BY 活动服务销售平台 客户消息直达工作群 Introduction vue-element-admin is a production-ready front-end solution for admin inter

花裤衩 80.1k Dec 31, 2022
:eyes: Vue in React, React in Vue. Seamless integration of the two. :dancers:

vuera NOTE: This project is looking for a maintainer! Use Vue components in your React app: import React from 'react' import MyVueComponent from './My

Aleksandr Komarov 4k Dec 30, 2022
🎉 基于 vite 2.0 + vue 3.0 + vue-router 4.0 + vuex 4.0 + element-plus 的后台管理系统vue3-element-admin

vue3-element-admin ?? 基于 Vite 2.0 + Vue3.0 + Vue-Router 4.0 + Vuex 4.0 + element-plus 的后台管理系统 简介 vue3-element-admin 是一个后台前端解决方案,它基于 vue3 和 element-plu

雪月欧巴 84 Nov 28, 2022
Jenesius vue modal is simple library for Vue 3 only

Jenesius Vue Modal Jenesius vue modal is simple library for Vue 3 only . Site Documentation Installation npm i jenesius-vue-modal For add modals in yo

Архипцев Евгений 63 Dec 30, 2022
A template repository / quick start to build Azure Static Web Apps with a Node.js function. It uses Vue.js v3, Vue Router, Vuex, and Vite.js.

Azure Static Web App Template with Node.js API This is a template repository for creating Azure Static Web Apps that comes pre-configured with: Vue.js

Marc Duiker 6 Jun 25, 2022
Mosha-vue-toastify - A light weight and fun Vue 3 toast or notification or snack bar or however you wanna call it library.

Mosha Vue Toastify A lightweight and fun Vue 3 toast or notification or snack bar or however you wanna call it library. English | 简体中文 Talk is cheap,

Baidi Liu 187 Jan 2, 2023
A plugin that can help you create project friendly with Vue for @vue/cli 4.5

vue-cli-plugin-patch A plugin that can help you create project friendly with Vue for @vue/cli 4.5. Install First you need to install @vue/cli globally

null 2 Jan 6, 2022
Veloce: Starter template that uses Vue 3, Vite, TypeScript, SSR, Pinia, Vue Router, Express and Docker

Veloce Lightning-fast cold server start Instant hot module replacement (HMR) and dev SSR True on-demand compilation Tech Stack Vue 3: UI Rendering lib

Alan Morel 10 Oct 7, 2022
The state manager ☄️

☄️ effector The state manager Table of Contents Introduction Effector follows five basic principles: Installation Documentation Packages Articles Comm

effector ☄️ 4.1k Jan 9, 2023
Prefetch and sync state to client with one line of code, out-of-the-box

vue3-SSR-starter Prefetch and sync state to client with one line of code, out-of-the-box Features vue3 SSR vue-router we don't need vuex anymore one l

周子贤 36 Aug 28, 2022
Carpatin is a React JS Admin Dashboard Template that focuses on the management flows of a back-office application. We leverage the Material-UI power of stylizing the components in a way that feels more professional.

Carpatin Dashboard Free Carpatin is a React Js Admin Dashboard Template that focuses on the management flows of a back-office application. We leverage

Devias 64 Dec 12, 2022
A library for creating typesafe standardized query keys, useful for cache management in @tanstack/query

Query Key Factory Typesafe query key management for @tanstack/query with auto-completion features. Focus on writing and invalidating queries without t

Luke Morales 446 Jan 3, 2023
📓 The UI component explorer. Develop, document, & test React, Vue, Angular, Web Components, Ember, Svelte & more!

Build bulletproof UI components faster Storybook is a development environment for UI components. It allows you to browse a component library, view the

Storybook 75.9k Jan 9, 2023
A Vue.js 2.0 UI Toolkit for Web

A Vue.js 2.0 UI Toolkit for Web. Element will stay with Vue 2.x For Vue 3.0, we recommend using Element Plus from the same team Links Homepage and doc

饿了么前端 53k Jan 3, 2023
The Intuitive Vue Framework

Build your next Vue.js application with confidence using Nuxt: a framework making web development simple and powerful. Links ?? Documentation: https:/

Nuxt 41.8k Jan 5, 2023
🐉 Material Component Framework for Vue

Supporting Vuetify Vuetify is a MIT licensed project that is developed and maintained full-time by John Leider and Heather Leider; with support from t

vuetify 36.2k Jan 3, 2023
🛠️ Standard Tooling for Vue.js Development

Vue CLI Vue CLI is the Standard Tooling for Vue.js Development. Documentation Docs are available at https://cli.vuejs.org/ - we are still working on r

vuejs 29.6k Jan 4, 2023
A high quality UI Toolkit built on Vue.js 2.0

iView A high quality UI Toolkit built on Vue.js. Docs 3.x | 2.x | 1.x Features Dozens of useful and beautiful components. Friendly API. It's made for

iView 24k Jan 5, 2023
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

vue-next This is the repository for Vue 3.0. Quickstart Via CDN: <script src="https://unpkg.com/vue@next"></script> In-browser playground on Codepen S

vuejs 34.6k Jan 9, 2023