I have two Vuex actions that both issue an axios request. I need to call one after the other, however, the second should only be called on the client side.
The first one, let's call it fetchContent is going to give me an object with details about the content that I need to fetch. The second one, fetchAd is going to fetch an ad, and it needs to know the id of the content object.
Due to various constraints, the ad should only be fetched on the client side, so just doing two awaits inside fetch will not.
I also thought about handling fetchContent inside fetch and then calling fetchAd inside mounted, but then I can't be sure by the time the page is mounted I actually have the response from fetchContent.
Another scenario I thought of is to just issue the fetchAd call from inside fetchContent, but there are several different variations of fetchContent and embedding fetchAd in every one of them would yield unnecessary complexity.
What's a clean, best-practice solution here?
Related
Let's say I have a notes app. I want to enable the user to make changes while he is offline, save the changes optimistically in a Mobx store, and add a request to save the changes (on the server) to a queue.
Then when the internet connection is re-established I want to run the requests in the queue one by one so the data in the app syncs with data on the server.
Any suggestions would help.
I tried using react-native-job-queue but it doesn't seem to work.
I also considered react-native-queue but the library seems to be abandoned.
You could create a separate store (or an array in AsyncStorage) for pending operations, and add the operations to an array there when the network is disconnected. Tell your existing stores to look there for data, so you can render it optimistically. Then, when you detect a connection, run the updates in array order, and clear the array when done.
You could also use your existing stores, and add something like pending: true to values that haven't posted to your backend. However, you'll have less control over the order of operations, which sounds like it is important.
As it turns out I was in the wrong. The react-native-job-queue library does work, I just made a mistake by trying to pass a function reference (API call) to the Worker instead of just passing an object that contains the request URL and method and then just implement the Worker to make the API call based on those parameters.
VueJS + Quasar + Pinia + Axios
Single page application
I have an entity called user with 4 endpoints associated:
GET /users
POST /user
PUT /user/{id}
DELETE /user/{id}
When I load my page I call the GET and I save the response slice of users inside a store (userStore)
Post and Put returns the created/updated user in the body of the response
Is it a good practice to manually update the slice of users in the store after calling one of these endpoints, or is better to call the GET immediatly after ?
If you own the API or can be sure about the behavior of what PUT/POST methods return, you can use local state manipulation. Those endpoints should return the same value as what the GET endpoint returns inside. Otherwise, you might end up with incomplete or wrong data on the local state.
By mutating the state locally without making an extra GET request, the user can immediately see the change in the browser. It will also be kinder to your server and the user's data usage.
However, if creating the resource(user, in this case) was a really common operation accessible by lots of users, then calling the GET endpoint to return a slice would be better since it would have more chance to include the new ones that are created by other users. But, in that case, listening to real-time events(i.e. using WebSockets) would be even better to ensure everyone gets accurate and new data in real-time.
My app consumes an self made - HTTP REST API. I use vueX for state management.
I have some nested components that needs access to the same http result as the parent, but I also use the component in other places where the parent does not fetch the result. Is there a way (pattern) to make sure a resource is not fetched multiple times.
I found this, and like the way of doing things, but I can't figure out how to make a new request to the server for updating the result. https://tkacz.pro/use-vuex-to-avoid-multiple-requests-from-different-components/
and is this even best practice ?
anyone has a better way ?
Using vuex and checking if your state is already populated is good enough. If it's not, then call a vuex action. It will help you to have a state shared globally in your app.
Not sure about this part
how to make a new request to the server for updating the result
What would be the issue or calling the API a second time? If needed, you can use the suggested solution in the comment, like adding a ?refresh or even and id to it id={randomId}.
I'm using apollo-client, and I've just noticed that my GraphQL queries don't appear on the list of Network calls when the XHR filter is active.
How is this possible? GQL is just a set of semantics on top of regular old HTTP, right? It's not like a JS library can introduce a whole new networking capability.
In the first image below, you see me filtering for requests with "gra" in them; two appear: the OPTIONS call, and then the POST (which is the real meat). In the second image, I additionally filter by XHRs; the POST is gone.
The "XHR" filter says it captures "XHR and Fetch". The only alternative I can think of would be dynamically adding <script> tags to the document, and I very much doubt that's how apollo-client is managing things.
I don't know what the "json" Type is. The docs for the DevTools don't mention that type.
I think the reason for this is that Chrome's fetch capability is not simply sugar on top of the age-old XMLHttpRequest capability, and the filter option in the DevTools (which says "XHR") is either not built or not designed as an umbrella "asynchronous request" filter. I hope they change that, especially since the Type column in the Network panel can still be used to differentiate between the two.
If I had to speculate, I'd say the behavior we observe flows from the way the Network tab hooks into the underlying networking code, and fetch calls don't travel the relevant portion of the codepath that XHR does. As supporting evidence, I offer this SO answer, which highlights functional differences between XHR & fetch that might readily be explained by their being entirely separate code. (It's also possible some of these differences are a result of the fetch spec explicitly calling for behavior different from XHR.)
Finally, I'd add that we probably only noticed this with Apollo's GQL tools because apollo-client was created in a post-XHR world, and may be one of the first libraries we worked with that prefers fetch over XHR rather than using an XHR polyfill.
I have a component that at creation fires two requests to a RESTful server. Responses are then stored in the Vue Store appropriately.
This component has a computed property that depends on both responses.
But, as designed, any relevant change in the store triggers recomputation of the property and all the consequent updates, for example in the related template.
How would I indicate that the property in fact did not change if only one of the required responses is received and there is no need to do any updates?
The post is from quite a while ago but I was running into the same problem. I have not tried this yet but I believe this to be the solution for this problem:
https://vuex.vuejs.org/en/actions.html#composing-actions
Especially the last part with the async/await example. It makes it clear how you can perform a mutation with multiple async actions.