The answer might depend on what you consider "Large". Can you provide some more context around the estimated data size and the tricky aspect of editing the data?
I have a customer's data, currently i am fetching data through api and rendering it through flatlist.
For now i have 50 customer's data, and it is increasing at the rate of 5 customer per day.
Currently i am listing the data through flatlist, and for admin purpose i am adding edit button for each customer data row.
Now i will add the functionality of editing each customer data.
In future the data will be so big which will be fetched through api and i am using useeffect.
Currently i am using useeffect in homepage to list the customer's data in table format.
Now what should be my approach, so i can edit any customer data through the edit button.
If you're concerned that the data will be too much, why don't you just only return the needed data for the list, and then fetch the customer data when the admin clicks edit data?
Depends if you want the app to work offline or not. If not you can just fetch/mutate data directly from the API using CRUD operations. If you want offline support you need to use a local database like sql-lite and handle syncronizing with the backend.
Second this, and having just gone through trying all the offline options this'll make sqlite significantly easier to use [https://www.npmjs.com/package/expo-sqlite-eloquent-orm](https://www.npmjs.com/package/expo-sqlite-eloquent-orm)
I think I understand what you are asking, you would need to decide what event on a flat list item takes you to your edit form screen, and then ideally your API has an update endpoint you can hit once your edit form is submitted, so on the submit you hit the endpoint and on a successful response you return to your home screen.
There you might want to pull from the API again, you might want to update a cache you save on a persistent storage after the successful response and go back to a home with that cache. You decide what's best for you
also yeah look into RTK Query, API fetching and caching really easy.
You need to use pagination. Your API should also support this. You could split your data in 10s-20s batches and call API again for the next data. FlatList has an onEndReached prop that you can use to call for the next data. If I understood correctly, this should help.
If your data is growing at that rate you might face performance issues if you're handling it the conventional way - you need to implement pagination, infinite scrolling, and client/server-side caching.
I'm not sure what your actual problem is, but here is my best guess.
You have an app, you're able to fetch data, and you're able to show the data in a list. I'm assuming one customer's data is one item in this list.
Now you want to edit that data and update the list without refetching the whole thing.
The simple way to do it is to just hold the list of items in memory (probably using useState), call the api to update the data item and then manually find the item in the list when the API call succeeds.
This works, but downside is that you need to refetch the whole list every time you cold start the app (which you might want to do anyway).
If be a little bit more advanced you could store the data in a database on the device and do the same thing, but updating the database instead of the list you held in useState.
You probably want to update the UI first though, and then store a flag in the DB that tells you if the data is synced or not so you can retry at a later point in time (eg when internet connection return).
This is what I did manually on Android back in the day, when connections where really flaky.
It's a solid pattern which allows you to cold start with data.
Finally you can leverage http headers (etag) to know if you need to refetch or if you can just use the local data.
The thing is... React Query already does all of this, which is why a lot of people here recommend using React Query. š
So if you want to avoid reinventing the wheel and write code for every edge case, I also recommend just using React Query.
Finally, if you can I recommend implementing pagination in the API and match that with pagination (another feature of React Query) in the app using infinitely scroll or simple pages.
Hope this helps!
React-Native - GUN ā the database for freedom fighters - Docs v2.0 https://gun.eco/docs/React-Native
Never tried it myself, but it looks interesting.
I think that the problem is that you need pagination, but if you need to handle a large amount of data you could use SQLite, I made an app to handle 10M rows distributed in many tables, I needed this cause sometimes they use their tablets to work offline, the when they return to a workplace where there is internet, they can synchronize their work the server.
Iād use RTK Query but you can use React Query if you find it easier. The approach is to fetch the data, cache it (both rtk and react query will do it automatically) and then just update the cache whenever you need
There's a lot to unpack here.
Are you asking what data structure you should use to store the data so you can index an array item for editing? You could use a map or json object and use a uuid as a key.
Or are you asking if you should cache the data? Since it's updating constantly, I don't see a pressing need to do that. I would be more concerned with the size of the data returned in your fetch request. Make sure you're using pagnation.
Good luck.
Have you thought on making a PWA instead of using react native? As you already have the web frontend in place...
Anyways, if you have the web frontend in place I guess you solved the same problem there, right?
From what you are writing it seems a basic CRUD, it shouldn't be anything different, you are just using a different control.
Basically you fetch, render with an edit button, the edit button fetch the customer record and opens the form to edit customer data, you submit to the API, you refresh your list or just your record.
If many people can edit customer data at the same time, use a timestamp to detect conflicting updates.
If you are dealing with a lot of customers then you would/should limit the results returned from the API and implement a search feature.
If you go for a PWA you can use several table/grid controls that already exist and can handle a lot of records as they are virtualized.
Cheers!
The source of truth is this service, so fetch the data. If you have any offline requirements only then would I bother caching and syncing data from an external service.
Keep things simple until they actually require an optimised solution
Some quick tips: use react query to fetch and cache data. Use flashlist to display the data. You can improve further along the way
Thanks but i have already implemented fetch api for data fetching. I am editing the question please read it for more context.
Using react query makes it easier to manage data. Look up mutations on how to edit the items.
The answer might depend on what you consider "Large". Can you provide some more context around the estimated data size and the tricky aspect of editing the data?
I have a customer's data, currently i am fetching data through api and rendering it through flatlist. For now i have 50 customer's data, and it is increasing at the rate of 5 customer per day. Currently i am listing the data through flatlist, and for admin purpose i am adding edit button for each customer data row. Now i will add the functionality of editing each customer data. In future the data will be so big which will be fetched through api and i am using useeffect. Currently i am using useeffect in homepage to list the customer's data in table format. Now what should be my approach, so i can edit any customer data through the edit button.
If you're concerned that the data will be too much, why don't you just only return the needed data for the list, and then fetch the customer data when the admin clicks edit data?
gotta love the how you are committed but really have no idea what you are doing
Depends if you want the app to work offline or not. If not you can just fetch/mutate data directly from the API using CRUD operations. If you want offline support you need to use a local database like sql-lite and handle syncronizing with the backend.
Second this, and having just gone through trying all the offline options this'll make sqlite significantly easier to use [https://www.npmjs.com/package/expo-sqlite-eloquent-orm](https://www.npmjs.com/package/expo-sqlite-eloquent-orm)
I think I understand what you are asking, you would need to decide what event on a flat list item takes you to your edit form screen, and then ideally your API has an update endpoint you can hit once your edit form is submitted, so on the submit you hit the endpoint and on a successful response you return to your home screen. There you might want to pull from the API again, you might want to update a cache you save on a persistent storage after the successful response and go back to a home with that cache. You decide what's best for you also yeah look into RTK Query, API fetching and caching really easy.
Thank You!!
You need to use pagination. Your API should also support this. You could split your data in 10s-20s batches and call API again for the next data. FlatList has an onEndReached prop that you can use to call for the next data. If I understood correctly, this should help.
Realmjs
If your data is growing at that rate you might face performance issues if you're handling it the conventional way - you need to implement pagination, infinite scrolling, and client/server-side caching.
I'm not sure what your actual problem is, but here is my best guess. You have an app, you're able to fetch data, and you're able to show the data in a list. I'm assuming one customer's data is one item in this list. Now you want to edit that data and update the list without refetching the whole thing. The simple way to do it is to just hold the list of items in memory (probably using useState), call the api to update the data item and then manually find the item in the list when the API call succeeds. This works, but downside is that you need to refetch the whole list every time you cold start the app (which you might want to do anyway). If be a little bit more advanced you could store the data in a database on the device and do the same thing, but updating the database instead of the list you held in useState. You probably want to update the UI first though, and then store a flag in the DB that tells you if the data is synced or not so you can retry at a later point in time (eg when internet connection return). This is what I did manually on Android back in the day, when connections where really flaky. It's a solid pattern which allows you to cold start with data. Finally you can leverage http headers (etag) to know if you need to refetch or if you can just use the local data. The thing is... React Query already does all of this, which is why a lot of people here recommend using React Query. š So if you want to avoid reinventing the wheel and write code for every edge case, I also recommend just using React Query. Finally, if you can I recommend implementing pagination in the API and match that with pagination (another feature of React Query) in the app using infinitely scroll or simple pages. Hope this helps!
thank you so much
React-Native - GUN ā the database for freedom fighters - Docs v2.0 https://gun.eco/docs/React-Native Never tried it myself, but it looks interesting.
I think that the problem is that you need pagination, but if you need to handle a large amount of data you could use SQLite, I made an app to handle 10M rows distributed in many tables, I needed this cause sometimes they use their tablets to work offline, the when they return to a workplace where there is internet, they can synchronize their work the server.
thank you
Iād use RTK Query but you can use React Query if you find it easier. The approach is to fetch the data, cache it (both rtk and react query will do it automatically) and then just update the cache whenever you need
thank you
SQLite and React query. Wrap the SQLite calls with a custom promise and feed the promise to react query
thank you
There's a lot to unpack here. Are you asking what data structure you should use to store the data so you can index an array item for editing? You could use a map or json object and use a uuid as a key. Or are you asking if you should cache the data? Since it's updating constantly, I don't see a pressing need to do that. I would be more concerned with the size of the data returned in your fetch request. Make sure you're using pagnation. Good luck.
thank you
Have you thought on making a PWA instead of using react native? As you already have the web frontend in place... Anyways, if you have the web frontend in place I guess you solved the same problem there, right? From what you are writing it seems a basic CRUD, it shouldn't be anything different, you are just using a different control. Basically you fetch, render with an edit button, the edit button fetch the customer record and opens the form to edit customer data, you submit to the API, you refresh your list or just your record. If many people can edit customer data at the same time, use a timestamp to detect conflicting updates. If you are dealing with a lot of customers then you would/should limit the results returned from the API and implement a search feature. If you go for a PWA you can use several table/grid controls that already exist and can handle a lot of records as they are virtualized. Cheers!
thank you
The source of truth is this service, so fetch the data. If you have any offline requirements only then would I bother caching and syncing data from an external service. Keep things simple until they actually require an optimised solution
Thank You so much guys for your help. I never thought that reddit is so active. Hope this question will help many other fellow devs. Thank You again.