How is this different from vuex-module-decorators

[IceSentry]

github.com/championswimmer/vuex-module-decorators/

Looks almost identical with maybe a few more features and a less verbose API. Why would I use your library instead?

[michaelolof]

You don't have to use it if you don't want to.

I wrote this because I didn't like the way vuex-module-decorators was handling Vuex actions since it was adding extra complexity with things like @mutateActions decorators etc.

If you like that library better use it. They are both open source.

[IceSentry]

It's not that I don't want to use it. I actually like your proposed pattern of a vuex manager object. I was just curious what difference there were to make a more informed decision. I currently use vuex-module-decorators, but since I liked the vuex manager pattern I was wondering if there were other reason to switch.

[asmadsen]

@IceSentry I also used the other alternative you mentioned before, and the main reason for my switch is that this library provides a proxy for the store modules so you won't loose the typings when using the module throughout the app.

In other words, the other one allows you define vuex modules using classes, whilst this one also gives you a way to use them afterwards in a way that you don't loose the type information.

[IceSentry]

That's very much a feature of vuex-module-decorators too. Maybe it wasn't when you used it though. The syntax is also slightly less verbose and doesn't require to pass the class a second time. After re-reading the docs I feel like vuex-class-component actually has a simpler api for actions/mutations, although I'm not sure I like the fact that you can mutate in an action by default.

[michaelolof]

Hello @IceSentry

I'm sorry if my initial tone sounded harsh. That was not my intent.

Just like you guys I also looked at vuex-module-decorators and honestly, I would have loved to continue with it until i saw how Vuex actions were implemented. I felt it was adding extra clutter to how you would not normally find in Vuex. I wanted something traditional Vuex users could easily pick up the library without having to learn additional things that were only library specific.

I generally try to stay away from discussions like this cause they can come off as criticisms which is not something I want to do.

I honestly think they are both fantastic libraries. Anybody who cares about type safe Vuex state management should have a look at them.

You just have to pick the one you like the most.

Thanks.

[michaelolof]

I'm not sure I like the fact that you can mutate in an action by default.

I'm not sure I understand what you mean. commit calls are very possible in Vuex actions.

[IceSentry]

Sorry if I wasn't clear.

What I mean is that mutating by doing this.counter += 1 in an action is possible. I like strict mode where every state change is done in mutations. What I don't like is that, at least from first glance, you can directly affect the state from an action and could essentially only use actions in mutate mode and never use mutations.

In standard vuex with strict mode, you would need to commit a specific mutation, you are not supposed to change the state directly. You are right that it is possible to do this in vuex and your library should probably stay as close as possible to vuex and therefore allow that.

Now that I think about it more I don't think it's possible to block state changes from actions using decorators.

Anyway, thanks for the response and I'm considering switching to this library since I think overall it looks like a simpler and more direct API. I understand why you prefer to stay away from these kind of discussions.