0

If there is a complex Redux store for determining the states of many components throughout the app.

What is the best pattern for when to save things to the DB? I see pros and cons to different approaches, but I am wondering what is standard for applications with a complex UI?

  • Save the store to DB every time a change is made. (Makes it difficult chasing lots of instant vs. async processes... Either lots of loading states and waiting or juggling the store and the DB separately.)

  • Autosaving every now and then... (Allows the store to instantly determine the UI, faster... With occasional loading states.)

  • Manual saving... Ya, no thanks...

clayton groth
  • 199
  • 2
  • 16
  • Is there a particular reason for you to have to save your redux store into your database? Usually redux store maintains a state of the FE application. You can load data from the database and store it in your redux store, but I don't get the reason of doing the other way around. Also redux store only change when actions are dispatched, so this may be a good trigger to identify when you are going to have a state change. – glneto Nov 04 '19 at 03:08
  • Focusing on DB updates frequency certainly makes a lot of sense. But there is another aspect. Any interaction with DB should generally be asynchronous. Redux doesn't support async code. There are packages that add async capability to Redux. For example redux-saga. – winwiz1 Nov 04 '19 at 06:03
  • Should have added that I am using Thunks to make async action creators. – clayton groth Nov 04 '19 at 20:05

1 Answers1

1

I recommend saving automatically every time a change is made, but use a "debounce" function so that you only save at most every X milliseconds (or whatever interval is appropriate for your situation).

Here is an example of a "debounce" function from lodash: https://lodash.com/docs/#debounce

aaryn101
  • 28
  • 3