Vuex over hyped?

I fell into the boat where Vuex was top dog and sure it has it great features but I think for a new learner saying run it thru store actions set state is just over kill.

Why not get data in components? Who says its wrong? I say its wrong to say its wrong… Why dispatch an action to call another action to do the same thing you can do from point A?

I’m going to call an action for Tim to go to the Vuex store to tell Jim to go get milk then when he gets back tell everyone i got milk? Why cant Tim just go get milk himself?

Makes no sense to me. Why is it “wrong” to do it direct from point A without all the over head of tell this to do that just to return it back to point A?

I want a burger from McDonalds, I am here but I need to tell my friend Joe to go order it for me? I don’t know to me it sounds so foolish.

And all this side stuff about api services getUser() / editUser() is so foolish. Run it thru Vuex save it to the store… Why? Why? Why?

I have 2 api calls as noted in earlier posts which do everything site wide.

1 for the Vuex store:

async callStore({ commit }, payload) {
    const store = payload.store
    commit(`${store}/setLoading`, true, { root: true })
    try {
      const response = await this.$axios.$request(payload)
      commit(`${store}/setRecords`, response, { root: true })
      return response
    } catch (e) {
      return Promise.reject(e)
    } finally {
      commit(`${store}/setLoading`, false, { root: true })
    }
  },

and one for general api call not needing a store.

async callRemote(payload) {
      this.loading = true
      try {
        const response = await this.$axios.$request(payload)
        return response
      } catch (e) {
        return Promise.reject(e)
      } finally {
        this.loading = false
      }
    }

No fancy api service junk all bloated with post / path / get / delete crap.

I guess I’m just irritated the fact everyone is pushing Vuex as best thing when in reality i think it over used when not needed. All my stores are basic like:

export const state = () => ({
  records: [],
  loading: false,
  meta: {
    selectables: []
  },
  count: 0,
  links: {}
})

But because I fell into the “Vuex store is best” way I now have 25+ identical modules line by line all doing same thing when in reality the store is only ever used for the loading state. Rest never is needed / used and can be done / set direct to component but because i fell into Vuex is god i now have to get info from Vuex when it should just have been set in the component directly.

I know I am going to get hell for this post saying I am using Vuex wrong but when I first started out the questions I asked were answered with use Vuex…ohh yes Vuex yes Vuex put it there…

Not knocking Vuex by any means, it is needed no doubt, I just think there should be a “well written” article / doc on when to use it and when not to. I think saying to anyone and everyone go Vuex is wrong.

Thats my rant… fire away I am waiting for the anger :slight_smile:

Dave

I agree that vuex are not meant to be used in all situation of storing data.

Imo, vuex store is great for centralizing or modularize a set of states that are meant to be used widely in the application, so it’s not specific to certain components.

For your situation, since the data is only used in that component, then it is simpler to handle the data mutation directly in it without any store.

I still use Vuex as a storage of count / edit / loading states since my layout is in need to know that from 1 point to react with outer components. But for the most part what is really shared data wise from component to component?

Login and say hello user name, if changed you can update the greeting in the toolbar perhaps but what is really of value that’s saved and used that you cant just get via server which I say is the real source of truth.

My dashboard (asked on here how to properly fill the component data) so I get my API request with 1 http requesting everything needed, then fill the stores with all the data. And it takes so much longer to fill the stores.
About 110k of data is not a whole lot in 1 shot vs letting each component just fetch it direct from the API with like 15 http requests. The 15 http was 5x faster. And no heavy lifting in Vuex, simply setting the data as is.

I would like to know what people actually put in Vuex and for what reason? Real world scenarios if anyone would like to share.

Thanks,

Dave

1 Like

In my cases, I use vuex store for storing authentication data of the user. It’s more convenient because I need the user data like email, feature, name to be accessed by many components.

Agreed 100%

1 Like

