Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
If for whatever reason the team decides to change the state management library, this tight coupling will make such a task pretty difficult. "But we would never do that!" you may be thinking. You may be right... but you do want to update to newer versions of the same library, don't you? Well, Kia King said it himself, "... consider Pinia as Vuex 5 with a different name". Whenever is time to make that upgrade, you'll wish you had your state management loosely coupled.
The issue here is that the state management library is taking in more responsibility than it has to. The state management library should ideally only be used for state management. This effectively means that all the code in your Vuex stores should only pertain to the issue of state management. It shouldn't be the store's responsibility to run unrelated side-effects, format the data for components, make API calls... All of which you can find throughout Vuex actions in many codebases. This leads to Vuex stores growing to immense complexity even for relatively simple apps (I have certainly been guilty of this in the past).
I tried to think of an example domain class with a useful method that uses a bit of all the ingredients I showed in the screenshot above (exceptions, types, enums, constants). Here is the codebase source. There's quite a few things to unpack here.