vuex状态管理几种状态
If you’ve tried to use Vuex with TypeScript, you’ll have realized that it’s not such a straightforward task. Vuex doesn’t provide tooling for working with TypeScript out of the box. TypeScript is important for many of us because it allows us to write statically typed JavaScript, with the main benefit being improved development experience via IDE type hits.
如果您尝试将Vuex与TypeScript一起使用，您将意识到这并不是一件容易的事。 Vuex不提供开箱即用的TypeScript工具。 TypeScript对我们许多人来说都很重要，因为它使我们能够编写静态类型JavaScript，主要好处是可以通过IDE类型匹配来改善开发体验。
What we want to accomplish is type-safe Vuex modules that inform us when we’re passing the wrong mutation/getter/action type or the wrong arguments — and this is possible in a couple of different ways. We will take a look at making this work with no external libraries, and then we’ll evaluate the options currently out there. Finally, we’ll make a rather subjective determination of which one is the cleanest.
我们想要实现的是类型安全的Vuex模块，当我们传递错误的突变/获取方法/操作类型或错误的参数时，这些模块会通知我们-这可以通过两种不同的方式实现。 我们将看看在没有外部库的情况下如何进行这项工作，然后我们将评估当前可用的选项。 最后，我们将比较主观地确定哪一个最干净。
These are the options we’ll be trying:
这些是我们将尝试的选项：
Even though Vue 3 is around the corner, along with the corresponding Vuex 4, usage won't vary from the Vuex side, as its changes are mostly related to Vue 3 compatibility. To clear up any confusion, Vue 3’s Reactivity API is not meant to replace Vuex. It just provides better tooling to handle those cases in which Vuex is already not necessary.
即使Vue 3以及相应的Vuex 4即将来临，其用法在Vuex方面也不会有所不同，因为其更改主要与Vue 3的兼容性有关。 为了消除任何混淆，Vue 3的Reactivity API不能替代Vuex。 它只是提供了更好的工具来处理那些已经不需要Vuex的情况。
With that said, there was a talk at Vue.js Global Online Conference that outlines the roadmap for Vuex 5. It will have no mutations, just actions, and new ways to define/register stores, including regular composition API. With these changes, none of the outlined options here will be necessary for TypeScript integration. Unfortunately, it isn’t likely to ship until sometime in 2021, as there isn’t even an RFC for it yet.
如此说来，在Vue.js全球在线会议上有一个演讲，概述了Vuex 5的路线图。它将没有任何变化，只有动作，以及定义/注册商店的新方法，包括常规的成分API。 进行了这些更改之后，TypeScript集成将不需要此处列出的所有选项。 不幸的是，它不可能在2021年的某个时候发布，因为它甚至还没有RFC。
Enough talking, let’s write some code. Feel free to go straight to the live example to see for yourself the different options at work in this sandbox, or take a look at this repo.
建立 (Setup)
It’s important to note that Vuex separates functionality in modules. These modules are defined independently from one another and are meant for representing logical groups of information and corresponding functionality. Let’s define some common types:
重要的是要注意，Vuex在模块中分离了功能。 这些模块是相互独立定义的，用于表示逻辑信息组和相应功能。 让我们定义一些常见的类型：
Each module will have a persons property that will be a mapping between the person’s id and its Person. We’ll have an action that’ll populate this property with static data and a getter that aggregates a persons’s name and lastName.
每个模块都有一个persons属性，该属性将是person的id和其Person之间的映射。 我们将执行一个操作，该操作将使用静态数据填充此属性，并执行一个将人的name和name汇总在一起的getter lastName.
This is what our stores file will look like in Vue 2/Vuex 3:
这是我们的stores文件在Vue 2 / Vuex 3中的外观：
Vue 3/Vuex 4:
Vue 3 / Vuex 4：
We have two stores here because plainStore will be typed entirely, passed into the Vue constructor, and accessed directly or through the $store property in Vue component instances. But modulesStore will not be registered, and its modules will be imported separately. The Vuex.Store constructors/createStore methods are being passed empty objects because we will register the modules dynamically.
我们在这里有两个商店，因为plainStore将被完全键入，传递到Vue构造函数中，并直接访问或通过Vue组件实例中的$store属性进行访问。 但是modulesStore不会被注册，并且其模块将单独导入。 Vuex.Store构造函数/ createStore方法被传递给空对象，因为我们将动态注册模块。
Our main.ts in Vue 2/Vuex 3:
我们main.ts在Vue公司2/3 Vuex：
Vue 3/Vuex 4:
Vue 3 / Vuex 4：
I will later explain where the PlainStore type comes from. For demonstration purposes, the Vue component definitions will be using vue-property-decorator, which depends on vue-class-component, although the usage would be the same with composition API.
稍后我将解释PlainStore类型的来源。 为了演示起见，Vue组件定义将使用vue-property-decorator ，它取决于vue-class-component ，尽管用法与composition API相同。
1.平原 (1. Plain)
You can indeed accomplish a fully typed Vuex store with no external libraries. We’ll need to define these types for the plain store:
您确实可以完成没有外部库的全类型Vuex存储。 我们需要为普通商店定义以下类型：
PersonModule: Will be the type of the plain Vuex moduleRootState: Will be the type of the root state (the state for plainStore). We will stick the plain module into the plain property of the root state.
PersonModule ：将是plain Vuex模块的类型RootState ：将是根状态的类型( plainStore的状态)。 我们将普通模块粘贴到根状态的plain属性中。
Now we can write the mutations:
现在我们可以写出突变了：
MutationTypes: An enum with the name of the mutations. We do this to avoid having to type mutation names manually across the application and get auto-completion functionality in the IDE.
MutationTypes ：一个带有突变名称的enum 。 我们这样做是为了避免在应用程序中手动键入突变名称并在IDE中获得自动完成功能。
Mutations: The definition of mutations’ type signatures. This is needed for type-safe implementation of only these defined mutations and so that we can construct the more complex PlainStore type later on.
Mutations ：突变类型签名的定义。 仅对这些定义的突变进行类型安全的实现才PlainStore稍后我们可以构造更复杂的PlainStore类型。
mutations: The mapping of mutation names to their implementation. At this point, we will be getting type-checking for the parameters state and persons, thanks to the union between Vuex’s built-in type MutationTree and our Mutations type.
mutations ：突变名称与其实现的映射。 在这一点上，由于Vuex的内置类型MutationTree和我们的Mutations类型之间的结合，我们将对参数state和persons进行类型检查。
The getters follow a similar approach:
吸气剂遵循类似的方法：
Now actions, which have an added component:
现在的动作，它具有一个附加的组件：
When you define an action function in Vuex, the first parameter is of type ActionContext which contains a commit function. This function allows you to trigger mutations defined in the current module (or any other module, if {root: true} is specified). The default type of this commit function lets you call commit with any string. We want to restrict this so that commit can only be called with the mutations defined in our module.
在Vuex中定义动作函数时，第一个参数的类型为ActionContext ，其中包含commit函数。 此功能允许您触发在当前模块(或任何其他模块，如果指定了{root: true} )中定义的突变。 此提交函数的默认类型允许您使用任何字符串调用commit 。 我们希望对此进行限制，以便只能使用模块中定义的突变来调用commit 。
This is accomplished by augmenting the default ActionContext and modifying the type of the commit function accordingly. Keep in mind that if you want to call global mutations or mutations from other modules, specifying {root: true} in commit functions from within actions, you have to aggregate all of the mutations and use that to augment the ActionContext instead of just the mutations from this module like we’re doing here. (I do this below to create the PlainStore type.)
这可以通过增加默认的ActionContext并相应地修改commit函数的类型来实现。 请记住，如果要调用全局突变或其他模块的突变，请在动作内部的commit函数中指定{root: true} ，则必须汇总所有突变，并使用它们来增强ActionContext而不仅仅是突变从这个模块开始，就像我们在这里所做的一样。 (我在下面执行此操作以创建PlainStore类型。)
Now that we’ve successfully defined our Vuex module, we have to register it on the store:
现在，我们已经成功定义了Vuex模块，我们必须在商店中注册它：
The last thing we need to do is construct the PlainStore type, which is the type of the actual store on which you access state, commit, dispatch, and getters. We want these properties to be type-checked and get errors if we try to access non-existent state or getters, or call commit or dispatch, with the wrong type or parameter.
我们需要做的最后一件事是构造PlainStore类型，这是您在其上访问state ， commit ， dispatch和getters的实际商店的类型。 如果我们尝试访问不存在的state或getters ，或者使用错误的type或参数调用commit或dispatch ，则我们希望对这些属性进行类型检查并获得错误。
To define PlainStore, we want to gather all of the mutations, getters, and actions from all of our modules and merge them through union with TypeScript’s & operator.
为了定义PlainStore ，我们想要收集所有的变异，获取器和动作 从我们所有的模块中合并，并通过与TypeScript的&运算符进行合并来合并它们。
We’re done defining and registering the Plain person module. We have two options on how to access it in our components. We can access it through this.$store (injected) or we can import the store directly in each component (imported).
我们就大功告成了定义和注册Plain人模块。 关于如何在组件中访问它，我们有两个选择。 我们可以通过this.$store (注入)访问它，也可以直接在每个组件中(导入)导入商店。
已注入 (Injected)
To have access to our typed store through this.$store, we’d need to override Vuex’s default $store type definition, which is currently only supported in Vuex 4 (with Vue 3), so if that’s you, all you need to do is:
要通过this.$store访问我们的类型化存储，我们需要覆盖Vuex的默认$store类型定义，当前仅在Vuex 4(与Vue 3)中受此支持，因此，如果是这样，您需要做的所有事情是：
But if you’re using Vuex 3 (with Vue 2), you need to create another property, as you can’t override $store typings. We can call it $vuex (or anything else):
但是，如果您使用的是Vuex 3(与Vue 2)，则需要创建另一个属性，因为您无法覆盖$store 。 我们可以称它为$vuex (或其他任何东西)：
And then we need to define the actual property, which would just be a getter for $store:
然后，我们需要定义实际属性，该属性只是$store的吸气剂：
Then you could access either $store or $vuex (depending on what you did above) like so:
然后，您可以访问$store或$vuex (取决于您在上面所做的工作)，如下所示：
进口的 (Imported)
This usage is much more straight forward because we exported the store with its PlainStore type, so we can just import it and use it directly:
这种用法更为简单，因为我们以其PlainStore类型导出了商店，因此我们可以直接导入并直接使用它：
That’s with $vuex being fully typed in both Injected and Imported scenarios, as you would expect.
正如您所期望的那样，在“已注入”和“已导入”方案中都完全键入了$vuex 。
命名空间模块 (Namespaced modules)
How would this look if we wanted to namespace our Plain module? We would need to define separate enumerations and type signatures for each of our mutations, getters, and actions.
如果我们想为我们的Plain模块命名空间，外观会如何？ 我们将需要为每个突变，获取器和操作定义单独的枚举和类型签名。
The main problem is that inside our module definition, all of the name constants don’t use the namespace prefix, because they are localized. Outside the module definition, they do have the prefix. So inside of an action of a namespaced module, you can commit nameOfMutation, but if you want to commit it from a component, you’d have to commit prefix/nameOfMutation.
主要问题在于，在我们的模块定义中，所有名称常量都不使用名称空间前缀，因为它们已本地化。 在模块定义之外，它们确实具有前缀。 因此，在命名空间模块的操作内部，您可以提交nameOfMutation ，但是如果要从组件中提交它，则必须提交prefix/nameOfMutation 。
A recently merged (dev branch) TypeScript feature would theoretically allow us to construct the namespaced signatures dynamically, by means of template literal types. Unfortunately, I couldn’t make this work, so we’re stuck with redefining the signatures one by one.
从理论上讲，最近合并的(开发分支)TypeScript功能将允许我们通过模板文字类型来动态地构造命名空间的签名。 不幸的是，我无法完成这项工作，因此我们只能一步一步地重新定义签名。
I will implement this for mutations only, so you get an idea:
我将仅针对突变实施此方法，因此您有一个主意：
We had to define separate enums for our different mutations with and without the namespace prefix (internal ones without the prefix to use in the definition of this module, and external ones with the prefix to export and use elsewhere).
我们必须为带有和不带有名称空间前缀的内部变量定义单独的枚举(内部模块没有在此模块的定义中使用的前缀，外部模块则具有在其他模块中导出和使用的前缀)。
印象数 (Impressions)
That was quite painful. It’s so explicit if it was a song it would be banned in 69 countries. This approach would get out of hand very quickly with large modules. Not a pleasant experience.
那是非常痛苦的。 如果这首歌很明确，那么它将在69个国家/地区禁止播放。 对于大型模块，这种方法会很快失控。 不愉快的经历。
2. vuex级 (2. vuex-class)
The first third-party solution we’ll look at is vuex-class. Although it is technically a TypeScript library, it doesn’t really provide any tooling to actually implement type safety. Therefore, it unfortunately still requires a significant effort to implement properly at scale. You don’t need a typed store definition to use it because vuex-class doesn’t access it anyway. The type would be directly in the component:
我们将要研究的第一个第三方解决方案是vuex-class 。 尽管从技术上讲它是TypeScript库，但实际上并没有提供任何工具来实际实现类型安全。 因此，不幸的是，仍然需要大量的努力才能正确地大规模实施。 您不需要类型化的商店定义来使用它，因为vuex-class仍然无法访问它。 类型将直接在组件中：
The problem with this is that you need to define the type of each resource manually. If you’re using the same resources in different components, you’ll have the same types defined in each of them. This is not ideal at scale because the types among components can differ, so changing the implementation or type of any of those resources and not successfully updating every component that’s accessing it can cause bugs that don’t become immediately obvious, bugs which TypeScript is designed to prevent.
问题在于您需要手动定义每个资源的类型。 如果在不同的组件中使用相同的资源，则每个组件中都将定义相同的类型。 这在规模上并不理想，因为组件之间的类型可能不同，因此更改任何资源的实现或类型，并且未成功更新正在访问它的每个组件都可能导致错误不会立即变得显而易见，这些错误是TypeScript设计的阻止。
In order to effectively implement vuex-class, it’s best that we define, the same way we did with the plain approach above, the store resources with their type signatures. If we do that, we could then construct a type that aggregates the relevant resources for easy access:
为了有效地实现vuex类，最好以与上述普通方法相同的方式定义具有类型签名的商店资源。 如果这样做，那么我们可以构造一个类型，该类型汇总相关资源以便于访问：
Which we could then use in our component:
然后我们可以在组件中使用它：
But at this point, the juice is definitely not worth the squeeze.
但是在这一点上，榨汁绝对是不值得的。
印象数 (Impressions)
To use vuex-class effectively, significant manual labor is still required of us. Therefore, it provides no advantage over just using an imported store typed using the plain approach. vuex-class is not something I’d recommend any team using.
为了有效地使用vuex类，我们仍然需要大量的体力劳动。 因此，与仅使用通过普通方法键入的导入存储相比，它没有任何优势。 我不建议任何团队使用vuex类。
3. vuex-typex (3. vuex-typex)
The first library we’re going to look at to truly save us some keystrokes is vuex-typex. It has a composable API that prompts us to define everything separately and then bring it all together for the module definition.
我们真正要为我们节省一些击键次数的第一个库是vuex-typex 。 它具有可组合的API，提示我们分别定义所有内容，然后将所有内容放在一起进行模块定义。
The mutations and actions are defined like plain functions, but getters are defined through the module builder, either through b.read or b.state. Everything is put together into a constant that we later export. This API is rather confusing, though, because the thing from which we get the plain Vuex module that we register or the thing we associate the store to is not the module we just put together but the module builder. We’re registering the module using the Vuex store directly and then associating the module builder to the store.
突变和动作的定义类似于普通函数，但getters是通过模块构建器(通过b.read或b.state 。 一切都放到一个常量中，以后再导出。 但是，此API相当令人困惑，因为我们从中获得注册的普通Vuex模块或与商店关联的事物不是我们刚刚放在一起的模块，而是模块构建器。 我们正在直接使用Vuex商店注册模块，然后将模块构建器与商店关联。
This is how we’d use it in a component:
这就是我们在组件中使用它的方式：
印象数 (Impressions)
The API is a bit weird, all over the place, and not very clean looking. The module builder API is just not very intuitive, and it seems we have to call a bunch of functions on it to register stuff properly.
该API有点奇怪，到处都是，看起来也不是很干净。 模块构建器API并不是很直观，似乎我们必须在其上调用一堆函数才能正确注册内容。
4. vuex-smart-module (4. vuex-smart-module)
We’ll now explore a library made by one of Vuex’s core contributors, vuex-smart-module. It stays as close to the Vuex API as possible. This library namespaces modules by default. This is where things start getting interesting.
现在，我们将探索由Vuex的核心贡献者之一vuex-smart-module制作的库。 它保持尽可能接近Vuex API。 默认情况下，该库命名空间模块。 这是事情开始变得有趣的地方。
We can see that this is very close to how we would typically define our Vuex module. Instead of having an object for each type of resource, we would have a class with the resources as class functions/accessors.
我们可以看到，这与我们通常定义Vuex模块的方式非常接近。 代替为每种类型的资源都拥有一个对象，我们将拥有一个将资源作为类函数/访问器的类。
Once we’re done defining them, we pass them into the provided Module function, which assembles the resources. We’re registering the module with vuex-smart-module’s own registerModule function. It takes as arguments the store, the name of the path of this module within the root state, the path of the namespace, and finally, the module that we’re registering.
定义完它们之后，我们将它们传递到提供的Module函数中，该函数将组装资源。 我们正在使用vuex-smart-module自己的registerModule函数注册该模块。 它以存储state ，该模块在根state内的路径名称，名称空间的路径以及最后要注册的模块作为参数。
To export a ready-to-use Vuex module, the Module instance has a context method that returns the module associated with the passed-in store. We can import this module directly in our components:
要导出现成的Vuex模块， Module实例具有context方法，该方法返回与传入的商店关联的模块。 我们可以直接在我们的组件中导入该模块：
印象数 (Impressions)
This is a solid solution. It builds on top of, and respects, the original Vuex API, leveraging the power of classes, containing both type signature and implementation. It was made by the author of Vuex, so we know it’s robust.
这是一个坚实的解决方案。 它利用原始的Vuex API构建并尊重原始Vuex API，利用类的力量，同时包含类型签名和实现。 它是由Vuex的作者制作的，因此我们知道它很健壮。
5. vuex类组件 (5. vuex-class-component)
vuex-class-component uses class syntax as well to define the Vuex module, but it goes a step further by allowing us to define everything in one class. This class is then converted into a Vuex module object definition that can be used like any other. This library namespaces modules by default.
vuex-class-component也使用类语法来定义Vuex模块，但通过允许我们在一个类中定义所有内容，它又走了一步。 然后，该类将转换为Vuex模块对象定义，可以像其他任何对象一样使用。 默认情况下，该库命名空间模块。
That’s a breath of fresh air. As you can see, we are provided with the mutation and action decorators, which are used to create the resources of the same name from functions. Class properties become state properties, and get accessors become conventional class getters.
那是新鲜空气。 如您所见，我们提供了mutation和action修饰符，用于从函数创建同名的资源。 类属性变成状态属性，而get访问器变成常规的类getter。
This time we’re using Vuex’s own registerModule to dynamically register it into the store instance modulesStore. createProxy just returns a proxy to our module associated to the modulesStore.
这次，我们使用Vuex自己的registerModule将其动态注册到商店实例modulesStore 。 createProxy只是将代理返回到与modulesStore关联的模块。
It can be imported and used directly:
可以导入并直接使用：
The module is imported directly, type safety being ensured.
模块直接进口，确保型号安全。
印象数 (Impressions)
This is what we’ve always wanted: a clean way to define our Vuex modules, and full type safety when accessing them. Can this be topped? We’ll have to continue and see.
这就是我们一直想要的：一种定义Vuex模块的干净方法，以及在访问它们时的完整类型安全性。 能顶一下吗？ 我们必须继续观察。
6. vuex类模块 (6. vuex-class-modules)
vuex-class-modules is a fork of vuex-class-component. What it improves is just the way the class is defined:
vuex-class-modules是vuex-class-component的分支。 它所改进的只是类定义的方式：
When we compare it to the module definition of vuex-class-component, we can see that we now have a Module decorator and that we can use the same class we defined to create a new instance that will do two things: register the module in the store and return a usable, namespaced module (namespaced by default).
当将其与vuex-class-component的模块定义进行比较时，我们可以看到我们现在有了一个Module装饰器，并且可以使用定义的相同类来创建一个新的实例，该实例将执行以下两项操作：将模块注册到存储并返回一个可用的命名空间模块(默认情况下命名空间)。
The component usage would be the exact same as vuex-class-component.
组件的用法与vuex-class-componen t完全相同。
印象数 (Impressions)
It’s not too different from vuex-class-component. We just get more tools to save us a couple of keystrokes. Pretty solid.
它与vuex-class-component没有太大区别。 我们只是获得了更多的工具来节省几次按键操作。 很扎实
7. vuex-module-decorators(7. vuex-module-decorators)
vuex-module-decorators implements the same concept as the previous libraries (class syntax). However, we get a few more useful decorators.
vuex-module-decorators实现与以前的库相同的概念(类语法)。 但是，我们得到了更多有用的装饰器。
vuex-module-decorators provides a Module decorator that wraps our class and accepts some options. The store option will take care of associating this module to our modulesStore, and the name will be the property under which this module will live in the state, as well as its namespace (this library namespaces by default).
vuex-module-decorators提供了一个Module装饰器，该装饰器包装了我们的类并接受了一些选项。 store选项将负责将此模块与我们的modulesStore ，并且name将是该模块将在其状态下生存的属性及其名称空间(默认情况下为该库名称空间)。
vuex-module-decorators provides the getModule function, which will return a typed usable module that can be used the exact same way as vuex-class-component in our components.
vuex-module-decorators提供了getModule函数，它将返回一个类型化的可用模块，该模块可以与我们组件中的vuex-class-component完全相同地使用。
It has long been a pain point of Vuex, the fact that we need to create mutations for every property we want to change in the state. Through the very interesting decorator MutationAction, we don’t need to create a mutation if we just want to directly assign one or more state properties.
长期以来，这一直是Vuex的痛点，这一事实是，我们需要为要更改状态的每个属性创建突变。 通过非常有趣的装饰器MutationAction ，如果我们只想直接分配一个或多个状态属性，就不需要创建一个突变。
The properties contained in the object returned from the decorated function will be assigned directly to the corresponding state properties via a mutation that’s created under the hood. This is an impactful helper decorator that significantly improves the Vuex experience.
从修饰函数返回的对象中包含的属性将通过在引擎盖下创建的突变直接分配给相应的状态属性。 这是一个很有影响力的助手装饰器，可以大大改善Vuex体验。
印象数 (Impressions)
This one provides the most concise and compact API for defining and using Vuex modules, leveraging classes, and providing additional decorators with options, to make development easier.
这提供了最简洁，最紧凑的API，用于定义和使用Vuex模块，利用类以及为其他装饰器提供选项，从而使开发变得更加容易。
最干净 (Cleanest)
There’s no question about it. From all the options we discussed, vuex-module-decorators takes the cake. Its API is simple and gives us access to a feature (although emulated) that will not come until the release of Vuex 5: the merging of actions and mutations. It allows us to write the least code needed while not compromising on readability or usability.
毫无疑问。 在我们讨论过的所有选项中，vuex-module-decorators都是蛋糕。 它的API很简单，使我们可以访问一项功能(尽管已仿真)，该功能要等到Vuex 5发布后才能实现：动作和突变的合并。 它使我们能够编写最少的代码，同时又不影响可读性或可用性。
结论 (Conclusion)
When looking to integrate TypeScript into your store, if you don’t want to use any external libraries, the plain approach has got you covered (if you’re into that sort of thing; not sure why you would do that to yourself, though). If you want a better development experience, we have plenty of great options here.
当您希望将TypeScript集成到商店中时，如果您不想使用任何外部库，那么简单的方法就可以满足您的要求(如果您喜欢这种事情；虽然不确定为什么要自己这样做) )。 如果您想要更好的开发体验，我们在这里有很多不错的选择。
I wouldn’t personally recommend plain, vuex-class, or vuex-typex, as they could get out of hand very rapidly. But vuex-smart-module, vuex-class-decorator, vuex-class-modules, and vuex-module-decorators are all great alternatives that receive decent community acceptance, the most popular by far being vuex-module-decorators (and the recipient of my cleanest title). They’re also very much plug-and-play, so you don’t have to rewrite all your store modules, you can just define and dynamically register new ones.
我个人不会推荐使用普通，vuex类或vuex-typex，因为它们很快就会失控。 但是vuex-smart-module，vuex-class-decorator，vuex-class-modules和vuex-module-decorator都是获得不错的社区认可的绝佳选择，到目前为止，最受欢迎的是vuex-module-decorators(和接收者)我最干净的头衔)。 它们也是非常即插即用的，因此您不必重写所有商店模块，只需定义并动态注册新模块即可。
Again, you can see them live in this sandbox or take a look at the code.
Performance is a nonfactor for any of these libraries because in the end, they all build and register a regular old Vuex module.
对于这些库中的任何一个，性能都不重要，因为最后它们都将构建并注册一个常规的旧Vuex模块。
So don’t fear Vuex. Working with it can be delightful and simple, and you can benefit from great dev tools support, with real-time inspection and time-travel debugging.
因此，不要担心Vuex。 使用它可以轻松愉快，您可以受益于强大的开发工具支持，包括实时检查和时间旅行调试。
Now let’s go out there and start writing some clean, type-checked Vuex modules!
现在，让我们到那里开始编写一些经过类型检查的干净Vuex模块！
翻译自: https://medium.com/better-programming/the-state-of-typed-vuex-the-cleanest-approach-2358ee05d230
vuex状态管理几种状态
269
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
