2

I am working on a product where I am using ReactJS for front-end. I am getting a huge amount of data(in thousands) in the form of a list, on API response which I want to store locally. So what should I prefer in this scenario, LocalStorage or Redux?

I am confused since the amount of data is very large and I think storing it on redux-store may lead to some performance issue.

GAJESH PANIGRAHI
  • 1,204
  • 10
  • 17
  • Besides just storing the data, what are you doing with it? – AnilRedshift May 21 '18 at 06:18
  • 2
    `localStorage` has storage limits. Though really, you shouldn't be storing huge amounts of data on the client-side at all. Do the data heavy stuff server side and send only the results or important parts to the client side. If you're talking about a huge list of data (like thousands of results from some kind of search) then you should have a pagination setup, where only small batches of them are loaded at any one time on the client side. – Jayce444 May 21 '18 at 06:26
  • @Jayce444 is right about localStorage, it has memory restrictions depending on browser. If u work with really big project, use redux or mobx for example. – Vasyl Gutnyk May 21 '18 at 14:29

2 Answers2

2

Personally, I don't find thousands of items in a list will cause much performance trouble to Redux store. Instead, when using redux to store large list, take following problems into consideration:

  1. Do you really need that much of data in one go? Common list display such as pagination list or infinite scroll only take a portion of data each time. If you don't need to render DOM for all data in list at once, consider to paginate the data in backend, and send to frontend the exact amount of data in list to display.

  2. How do you store your list? Redux recommends data normalization, in order to improve performance. Array is the last structure you want to store your list if the app queries and displays the list frequently.

  3. How do you take out your list from redux store for DOM rendering? This is crucial if you need to update items in list frequently. Here is an excellent solution which breaks down what you can do to handle this case.

blaz
  • 3,981
  • 22
  • 37
  • Any performance issue in the system(Like memory, CPU etc) if I store thousands of data in redux-store? I know how to handle it on the view page. I want to just know any issue if I store a thousand rows of data in the redux store. – GAJESH PANIGRAHI May 21 '18 at 10:25
  • @GAJESHPANIGRAHI redux store also has data limit. It will give out of memory if limit exceeds. – Sourabh Bhutani Sep 28 '19 at 07:23
1

Localstorage is (usually) limited to 5mb or less of storage space, so if you are storing data that serializes to > 5mb, then localstorage isn't an option.

Generally, your performance will suffer as you try to iterate through the data, or change the DOM based on it. Generally, I think you're looking for an answer to the wrong question.

Instead, consider what is the best way to display large amounts of data to the user?

If the answer to that is to have pagination, then you've solved your data problem as you can load the calls per-view. Same with infinite scrolling. If you need to optimize your backend load, you can add a backend caching layer, etc.

AnilRedshift
  • 7,937
  • 7
  • 35
  • 59
  • I am looking, where I should store the data, If I will store huge amount of data in redux-store then any issue with the system performance? – GAJESH PANIGRAHI May 21 '18 at 06:39
  • 1
    I agree with this answer. You need to ask what is the use case for thousands of rows of data. Does it need to be fetched all at one go? If yes, then why? If there are multiple apis, result of which accumulates to thousands of rows of data, then your question would be how to optimize the api calls. – Aseem Upadhyay May 21 '18 at 06:54
  • Any performance issue in the system(Like memory, CPU etc) if I store thousands of data in redux-store? I know how to handle it on the view page. I just want to know any issue if I store a thousand rows of data in the redux store. – GAJESH PANIGRAHI May 21 '18 at 10:36