I made this autocomplete field that can be filtered by another dropdown field.
On initial load the autocomplete field loads a bunch of data through graphQl.
The problem is the data on initial load is huge and takes a while for this to finish.
On the meantime users can opt to filter this autocomplete list and thus making another request . The filtered request finishes faster and the data from the initial request overwrites the filtered results.
I am already using debounce for this one.
Is there a possible way to cancel the a request done through apollo-client?
thanks
Related
We are using React-Admin v4, and some of our APIs are quite slow. We're using the search input field, and our problem is that api requests can overlap. If there is an existing fetch in progress, typing again doesn't cancel the existing fetch. It fires another one, and the results list is updated when each request returns, leading to confusing UI.
Can we configure the search field to cancel existing fetches when a new one is triggered?
React-admin doesn't implement Query Cancellation, although its underlying data fetching library, react-query, does allow it (see https://react-query-v3.tanstack.com/guides/query-cancellation for details).
So if you want to implement query cancellation in a react-admin filter, you'll have to build your own component based on react-query's useQuery hook, and populate a ListContext with the results. Check the Building a List View By Hand tutorial for guidance.
I have a table that shows a paginated result of large data. Those data are loaded at once. The client wants to have a Save All functionality where only those data that the user added/modified/deleted will passed down to the API.
The table:
Is there a way to only get the data that was added/modified/deleted by the user? I am using Vue2 with Veevalidate and my plan at first is to get only those who are dirty (from veevalidate) but there is no way to do that in Veevalidate. I am not sure now how I can achieve this.
General idea can be accepted.
Within my app there are multiple pages that display a drop down of "clients". The select options are loading via an GET call made in Axios. Every time a page is displayed it makes that get call.
I'm curious if it's better to store those clients in Vuex, and then just load them that way so I don't make a call every time? The only thing I am concerned about is when a new "client" is added the best way to tell the app it needs to make a new get call to update the data in Vuex.
There are many possible solutions to this.
You could use a cache in back-end suchlike Redis, or as you said, cache it in the front-end.
You can abstract this caching with a get function which will check a maximum threshold of cache age.
For example, you can set it to last for 15 minutes. If another request is made before it you could answer with the last obtained data, else it will request the data to the server again.
As I know that, instead of get() I can use onSapshot() for my queries and listen to the changes(additions, deletions, modifications) for that query. But when there are changes, onSnaphot() returns multiple full documents whether modified, deleted or added (a new snapshot). What I want to do is, to check if new documents have been added matching my query and show a notification to the user that there are new records available, and only when a button is clicked, they should be able to fetch and see the new records. I don't want to fetch from the firestore whole sets of documents when there are changes. I just want to know about those changes and fetch on demand. And fetch only the added ones.
How can I do that? Any ideas?
By the way, I am using react-native for my app.
P.S. - I know, I can run the query periodically and check if the id of the first item in the new query matches the first item id in the previous query, and so I can detect the added records and show my notification/button. But I am looking for a more elegant solution. I think the notification should be triggered from the backend instead of polling the backend periodically.
P.S. 2 - Using cloud functions would not seem to be a logical option since these queries will be different for each user of my app. Which would require running thousands of functions (hopefully more) on the firestore. Or would it?
Thanks!
There is no way in the Firestore API to get notified about changes to a query without actually retrieving the changed documents. But you can of course show just a notification to the user when your onSnapshot callback gets called, and then only show the actual data from those documents when the user chooses to refresh the UI.
On a second note, when you use a snapshot listener the Firestore client will only retrieve the modified documents on additional callbacks.
Say you attach a listener for a query that matches 10 documents. On the first onSnapshot callback, you will get 10 documents and will be charged for 10 document reads. Now say that one of the documents changes. When your onSnapshot callback gets invoked for this, you will see 10 documents again, but will be charged only 1 read - for the document that was changed.
If you only want to process the changes, have a look at the documentation on viewing changes between snapshots, which contains a good example of how to do this with the docChanges() method.
I have 50K+ records in my db,I want to add search filter without affecting performance of the application .Please suggest me what approach I should adopt to search the large data.
I am calling api to fetch data from server. And used react native search functionality. But due to large data i have implemented pagination at server side so each time new api being called and new data fetched from server. Now issue is it will search only from fetched page records and i want to search from all 50K+ records. And i want to search for each character typed. So I think it is not fissible to call api at each character typed.
So what is the best approch?
I have a quote finder app which holds 400k quotes on mongodb and I am using Node JS as backend. In my point of view if you are going to search more than 100 items in your front end lets say you are going to use flatlist you can create your searching algoritms in front-end side, than you can dynamically render your list according to search results. 100 items are not a specific limit it is just my idea. Because in lists more data than that would look ugly.
For 50k search you definitely have to come up with search algorithms on server-side. After you get your search data you can use
https://github.com/UnPourTous/react-native-search-list
And if your specific aim is to search on server-side I would recommend elastic-search.
But for 50k data it is better you implement your own algoritms. When you send fetch request let your server run the search and in response get the data you want.
You can use redux for this situation. When you start your application get all records(50+K) from server it will take time(You can get records in splashscreen) based on your server and store all records in redux store. Now you can search data from your redux store so don't need to call API on every search.
Make sure your server send only those data in response which you required to show in mobile application. So for getting records it will reduce response time.
You can use redux-search for this.