I think one of the main goals of vuex is to provide the one way to do it which is important for team and collaboration.
I don’t use vuex too, but I wrote my own with blackjack and ladies based only on Vue itself.
My Real world scenario from engineering:
suppose we have an assembly of two parts, and we want to calculate the summary of some dimensions of this assembly. The hell starts from here:

  • each part (as well as assembly content) has implementation as revision
  • at any revision any dimension may be changed or inherited from the previous one and also new dimensions may be added or the existing one may be annulled
  • all changes must be inspected/approved, so we have to deal with forks like at GitHub (i.e. we store all user changes in the database as delta-patch and perform merge on the fly with master-fork to show the final result)

I agree with on the fly in 1 spot / sort filter then you need it.
But if it was side situation when you get 1000 records from say a DMV query your not going to drop that in Vuex…

Everyone hypes Vuex run actions via store and use vuex… ohh dont do it from the component, make a service, make a api foolishness

i just think that telling everyone use Vuex for everything with no real documentation. That was my only point in the topic.

Vuex good yes, but used proper = no.
And my guess is since none of the top guys are not saying anything is because they know I am right.

You’ll have a hard time finding any posts by me recommending to “put everything into vuex” (because I never have done that), so yeah, I agree to your basic argument about not putting everything into vuex.

That being said, abstracting your API into its own entitiy rather than doing raw HTTP requests with axios.get() is a good idea in almost any case, wether you consume it from a component or vuex or whatever. It may be unnecessary only if your app has less than a handful apis and no authentication requirements.

What I would be curious about would be this:

I see no reason why that should be faster, especially since vuex doesn’t have a real performance overhead except when doing a lot of mutations with devtools running.

Ok
As best to explain… a user logins in noting vuex related but auth and its basic JWT token and name or email.

directs dashboard which has basically has the site info for the user. You can do anything on the dash from editing skills beers grocery list you name it its all on one page, each component can be rendered down into individual pages or if user wants to max it out make it a full screen modal…
dashboard has like 15 components / widgets all needing data server side. I figured make one http request to get that data need for them and simple commit.

Nothing, no crazy computing functions just commit strait data as it is…Vue dev tools I see the commits work and it takes like 5 seconds, then i say ok let me try on mount each fetch they own… and it lightning fast even making 15 http calls.

112kb of data is not much to fill so i was just curious why Vuex is so hyped… your top dog when it comes to this forum…so i appreciate it when you answer for sure.

Not knocking Vuex I need it for sure and does wonders, my only issue was there should be a well written doc on when to use it as apposed the how to use it… sure every site has different scenarios and case by case usage. Running everything thru Vuex /Service / Api seems like fancy stuff that’s not needed.

I want to know what average person uses Vuex for… thats all no disrespect…

You automatically assume that

  • Everyone experiences this
  • This is because of vuex and not possibly because of devtools (or the HTTP request)
  • and still people “hype” it, despite vuex being “so slow”.

Which is a lot of assumptions extrapolted from your isolated experience.

While I still don’T have any details about what you actually do when committing stuff, my assumption would be that the performance bottleneck is with

a) The HTTP request “combining” 15 requests is inefficiently solved server-side
b) the way in which you commit data produces many small commits which put load on the logging mechanism of vuex.

It’s more likely b), which can again have different reasons:

  1. For a lot of data, devtools slow down because for each single commit, the store is essentially cloned to be able to revert to the previous state for time travelling
  2. Adding to that, some users experience significant performance problems with devtools recently (in v5) that’s not explainable with “1.” and the v4 works fine for them. We still haven’T figured out why that is though. (Related issue)

So Maybe go ahead and test your app with devtools disabled, I would expect performance to be just like with individual calls from components.

Thank you I will try your noted advice…

I do not assume anything I was just wondering it anyone one has / similar issues

Much appreciation for your insight as always :slight_smile:

I will try and let you know results

I get your point mehn…I have felt same way too.
The trick is to use vuex when a particular state needs to be altered or used by more than one component…if not, you do all the logic in the component itself…

