In a chat application should pagination be implement in react native flatlist for chat list and messages list?
when and by how much can we see the performance benefits?
I tried loading array of 250 with(limiting 25 items per call) and without pagination I did not see any performance benefit react native flatlist handled both cases without performance hits.
I was expecting list with pagination to load faster.
Will pagination be beneficial for lets say 1000 item in a list?
Pagination is mostly about API support and optimization working with a network. For example, you have a cache on your API side for the last 10 items and it makes sense to show users the first time only these 10 items. For pagination, we use onEndReached.
If you are talking about UI performance you need to check the options initialNumToRender and maxToRenderPerBatch. From documentation:
The maximum number of items to render in each incremental render batch. The more rendered at once, the better the fill rate, but responsiveness may suffer because rendering content may interfere with responding to button taps or other interactions.
Also, don't forget about key list optimization:
Use Key Extractor
Avoid anonymous functions
Memoize expensive component
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'm designing a website with a REST API using Django Rest Framework and Vue for the front end and I'm trying to work out what the proper way to do filtering is.
As far as I can see, I can either:-
a) Allow filtering via the API by using URL parameters like /?foo=bar
or
b) Do all the filtering on the Vue side by only displaying the items that are returned that have foo=bar
Are there any strong reasons for doing one over the other?
The real answer to this question is "it depends".
Here are a few questions to ask yourself to help determine what the best approach is:
How much data will be returned if I don't filter at the API level?
If you're returning just a few records, there won't be a noticeable performance hit when the query runs. If you're returning thousands, you'll likely want to consider server side querying/paging.
If you're building an application where the amount of data will grow over time, it's best to build the server side querying from the get-go.
What do I want the front-end experience to be like?
For API calls that return small amounts of data, the user experience will be much more responsive if you return all records up front and do client-side filtering. That way if users change filters or click through paged data, the UI can update almost instantaneously.
Will any other applications be consuming my API?
If you plan to build other apps that consume the API, you may want to build the filtering at the API level so you don't need to recreate front-end filtering logic in every consuming application.
Hopefully these questions can help guide you to the best answer for your use case.
Whenever I come across this issue I ask myself just one question: How many items are you working with? If you're only returning a few items from the API you can easily do the filtering on the front-end side and save yourself a bunch of requests whenever the results are filtered. Also, if the result set is quite small, it's a lot faster to do it this way rather than sending off a request every time the filters change.
However, if you're working with a very large number of items, it's probably best to just filter them out in the API, or even via your database query if that's what you're working with. This will save you from returning a large number of results to the front-end. Also, filtering large numbers of items on the front-end can significantly impact performance since it usually involves looping over a collection.
I have an app in which I want to show a list of around 19000 products. You can search this list and you can filter it by categories. I added paging for my API where the data comes from and I plan on using LoadMore for React FlatList. Now, when I type a search-query inside the search-bar, I want to search within all the data, not the filtered data. Where should I perform the search then? Should i either load all 19000 Items from the API, store them locally and search it? Then the paging would be kind of unnecessary.. Or should I send the search-term to the API and handle the search there? The latter also seems kind of inperformant, because It would send an API-Request every moment I type a letter to the search-bar. Or is there a third approach? What would be the proper way for this?
Thanks in Advance.
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.
Let's say I have this blog app. There are posts, pages, menu, and user login.
One way to load the entire application state is to have one api call which will include posts, total number of pages for pagination, menu items and current user state.
The second way would be to have multiple API called, one for each component. So one call for posts and pages, one for menu and one for current user.
Which would be best strategy given the fact react is built around components?
I'll add my 2 cents as answer but still wanting to close as primarily opinion based.
The way I structure my React apps is to have a top level components called Screens or URLs, ie., /list-users should map against the ListUsersScreen component.
In said screen I declare a static method called fetchData, this method returns an object which values are Promises.
{
users: fetchUsersAction(),
someOtherApiData: fetchSomeOtherAPIData()
}
This lends well to both pure client apps and universal apps, as well.
On your server side you'd have to wait until all Promises resolves until you can render something.
Furthermore you can easily cache the values in your application state object and decide if you want to fetch new data or render stale data, also it saves on bandwidth for your user since the user might or might not decide to continue browsing your site.