3 ms·

You'd honestly be better off rewriting it. And if that's a huge ask, you need to seriously reconsider what is 'global state' in your app. You state management

You'd honestly be better off rewriting it. And if that's a huge ask, you need to seriously reconsider what is 'global state' in your app. You state management shouldn't really have all your api calls in it. Especially if you're worried about cross platform, put your api interface code into a library, call that from components or your state management. If you find your state management code seems to exist only to call out to your api, it's probably not global state in the first place. Approximately 90% of the time, when people are posting questions about VueX, my first thought, is 'that really doesn't seem like global state'

williamdclt 7y ago
I don't think I get it, what do you use global state for? And what do you use to query your API and store responses then? Most of the time yeah I do use Redux (sagas) to query my API and store the result. Many of my components need access to the same data (who's the current user, what's their list of items, what's the current item being looked at...), so it's at least shared state if not global
- ehutch79 7y ago
  It's super dependant on the app. however, abstracting your api calls to a single library is helpful for any app beyond the most simple todo app. Things like the current user are 100% global state. A list of user settings, or valid values for a dropdown that doesn't change often (like a list of timezones, or countries), totally global state. A list of objects only shown on one page or in one component? That component can call an api library for the data itself. State of a component? Definitely not global scope. Specific example; virtual scroll for a table. storing the offset as global scope. As soon as a second instance of the component was loaded on the same page there would be major issues. Data that gets paginated should probably not be in global state, or cached heavily, depending on the app. A couple dozen entries is fine, but the idea of pulling every record in a list from say, an erp app, and then paginating in memory, would wreak havoc on a user's browser. And you're keeping that in the browsers session memory. Not to mention ramifications on the backend, even if it is cached. and then you need to deal with cache invalidation, and then...

williamdclt 7y ago

I don't think I get it, what do you use global state for? And what do you use to query your API and store responses then? Most of the time yeah I do use Redux (sagas) to query my API and store the result. Many of my components need access to the same data (who's the current user, what's their list of items, what's the current item being looked at...), so it's at least shared state if not global

ehutch79 7y ago
It's super dependant on the app. however, abstracting your api calls to a single library is helpful for any app beyond the most simple todo app. Things like the current user are 100% global state. A list of user settings, or valid values for a dropdown that doesn't change often (like a list of timezones, or countries), totally global state. A list of objects only shown on one page or in one component? That component can call an api library for the data itself. State of a component? Definitely not global scope. Specific example; virtual scroll for a table. storing the offset as global scope. As soon as a second instance of the component was loaded on the same page there would be major issues. Data that gets paginated should probably not be in global state, or cached heavily, depending on the app. A couple dozen entries is fine, but the idea of pulling every record in a list from say, an erp app, and then paginating in memory, would wreak havoc on a user's browser. And you're keeping that in the browsers session memory. Not to mention ramifications on the backend, even if it is cached. and then you need to deal with cache invalidation, and then...