I do love Vuex, in no way saying its bad. my point was I think they should have written a good doc on when you use it…as opposed to how to use it. But i guess everyone case is different so you really cant say how to do something on a case by case basis.

Yeah… totally understand!

You guessed it. There’s far too many possible use cases to even try to be opinionated on. Vuex is the tool provided, it’s up to the end user to use it how they see fit. This really just comes down to exposure and experience. As has already been discussed above, I feel similarly and take the same approach - I use it when I know the state is either shared or needs to persist.

My problem with vuex was it felt quite cumbersome. For simple things you are already touching getters, mutations and actions if you want to do it the “right way”. Especially for bigger projects with multiple developers this can easily lead to chaos where some use mutations, some use actions … some use getters, some retrieve states directly … and for what, exactly ? For “time travel” ? I have never needed that feature and I never heard of someone making use of it.

I switched all our vuex stores to the new vue-function-api (or component api as it is now called). This might bite me in the ass since it is not even on the bleeding edge, but past it. It feels great, though !

Well, that’s really a problem of insufficient knowledge and teamwork rather than a problem with Vuex.

1 Like

Nobody’s forcing anyone to use Vuex for all state in their app, if you don’t like it for a scenario just don’t use it.

I use Vuex for all global-ish state that may need to be accessed in other components. For example an admin dashboard that lets you browse through users, drill into individual user details, display charts and graphs on user count, etc. Multiple components on that page need access to the users list, so it’s in Vuex.

For keeping data about whether a button is currently disabled, or whether a pop up is displayed, or the value of some input on a form, I keep all of that right on the component itself in the data() block because no other component will ever feasibly need access to that data and it won’t ever affect any other components.

Vuex is also very nice for debugging compared to keeping all state in components. Using the Vuex logger gives you a chronological log of every action and state change that has occurred in your app, alongside the entire state tree before and after each change, which makes hunting down where and when state changed to some value that’s causing a bug way easier than trying to debug each component’s state separately.

And finally, Vuex’s overhead is (IMO) outweighed by its predictability. More boilerplate code might seem annoying at first, but when you’ve got an app with hundreds of components and thousands of different state values driving the UI and its computed values, doing all of that without Vuex would be a disaster, especially if you were passing data and state down from one component to another to another. Hunting down where a value changed, and what caused it to change, could take days. With Vuex you know exactly where that value lives because it’s only in one place, the Vuex store, and you know exactly what changed it, because it can only be changed by a mutation. This predictability is an absolute requirement for working with large apps, especially when you’ve got multiple ppl working on a code base.

Well, sometimes vuex is really useful, but sometimes it could be headache. Imagine that you only use vuex for modals, and when you pass some data to modal through vuex - boom, you are forced to use vuex in every function. In my case I have big complex class instance with some internal methods and other complex objects inside. This instance holds all data necessary for vue component. I did not used vuex here, be cause if i would, code would be 3-4 times bigger and messy. I don’t need external access to objects that are deep inside this root object. My component childrens are totally isolated in that component scope. But then I decided to use vuex as api layer for that component and guess what: “Do not mutate vuex store state outside mutation handlers”. Once you stored some data on vuex store, you only can manipulate that data through vuex, otherwise your console will be full of red warnings. That’s sucks.

Technically you can use Vuex without strict mode enabled which will allow you to do this. They are just warnings after all. That said, this is part of the purpose of Vuex - to isolate mutations to one single predictable location within your code. Sure this adds a bit of extra wiring which can seem verbose and a lot of the time it does feel like overkill, BUT it really pays off when the app becomes complex and you need to debug things. It’s SO much simpler knowing that the cause is likely coming from one location in your code rather than digging through all the possible areas where an object could be unexpectedly mutated in a component somewhere.

This along with Vue devtools has been a huge time saver for me. Well worth the overhead that Vuex comes with.